dimon27254

В 4.0 Alpha 8 поведение сохраняется. Я заметил, что для проявления достаточно установленной 4.0 на экстендерах, контроллер в этот момент может быть и на 3.9, сообщения все равно будут сыпаться. Посмотрел по логам, на контроллере сообщения появляются с периодичностью ровно в 2 минуты. Очень похоже на работу какого-то фонового сканирования эфира, но не понятно, почему оно срабатывает только при установленной на ретрансляторах 4.0. Снял и прикрепил self-test до и после включения debug-режима. Контроллер на 3.9.3, ретрансляторы на 4.0 Alpha 8.

В 4.0 Alpha 6 все аналогично при работающем ppe hardware.

В 4.0 Alpha 4-6 сохраняется некорректный подсчет входящего трафика при включенном ppe hardware.

В 4.0 Alpha 5-6 в логе контроллера также есть эти сообщения в большом количестве. В логах экстендеров появляются реже и в меньшем количестве. В 3.9.2 они не появлялись спонтанно во время работы. @Le ecureuil@hellonow, если это возможно, переместите, пожалуйста, этот вопрос назад в "Тестирование Dev-сборок". Из-за моей ошибки при его написании, он был перемещен в Keenetic RMM, но с этим сервисом никак не связан, т.к. у меня там нет добавленных устройств. Я имею ввиду работу протокола 802.11k, который из веб-интерфейса управляется параметром "Управление BSS-окружением 802.11k/v", а в системе именуется как RRM.

После выхода 4.0 Alpha 4, перешел на неё. Сегодня ночью снова все "сломалось", весь лог забит повторяющимися записями из первого сообщения вопроса. В этот раз перестал работать и KeenDNS, выдавая ошибку 503 Not Reachable.

После выхода 4.0 Alpha 1, обновил свой KN-3010, который работает в качестве контроллера mesh, и два экстендера KN-3210. Заметил, что лог контроллера забивался сообщениями такого вида: RRM: perform scan notified channel: 9 Иногда в сообщениях появлялась цифра 13 вместо 9. Судя по сообщениям, это связано с работой RRM. Проверил настройки экстендеров, в одном установлен 13 канал Wi-Fi, в другом 9. Перезагрузка контроллера не помогает, также как и перезагрузка экстендеров. Зато, если на экстендерах откатить версию на 3.9.2, в логах контроллера исчезают сообщения RRM. KN-3210 подключены по кабелю, беспроводной backhaul отключен. Сейчас контроллер работает на версии 4.0 Alpha 4. В 3.9.2 и более ранних такого поведения мной замечено не было. Начиная с версии 4.0 так и должно быть, или это баг?

@Le ecureuil на KN-1211 с 4.0 Alpha 3 появляется "answer from wrong socket, ignore" в логе. При этом, по моим наблюдениям, начинает вылазить только после продолжительной работы кинетика и последующей его перезагрузки. Затем, чтобы в логе сообщения перестали выходить, нужно снова сделать перезагрузку.

Долгое время проблема не проявлялась, за это время с 3.9.0 обновлялся на каждую выходящую версию, но сегодня снова столкнулся в актуальной 4.0 Alpha 3. Поведение идентично всем предыдущим случаям.

@Le ecureuil, в 4.0 Alpha 2-3 поведение сохраняется. Если отключить аппаратный ускоритель, то входящий трафик начинает корректно отображаться и группироваться по устройствам. Как только включаю ускоритель, входящий снова начинает рандомно уходить в "незарегистрированные устройства". По всей видимости, весь подсчет трафика через ppe hardware работает некорректно, т.к. его отключение исправляет и подсчет отдачи: Зависимости от компонента IPv6 нет, что с ним, что без него, поведение аналогичное.

@Le ecureuil, в 4.0 Alpha 3 отдача также не отображается для PPPoE. При этом, если отключить аппаратный ускоритель, то отдача сразу же появляется. Затем, если его снова включить - тут же пропадает.

Подтверждаю исправление в 4.0 Alpha 3. Спасибо!

Исправление в 4.0 Alpha 2 подтверждаю. Спасибо!

@Le ecureuil, если из веб-интерфейса выключить порт и затем его включить с любым из режимов, то линк не поднимается. Нужно или перезагрузить кинетик, или сделать вручную для порта down и up через cli, тогда линк поднимается. Обнаружил у себя на KN-3010 и KN-1211.

@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 результат аналогичный.