dimon27254

@eralde @Anna_ в 4.2 Alpha 9 исправлено. Спасибо!

@Le ecureuil @admin с обновлением на 4.2 Alpha 8-9 система автоматически меняет некоторые настройки в running-config. В моем случае: 1. Отключились автообновление и "программа улучшения продукта" (components auto-update disable, ndss dump-report disable). 2. Для беспроводных интерфейсов прописался mu-mimo (beamforming explicit mu-mimo). 3. Для PPPoE-подключения включился ccp. Если сохранить изменения, то эти настройки попадают уже и в startup-config.

@hellonow проверил на трех Кинетиках с 4.2 Alpha 9 - доступ к веб-интерфейсу заработал без отключенного флага. Спасибо! В ветку 4.1 планируется добавить это исправление?

@admin в 4.2 Alpha 9 проблем с паролями нет. Спасибо за хотфикс!

@eralde @Anna_ в 4.2 Alpha 8 иконка в темной теме корректная. Спасибо!

Скорее всего, было: [I] May 8 23:01:52 ndm: Network::Interface::Supplicant: "PPPoE0": identity saved. [E] May 8 23:01:52 ndm: Command::Base: argument parse error. [I] May 8 23:01:52 ndm: Network::Interface::Base: "PPPoE0": static MTU is 1492. В процессе загрузки система не может разобрать пароль, закодированный в startup-config с помощью ns3. Как итог, он исчезает для PPPoE-подключения в running-config, а затем и в startup-config, если внести хоть какие-то изменения в настройки Кинетика. При вводе пароля через командную строку или веб-интерфейс, сохранение идет не в ns3 (как было всегда), а в виде обычной текстовой строки, которая без проблем далее используется системой.

В данном случае клиентом является только одно мое устройство (как раз с адресом 192.168.1.40), с которого я управляю Кинетиком. При обращении к текущему вебу таких ошибок от nginx ни разу не встречал.

@eralde при обращении к новому вебу иногда в логе появляется большая простыня ошибок от nginx: [E] May 7 15:35:59 keenetic-* nginx: 2024/05/07 15:35:59 [error] 1051#0: *21 limiting requests, excess: 200.150 by zone "peraddr", client: 192.168.1.40, server: , request: "GET /assets/images//printer.svg HTTP/1.1", host: "192.168.1.1", referrer: "http://192.168.1.1/login?backUrl=%2Fdashboard%3FbackUrl%3D%252Fsystem" [E] May 7 15:35:59 keenetic-* nginx: 2024/05/07 15:35:59 [error] 1051#0: *25 limiting requests, excess: 200.975 by zone "peraddr", client: 192.168.1.40, server: , request: "GET /assets/images//question.svg HTTP/1.1", host: "192.168.1.1", referrer: "http://192.168.1.1/login?backUrl=%2Fdashboard%3FbackUrl%3D%252Fsystem" [E] May 7 15:35:59 keenetic-* nginx: 2024/05/07 15:35:59 [error] 1051#0: *27 limiting requests, excess: 200.025 by zone "peraddr", client: 192.168.1.40, server: , request: "GET /assets/images//restart.svg HTTP/1.1", host: "192.168.1.1", referrer: "http://192.168.1.1/login?backUrl=%2Fdashboard%3FbackUrl%3D%252Fsystem" [E] May 7 15:35:59 keenetic-* nginx: 2024/05/07 15:35:59 [error] 1051#0: *23 limiting requests, excess: 200.025 by zone "peraddr", client: 192.168.1.40, server: , request: "GET /assets/images//role-free.svg HTTP/1.1", host: "192.168.1.1", referrer: "http://192.168.1.1/login?backUrl=%2Fdashboard%3FbackUrl%3D%252Fsystem" Я привел лишь часть для примера. В реальности может быть как пара-тройка строк, так и 40-50. Какую-либо закономерность мне пока что найти так и не удалось - это происходит в случайное время, вне зависимости от типа доступа - HTTP или HTTPS. Иногда при авторизации, иногда при переходе между страницами. При этом, с самим вебом никаких проблем нет. Все работает корректно и без ошибок. Проверял на KN-1811 с 4.2 Alpha 7.

@eralde @Le ecureuil если в новом веб-интерфейсе внести изменения в настройки сегмента, например, сменить тип шифрования для Wi-Fi-сети, то после этого пропадает доступ к вебу по домену KeenDNS внутри локальной сети Кинетика. Доступ по локальному IP через HTTP в этот момент продолжает работать. Также может произойти рассинхронизация настроек беспроводных сетей 2,4 и 5 ГГц. Перезагрузка Кинетика исправляет проблему - доступ восстанавливается, а настройки сетей снова оказываются идентичными. В текущем интерфейсе изменение настроек сегмента не "ломает" доступ к Кинетику по KeenDNS из локальной сети. Проверял на KN-1811 с 4.2 Alpha 7.

Сейчас ещё раз повторил перемещение, за 5 минут так и не загрузилась. UPD: похоже, я нашел причину такого поведения - на KN-3610 у меня отсутствует компонент tsmb (общий доступ к файлам и принтерам по протоколу SMB). После его установки карточка начала корректно загружаться после каждого перемещения. Видимо, это как-то связано с багом, который исправляли ранее:

@hellonow свежий self-test требуется? В 4.2 Alpha 7 все ещё без изменений.

@eralde если переместить эту плитку из одной колонки в другую, а затем вернуть в исходную, то она "падает" в бесконечную загрузку. После перезагрузки страницы работоспособность восстанавливается, но до следующего перемещения плитки между колонками. Ни в логе, ни в консоли DevTools ошибок в этот момент нет. Проверял на KN-3610 с 4.2 Alpha 7. Из подключенных USB-устройств только модем T77W676.

@Le ecureuil на KN-1811 c 4.2 Alpha 7 парочка доменов резолвятся через сервер DoT/DoH. Обратил внимание, что после каждого продления аренды IP на IPoE-подключении в логе появляются сообщения об обновлении адресов серверов DoT/DoH: [I] May 5 09:44:56 ndhcpc: GigabitEthernet0/Vlan100: received ACK for 192.168.5.2 from 192.168.5.1 lease 1800 sec. [I] May 5 09:45:07 ndm: Dns::Secure::Tools: unable to obtain addresses for "*". [I] May 5 09:45:07 ndm: Dns::Secure::Tools: unable to obtain addresses for "*". [I] May 5 09:45:07 ndm: Dns::Manager: updating DNS-over-HTTPS servers addresses. [I] May 5 09:45:07 ndm: Dns::Secure::Tools: unable to obtain addresses for "*". [I] May 5 09:45:07 ndm: Dns::Secure::DohConfigurator: "System": skip service "https://*/dns-query", wait for bootstrap. [I] May 5 09:45:07 ndm: Dns::Secure::Tools: unable to obtain addresses for "*". [I] May 5 09:45:07 ndm: Dns::Secure::DohConfigurator: "System": skip service "https://*/dns-query", wait for bootstrap. [I] May 5 09:45:07 ndm: Dns::Secure::Tools: unable to obtain addresses for "*". [I] May 5 09:45:07 ndm: Dns::Secure::DohConfigurator: "Policy0": skip service "https://*/dns-query", wait for bootstrap. [I] May 5 09:45:07 ndm: Dns::Secure::Tools: unable to obtain addresses for "*". [I] May 5 09:45:07 ndm: Dns::Secure::DohConfigurator: "Policy0": skip service "https://*/dns-query", wait for bootstrap. [I] May 5 09:45:17 ndm: Dns::Manager: updating DNS-over-HTTPS servers addresses. Когда срок аренды адреса большой, например, 24 часа - эти сообщения появляются раз в 12 часов и не мешают. Но когда срок аренды составляет, к примеру, 30 минут (такими значениями увлекаются некоторые интернет-провайдеры) - сообщения повторяются каждые 15 минут, что немного усложняет изучение системного лога. Хотел бы уточнить: с каким периодом должно происходить обновление адресов DoT/DoH? Оно жестко привязано к сроку аренды IP на интернет-подключении или же может работать по какому-то собственному таймеру? IPoE у меня является резервным подключением.

@eralde @Le ecureuil в 4.2 Alpha 7 сообщений в логе больше нет. Спасибо!

В 4.2 Alpha 7 ошибок в логе более нет, и в имени автоматически регистрируемого устройства теперь корректные дата и время. Спасибо за оперативное исправление!

@eralde при каждом обращении к этой странице в логе появляются предупреждения: [W] Apr 27 16:58:12 ndm: Json::Object: AppendMember: duplicate key: "short". [W] Apr 27 16:58:12 ndm: Core::Syslog: last message repeated 191 times. Проверял на KN-1811 с 4.2 Alpha 6.

@eralde @Anna_ в 4.2 Alpha 6 отображение исправлено. Спасибо!

@eralde в 4.2 Alpha 6 с выбором правил проблем более нет. Спасибо!

В 4.2 Alpha 6 вышеприведенная ошибка в логе больше не появляется. Вместо неё, появилась пачка других: [C] Apr 27 14:33:09 ndm: Mutex: "INTERFACE_REPO": system failed [0xcffd0042], resource deadlock avoided. [C] Apr 27 14:33:09 ndm: Mutex: "Event sender" (709) backtrace: [C] Apr 27 14:33:09 ndm: Mutex: Hotspot::AutoRegister::OnDhcpLease_(Event::DhcpLease const&)+0x1a4 [C] Apr 27 14:33:09 ndm: Mutex: Event::Sender::Run()+0x250 [C] Apr 27 14:33:09 ndm: Mutex: Thread::StartRoutine_(void*)+0x2c8 [C] Apr 27 14:33:09 ndm: Mutex: start()+0x90 [C] Apr 27 14:33:09 ndm: Mutex: __clone()+0x30 [C] Apr 27 14:33:09 ndm: Mutex: "INTERFACE_REPO": system failed [0xcffd0042], resource deadlock avoided. [C] Apr 27 14:33:09 ndm: Mutex: "Event sender" (709) backtrace: [C] Apr 27 14:33:09 ndm: Mutex: Hotspot::AutoRegister::OnDhcpLease_(Event::DhcpLease const&)+0x1a4 [C] Apr 27 14:33:09 ndm: Mutex: Event::Sender::Run()+0x250 [C] Apr 27 14:33:09 ndm: Mutex: Thread::StartRoutine_(void*)+0x2c8 [C] Apr 27 14:33:09 ndm: Mutex: start()+0x90 [C] Apr 27 14:33:09 ndm: Mutex: __clone()+0x30 [I] Apr 27 14:33:09 ndm: Core::KnownHosts: new host "*:*:*:*:*:* - Home network - 1/01/1970 13:57" has been created. [C] Apr 27 14:33:09 ndm: Thread: "Event sender": lock precedence violation: HOTSPOT_MANAGER (19) after INTERFACE_REPO (52). [C] Apr 27 14:33:09 ndm: Thread: "Event sender" (709) backtrace: [C] Apr 27 14:33:09 ndm: Thread: Hotspot::Manager::SetHostConform(CString const&)+0x30 [C] Apr 27 14:33:09 ndm: Thread: Hotspot::AutoRegister::OnDhcpLease_(Event::DhcpLease const&)+0x5f4 [C] Apr 27 14:33:09 ndm: Thread: Event::Sender::Run()+0x250 [C] Apr 27 14:33:09 ndm: Thread: Thread::StartRoutine_(void*)+0x2c8 [C] Apr 27 14:33:09 ndm: Thread: start()+0x90 [C] Apr 27 14:33:09 ndm: Thread: __clone()+0x30 Также заметил, что в имя авторегистрируемого устройства подставляются некорректные дата и время.

@Le ecureuil в 4.2 Alpha 6 спама больше нет. Проверил и на DoT, и на DoH. Спасибо!

Таким образом получается, что проблема в оборудовании фильтрации трафика, в моем случае установленном у интернет-провайдера. Обновил сейчас Chrome до этой версии, но ситуация не изменилась. Пока Kyber не выключить вручную через групповые политики или флаги - веб-интерфейс Кинетиков остается недоступен.

@Le ecureuil нет ли свежих новостей по реализации возможности ввода нескольких IP/доменов в профилях ping-check? В default-профиле это уже есть, но хотелось бы, например, изменить интервал проверки, или же отключить перезагрузку подключенного USB-модема по питанию.

Предлагаю немного другой способ - выключение и последующее включение именно Ethernet-порта по расписанию. В этом случае линк будет перезапускаться на физическом уровне, словно был отсоединен и снова подсоединен Ethernet-кабель. Перезагрузка Кинетика не потребуется. Минусы: 1) интернет будет отсутствовать минимум 1 минуту, т.к. KeeneticOS не позволяет создавать расписания с большей точностью; 2) в веб-интерфейсе такое сделать не получится - только через командную строку (CLI). Последовательность команд: schedule resetlink description resetlink action stop 0 6 * action start 1 6 * exit interface GigabitEthernet1 schedule resetlink system configuration save Создается расписание "resetlink" (можно дать и любое другое имя) с действием "stop" каждый день в 06:00, и действием "start" каждый день в 06:01. Далее это расписание привязывается к нужному интерфейсу (в случае с KN-1810 - WAN-порт находится на GigabitEthernet1) и внесенные изменения сохраняются в память. Таким образом, каждый день в 06:00 будет выключаться порт, а в 06:01 включаться обратно. На других моделях Кинетиков вместо GigabitEthernet1 может потребоваться указать иной интерфейс, через который работает подключение к интернету. Например: GigabitEthernet0/0, FastEthernet0/0 или другой - в зависимости от номера порта и конкретной конфигурации.

@eralde @Anna_ в темной теме, после изменения настроек приложения, на некоторое время его карточка выделяется светлым фоном: Проверял на KN-1811 с 4.2 Alpha 5.