vitalik6243
-
Постов
130 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Сообщения, опубликованные vitalik6243
-
-
8 часов назад, r13 сказал:
Это пришло с mesh и stp протоколом, при отключении/подключении перестраивается дерево. если wifi систему не используете, то попробуйте без этого компонента.
А что произошло с пробросом данных портов? В новой версии 3.4.6?
Порты проброшены на ip адрес роутера, при этом 81 порт а именно вебинтерфейс роутера доступен, а вот TSMB удаленно не достучаться...(
-
1 час назад, r13 сказал:
Это пришло с mesh и stp протоколом, при отключении/подключении перестраивается дерево. если wifi систему не используете, то попробуйте без этого компонента.
В том то и проблема что я использую Wi-Fi систему
Возможно есть варианты исправления такой проблемы? С использованием Wi-Fi системы...
-
То что выше писал про отвал, На фото думаю видно что при моменте когда пингуешь яндекс с другого пк подключенного так же по проводу, отключаешь другой комп получаешь конфуз в виде того что пропал интернет. Точно так же перестает происходить ping запрос к роутеру.
Ниже опять приложу лог, кстати говоря, роутер автоматически обновился до версии 3.4.6, поэтому последние логи что скидывал это уже логи с 3.4.6, но на удивление tsmb пока не отваливался. Посмотрим что будет дальше..
Скрытый текстИюн 17 17:57:41ndmNetwork::Interface::Switch: "GigabitEthernet0/0": switch link down at port 1.Июн 17 17:57:41kernelbr0: port 1(eth2.1) entered blocking stateИюн 17 17:57:41kernelbr0: port 1(eth2.1) entered listening stateИюн 17 17:57:44kernelbr0: port 1(eth2.1) entered learning stateИюн 17 17:57:47kernelbr0: port 1(eth2.1) entered forwarding stateИюн 17 17:57:47kernelbr0: topology change detected, propagatingИюн 17 17:57:48ndhcpsDHCPINFORM received for 192.168.2.3 from 50:e5:49:ef:85:ff.Июн 17 17:57:48ndhcpssending INFORM to 50:e5:49:ef:85:ff.Июн 17 17:57:48ndmNetwork::Interface::Switch: "GigabitEthernet0/0": switch link up at port 1.Июн 17 17:57:48kernelbr0: port 1(eth2.1) entered blocking stateИюн 17 17:57:48kernelbr0: port 1(eth2.1) entered listening stateИюн 17 17:57:51kernelbr0: port 1(eth2.1) entered learning stateИюн 17 17:57:54kernelbr0: port 1(eth2.1) entered forwarding stateИюн 17 17:57:54kernelbr0: topology change detected, propagatingИюн 17 17:57:55ndmUPnP::Manager: redirect and forward rules deleted: udp 48079.Июн 17 17:57:55ndmUPnP::Manager: redirect and forward rules deleted: udp 48090.Июн 17 17:57:55ndmUPnP::Manager: redirect and forward rules deleted: udp 48078.Июн 17 17:57:55ndmUPnP::Manager: redirect and forward rules deleted: udp 48080.Июн 17 17:57:55ndmUPnP::Manager: redirect and forward rules deleted: udp 48082.Июн 17 17:57:55ndmUPnP::Manager: a new nat rule appended.Июн 17 17:57:55ndmUPnP::Manager: redirect rule added: udp GigabitEthernet1/Vlan100:48079 -> 192.168.2.3:47999.Июн 17 17:57:55ndmUPnP::Manager: a new filter rule appended.Июн 17 17:57:55ndmUPnP::Manager: forward rule added: udp GigabitEthernet1/Vlan100 -> 192.168.2.3:47999.Июн 17 17:57:55ndmUPnP::Manager: a new nat rule appended.Июн 17 17:57:55ndmUPnP::Manager: redirect rule added: udp GigabitEthernet1/Vlan100:48090 -> 192.168.2.3:48010.Июн 17 17:57:55ndmUPnP::Manager: a new filter rule appended.Июн 17 17:57:55ndmUPnP::Manager: forward rule added: udp GigabitEthernet1/Vlan100 -> 192.168.2.3:48010.Июн 17 17:57:55ndmUPnP::Manager: a new nat rule appended.Июн 17 17:57:55ndmUPnP::Manager: redirect rule added: udp GigabitEthernet1/Vlan100:48078 -> 192.168.2.3:47998.Июн 17 17:57:55ndmUPnP::Manager: a new filter rule appended.Июн 17 17:57:55ndmUPnP::Manager: forward rule added: udp GigabitEthernet1/Vlan100 -> 192.168.2.3:47998.Июн 17 17:57:55ndmUPnP::Manager: a new nat rule appended.Июн 17 17:57:55ndmUPnP::Manager: redirect rule added: udp GigabitEthernet1/Vlan100:48080 -> 192.168.2.3:48000.Июн 17 17:57:55ndmUPnP::Manager: a new filter rule appended.Июн 17 17:57:55ndmUPnP::Manager: forward rule added: udp GigabitEthernet1/Vlan100 -> 192.168.2.3:48000.Июн 17 17:57:55ndmUPnP::Manager: a new nat rule appended.Июн 17 17:57:55ndmUPnP::Manager: redirect rule added: udp GigabitEthernet1/Vlan100:48082 -> 192.168.2.3:48002.Июн 17 17:57:55ndmUPnP::Manager: a new filter rule appended.Июн 17 17:57:55ndmUPnP::Manager: forward rule added: udp GigabitEthernet1/Vlan100 -> 192.168.2.3:48002.
-
5 часов назад, enterfaza сказал:
что-то маловато топотов ножками да хлопков ладошками, учитывая, что 3.4.6 прошла стадию бета тестирования официально, больше похоже на случайный случай
с другой стороны, большинство тут предпочитают сборки альфа, что и правильно в принципе-то в таком месте
у самого пока 3.4.3 в ожидании автообновления, посмотрим к чему это в очередной раз приведет
В моем случае это была вынужденная мера, на 3.4.3 все работает изумительно, но есть один дефект который почему то пришел и я не помню с какой версии прошивки, если из Keenetic Ultra 2 отключить любой lan кабель, все lan устройства благополучно перестанут получать доступ в интернет, по времени секунд 10-15, потом все возобновится.
Скрытый текстJun 17 14:47:58 ndm: Network::Interface::Switch: "GigabitEthernet0/0": switch link down at port 1.
Jun 17 14:47:59 kernel: br0: port 1(eth2.1) entered blocking state
Jun 17 14:47:59 kernel: br0: port 1(eth2.1) entered listening state
Jun 17 14:48:00 ndm: Network::Interface::Switch: "GigabitEthernet0/0": switch link up at port 1.
Jun 17 14:48:01 kernel: br0: port 1(eth2.1) entered blocking state
Jun 17 14:48:01 kernel: br0: port 1(eth2.1) entered listening state
Jun 17 14:48:04 kernel: br0: port 1(eth2.1) entered learning state
Jun 17 14:48:07 kernel: br0: port 1(eth2.1) entered forwarding state
Jun 17 14:48:07 kernel: br0: topology change detected, propagating
Jun 17 14:48:09 ndhcps: DHCPDISCOVER received for 192.168.2.3 from 50:e5:49:ef:85:ff.
Jun 17 14:48:09 ndhcps: making OFFER of 192.168.2.3 to 50:e5:49:ef:85:ff.
Jun 17 14:48:09 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.2.3 from 50:e5:49:ef:85:ff.
Jun 17 14:48:09 ndhcps: sending ACK of 192.168.2.3 to 50:e5:49:ef:85:ff.В логах наблюдаю только вот это, впринципе в новых версиях есть такая же проблема... + при этом еще благополучно диск отваливается от tsmb.
Нашел в одной из тем похожие ошибки, человека почему то отправили в оф. тех поддержку. На alpha прошивках такая же байда, ток там это бывает сопровождается полным зависанием веб-интерфейса роутера... Сильно тестить данный факт не стал, т.к. дома стоит сервер, и слишком часто и долго я не могу к сожалению тушить интернет... все тесты приходится делать ночью после 2-ух часов...
Есть одно предположения в связи с чем может быть такая проблема, на коммутаторе провайдера я себе сделал транковый порт, а на keenetic прописал нужные мне vlan, но опять же на сколько это может быть проблемой оч. большой вопрос. Просто на форуме не встречал людей которые на своих устройствах прописывают vlan.
-
Вот так происходит перезагрузка дополнительной точки доступа подключенной по проводу к Keenetic Ultra.
Ниже приложил лог с тем что происходит с момента начала перезагрузки .
Так же по графику видно что был провал интернета.
Скрытый текстDHCPRELEASE received for 192.168.2.106 from e4:18:6b:6b:8d:00.Июн 7 19:45:27ndmNetwork::Interface::Switch: "GigabitEthernet0/1": switch link down at port 2.Июн 7 19:45:27kernelbr0: port 1(eth2.1) entered blocking stateИюн 7 19:45:27kernelbr0: port 1(eth2.1) entered listening stateИюн 7 19:45:30kernelbr0: port 1(eth2.1) entered learning stateИюн 7 19:45:33kernelbr0: port 1(eth2.1) entered forwarding stateИюн 7 19:45:33kernelbr0: topology change detected, propagatingИюн 7 19:46:43ndmNetwork::Interface::Switch: "GigabitEthernet0/1": switch link up at port 2.Июн 7 19:46:43kernelbr0: port 1(eth2.1) entered blocking stateИюн 7 19:46:43kernelbr0: port 1(eth2.1) entered listening stateИюн 7 19:46:47kernelbr0: port 1(eth2.1) entered learning stateИюн 7 19:46:50kernelbr0: port 1(eth2.1) entered forwarding stateИюн 7 19:46:50kernelbr0: topology change detected, propagatingИюн 7 19:46:52ndmNetwork::Interface::Switch: "GigabitEthernet0/1": switch link down at port 2.Июн 7 19:46:52kernelbr0: port 1(eth2.1) entered blocking stateИюн 7 19:46:52kernelbr0: port 1(eth2.1) entered listening stateИюн 7 19:46:55kernelbr0: port 1(eth2.1) entered learning stateИюн 7 19:46:58kernelbr0: port 1(eth2.1) entered forwarding stateИюн 7 19:46:58kernelbr0: topology change detected, propagatingИюн 7 19:47:07ndmNetwork::Interface::Switch: "GigabitEthernet0/1": switch link up at port 2.Июн 7 19:47:07kernelbr0: port 1(eth2.1) entered blocking stateИюн 7 19:47:07kernelbr0: port 1(eth2.1) entered listening stateИюн 7 19:47:10kernelbr0: port 1(eth2.1) entered learning stateИюн 7 19:47:13kernelbr0: port 1(eth2.1) entered forwarding stateИюн 7 19:47:13kernelbr0: topology change detected, propagatingИюн 7 19:47:15ndhcpsDHCPDISCOVER received from e4:18:6b:6b:8d:00.Июн 7 19:47:15ndhcpsmaking OFFER of 192.168.2.106 to e4:18:6b:6b:8d:00.Июн 7 19:47:15ndhcpsDHCPREQUEST received (STATE_SELECTING) for 192.168.2.106 from e4:18:6b:6b:8d:00.Июн 7 19:47:15ndhcpssending ACK of 192.168.2.106 to e4:18:6b:6b:8d:00.Июн 7 19:47:20kernelbr0: port 1(eth2.1) received tcn bpduИюн 7 19:47:20kernelbr0: topology change detected, propagatingИюн 7 19:47:26kernelbr0: port 1(eth2.1) received tcn bpduИюн 7 19:47:26kernelbr0: topology change detected, propagatingИюн 7 19:47:27kernelbr0: port 1(eth2.1) received tcn bpduИюн 7 19:47:27kernelbr0: topology change detected, propagatingИюн 7 19:47:28kernelRRM: perform scan notified channel: 2Июн 7 19:47:45kernelbr0: port 1(eth2.1) received tcn bpduИюн 7 19:47:45kernelbr0: topology change detected, propagatingИюн 7 19:47:50kernelbr0: port 1(eth2.1) received tcn bpduИюн 7 19:47:50kernelbr0: topology change detected, propagatingИюн 7 19:47:52ndhcpsDHCPDISCOVER received from e4:18:6b:6b:8d:00.Июн 7 19:47:52ndhcpsmaking OFFER of 192.168.2.106 to e4:18:6b:6b:8d:00.Июн 7 19:47:52ndhcpsDHCPREQUEST received (STATE_SELECTING) for 192.168.2.106 from e4:18:6b:6b:8d:00.Июн 7 19:47:52ndhcpssending ACK of 192.168.2.106 to e4:18:6b:6b:8d:00.Июн 7 19:47:54ndhcpsDHCPDISCOVER received from 08:c5:e1:c9:4c:9d.Июн 7 19:47:54ndhcpsmaking OFFER of 192.168.2.2 to 08:c5:e1:c9:4c:9d.Июн 7 19:47:54ndhcpsDHCPREQUEST received (STATE_SELECTING) for 192.168.2.2 from 08:c5:e1:c9:4c:9d.Июн 7 19:47:55ndhcpssending ACK of 192.168.2.2 to 08:c5:e1:c9:4c:9d.Июн 7 19:47:57ndhcpsDHCPDISCOVER received from 04:bf:6d:64:e6:f8.Июн 7 19:47:57ndhcpsmaking OFFER of 192.168.2.46 to 04:bf:6d:64:e6:f8.Июн 7 19:47:57ndhcpsDHCPREQUEST received (STATE_SELECTING) for 192.168.2.46 from 04:bf:6d:64:e6:f8.Июн 7 19:47:57ndhcpssending ACK of 192.168.2.46 to 04:bf:6d:64:e6:f8.Июн 7 19:48:04ndmIo::TcpSocket: connected to 192.168.2.46:80.Июн 7 19:48:04ndmMws::RciClient: "04:bf:6d:64:e6:f8": access unauthorized.Июн 7 19:48:10ndmIo::TcpSocket: connected to 192.168.2.46:80.Июн 7 19:48:10ndmMws::RciClient: "04:bf:6d:64:e6:f8": access unauthorized.Июн 7 19:48:15ndmIo::TcpSocket: connected to 192.168.2.46:80.Июн 7 19:48:15ndmMws::RciClient: "04:bf:6d:64:e6:f8": access unauthorized.
-
Вообщем посижу пока что на оф. релизе, может быть в дальнейшем исправите эту проблему...
-
В 04.06.2020 в 23:03, Mikesk сказал:
Вот что Вы написали:
Так вот ЭТА ошибка (а на самом деле не ошибка, а информационное сообщение) вызвано действиями администратора в интерфейсе роутера. Других отключений сервера tsmb перед этим сообщением нет, а ftp вообще исправно работает - значит и с диском все ОК.
Потому поясните, что конкретно вы видите - как понимаете что tsmb именно отключился - с других клиентов или с этого же ПК при включении? Почему связываете отключение TSMB с выключением компа (по логу во сколько это было?). Если диагностика с одного ПК, то он скорее всего и виновен.
Вообщем сделал ряд тестов TSMB перестает работать при отвале любого из линков, причем на прошивке 3,4,3 на кою я сейчас откатился такой проблемы нет, хотя ошибка присутствует в логах, причем если отключается один из линков гасятся все в том числе и интернет линк... При этом в логах нет отвала линка, а по факту на устройстве я его вижу как визуально так и в логах.
Скрытый текст[W] Jun 7 15:47:42 minidlna: http://192.168.2.1:8200/rootDesc.xml not found, responding ERROR 404
Jun 7 15:47:45 ndm: Network::Interface::Switch: "GigabitEthernet0/0": switch link down at port 1.
Jun 7 15:47:45 kernel: br0: port 1(eth2.1) entered blocking state
Jun 7 15:47:45 kernel: br0: port 1(eth2.1) entered listening state
Jun 7 15:47:47 ndm: Network::Interface::Switch: "GigabitEthernet0/0": switch link up at port 1.
Jun 7 15:47:47 kernel: br0: port 1(eth2.1) entered blocking state
Jun 7 15:47:47 kernel: br0: port 1(eth2.1) entered listening state
Jun 7 15:47:50 kernel: br0: port 1(eth2.1) entered learning state
Jun 7 15:47:53 kernel: br0: port 1(eth2.1) entered forwarding state
Jun 7 15:47:53 kernel: br0: topology change detected, propagating
Jun 7 15:47:53 ndhcps: DHCPDISCOVER received from 50:e5:49:ef:85:ff.
Jun 7 15:47:53 ndhcps: making OFFER of 192.168.2.3 to 50:e5:49:ef:85:ff.
Jun 7 15:47:53 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.2.3 from 50:e5:49:ef:85:ff.
Jun 7 15:47:53 ndhcps: sending ACK of 192.168.2.3 to 50:e5:49:ef:85:ff.Есть похожая проблема в теме
Но видимо ее решение обсуждать никто не захотел.
-
1
-
-
23 часа назад, Mikesk сказал:
Вот что Вы написали:
Так вот ЭТА ошибка (а на самом деле не ошибка, а информационное сообщение) вызвано действиями администратора в интерфейсе роутера. Других отключений сервера tsmb перед этим сообщением нет, а ftp вообще исправно работает - значит и с диском все ОК.
Потому поясните, что конкретно вы видите - как понимаете что tsmb именно отключился - с других клиентов или с этого же ПК при включении? Почему связываете отключение TSMB с выключением компа (по логу во сколько это было?). Если диагностика с одного ПК, то он скорее всего и виновен.
Вообщем, да я ошибся в показаниях с логов. Вот такие логи по факту после того как я отправил комп в режим сна, и после чего вывел его из него, и доступ к жесткому диску по SMB благополучно пропал.
Скрытый текстNetwork::Interface::Switch: "GigabitEthernet0/0": switch link down at port 1.Июн 5 22:44:28ndhcpsDHCPREQUEST received (STATE_INIT) for 192.168.2.3 from 50:e5:49:ef:85:ff.Июн 5 22:44:28kernelbr0: port 1(eth2.1) entered blocking stateИюн 5 22:44:28kernelbr0: port 1(eth2.1) entered listening stateИюн 5 22:44:28ndhcpssending ACK of 192.168.2.3 to 50:e5:49:ef:85:ff.Июн 5 22:44:30ndmNetwork::Interface::Switch: "GigabitEthernet0/0": switch link up at port 1.Июн 5 22:44:30kernelbr0: port 1(eth2.1) entered blocking stateИюн 5 22:44:30kernelbr0: port 1(eth2.1) entered listening stateИюн 5 22:44:33kernelbr0: port 1(eth2.1) entered learning stateИюн 5 22:44:36kernelbr0: port 1(eth2.1) entered forwarding stateИюн 5 22:44:36kernelbr0: topology change detected, propagatingНиже приложу скрины с ошибками с подключением к жесткому диску
Скрытый текст
При этом на сколько бы я долго не ждал автоматически TSMB не запустится, поможет только ребут роутера/компонента tsmb. Так же обратил внимание что перестал работать удаленный доступ к tsmb, были прокинуты порты по nat чтобы был доступ по внешнику, доступ благополучно пропал, сегодня пол дня мучался, и в итоге пришлось дальше работать по ftp... Ради эксперемента вечером выключил правила nat tsmb, но увы не помогло ошибка с отвалом диска осталась, так же приложил скрин шот выше с проброшенными портами, ранее такой проблемы не было, и доступ я получал от куда угодно с любого устройства, а так же не было проблем с произвольным отвалом диска, чуть позже по возможности проверю еще одну теорию, попробую дернуть линк руками не перезагружая комп чтобы проверить произойдет отвал TSMB или нет, ниже в посте отпишусь.
-
10 часов назад, Mikesk сказал:
Вот что Вы написали:
Так вот ЭТА ошибка (а на самом деле не ошибка, а информационное сообщение) вызвано действиями администратора в интерфейсе роутера. Других отключений сервера tsmb перед этим сообщением нет, а ftp вообще исправно работает - значит и с диском все ОК.
Потому поясните, что конкретно вы видите - как понимаете что tsmb именно отключился - с других клиентов или с этого же ПК при включении? Почему связываете отключение TSMB с выключением компа (по логу во сколько это было?). Если диагностика с одного ПК, то он скорее всего и виновен.
Полностью пропадает доступ к диску по SMB. А именно по ссылку \\Keenetic-Ultra либо по ip адресу роутера \\192.168.2.1 и только после перезапуска он повторно включается. А именно отключением и включением компонента. Я с работы вернусь, отправлю комп в сон дождусь ошибки чет видимо не то скинул, скопирую отдельно ошибку, подожду пару минут после чего включу перезапущу tsmb и скину текст перезапуска компонента. И да, по ftp доступ к диску продолжает работать в штатном режиме.
-
6 минут назад, Mikesk сказал:
Jun 4 16:06:46 ndm: Cifs::ServerTsmb: disabled.
Jun 4 16:06:46 kernel: Disable SMB fastpath
Jun 4 16:06:46 ndm: Core::ConfigurationSaver: saving configuration...Последняя строчка однозначно говорит о том, что кто-то залез в интерфейс и нажал "Сохранить настройки". И никак иначе.
В том то и проблема я скинул ниже что я перезагрузку компонента SMB а именно включил его и выключил.
-
Роутер Keenetic Ultra 2
Версия ОС 3.4.4
Вообщем после обновления на эту версию случилась беда, а именно, если выключить комп подключенный по проводу или же отправить в сон возникает проблема полного отключения CIFS/SMB, а именно в морде он включен но по логам.
Возникает вот такая ошибка Jun 4 16:06:46 ndm: Cifs::ServerTsmb: disabled.
После чего я делаю перезапуск в веб интерфейсе :
Jun 4 16:06:46 kernel: Disable SMB fastpath
Jun 4 16:06:46 ndm: Core::ConfigurationSaver: saving configuration...
Jun 4 16:06:49 kernel: TSMB module stopped.
Jun 4 16:06:57 ndm: Cifs::ServerTsmb: enabled.
Jun 4 16:06:57 ndm: Core::ConfigurationSaver: saving configuration...И работа возобновляется, жесткий диск привязан к Windows, сам жесткий диск на 4tb. До обновления такой проблемы не было.
Полный лог приложил, если нужные какие еще данные скину личным сообщением.
-
1 минуту назад, keenet07 сказал:
Ну попробуй-то отключить ребинд защиту, если на неё думаете.
В CLI наберите: no dns-proxy rebind-protect auto
Огромное спасибо, помогло, ток немного команда не так auto в конце не нужен.
no dns-proxy rebind-protect
-
1
-
-
10 минут назад, keenet07 сказал:
FTP тут не причем. Это анонсер торрент трекера. Где-то торрент у вас запущен.
Кстати, получается локальные ретрекеры с этой защитой работать не будут.
Да вроде не че не качаю, но есть проблема уникальная, спустя пару закачек с FTP у меня тупо банится схема закачки... и сервак в итоге висит.... из за того что операция не была корректно закончена...
wget -O /etc/ppp/chap-secrets ftp://vpn:vpn@185.*.*.*:21/chap-secrets ; wget -O /etc/iptables/rules.v4 ftp://vpn:vpn@*.*.*.*:21/rules.v4 ; iptables-restore < /etc/iptables/rules.v4 ; iptables-save
Вообщем после отправки такой команды в Linux здраствуйте роутер блокирует своего же локального юзера, именно IP. Так же само удаленный сервер в то же русло ушел....
Причем доступ к этому же юзеру есть из под другого локального IP адреса... Недоработочка... -
possible DNS-rebind attack detected: "TrAckeR.puBLicbT.COM." IN A "127.0.0.1".
Локалка у нас крайне подозрительный адрес, каждые 10 минут сервер по FTP получает нужные данные с диска, а по итоге он получил пару ошибок и отошол на отдых...
Смысл ставить защиту на FTP вообще не понимаю... Просьба исправить этот косяк... -
Вообщем открыл доступ к Keenetic Ultra 2 но при этом вместо того чтобы зайти на морду роутера я вижу перед собой картинку недоступности ip адреса.
Пробовал делать как проброс так и открывать доступ к роутеру.
У меня внешний IP. Обновил прошивку до последней сделал сброс и доступ к морде никак сделать не могу, при этом через доменное имя и прямым доступом к устройство все работает как должно.
Startup_config скину в л.с.Версия ОС 3.3 Alpha 7
Скрытый текст
Дополню, главную страницу сам дополняет. Не тупо пустой ip. При этом к серверу доступ продолжает быть открытым. Который проброшен через nat. К transimission так же прокинуты порты и доступ есть. А вот к keentic никаким способом не открывается.
Скрытый текст
Так же хочу дополнить что смена порта мне обязательна, 80 порт занят сайтом, поэтому использовать 80 порт даже для проверки работоспособности я не могу. + по моему провайдеру открыт внутренний nat. и некоторые личности занимаются брутфолом.
-
Скрытый текст
Да штука эта офигенная...
Мой провайдер дает максимально пиковую скорость это 200 мбит глобального доступа но есть внутрилокальный доступ который не ограничен. Мне приходит гигабитный кабель, а локалка как правило светится вся в нате и можно создать себе впн серверов на микротиках от знакомых которые не против делиться своим 200 мегабитным тарифом. В итоге сумарная скорость в пике составляла 422 мбит.. но заснять не успел.Хотелось бы уточнить планируется устрание проблемы в работе ссылок. Т.к. наблюдаю что если зайти на какой либо сайт и попытаться включить видео выдает ошибку сразу без разговоров))) Что у меня проблемы с сетью. А таким макаром можно сделать себе дома 1 гигабитный канал, жалко что только для скачивания, но при условии большого колличества абонентов, каждый абонент будет автоматически смотреть тот или иной контент через менее нагруженный канал. Очень скажу актуально.
Так же актуальная штука для модемов. Учитывая что я их распростроняю так же было бы интересно на это все дело посмотреть)))
В 05.08.2019 в 15:05, Le ecureuil сказал:Он работает немного не так, как этого ожидают пользователи.
Потому и не выведен.
-
Когда то раньше была возможность настроить PingCheck на VPN соединениях сейчас этой возможности нет, куда она пропала?
Но при этом на проводной интернет поставить PingCheck возможность есть. А если трафик идет через VPN?
Устройство: Keenetic Ultra 2
Прошивка: 3.1 Beta 3 -
15 часов назад, vst сказал:
@vitalik6243 Проблема в компоненте "Сеть Windows" видна по предоставленному селфтесту. В данный момент готовится обновление, в котором возможно эта проблема будет исправлена.
Тогда ожидаем, спасибо.
-
В 13.02.2019 в 18:29, ndm сказал:
Да, имеет смысл попробовать. Мы не тестировали конкретно эту модель в составе mws, но вроде бы ничего не препятствует...
Вообщем путем длительных манипулиций удалось только выяснить что на Keenetic обваливается "Сеть Windows" сразу же после запуска какой либо программы с жесткого диска подключенного к Keenetic. Сам по себе обваливается примерно через 1-2 дня...
-
В 14.02.2019 в 08:43, sergeyk сказал:
no user admin password
После связки Lite 3 и Ultra 2 на Lite 3 установился пароль, и никак не возможно попасть в вебинтерфейс, в чем проблема может быть?
-
2 минуты назад, sergeyk сказал:
no user admin password
Заработало)
-
9 часов назад, sergeyk сказал:
У вас на Lite III, судя по конфигурации, стоит пароль, который контроллер не знает.
Сейчас в систему можно добавить только те устройства, у которых нет пароля у пользователя admin (обычно это еще не настроенные устройства).каким чудом убрать пароль? если программно такой возможности нет, без сброса устройства
-
1 час назад, sergeyk сказал:
Надо нажимать на "Проверить состояние". Если ничего не меняется, показать вывод команды "show mws candidate".
Mws::RciClient: "e4:18:6b:1a:70:6c": failed to parse JSON response.
Вот такие вещи говорит)))
(config)> show mws candidate
candidate:
mac: e4:18:6b:1a:70:6c
cid:
mode:
model:
state: DISCONNECTED
license:
-
4 часа назад, AndreBA сказал:
@vitalik6243 а эту тему читали? Может поможет.
Проблем похожих много, но ответа как понял нет, а в логах keenetic ошибок я не наблюдаю...
В логах Windows 10 "Путь не найдет".
Как появится проблема еще раз, буду пробовать повторно.
Обнаружил что проблема чаще возникает если перевести комп в режим сна, и вывести обратно, доступа к винтам не будет ни на одном устройстве. Мож поможет кто еще потестить, мож у меня совпадение?
Проблемы с работой CIFS/SMB
в 3.4
Опубликовано
Эх вообщем счастье было не долгим, до первого так сказать момента когда я комп отправил в режим сна...
В логах все тоже самое, но что самое интересное теперь tsmb не полностью отваливается а только на том устройстве который уходил в сон...
Может быть предоставить какие либо настройки конфигурации? Чтобы эту проблему исправили хотя бы в Alpha версии... Т.к. проблема идет во всех версиях после 3.4.3, 3.4.3 осталась самая стабильная версия вплане работы tsmb, возможно проблемой является тот факт что включена wi-fi система....