Купил новый контроллер WB 7. Сталкиваюсь с постоянным зависание web консоли, причем сначала на мобильном телефоне android (отражает что страница offline), затем спустя некоторое время отваливается доступ к консоли с ПК, ping к устройству по сети не проходит, при этом на контроллере мигает зеленая лампочка, никаких признаков неисправности не выдает.
Лечится все рестартом контроллера. После перезапуска все отлично работает.
Не подскажете куда копать? какие/где логи посмотреть? или может быть какие-то настройки сети проверить?
Добрый день.
Для начала - опишите как спланирована сеть. Каким (какими) интерфейсами в нее включен контроллер, как (для DHCP - чем) настраиваются адреса.
Ну и - посмотрите в архив с диагностической информацией контроллера. Создание архива описано в документации. И выложите архив сюда. Или в логи, в логах NetworkManager есть записи о состоянии соединений.
Во вложении файлы (настройка сети на контроллере, настройка на роутере, закреплен выделенный адрес, без доступа в интернет).
Вчера (05.06.2024) где-то в 23:00 обнаружил что консоль контроллера снова не отвечает, выполнил перезагрузку с кнопки. В системном логе за это время вижу странную хронологию (текст ниже), может быть проблема с системным временем (у контроллера нет выхода в интеренет и доступа к ntp серверу)
| 05-06-2024 23:04:19.631 | iio-rescale a2-volt: using raw+scale source channel |
|---|---|
| 05-06-2024 23:04:19.544 | wbec-rtc wbec-rtc.6.auto: setting system clock to 2024-06-05T20:04:19 UTC (1717617859) |
| — ДАТА В ЖУРНАЛЕ ИЗМЕНИЛАСЬ, ПРИ ЭТОМ ВСЕ ВРЕМЯ КОНТРОЛЛЕР РАБОТАЛ | |
| 02-06-2024 08:47:40.188 [ntp] | error resolving pool 0.debian.pool.ntp.org: Name or service not known (-2) |
| 02-06-2024 08:47:40.188 [ntp] | error resolving pool 0.debian.pool.ntp.org: Name or service not known (-2) |
| 02-06-2024 08:47:34.786 [init.scope] | knxd.service: Failed with result ‘exit-code’. |
| 02-06-2024 08:47:34.785 [init.scope] | knxd.service: Main process exited, code=exited, status=1/FAILURE |
log_20240606T010705.log (669,9 КБ)
В приведенном файле всего 3 минуты перед перезапуском, не вижу в нем странного, ntp по крайней мере пытается подключиться.
То что в процессе запуска время устанавливается по RTC- это нормально, практически в любом компьютере так.
Советую все ж проверить логи сети за период когда контроллер недоступен. Ну и совсем однозначная диагностика - подключиться к контроллеру используя debug console и проверить с него.
Уточните за какой период нужен лог? и прошу прощения за глупый вопрос: можно ли как-то задать диапазон для выгрузки лога? в WEB UI я вижу только время начала выгрузки, конец выгрузки формируется скролом, а скролить столько строк времени нет) или может нужна выгрузка только с ошибками?
Поясните пожалуйста что вы подразумеваете под логом сети? это какой-то файл на контроллере или мне эту информацию каким-то образом с роутера необходимо получить. дайте больше деталей пожалуйста
Проверить что? доступность контроллера через debug console или на что-то еще обратить внимание?
Обычно так пользуюсь
Ну и да, логи с роутера - тоже помогут, конечно.
Подключился к контроллеру через debug console, на команды реагирует нормально, провел базовую диагностику информация в файле во вложении.
- вытащить лог у меня не получилось, может вы подскажете. Попытка вывести лог в файл через запись с терминала MobaXterm не увенчалась успехом, т.к. файл большой и видимо заканчивается буфер (после нескольких тысяч строк вывод останавливает). скопировал лог в файл на контроллере, но по SSH к контроллеру подключиться невозможно (вытащить файл лога с контроллера не могу). могу конечно его ребутнуть и забрать файл по SSH, но тогда он снова станет работать и диагностика прервется еще на несколько дней. Что-то можете посоветовать?
- по логам/командам вижу что время на контроллере на 4 часа отличается (меньше) от реального времени
- с контроллера устройства в локальной сети пингуются (информация в логе), но сам контроллер с локальных устройств не пингуется (после рестарта пинговался)
- на роутере ошибок или сообщений связанных с маком контроллера не вижу, только эти сообщения:
||Line 812: [I] Jun 3 21:05:22 ndm: Network::Interface::Rtx::WifiMonitor: WifiMaster0/AccessPoint0: STA(***MAC ADDR ***) had deauthenticated by STA (reason: STA is leaving or has left BSS). |
|—|—|
||Line 813: [I] Jun 3 21:06:15 ndm: Network::Interface::Rtx::WifiMonitor: WifiMaster0/AccessPoint0: STA(***MAC ADDR ***) had associated successfully. |
||Line 814: [I] Jun 3 21:06:15 ndm: Network::Interface::Rtx::WifiMonitor: WifiMaster0/AccessPoint0: STA(***MAC ADDR ***) set key done in WPA2/WPA2PSK. |
||Line 890: [I] Jun 3 23:58:32 ndm: Network::Interface::Rtx::WifiMonitor: WifiMaster0/AccessPoint0: STA(***MAC ADDR ***) GTK rekey done, group cipher AES. |
||Line 1789: [I] Jun 5 00:33:08 ndm: Network::Interface::Rtx::WifiMonitor: WifiMaster0/AccessPoint0: STA(***MAC ADDR ***) GTK rekey done, group cipher AES. |
||Line 2542: [I] Jun 5 23:03:43 ndm: Network::Interface::Rtx::WifiMonitor: WifiMaster0/AccessPoint0: STA(***MAC ADDR ***) had deauthenticated by STA (reason: STA is leaving or has left BSS). |
||Line 2543: [I] Jun 5 23:04:40 ndm: Network::Interface::Rtx::WifiMonitor: WifiMaster0/AccessPoint0: STA(***MAC ADDR ***) had associated successfully. |
||Line 2544: [I] Jun 5 23:04:40 ndm: Network::Interface::Rtx::WifiMonitor: WifiMaster0/AccessPoint0: STA(***MAC ADDR ***) set key done in WPA2/WPA2PSK. |
||Line 2591: [I] Jun 6 01:07:44 ndm: Network::Interface::Rtx::WifiMonitor: WifiMaster0/AccessPoint0: STA(***MAC ADDR ***) GTK rekey done, group cipher AES. |
||Line 3519: [I] Jun 7 01:42:19 ndm: Network::Interface::Rtx::WifiMonitor: WifiMaster0/AccessPoint0: STA(***MAC ADDR ***) GTK rekey done, group cipher AES. |
MobaXterm terminal output.log (11,9 КБ)
log-file.rar (1,4 МБ)
Контроллер перезагрузил, логи вытащил (во вложении).
То есть - с контроллера пакет отправляется , доходит до конечного хоста и успешно возвращается ответ от него? Верно?
А с того же хоста который успешно пингуется - либо, вероятнее) к контролеру не доходит либо не возвращается ответ. В общем - дело в роутере.
Для проверки - возьмите другой, попроще в настройках, Микротик например.
Ну и, как вариант - добавьте контроллер в облако, для проверки.
- Как вы так все легко спихнули на роутер)) есть какие-то обоснования этих выводов? Какие диагностические команды я могу выполнить для подтверждения вашей версии?
Очень странное требование, я настроил сетевое подключение в соответствии с инструкцией контроллера, в описании контроллера нет заявлений что он не совместим с какими-то версиями роутеров, данный роутер представляют у меня целевую конфигурацию и я хотел бы чтобы функционал заработал на нем.
не планирую пользоваться облачными сервисами и открывать доступ контроллеру во внешнюю сеть, искал контроллер как раз без доступа к облаку.
P.S. Вы меня извините конечно, но как у нового пользователя у меня не очень приятный опыт работы с вашим устройством и качеством поддержки. У вас есть какой-то платный сервис поддержки или процесс эскалации? я не представляю как можно строить какую-то сколько-нибудь критичную инфраструктуру на оборудовании с подобными сбоями функционала и временем решения проблем со стороны поддержки. (это не претензия, а пользовательский feedback если что)
Пример: слежу за пакетами проходящиими через интерфейс к контроллеру:
Выполняю при этом на хосте за маршутизатором:
traceroute 10.0.0.79
traceroute to 10.0.0.79 (10.0.0.79), 30 hops max, 60 byte packets
1 10.0.28.22 (10.0.28.22) 46.622 ms 45.019 ms 44.605 ms
2 10.0.0.79 (10.0.0.79) 42.926 ms 42.666 ms 42.441 ms
Вижу что пакеты уходят, проходят через роутер и возвращаются.
Если бы пакеты с контроллера ходили бы, в том числе и в интернет - видел бы и их.
Команду - да тот же traceeroute, обычно достаточно. Ну и посмотреть куда идеут и где останавливаюются.
Совместим. Контроллер - обыкноввенный компьютер.
Что можем сделать лучше? Мы разрабатываем и производим оборудование, обычно настройкой и пусконаладкой занимаются партнеры.
Ну и, как писал выше - контроллер обычный компьютер, с таким же Debian, процесс настройки и диагностики соединений не отличается ничуть.
traceroute на контроллере не установлен, в репозитарии ОС его тоже не вижу. у контроллера нет доступа во внешнюю сеть, буду доустанавливать “вручную”.
“с клиентского устройства” на ОС Windows трассировка выглядит примитивно, устройства находятся в рамках локальной сети (192.168.0.214 - контроллер WB):
C:\Users\username>tracert 192.168.0.214
Трассировка маршрута к 192.168.0.214 с максимальным числом прыжков 30
1 1 ms 1 ms 1 ms 192.168.0.214
Трассировка завершена.
Сейчас подключение к консоли работает. Для проведения диагностики видимо придется дождаться очередного зависания (обычно это раз в 1-2 дня случается)
Подскажите, удалось ли найти какую-то полезную информацию в системных логах контроллера (которые я высылал ранее)? логи были в том числе за время недоступности контроллера? может вы видите там какие-то ошибки или попытки внешнего подключения?
Нет, как раз в репозиториях есть:
apt policy traceroute
traceroute:
Candidate: 1:2.1.0-2+deb11u1
Version table:
*** 1:2.1.0-2+deb11u1 500
500 http://debian-mirror.wirenboard.com/debian bullseye/main armhf Packages
100 /var/lib/dpkg/status
Ошибок - нет, не вижу. Ну и подклюючения снаружи не логирутся по умолчани. Разве что в логах nginx можно http запросы глянуть.
По опыту - все ж дело внастройках роутера. Может быть с бриджом сетей что-то не так. И, кстати, для проверки - попробуйте при повторении перезапустить сам роутер?
похоже что нет)
package_list (26,3 КБ)
Посмотрел, там только информация о подключениях после рестарта контроллера, за время пока контроллер был недоступен ничего нет. Ошибок в логах тоже нет
попробую
Ну очевидно же что список пакетов - не обновлен…
Выполните
apt update
вы имеете в виду из какого-то локального репозитория подгрузить?
на всякий случай дублирую (я неоднократно писал выше что у контроллера нет доступа во внешнюю сеть)
Для того чтобы исключить недопонимание вот вывод запрошенной вами команды:
root@wirenboard-APBCR36S:/var/log/nginx# apt update
Err:1 http://deb.wirenboard.com/wb7/bullseye stable InRelease
Could not resolve ‘deb.wirenboard.com’
Err:2 https://deb.nodesource.com/node_16.x bullseye InRelease
Could not resolve ‘deb.nodesource.com’
Err:3 Index of /debian bullseye InRelease
Could not resolve ‘debian-mirror.wirenboard.com’
Err:4 Index of /debian bullseye-updates InRelease
Could not resolve ‘debian-mirror.wirenboard.com’
Err:5 Index of /debian bullseye-backports InRelease
Could not resolve ‘debian-mirror.wirenboard.com’
Err:6 Index of /debian-security bullseye-security InRelease
Could not resolve ‘debian-mirror.wirenboard.com’
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
All packages are up to date.
W: Failed to fetch http://debian-mirror.wirenboard.com/debian/dists/bullseye/InRelease Could not resolve ‘debian-mirror.wirenboard.com’
W: Failed to fetch http://debian-mirror.wirenboard.com/debian/dists/bullseye-updates/InRelease Could not resolve ‘debian-mirror.wirenboard.com’
W: Failed to fetch http://debian-mirror.wirenboard.com/debian/dists/bullseye-backports/InRelease Could not resolve ‘debian-mirror.wirenboard.com’
W: Failed to fetch http://debian-mirror.wirenboard.com/debian-security/dists/bullseye-security/InRelease Could not resolve ‘debian-mirror.wirenboard.com’
W: Failed to fetch https://deb.nodesource.com/node_16.x/dists/bullseye/InRelease Could not resolve ‘deb.nodesource.com’
W: Failed to fetch http://deb.wirenboard.com/wb7/bullseye/dists/stable/InRelease Could not resolve ‘deb.wirenboard.com’
W: Some index files failed to download. They have been ignored, or old ones used instead.
Да, можно, например использовать другой. То есть - если нет доступа к основному репозиторию - то нужно делать локальный или заниматься работой apt вручную - качать пакеты, заботиться о их зависимостях.