dimon27254

@Le ecureuil, посмотрите, пожалуйста, в чем может быть баг со стороны системы.

Откатился на 3.9.2, посмотрел в логе, после включения интерфейса с помощью переключателя, вслед за сообщением Network::Interface::Ppp: "PPPoE0": connection service standby. сразу происходит запуск pppd и последующая установка соединения. В 4.0 Alpha 1 pppd не запускается, и, соответственно, не устанавливается соединение. Но возникает вопрос, почему же тогда работает автоподключение при загрузке кинетика, а также после ручного выкл/вкл WAN интерфейса через cli.

@eralde, обнаружил на KN-3010 баг. Если выключить PPPoE соединение в веб-интерфейсе через соответствующий переключатель в разделе "Ethernet", то включить обратно данное соединение этим путем уже не удастся. Визуально после нажатия состояние переключателя изменяется, но интерфейс остается выключенным: Если перезагрузить страницу, переключатель вернется в выключенное положение: Запустить соединение удается только через ручное включение PPPoE0 в cli и последующее выключение-включение интерфейса GigabitEthernet1.

Обнаружил на KN-3010 некорректное отображение входящего трафика в мониторе. У устройств, подключенных по кабелю, отображение корректное. А у тех, которые подключены по Wi-Fi к KN-3010, входящий трафик рандомно уходит в раздел "незарегистрированные устройства", хотя сами устройства зарегистрированы. При этом, если эти же устройства подключить к экстендерам KN-3210, учет корректный.

Установил 4.0 Alpha 1 на KN-3010 и KN-1211. Пробовал запускать speedtest, iperf и любые другие службы, отдача не отображается, но только для подключения PPPoE. В подключениях типа IPoE или UsbQmi все работает корректно.

В 3.9.1 исправлено. Спасибо!

В попытках выяснить причину, включил на кинетике режим отладки и выгрузку логов на syslog сервер. С момента написания последнего сообщения, только сегодня удалось снова словить "отвал". В скрытом файле прикрепил лог в отрезке времени с 13:20 до 13:50 сегодняшнего дня. В этом промежутке времени можно заметить, что периодически проверка соединения завершалась неудачей. Затем последняя попытка была в 13:31:58, но она никак не завершилась, в отличие от прежних, после чего и посыпались повторяющиеся записи, подобные выложенным в первом сообщении. В то же время отвалился и веб с мобильным приложением. При необходимости, могу выложить полный лог с момента запуска режима отладки.

Спустя 11 дней снова словил "отвал". За это время обновился до 3.9.0, а также экспериментировал с настройками: Сначала увеличил на хосте ya.ru интервал до 5 секунд. Посмотрел в течение 5 дней, все было стабильно. Затем попробовал вернуть старый интервал в 3 секунды, но уже с хостом google.com. Спустя 5 дней никаких проблем также не заметил. Вчера снова установил хост ya.ru и интервал в 3 секунды. Сегодня сработал ping-check, кинетик перезагрузил модем. Сразу же зашел в веб-интерфейс, увидел, что модем подключился к очень отдаленной БС с слабым сигналом. Через небольшое время веб и мобильная часть отвалились. Лог прикрепил.

В 3.9.0 исправление не подтверждаю. Гиперссылка также накладывается. На форуме есть упоминание в списке изменений об исправлении, но на сайте docs.keenetic.com этого нет.

По прикрепленным логам видно, что где-то на это ушло несколько дней, а где-то достаточно и пары часов, поэтому вряд ли удастся это обнаружить сразу после запуска. Пока что только увеличил интервал и порог срабатывания на ya.ru. Буду наблюдать за поведением. Короткий интервал и малое количество попыток для срабатывания устанавливал из-за того, что у Мегафона в моей местности перегружены окружающие базовые станции, и бывают моменты, когда интернет может не работать вообще в течение 20-40 секунд. При такой ситуации само подключение модема к сети не рвется, уровень связи остается на том же уровне, просто нет доступа к интернету. В таком случае, кинетик достаточно быстро переключается на IPoE, одновременно с этим перезагружая модем по питанию для переподключения. Но стоит отметить, что домен не резолвится только при загрузке кинетика. Во вчерашнем self-test это произошло, когда еще не был получен адрес через IPoE, а модем еще не инициализировался. В этот момент времени оба подключения еще были недоступны, соответственно, и нет возможности выполнить резолвинг. В self-test, снятом 28.10 и логе от 30.10 это также произошло при первой загрузке, когда оба подключения еще недоступны. Затем это же произошло сразу же после получения адреса через IPoE, в тот же момент времени: [I] Oct 26 22:14:47 ndm: Dhcp::Client: configuring interface ISP. [I] Oct 26 22:14:47 ndm: Network::Interface::Ip: "FastEthernet0/Vlan2": IP address is 192.168.0.2/24. [I] Oct 26 22:14:47 ndm: Dhcp::Client: obtained IP address 192.168.0.2/24. [I] Oct 26 22:14:47 ndm: Dhcp::Client: interface "ISP" is global, priority 700. [I] Oct 26 22:14:47 ndm: Dhcp::Client: adding a default route via 192.168.0.1. [I] Oct 26 22:14:47 ndm: Dhcp::Client: adding name server 192.168.0.1. [I] Oct 26 22:14:47 ndm: Dns::Manager: name server 192.168.0.1 added, domain (default). [I] Oct 26 22:14:47 ndm: Network::InterfaceFlusher: flushed conntrack and route cache. [W] Oct 26 22:14:47 ndm: PingCheck::Profile: "_WEBADMIN_UsbQmi0": failed to resolve "yandex.ru". Но далее по логам такой ошибки больше не появляется.

Обнаружил странное поведение KN-1211 на прошивках 3.9 Beta 1-2: Подключен модем T77W676, используется в качестве основного подключения, резервное подключение IPoE. Суть проблемы: при включенной TLS-проверке порта TCP в основном подключении через некоторое время работы пропадает доступ к кинетику через веб-интерфейс и мобильное приложение. Проявляется так: вхожу в веб-интерфейс кинетика (как по локальному ip-адресу, так и через доменное имя KeenDNS), выполняю авторизацию. После нажатия кнопки "войти", страница авторизации зависает. В консоли разработчика Chrome увидел, что не приходит ответ на запрос "http://ip/rci", в результате чего не происходит дальнейших "движений". Если страницу перезагрузить, отобразится пустой dashboard, а в консоли также показывается, что нет ответа на запрос "http://ip/rci". В мобильном приложении показывается, что роутер не в сети, но также и не приходит уведомление о том, что он офлайн. При этом, до него можно "достучаться" через telnet, но и там все работает некорректно: например, я не могу просмотреть running-config, self-test, или же, например, получить вывод команд вида "show ping-check", "show interface". После ввода нет ответа, а через некоторое время соединение разрывается. Несмотря на это, доступен просмотр лога путем ввода команды "show log". Введя в адресной строке браузера запрос вида "http://ip/ci/log.txt", удалось выгрузить лог. Обнаружил повторяющиеся записи вида: [W] Nov 18 17:41:21 ndm: Timer: unable to alarm "Network::Interface::LinkDetector" for 7350 seconds. [W] Nov 18 17:41:21 ndm: Timer: "Ping-check profile queue" (26866) backtrace: [W] Nov 18 17:41:21 ndm: Timer: no backtrace available. [W] Nov 18 17:41:26 ndm: Event::Forwarder: unable to send "Event::Type::Neighbour" to "Network::Interface::AccessPoint" for 7350 seconds. [W] Nov 18 17:41:26 ndm: Event::Forwarder: "Ping-check profile queue" (26866) backtrace: [W] Nov 18 17:41:26 ndm: Event::Forwarder: no backtrace available. [W] Nov 18 17:41:43 ndm: Core::Watchdog: Ping-check profile queue holds INTERFACE_REPO (62) lock 7372 seconds acquired Nov 18 15:38:51. [W] Nov 18 17:41:43 ndm: Core::Watchdog: "Ping-check profile queue" (26866) backtrace: [W] Nov 18 17:41:43 ndm: Core::Watchdog: no backtrace available. При этом, self-test схожим методом выгрузить не удается: некоторое время нет ответа, а затем веб-сервер кинетика выдает ошибку 504. Несмотря на длинную "простыню" в логе, неработающий веб и мобильную часть, нормально работает доступ к интернету по проводу и Wi-Fi, отрабатываются все правила межсетевого экрана, нет проблем с доступом к веб-приложениям через KeenDNS. Вывести кинетик из такого состояния удается с помощью команды "system reboot" в telnet. После перезагрузки, доступ к веб-интерфейсу и через мобильное приложение восстанавливается до следующего такого сбоя. Изменения хоста проверки не решает проблему, но если изменить тип проверки в ping-check на icmp, все вышеописанное перестает проявляться. В поддержке с этой проблемой мне ничем не смогли помочь, закрыли запрос после того, как я написал, что изменение типа проверки решает данную ситуацию. На KN-3010 с 3.9 Beta 1-2, где основное подключение PPPoE и на нём включена TLS-проверка порта, все работает стабильно неделями. В скрытом сообщении прикрепил файлы, которые отправлял в поддержку: логи с "отвалами" и "чистый" self-test, снятый после перезагрузки. Эти файлы были сохранены при установленном компоненте IPv6, так как изначально предполагал, что проблема в нем. Но и удаление этого компонента проблему не решило, поэтому добавил ещё сегодняшний лог и "чистый" self-test без него. Предполагаю, что полученных данных может оказаться мало для понимания источников проблемы, в связи с чем поддержка и не смогла помочь, но какими еще способами можно снять диагностику при таких "глюках"?

Проверял на двух устройствах: OnePlus 9R (2400x1080, 6.55") и Samsung Galaxy A40 (2340x1080, 5.9"). Размер шрифта и масштаб установлены стандартные. В Chrome, Edge, Firefox и Kiwi результат аналогичный.

@eralde, в разделе "Мои сети и Wi-Fi", в выбранном сегменте при установленном расписании работы Wi-Fi сети, происходит наложение гиперссылки "Редактировать" на гиперссылку "Дополнительные настройки": Проявляется только в мобильном вебе, в актуальных версиях 3.8.5.4, 3.9 Beta 2, а также более ранних.

В 3.9 Beta 2 отображение корректное. Спасибо!

Аналогичный вид текста верхней кнопки обнаружил и в других, схожих по компоновке диалоговых окнах:

Появившийся в 3.9 Beta 1 failsafe mode, безусловно, окажется полезной и удобной функцией при удаленной настройке. В текущей реализации изменения сохраняются в startup-config только при нажатии соответствующей кнопки. Если не успеть нажать данную кнопку в установленный таймаут, кинетик автоматически перезагружается без сохранения изменений. Есть предложения по доработке функционала: Если после внесения изменений связь с кинетиком не потерялась, или же потерялась, но после восстановилась до истечения установленного таймаута, автоматически сохранить изменения в память. Если связь потерялась, и ее не удается восстановить, в течение определенного времени, меньшего чем таймаут перезагрузки, в случае, если доступ к веб-интерфейсу происходит через доменное имя, предложить пользователю попробовать перезагрузить страницу или сделать это автоматически с предупреждением. Может быть актуально при подключении с динамическим белым ip-адресом, когда производятся изменения настроек, касающиеся активного интернет-подключения, после чего веб становится недоступным по старому адресу, пока пользователь вручную не перезагрузит страницу и нажмёт кнопку сохранения. Добавить в веб-интерфейс возможность задания таймаута перезагрузки. Сейчас это уже реализовано в CLI. Будет полезно в совокупности с п. 1 в случаях, когда подключение к интернету может занимать длительное время. Например, у Ростелекома в Алтайском крае подключение по PPPoE иногда длится вплоть до 5-10 минут, т.к. старую сессию сервер может не разорвать, а затем и вовсе перестает отвечать на какое-то время. Задав свой таймаут, пользователь будет понимать, что если связь быстро не восстановилась, нужно ожидать заданное время, т.к. возможны проблемы со стороны провайдера. Если связь восстановилась за это время, значит, ничего не "сломалось" и можно сохранить настройки. А если даже после истечения установленного времени ответа нет, значит, или все также проблема в провайдере, или что-то неправильно было настроено. В таком случае, кинетик автоматически перезагрузится с предыдущими настройками.

@eralde, в 3.9 Beta 1 и более ранних, в мобильном веб-интерфейсе в окне резервного копирования не отображается полностью текст кнопки создания резервной копии: В 3.8.5 отображение текста корректное:

На 3.9 Beta 0 заголовки отображаются правильно. Спасибо!

В 3.9 Beta 0 WoL работает корректно, как на 3.7.4. Спасибо!

3.8.5; 3.9 Alpha 8, 9: ошибка сохраняется

Уточнил в поддержке на счёт вышеописанного поведения WoL, ошибку подтвердили.

После обновления KN-3010 с 3.7.4 на 3.8.4 заметил, что при попытке разбудить устройство по сети, WoL пакеты стали отправляться по-другому. Нижеописанное происходит и на 3.9 Alpha 7. Теперь отправка идет на интерфейсы с security-level private и public. Bridge0 имеет security-level private, у Bridge1 security-level protected. Судя по логу, отправка идет также в PPPoE (PPPoE0), IPoE (GigabitEthernet0/Vlan11) и Wireguard (Wireguard3), имеющие security-level public, что сопровождается ошибкой: При этом, устройства на Bridge0 успешно пробуждаются, а на интерфейсе Bridge1 пробуждение устройств не происходит, так как туда не отправляются пакеты WoL. Если же на Bridge1 поставить security-level private, то пакеты начинают туда уходить: На 3.7.4 поведение иное, там отправка пакета идет только на интерфейсы private (Bridge0) и protected (Bridge1). Все работает корректно: В документации по CLI для 3.7-3.9 также написано, что отправка идет только на интерфейсы private и protected. @Le ecureuil, где-то закралась ошибка в коде 3.8-3.9, или же изменилась работа WoL?

@eralde, после обновления на 3.9 Alpha 7 в мобильной версии веб-интерфейса исчезли заголовки разделов в меню. Обнаружил это на двух ретрансляторах KN-1110 и контроллере KN-3010. Пример на KN-1110: Если открыть код элементов меню, текст в заголовках есть, но не отображается: При этом, если откатиться на 3.9 Alpha 6, все восстанавливается: Так и должно быть, или это ошибка?

Возникла потребность настроить доступ ip-камеры, подключенной к ретранслятору в mesh-системе, к отдельному сегменту. Настраивал через cli, все работает до перезагрузки ретранслятора или контроллера. На порте сбрасывается access vlan на 1, и ip-камера возвращается в домашнюю сеть. Поведение схоже с описанным у @dvg_lab пару лет назад в данной теме, с контроллера прилетают настройки, всё перезаписывающие в соответствии с используемыми в mesh-системе сегментами. При этом, заметил, что изменяется при перезагрузке только running-config, в startup-config все остается так, как было настроено мной через cli, если только вручную не произвести сохранение прилетевших настроек. Оставил в поддержке запрос #573389 на эту тему, где описал свою схему подключения и поведение. Было подтверждено, что это особенность работы mesh-системы. Уважаемый @Le ecureuil, есть ли возможность реализации настройки портов в режиме ретранслятора в будущих релизах, например, 3.8? Понимаю, что данная функция, возможно, не будет широко востребована ввиду своей специфичности, но, все же, такая настройка была бы очень полезна даже в cli.

Обновился на бету 3.7.7. В течение 5 часов с момента запуска роутера, не появилось ни одного отладочного сообщения от qmi, что при инициализации модема, что во время работы. @vst, спасибо!