Jump to content

dimon27254

Forum Members
  • Posts

    575
  • Joined

  • Last visited

  • Days Won

    19

Posts posted by dimon27254

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

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

  3. @Le ecureuil, в 4.0 Alpha 2-3 поведение сохраняется.

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

    По всей видимости, весь подсчет трафика через ppe hardware работает некорректно, т.к. его отключение исправляет и подсчет отдачи:

    Зависимости от компонента IPv6 нет, что с ним, что без него, поведение аналогичное.

    • Upvote 1
  4. @Le ecureuil, в 4.0 Alpha 3 отдача также не отображается для PPPoE.

    При этом, если отключить аппаратный ускоритель, то отдача сразу же появляется. Затем, если его снова включить - тут же пропадает.

    • Upvote 2
  5. @Le ecureuil, если из веб-интерфейса выключить порт и затем его включить с любым из режимов, то линк не поднимается.

    Нужно или перезагрузить кинетик, или сделать вручную для порта down и up через cli, тогда линк поднимается.

    Обнаружил у себя на KN-3010 и KN-1211.

  6. Откатился на 3.9.2, посмотрел в логе, после включения интерфейса с помощью переключателя, вслед за сообщением 

    Network::Interface::Ppp: "PPPoE0": connection service standby.

    сразу происходит запуск pppd и последующая установка соединения.

    В 4.0 Alpha 1 pppd не запускается, и, соответственно, не устанавливается соединение.
    Но возникает вопрос, почему же тогда работает автоподключение при загрузке кинетика, а также после ручного выкл/вкл WAN интерфейса через cli.

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

    Визуально после нажатия состояние переключателя изменяется, но интерфейс остается выключенным:

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

    1113004597__20221229_103901.png.28823cd532a428bb86882a2c2f75a960.png

    Если перезагрузить страницу, переключатель вернется в выключенное положение:

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

    630446195__20221229_103924.png.33f5a5587c223dd5f4d7c39167e792c2.png

    Запустить соединение удается только через ручное включение PPPoE0 в cli и последующее выключение-включение интерфейса GigabitEthernet1.

    • Upvote 1
  8. Обнаружил на KN-3010 некорректное отображение входящего трафика в мониторе.

    У устройств, подключенных по кабелю, отображение корректное.

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

    При этом, если эти же устройства подключить к экстендерам KN-3210, учет корректный.

    • Upvote 2
  9. В попытках выяснить причину, включил на кинетике режим отладки и выгрузку логов на syslog сервер. С момента написания последнего сообщения, только сегодня удалось снова словить "отвал".

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

    При необходимости, могу выложить полный лог с момента запуска режима отладки.

  10. Спустя 11 дней снова словил "отвал".

    За это время обновился до 3.9.0, а также экспериментировал с настройками:

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

    Лог прикрепил.

    • Thanks 1
  11. В 3.9.0 исправление не подтверждаю. Гиперссылка также накладывается. 

    На форуме есть упоминание в списке изменений об исправлении, но на сайте docs.keenetic.com этого нет.

  12. 5 часов назад, hellonow сказал:

     с ходу воспроизвести не получилось

    По прикрепленным логам видно, что где-то на это ушло несколько дней, а где-то достаточно и пары часов, поэтому вряд ли удастся это обнаружить сразу после запуска.

     

    5 часов назад, hellonow сказал:

    Если указать выше интервал? Другой домен, например google.com?

    Пока что только увеличил интервал и порог срабатывания на ya.ru. Буду наблюдать за поведением.
    Короткий интервал и малое количество попыток для срабатывания устанавливал из-за того, что у Мегафона в моей местности перегружены окружающие базовые станции, и бывают моменты, когда интернет может не работать вообще в течение 20-40 секунд. При такой ситуации само подключение модема к сети не рвется, уровень связи остается на том же уровне, просто нет доступа к интернету. В таком случае, кинетик достаточно быстро переключается на IPoE, одновременно с этим перезагружая модем по питанию для переподключения.

     

    5 часов назад, hellonow сказал:

    В других self-test файлах в логе фиксируется, что домен не резолвится

    Но стоит отметить, что домен не резолвится только при загрузке кинетика. Во вчерашнем 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". 

    Но далее по логам такой ошибки больше не появляется.

  13. Обнаружил странное поведение 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
  14. 9 часов назад, enterfaza сказал:

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

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

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

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

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

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

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

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

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

     

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

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

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

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