Не стабильное облако wirenboard.cloud

1

Добрый день. К облаку подключается без проблем, но далее при переходе конкретно в веб-интерфейс начинаются переподключения.
root@wirenboard-AA27OEMM:~# journalctl -u mosquitto -f
– Journal begins at Thu 2025-06-26 03:44:57 MSK. –
Jan 14 11:59:31 wirenboard-AA27OEMM mosquitto[1867]: 1768381171: Client wb-mqtt-homeui-NqVdEf7WoX closed its connection.
Jan 14 11:59:33 wirenboard-AA27OEMM mosquitto[1867]: 1768381173: New client connected from 188.126.41.156:0 as wb-mqtt-homeui-NqVdEf7WoX (p2, c1, k60).
Jan 14 12:00:42 wirenboard-AA27OEMM mosquitto[1867]: 1768381242: Client wb-mqtt-homeui-NqVdEf7WoX closed its connection.
Jan 14 12:00:44 wirenboard-AA27OEMM mosquitto[1867]: 1768381244: New client connected from 188.126.41.156:0 as wb-mqtt-homeui-NqVdEf7WoX (p2, c1, k60).
Jan 14 12:01:10 wirenboard-AA27OEMM mosquitto[1867]: 1768381270: New connection from /var/run/mosquitto/mosquitto.sock:0 on port 0.
Jan 14 12:01:10 wirenboard-AA27OEMM mosquitto[1867]: 1768381270: New client connected from /var/run/mosquitto/mosquitto.sock:0 as auto-E465C419-A935-DE01-7020-D3D3DD10EE84 (p2, c1, k60).
Jan 14 12:01:10 wirenboard-AA27OEMM mosquitto[1867]: 1768381270: Client auto-E465C419-A935-DE01-7020-D3D3DD10EE84 disconnected.
Jan 14 12:01:14 wirenboard-AA27OEMM mosquitto[1867]: 1768381274: New connection from /var/run/mosquitto/mosquitto.sock:0 on port 0.
Jan 14 12:01:14 wirenboard-AA27OEMM mosquitto[1867]: 1768381274: New client connected from /var/run/mosquitto/mosquitto.sock:0 as auto-C1F686C2-CB29-F5DD-7835-7FE5D7C315BC (p2, c1, k60).
Jan 14 12:01:14 wirenboard-AA27OEMM mosquitto[1867]: 1768381274: Client auto-C1F686C2-CB29-F5DD-7835-7FE5D7C315BC disconnected.
Jan 14 12:01:52 wirenboard-AA27OEMM mosquitto[1867]: 1768381312: Client wb-mqtt-homeui-NqVdEf7WoX closed its connection.
Jan 14 12:01:54 wirenboard-AA27OEMM mosquitto[1867]: 1768381314: New client connected from 188.126.41.156:0 as wb-mqtt-homeui-NqVdEf7WoX (p2, c1, k60).
Соответственно очень большие задержки при передаче информации в дашбордах.

приложен диагностический архив, доступен только сотрудникам поддержки
(569,5 КБ)

4

Здравствуйте!
Спасибо за диагархив – к сожалению все выглядит, как очень неустойчивый канал. В архиве не вижу других ошибок. У вас нет возможности, хотя бы временно, переподключить контроллер через другого провайдера?

5

Добрый день! Скажите, по-прежнему подключение к облаку нестабильно? Не удалось попробовать поддключаться через другого провайдера?

6

День добрый. Провайдера не менял. Подключился к той же сети через wi-fi и проблема исчезла. Изначально задумывалось что проводное соединение будет надёжней, но с ним непонятная проблема(описанная выше).

7

Понятно, да – от проводного подключения всегда ожидаешь большей стабильностии надежности. Если переключение на Wi-Fi тут же решило проблему, то это с высокой долей вероятности исключает проблемы с провайдером/блокировками.
В логах в диагархиве не вижу каких-то указаний на то, что проводное подключение физически сбоит – стабильное физическое подключение на 100 Мбит/с, но в логах, конечно, не увидеть, есть ли ошибки на интерфейсе. 25 сентября только вижу “device has no carrier”. Ну и практика показывает, что в наших контроллерах проводное подключение действительно надежно.
Если решите вернуться к отладке связи с облаком по Ethernet, то дальнейший план диагностики такой:

  1. Переключить выход в интернет через eth0 и убедиться, что подключение к облаку по-прежнему нестабильно.
  2. Показать результат выпонеия команды
    ethtool -S eth0 | egrep -i "crc|error|drop|miss|timeout" | head -n 50
  3. Установить утилиту MyTraceRoute
    apt install -y mtr
    и показать вывод
    mtr -ezbw -c 200 agent.wirenboard.cloud
    (получение результата займет несколько минут).
  4. Установить tcpdump (для сполучения дампа трафика меду контроллером и облаком)
    apt install -y tcpdump
    и запустить на 5 минут
    tcpdump -i eth0 -nn -s 0 -w eth0_cloud.pcap host agent.wirenboard.cloud
    (для останова нажмите Ctrl-С).
  5. Переключится на Wi-Fi (предполагаю, что это порт wlan1) и убедиться, что теперь подключение к облаку стабильно.
  6. Еще раз
    mtr -ezbw -c 200 agent.wirenboard.cloud
  7. Еще раз на 5 минут запустить tcpdump:
    tcpdump -i wlan1 -nn -s 0 -w wlan1_cloud.pcap host agent.wirenboard.cloud
    и приложить в ответе оба дампа трафика: eth0_cloud.pcap и wlan1_cloud.pcap
  8. Приложить вывод команд из пп. 2, 3, 6 и новый диагностический архив.
8

Для eth0
root@wirenboard-AA27OEMM:~# ethtool -S eth0 | egrep -i “crc|error|drop|miss|timeout” | head -n 50
tx_payload_error: 0
tx_ip_header_error: 0
overflow_error: 0
ipc_csum_error: 0
rx_crc_errors: 0
rx_missed_cntr: 0
fatal_bus_error_irq: 0
phy_eee_wakeup_error_n: 0
timestamp_dropped: 0
root@wirenboard-AA27OEMM:~# mtr -ezbw -c 200 agent.wirenboard.cloud
Start: 2026-01-24T13:01:46+0300
HOST: wirenboard-AA27OEMM Loss% Snt Last Avg Best Wrst StDev

  1. AS??? 192.168.0.1 0.0% 200 0.3 0.5 0.3 2.7 0.2
  2. AS??? 10.8.1.208 0.0% 200 2.6 6.5 0.7 23.4 5.4
  3. AS??? 10.1.7.10 0.0% 200 1.8 3.7 1.0 21.7 3.4
  4. AS??? 109.239.137.217 0.0% 200 4.2 5.6 2.3 29.1 4.9
  5. AS49505 92.53.94.72 0.0% 200 3.3 4.6 2.1 31.4 4.2
  6. AS50340 5.35.10.8 0.0% 200 4.3 4.7 2.2 18.3 3.5

Для wi-fi
root@wirenboard-AA27OEMM:~# mtr -ezbw -c 200 agent.wirenboard.cloud
Start: 2026-01-24T14:00:31+0300
HOST: wirenboard-AA27OEMM Loss% Snt Last Avg Best Wrst StDev

  1. AS??? 192.168.0.1 0.0% 200 1.6 2.2 0.7 15.4 1.9

  2. AS??? 10.8.1.208 0.0% 200 3.8 3.8 1.5 20.0 2.6

  3. AS??? 10.1.7.10 0.0% 200 4.9 4.1 2.0 18.6 2.1

  4. AS??? 109.239.137.217 0.0% 200 10.9 6.4 3.2 38.3 4.5

  5. AS49505 92.53.94.72 0.0% 200 4.5 5.3 3.1 24.5 2.8

  6. AS50340 5.35.10.8 0.0% 200 3.3 5.2 3.1 20.2 2.4

    приложен диагностический архив, доступен только сотрудникам поддержки
    (595,3 КБ)

    wlan1_cloud.pcap (2,1 МБ)

    eth0_cloud.pcap (2,8 МБ)

10

Большое спасибо большое за диагностику! Буду изучать, вернусь завтра с ответом.

11

Посмотрл внимательно трафик и диагархив. Я немного ошибся с командой, которая делает дамп трафика через беспроводную сеть, и собрался трафик только от контроллера в сторону облака, но это не принципиально. Очень хорошо видно, как TCP-трафик через езернет “замирает” на 27-28 секунд из-за серии неудачных повторов (TCP retransmissions).
То есть причина – потеря пакетов.
Судя по остальной диагностике счетчики ошибок – нулевые, это значит, что скорее всего проблема не в физическом соединении контроллера – маршрутизатор. Хотя, конечно, счетчики ошибок на порту маршрутизатора могут быть и ненулевые.

Есть ли какое-то активное сетевое устройство между маршрутизатором и контроллером (коммутатор)? Или они соединены напрямую?
Можете ли вы сменить порт, к которому подключен кабель от контроллера?
Пока мне кажется, что проблема в самос маршрутизаторе или промежуточном коммутаторе (если есть). Скорее всего, пакеты теряются там.
Есть ли проблемы со связью у других устройств, подключенных по проводу к маршрутизатору? Можете ли вы временно заменить маррутизатор (коммутатор)? Проблем с Ethernet-портом контрллера я пока не увидел.

12

Добрый день! Хотел поинтересоваться, получается ли диагностировать проблему?

13

День добрый. Проблемой проводного подключения особо не занимался, переключил на wi-fi и всё работает без проблем. Промежуточных устройств нет, контроллер непосредственно подключается к роутеру. Вы сказали что проблема 100% не в контроллере, тогда вопросы снимаются, спасибо. Далее чуть позже буду разбираться со своей сетью.

14

Хорошо! Если будет важно, нужно, актуально – напишите тогда в новую тему, сославшись на эту.