Даже не знаю что сказать.
Могу попробовать воспроизвести, конечно.
Какой минимальный скрипт и настройки позволит это сделать?
То есть чтобы воспроизвести - надо именно вот такой стенд делать, с меньшим количеством скриптов - не воспроизведется?
Я как раз не готов ответить. Знал бы - решил вопрос самостоятельно)
Т.е. это все работало до какого-то момента, потом началась такая проблема.
День добрый!
Видео с проблемой [wb-mqtt-serial] ERROR: [serial client] Serial protocol error: IP:23 connect error: No route to host (113)
Снова же проблема появилась на ровном месте.
Проблема на контроллере WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
На контроллерах ниже все ок.
WB7 7.3.3E, wb-2304, stable, s/n AVZOK2XH
WB7 7.3.3E, wb-2207, stable, s/n AP72NKRI
- На видео модуль WB-MIO-E v.2 был подключен к контроллеру AP5CRMOL, недавно появилась ошибка;
- подключаем к контроллеру AVZOK2XH, ошибка [wb-mqtt-serial] WARNING: <192.168.2.144:23>: closed due to repetetive errors;
- подключаем к контроллеру AP72NKRI - все ок, все работает;
- снова подключаем к контроллеру AVZOK2XH - все ок, все работает;
- снова подключаем к контроллеру AP5CRMOL - ошибка [wb-mqtt-serial] ERROR: [serial client] Serial protocol error: IP:23 connect error: No route to host (113);
- Ко всему остальному я уже все контроллеры вынес в менее жаркое место, что видно на видео. Зарядки нет.
Все контроллеры имеют одинаковые настройки сети с одинаковым mask, gw и dns.
Контроллеры имеют одинаковую версию обновления apt.
WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
WB7 7.3.3E, wb-2304, stable, s/n AVZOK2XH
ls -l /var/lib/apt/periodic/update-stamp
-rw-r–r-- 1 root root 0 Jul 18 03:57 /var/lib/apt/periodic/update-stamp
ls -l /var/lib/apt/periodic/update-stamp
-rw-r–r-- 1 root root 0 Jul 17 05:10 /var/lib/apt/periodic/update-stamp
Следующий момент:
Контроллер WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
Добавляю новые устройства, например Чиллер (WB-MAI6 через WB-MIO-E v.2). 2 датчика давления и 2 температуры.
После сохранения устройств перестают работать правила. Видно что драйвер перезагружает все устройства, добавляются новые. И данные, из части правил перестают обновляться. Т.е. на графике “флэт”.
Проблема решается service wb-rules restart, но это грабли. Так неправильно и не должно быть.
Контроллер - точно такой жже компьютер за которым мы работаем. С совершенно теми же способами настройки. Абсолютно.
А запущенный ping с тем же адрсом - что возвращает?
Через какой маршрут доступ к целевому адресу? Какой маршрут есть default, какой (если есть) именно в подсеть целевую? Я предполагаю неверные настройки сети.
Каой план сети и маршрутизации в ней?
Сейчас батарея имеет критически малый заряд. Какое время она уже заряжается?
Да, соглашусь. А как реализовано в правилах чтение устройст? Есть ли что-то динамически добавляемое?
Возможно, какой-то минимальный пример, воспроизводящий поведение?
Кстати, если перезапустить wb-mqtt-serial - первое опубликованное в mqtt значение энергии от счетчиков - тоже некорректно?
Пришлите пожалуйста файл /var/lib/wb-mqtt-serial/libwbmqtt.db с контроллера.
Контроллер - точно такой жже компьютер за которым мы работаем. С совершенно теми же способами настройки. Абсолютно.
Именно поэтому я и выбрал WB
Каой план сети и маршрутизации в ней?
Сейчас батарея имеет критически малый заряд. Какое время она уже заряжается?
Да, соглашусь. А как реализовано в правилах чтение устройст? Есть ли что-то динамически добавляемое?
Возможно, какой-то минимальный пример, воспроизводящий поведение?
Только устройства отсюда. Больше ничего нет пока что)
Кстати, если перезапустить wb-mqtt-serial - первое опубликованное в mqtt значение энергии от счетчиков - тоже некорректно?
Пришлите пожалуйста файл /var/lib/wb-mqtt-serial/libwbmqtt.db с контроллера.
libwbmqtt.db (28 КБ)
На скриншоте вижу ответ от 192.168.2.133. Почему?
Покажите traceroute к этому ж узлу. Ну и лучше все ж текстом, скриншоты чтаются не очень.
Тут совсем все удивительно
- WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
ping 192.168.2.144
PING 192.168.2.144 (192.168.2.144) 56(84) bytes of data.
From 192.168.2.133 icmp_seq=1 Destination Host Unreachable
From 192.168.2.133 icmp_seq=2 Destination Host Unreachable
From 192.168.2.133 icmp_seq=3 Destination Host Unreachable
traceroute 192.168.2.144
traceroute to 192.168.2.144 (192.168.2.144), 30 hops max, 60 byte packets
1 wirenboard-AP5CRMOL.local (192.168.2.133) 3122.103 ms !H 3121.850 ms !H 3121.685 ms !H
- WB7 7.3.3E, wb-2304, stable, s/n AVZOK2XH
ping 192.168.2.144
PING 192.168.2.144 (192.168.2.144) 56(84) bytes of data.
64 bytes from 192.168.2.144: icmp_seq=1 ttl=255 time=1.08 ms
64 bytes from 192.168.2.144: icmp_seq=2 ttl=255 time=1.60 ms
64 bytes from 192.168.2.144: icmp_seq=3 ttl=255 time=4.51 ms
64 bytes from 192.168.2.144: icmp_seq=4 ttl=255 time=9.43 ms
traceroute 192.168.2.144
traceroute to 192.168.2.144 (192.168.2.144), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
- WB7 7.3.3E, wb-2207, stable, s/n AP72NKRI
ping 192.168.2.144
PING 192.168.2.144 (192.168.2.144) 56(84) bytes of data.
64 bytes from 192.168.2.144: icmp_seq=1 ttl=255 time=1055 ms
64 bytes from 192.168.2.144: icmp_seq=2 ttl=255 time=35.5 ms
64 bytes from 192.168.2.144: icmp_seq=3 ttl=255 time=2.65 ms
64 bytes from 192.168.2.144: icmp_seq=4 ttl=255 time=1.74 ms
traceroute 192.168.2.144
traceroute to 192.168.2.144 (192.168.2.144), 30 hops max, 60 byte packets
1 wirenboard-AP72NKRI.local (192.168.2.132) 3151.652 ms !H 3151.488 ms !H 3151.431 ms !H
- Windows
ping 192.168.2.144
Статистика Ping для 192.168.2.144:
Пакетов: отправлено = 21, получено = 21, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 2мсек, Максимальное = 10 мсек, Среднее = 5 мсек
tracert 192.168.2.144
Трассировка маршрута к 192.168.2.144 с максимальным числом прыжков 30
1 * 110 ms 5 ms 192.168.2.144
Трассировка завершена.
- Скрин
Да. Почему ответ контроллер приходит от узла 192.168.2.133?
Если поменть адреса машинок друг с другом - то поведение такое же?
Почему ответ контроллер приходит от узла 192.168.2.133 ?
Ну потому что любое устройство с назначенным адресом при отсутствии ответа от целевого устройства (или несуществующего) будет давать ответ от себя что адрес недоступен. Это нормальное поведение в любой системе. Проверьте у себя. На скрине моя сеть и удаленная сеть, никак не связанная с моей.
Разница в контроллерах в сетевом демоне. Как мне его переключить на старую версию, networks? Мне кажется все проблемы оттуда.
Как мне его переключить на старую версию, networks? Мне кажется все проблемы оттуда.
Поотключал все интерфейсы (включая gsm), остался только eth0.
Дропнул Network Manager, и?
На контроллере WB7 7.3.3E, wb-2304, stable, s/n AVZOK2XH стало так же как и на * WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
Какие идеи?
SSH
Welcome to Wiren Board 7.3.3 (s/n AVZOK2XH), release wb-2304 (as stable)
Linux wirenboard-AVZOK2XH 5.10.35-wb133+wb101 #1 SMP Mon May 29 08:56:14 UTC 2023 armv7l GNU/Linux
System load: 6.08 1.62 0.55 Up time: 0 min
Memory usage: 19% of 997M Usage of /: 66% of 976M /mnt/data: 30% of 4.9G
8 package updates are available; type ‘apt update && apt upgrade’ to update them.
Last login: Fri Jul 21 06:35:08 2023 from 192.168.5.239
root@wirenboard-AVZOK2XH:~# ping 192.168.2.144
PING 192.168.2.144 (192.168.2.144) 56(84) bytes of data.
From 192.168.2.131 icmp_seq=1 Destination Host Unreachable
From 192.168.2.131 icmp_seq=2 Destination Host Unreachable
From 192.168.2.131 icmp_seq=3 Destination Host Unreachable
From 192.168.2.131 icmp_seq=4 Destination Host Unreachable
From 192.168.2.131 icmp_seq=5 Destination Host Unreachable
^C
— 192.168.2.144 ping statistics —
6 packets transmitted, 0 received, +5 errors, 100% packet loss, time 5166ms
pipe 4
root@wirenboard-AVZOK2XH:~# traceroute 192.168.2.144
traceroute to 192.168.2.144 (192.168.2.144), 30 hops max, 60 byte packets
1 wirenboard-AVZOK2XH.local (192.168.2.131) 2522.729 ms !H 2522.567 ms !H 2522.495 ms !H
root@wirenboard-AVZOK2XH:~#
ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.131 netmask 255.255.240.0 broadcast 192.168.15.255
ether 00:85:01:01:57:cf txqueuelen 1000 (Ethernet)
RX packets 298782 bytes 21840850 (20.8 MiB)
RX errors 0 dropped 1838 overruns 0 frame 0
TX packets 501522 bytes 57628721 (54.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 65 base 0x5000
eth1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:85:01:01:f4:35 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 64
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 1167 bytes 65517 (63.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1167 bytes 65517 (63.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.42.1 netmask 255.255.255.0 broadcast 192.168.42.255
ether c4:3c:b0:5f:d1:24 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 15 bytes 900 (900.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Спустя 5 минут…
Пока писал предыдущий текст ситуация поменялась
Ping Trace
root@wirenboard-AVZOK2XH:~# ping 192.168.2.144
PING 192.168.2.144 (192.168.2.144) 56(84) bytes of data.
\64 bytes from 192.168.2.144: icmp_seq=1 ttl=255 time=8.81 ms
64 bytes from 192.168.2.144: icmp_seq=2 ttl=255 time=2.37 ms
64 bytes from 192.168.2.144: icmp_seq=3 ttl=255 time=3.72 ms
^C
— 192.168.2.144 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2008ms
rtt min/avg/max/mdev = 2.368/4.966/8.813/2.775 ms
root@wirenboard-AVZOK2XH:~# traceroute 192.168.2.144
traceroute to 192.168.2.144 (192.168.2.144), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 *^C
Смотрите на правила на маршрутизаторе.
Просто для примера:
Таблица маршрутизации выглядит так:
ip route
default via 10.0.0.2 dev eth0 proto dhcp src 10.0.0.78 metric 55
default via 192.168.42.1 dev wlan1 proto dhcp src 192.168.42.184 metric 205
default dev ppp0 proto static scope link metric 700
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.78 metric 55
10.64.64.64 dev ppp0 proto kernel scope link src 10.39.208.175
192.168.42.0/24 dev wlan1 proto kernel scope link src 192.168.42.184 metric 205
192.168.42.0/24 dev wlan0 proto kernel scope link src 192.168.42.1 metric 600
Я хочу проверить маршрут к какому-то узлу расположенному за два маршрутизатора.
Предполагаю - что мне ответит сначала ближайший, тот который описан у меня как default, потом уже по цепочке.
traceroute 10.77.0.114
traceroute to 10.77.0.114 (10.77.0.114), 30 hops max, 60 byte packets
1 router.lan (10.0.0.2) 0.433 ms 0.339 ms 0.400 ms
2 10.78.0.1 (10.78.0.1) 74.879 ms 75.019 ms 75.029 ms
3 10.77.0.114 (10.77.0.114) 75.050 ms 75.183 ms 74.968 ms
У вас адрес 192.168.2.131 с маской 20.
Прошу прощения, сразу на маску не обратил внимания. Ну и выгляжу довольно глупо, рассуждая про маршрутизацию. Моя вина.
То есть - узлы сегмента сети могут иметь 192.168.0.1 - 192.168.15.254
Естественно что при работе в пределах одного сегмента - пакет не будет отправлен в шлюз а будет попытка определить mac целевого широковещанием.
arp -n
выводит связку ip и mac для целевого (192.168.2.144) хоста?
У вас адрес 192.168.2.131 с маской 20 .
Прошу прощения, сразу на маску не обратил внимания. Ну и выгляжу довольно глупо, рассуждая про маршрутизацию. Моя вина.
Все норм)
выводит связку ip и mac для целевого (192.168.2.144) хоста?
Да.
-
- WB7 7.3.3E, wb-2304, stable, s/n AVZOK2XH
arp -n
Address HWtype HWaddress Flags Mask Iface
1.1.1.1 (incomplete) eth1
192.168.5.239 ether a4:97:b1:d7:aa:2b C eth0
192.168.2.144 ether a6:4c:5e:e6:75:47 C eth0
192.168.2.142 ether a6:4c:5e:e6:6b:a5 C eth0
192.168.2.139 ether a6:4c:5e:e6:6c:71 C eth0
192.168.1.253 ether 6c:3b:6b:ee:18:7c C eth0
192.168.1.117 ether 00:15:5d:01:7a:11 C eth0
192.168.2.137 ether a6:4c:5e:e6:36:c5 C eth0
1.1.1.1 (incomplete) wlan0
192.168.1.220 ether 0c:c4:7a:41:26:1e C eth0
Нет.
-
- WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.5.239 ether a4:97:b1:d7:aa:2b C eth0
192.168.42.80 ether 86:d9:49:34:73:99 C wlan0
192.168.6.28 ether d6:d0:70:08:42:88 C eth0
192.168.1.117 ether 00:15:5d:01:7a:11 C eth0
192.168.2.144 (incomplete) eth0
192.168.2.143 ether a6:4c:5e:e6:6c:6f C eth0
1.1.1.1 (incomplete) wlan1
192.168.1.253 ether 6c:3b:6b:ee:18:7c C eth0
192.168.2.138 ether a6:4c:5e:e6:75:4c C eth0
149.20.4.15 (incomplete) wlan0
192.168.2.141 ether a6:4c:5e:e6:5b:ce C eth0
1.1.1.1 (incomplete) wlan0
1.1.1.1 (incomplete) eth1
130.89.148.77 (incomplete) wlan0
192.168.2.145 ether a6:4c:5e:e6:37:f4 C eth0
192.168.42.67 ether 76:17:a0:45:d3:0d C wlan0
192.168.1.220 ether 0c:c4:7a:41:26:1e C eth0
192.168.2.140 ether a6:4c:5e:e6:74:9c C eth0
128.31.0.62 (incomplete) wlan0
так… а на самом узле 192.168.2.144 - сеть сконфигурирована так же как на 192.168.2.142, например? Просто это устройство - похоже, mac’ом на такой же MGE.
Если пинговать 192.168.2.142 - результат тот же?
а на самом узле 192.168.2.144 - сеть сконфигурирована так же как на 192.168.2.142
Да, иначе бы я не смог получить доступ с других устройств.
Просто это устройство - похоже, mac’ом на такой же MGE.
Ну да, такой же.
С других устройств, любых, я его пингую.
Например шлюз: ping 192.168.2.144
SEQ HOST SIZE TTL TIME STATUS
0 192.168.2.144 56 255 10ms
1 192.168.2.144 56 255 3ms
2 192.168.2.144 56 255 3ms
sent=3 received=3 packet-loss=0% min-rtt=3ms avg-rtt=5ms max-rtt=10ms
- *WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
192.168.2.142 все ок.
ping 192.168.2.142
PING 192.168.2.142 (192.168.2.142) 56(84) bytes of data.
64 bytes from 192.168.2.142: icmp_seq=1 ttl=255 time=13.1 ms
64 bytes from 192.168.2.142: icmp_seq=2 ttl=255 time=2.01 ms
64 bytes from 192.168.2.142: icmp_seq=3 ttl=255 time=3.46 ms
64 bytes from 192.168.2.142: icmp_seq=4 ttl=255 time=2.55 ms
^C
— 192.168.2.142 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.010/5.291/13.141/4.561 ms
root@wirenboard-AP5CRMOL:~# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.2.140 ether a6:4c:5e:e6:74:9c C eth0
192.168.5.239 ether a4:97:b1:d7:aa:2b C eth0
192.168.2.131 ether 00:85:01:01:57:cf C eth0
192.168.2.138 ether a6:4c:5e:e6:75:4c C eth0
192.168.2.141 ether a6:4c:5e:e6:5b:ce C eth0
1.1.1.1 (incomplete) eth1
192.168.1.253 ether 6c:3b:6b:ee:18:7c C eth0
192.168.1.220 ether 0c:c4:7a:41:26:1e C eth0
192.168.1.117 ether 00:15:5d:01:7a:11 C eth0
192.168.2.144 (incomplete) eth0
130.89.148.77 (incomplete) wlan0
128.31.0.62 (incomplete) wlan0
1.1.1.1 (incomplete) wlan0
192.168.2.142 ether a6:4c:5e:e6:6b:a5 C eth0
192.168.2.145 ether a6:4c:5e:e6:37:f4 C eth0
149.20.4.15 (incomplete) wlan0
192.168.2.143 ether a6:4c:5e:e6:6c:6f C eth0
1.1.1.1 (incomplete) wlan1
Так… Ну, это учдивительно, но, кажется мы уже рядом с разгадкой. Контроллеры воткнуты в тупой свитч или с опциями Lx?
Стесняюсь спросить, а mac адреса самих контроллеров - не совпадают ли? С завода - не должны, но их же можно поменять…
И еще - обновите прошивку самих WB-MGE, файл отправляю в личку, производитель его не распространяет.
Да вот уже подумал тестовую среду собрать, с одним свитчем. Потому что все свои уже перетрясли. Одинаковых мак нет, шлюзы о них вообще не знают.
Вернусь через некоторое время с отчетом.
-
Проблема с отсутствием пинга с контроллера до MIO
Решение:
Отдельно стоящие здания подключены через Wifi мост Rocket 5AC Lite. С настройкой “Client isolation”. WB и MIO как раз были на разных зданиях.
Щас ок, все работает. -
Проблема
- с “флет” данных. Зависает wb_rules, зависают правила.
- Происходит после добавления или изменения устройств в
wb-mqtt-serial.confтолько на одном контроллере. Не знаю куда копать.
В этом же форуме выше
Решение (возможно есть лучше):
~# service wb-rules restart
- Проблема
- Error in getting device: Device with given ID doesn’t exist
- failed to convert value ‘’, passing raw, error: This control is incomplete
Из форума выше
Решение (возможно есть лучше):
~# mqtt-delete-retained /devices/#
~# reboot
Я бы еще добавил кнопку в топик System с названием MQTT Clean Retained (подскажите как (ссылка на инстр.), я себе сразу сделаю)
- Проблема с
WARNING: [modbus] failed to read 6 input(s) @ 17664 of device modbus-tcp:36: Serial protocol error: request timed out
Решение помогает частично (значительно сокращает количество ошибок):
Из форума тут
Guard interval (us) в 5000 для всех портов и Response timeout (ms) в 5000
- Проблема с зарядом батареи.
Зарядим отдельно акк, посмотрим как себя будет вести после.
Можно пометить как решение, обновить Wiki.
Но лучше добиться результата с отсутствием ошибок в логе.
Что можно еще сделать?