Jump to content

dimon27254

Forum Members
 View Profile  See their activity

  • Posts

    584

  • Joined

  • Last visited

  • Days Won

    20

 Content Type 

Posts posted by dimon27254

    3.9 Beta 1-2: работа режима проверки TLS с 1211 и модема T77W676

    in Тестирование Dev-сборок

    Posted

    Обнаружил странное поведение 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 без него.

    Предполагаю, что полученных данных может оказаться мало для понимания источников проблемы, в связи с чем поддержка и не смогла помочь, но какими еще способами можно снять диагностику при таких "глюках"?

    • Thanks 1

    3.9, 3.8: наложение гиперссылки "Редактировать" на гиперссылку "Дополнительные настройки" в веб

    in Тестирование Dev-сборок

    Posted

    9 часов назад, enterfaza сказал:

    какое разрешение (диагональ)

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

    9 часов назад, krass сказал:

    тут еще как вариант попробовать другой вэб-браузер.....тот же kiwi например....

    В Chrome, Edge, Firefox и Kiwi результат аналогичный.

    • Thanks 1

    3.9, 3.8: наложение гиперссылки "Редактировать" на гиперссылку "Дополнительные настройки" в веб

    in Тестирование Dev-сборок

    Posted

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

    Скрытый текст

    1553682481_2022-11-10214305.png.30ccf22551ab17d5d4f1702ba1a4d865.png

    Проявляется только в мобильном вебе, в актуальных версиях 3.8.5.4, 3.9 Beta 2, а также более ранних.

     

    • Thanks 2

    Усовершенствование режима безопасной настройки

    in Развитие

    Posted

    Появившийся в 3.9 Beta 1 failsafe mode, безусловно, окажется полезной и удобной функцией при удаленной настройке.

    В текущей реализации изменения сохраняются в startup-config только при нажатии соответствующей кнопки. Если не успеть нажать данную кнопку в установленный таймаут, кинетик автоматически перезагружается без сохранения изменений.

    Есть предложения по доработке функционала:

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

    3.9 Beta 1 : некорректно отображается текст кнопки в окне резервного копирования в веб

    in Тестирование Dev-сборок

    Posted

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

    Скрытый текст

    Screenshot_2022_10_13_08_06_40_05_40deb401b9ffe8e1df2f1cc5ba480b12.thumb.jpg.92586de4fc01977a1e55524ba36a1c96.jpg

    В 3.8.5 отображение текста корректное:

    Скрытый текст

    Screenshot_2022_10_13_08_06_04_98_40deb401b9ffe8e1df2f1cc5ba480b12.thumb.jpg.de657b92e245dd4b72101f41454525c5.jpg

    • Thanks 2

    3.9 Alpha 7: Некорректная работа Wake-on-LAN

    in Тестирование Dev-сборок

    Posted

    После обновления 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, что сопровождается ошибкой:

    Скрытый текст

    1336854299_(20).png.e4464f987f8046e1604661726a3f3806.png

    При этом, устройства на Bridge0 успешно пробуждаются, а на интерфейсе Bridge1 пробуждение устройств не происходит, так как туда не отправляются пакеты WoL.

    Если же на Bridge1 поставить security-level private, то пакеты начинают туда уходить:

    Скрытый текст

    565425590_2022-08-28111236.png.fe6c85100d488f6b8a4a1f3c6789ccc7.png

    На 3.7.4 поведение иное, там отправка пакета идет только на интерфейсы private (Bridge0) и protected (Bridge1). Все работает корректно:

    Скрытый текст

    311109131_(19).png.bde3ef0a0705f94c18a7106b18617760.png

    В документации по CLI для 3.7-3.9 также написано, что отправка идет только на интерфейсы private и protected.

    @Le ecureuil, где-то закралась ошибка в коде 3.8-3.9, или же изменилась работа WoL?

    • Thanks 1

    3.9 Alpha 7: пропали заголовки разделов меню в веб-интерфейсе

    in Тестирование Dev-сборок

    Posted

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

    Скрытый текст

    Screenshot_2022-08-27-21-52-59-44_40deb401b9ffe8e1df2f1cc5ba480b12.thumb.jpg.b520a078c931b8964387ea3d4c926e1e.jpg

    Если открыть код элементов меню, текст в заголовках есть, но не отображается:

    Скрытый текст

    1441457809_2022-08-27220828.thumb.png.4f22fedf55d652fe0c47b27b5b882d3b.png

     При этом, если откатиться на 3.9 Alpha 6, все восстанавливается:

    Скрытый текст

    Screenshot_2022-08-27-21-56-00-54_40deb401b9ffe8e1df2f1cc5ba480b12.thumb.jpg.0e64b5885db125a21ac98f81ee6d05ba.jpg

    Так и должно быть, или это ошибка?

    • Thanks 2

    MWS и соответствия VLAN портам

    in Обмен опытом

    Posted

    Возникла потребность настроить доступ ip-камеры, подключенной к ретранслятору в mesh-системе, к отдельному сегменту.

    Настраивал через cli, все работает до перезагрузки ретранслятора или контроллера. На порте сбрасывается access vlan на 1, и ip-камера возвращается в домашнюю сеть. Поведение схоже с описанным у @dvg_lab пару лет назад в данной теме, с контроллера прилетают настройки, всё перезаписывающие в соответствии с используемыми в mesh-системе сегментами.

    При этом, заметил, что изменяется при перезагрузке только running-config, в startup-config все остается так, как было настроено мной через cli, если только вручную не произвести сохранение прилетевших настроек.

    Оставил в поддержке запрос #573389 на эту тему, где описал свою схему подключения и поведение. Было подтверждено, что это особенность работы mesh-системы.

    Уважаемый @Le ecureuil, есть ли возможность реализации настройки портов в режиме ретранслятора в будущих релизах, например, 3.8? Понимаю, что данная функция, возможно, не будет широко востребована ввиду своей специфичности, но, все же, такая настройка была бы очень полезна даже в cli.

     

    QMI error: 0x4a

    in Тестирование Dev-сборок

    Posted

    В файле конфигурации у себя не нашел никаких опций, связанных с отладкой. Между каналами прошивок перехожу только через веб-интерфейс и последующее обновление, предлагаемое самой KeeneticOS. 

    Смею предположить, если бы роутер у меня запускался в debug-режиме, то и лог был бы более детализированным, нежели прикрепленный в self-тесте. В моем же случае, во время работы появляются только сообщения от библиотеки qmi.

    QMI error: 0x4a

    in Тестирование Dev-сборок

    Posted · Edited by dimon27254

    Имею роутер Keenetic 4G (KN-1211) с последней альфа-прошивкой 3.7.4.

    К нему подключен модем T77W676 через 5 метровый удлинитель из качественной медной экранированной витой пары.

    В журнале событий постоянно появляются строки вида: 

    UsbQmi::Device: "UsbQmi0": QMI error: 0x4a.

    За чуть менее чем час работы роутера, накопилась 291 строка. Появляются вне зависимости от нагрузки.

    При этом, модем прекрасно работает. В веб-интерфейсе отображаются все параметры сигнала, скорость высокая (в моих условиях это около 50-70 Мбит/с), под нагрузкой отвалов нет.

    Базовая станция находится примерно в 100 метрах, прямая видимость, уровень сигнала достаточно высокий, несмотря на загруженность станции:
      

        "rssi": "-34",
    "rsrp": "-61",
    "cinr": "14",
    "rsrq": "-11"

    Агрегация на БС не поддерживается.

    Если подключить вместо T77W676 модем Huawei E3372, в журнале никаких ошибок не возникает, проблем со скоростью и стабильностью также не замечено.

    Ранее, при использовании более старых альфа 3.7, еще до выхода бета версий, подключал T77W676 через кабель длиной 15 метров. В журнале появлялись те же самые строки, при этом модем сохранял полную стабильность и работоспособность. E3372 на том кабеле также работал без каких-либо проблем.
    Так как и 3372 работает нормально, это отметает нехватку питания или проблемы с кабелями.

    Пробовал чистить контакты сим-карты, самого модема в переходнике, не помогло.

    При этом, если установить стабильную прошивку 3.6.12, в журнале событий вышеописанные строки не появляются. Модемы полностью сохраняют работоспособность.

    В чем возможна проблема такого поведения? Может ли это быть связано с отсутствием агрегации, тогда как система пытается, например, запросить информацию о ней, но не получает нужный ответ от модема? 

    Self-test прикрепил.

×
×
  • Create New...