MQTT RPC request timed out MqttTimeoutError на странице конфига wb-mqtt-serial

Извиняюсь, но проблема не решена, уже 2 года как…
Соглашусь, что проблема сложная и это не ошибка разработчиков и “фу, настоящие админы через вайфай не ходят”, но … факт остается фактом…

TL;DR:

wb-release

Wirenboard release wb-2401 (as stable), target wb7/bullseye

При работе через wifi интерфейс невозможно открыть страницу с конфигом wb-mqtt-serial, если использовать любой проводной eth0/1 - этой ошибки нет.

Пруф:

  1. Подключен к контроллеру через wifi:

Результат попытки открыть wb-mqtt-serial:

  1. Выключил wifi, включил eth1:

Конфиг wb-mqtt-serial отрывается:

Кейс гарантированно многократно воспроизодится…

Я поднимал этот вопрос, но разбор тогда результата не принес.
Мое имхо - дело либо в драйвере, либо в чипе… которые не могут корректно отработать флуд из мелких mqtt msgs …
Еще как вариант допускаю что могли быть потери пакетов в wifi канале…и возможно retry для такого случая не оч хорошо реализован…но это маловероятно…

Все бы ничего, провод так провод, но если пробовать подключаться к ui контроллера через скажем tailscale, то работать с serial конфигом становится невозможно…
а это уже, на мой взгляд, серьезный недостаток…
т.е. провод становится единственным рабочим интерфейсом и зачем тогда такой вайфай…

Кроме того, во время загрузки иногда замечаю следующее:


[ 31.154930] RTL871X: rtw_set_802_11_connect(wlan1) fw_state=0x00000008
[ 31.207077] using random self ethernet address
[ 31.211677] using random host ethernet address
[ 31.448554] RTL871X: start auth
[ 31.454441] RTL871X: auth success, start assoc
r[ 31.600524] dbg0: HOST MAC 1a:55:89:a2:69:44
[ 31.605275] dbg0: MAC 1a:55:89:a2:69:43
oo[ 31.871436] RTL871X: port switch - port0(wlan1), port1(wlan0)
t
Password: [ 33.435661] ------------[ cut here ]------------
[ 33.440770] WARNING: CPU: 3 PID: 1695 at drivers/net/wireless/realtek/rtl8723bu/core/rtw_mlme_ext.c:8267 issue_nulldata+0xb0]
[ 33.453529] Modules linked in: usb_f_rndis u_ether usb_f_mass_storage libcomposite tun nf_tables nfnetlink ip6_tables iptabls
[ 33.488265] CPU: 3 PID: 1695 Comm: RTW_CMD_THREAD Not tainted 5.10.35-wb159+wb1 #1
[ 33.495863] Hardware name: Allwinner sun8i Family
[ 33.500608] Backtrace:
[ 33.503135] [] (dump_backtrace) from [] (show_stack+0x20/0x24)
[ 33.510755] r7:ffffffff r6:600e0013 r5:00000000 r4:c10e4998
[ 33.516466] [] (show_stack) from [] (dump_stack+0xb4/0xd4)
[ 33.523737] [] (dump_stack) from [] (__warn+0xfc/0x158)
[ 33.530732] r9:f0902000 r8:00000009 r7:0000204b r6:00000009 r5:bf27ad60 r4:bf2f1a08
[ 33.538519] [] (__warn) from [] (warn_slowpath_fmt+0x70/0xcc)
[ 33.546042] r7:bf27ad60 r6:0000204b r5:bf2f1a08 r4:00000000
[ 33.552237] [] (warn_slowpath_fmt) from [] (issue_nulldata+0xb0/0x144 [8723bu])
[ 33.561328] r8:000001f4 r7:00000003 r6:00000001 r5:00000000 r4:f08c1000
[ 33.568778] [] (issue_nulldata [8723bu]) from [] (site_survey+0x660/0x748 [8723bu])
[ 33.578215] r10:00000003 r9:f08c2488 r8:00000000 r7:00000000 r6:00000001 r5:00000000
[ 33.586078] r4:f08c1000
[ 33.589392] [] (site_survey [8723bu]) from [] (sitesurvey_cmd_hdl+0x54/0x460 [8723bu])
[ 33.599099] r10:00000003 r9:f08c2488 r8:f08c4000 r7:f08c2488 r6:f08c24a8 r5:f08c1000
[ 33.606961] r4:c435e980
[ 33.610144] [] (sitesurvey_cmd_hdl [8723bu]) from [] (rtw_cmd_thread+0x18c/0x3a8 [8723bu])
[ 33.620192] r10:c42b4000 r9:f08c2488 r8:f08c4000 r7:f08c2488 r6:f08c24a8 r5:f08c1000
[ 33.628051] r4:c435e980
[ 33.631020] [] (rtw_cmd_thread [8723bu]) from [] (kthread+0x168/0x16c)
[ 33.639343] r10:c3eeb814 r9:f08c1000 r8:bf25f8b0 r7:c42b4000 r6:00000000 r5:c30118c0
[ 33.647207] r4:c30119c0
[ 33.649797] [] (kthread) from [] (ret_from_fork+0x14/0x20)
[ 33.657051] Exception stack(0xc42b5fb0 to 0xc42b5ff8)
[ 33.662142] 5fa0: 00000000 00000000 00000000 00000000
[ 33.670354] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 33.678572] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 33.685232] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c014a5a8
[ 33.693096] r4:c30118c0
[ 33.695947] —[ end trace 9c0d1d2a5fed2077 ]—
[ 33.761929] vcc-gmac-phy: disabling
[ 33.765993] dc5ldo: disabling
[ 33.769492] dldo4: disabling
[ 33.775927] vdd-sd-power: disabling
[ 33.779564] errwb73002-disable-can: disabling
[ 33.784271] vcc-sd: disabling
[ 35.569796] RTL871X: rtw_set_802_11_connect(wlan1) fw_state=0x00000008
[ 35.851643] RTL871X: start auth
[ 35.856521] RTL871X: auth success, start assoc
[ 35.864416] RTL871X: rtw_cfg80211_indicate_connect(wlan1) BSS not found !!
[ 35.871345] RTL871X: assoc success
[ 35.893032] RTL871X: send eapol packet
[ 35.931854] RTL871X: send eapol packet
[ 35.936959] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 36.113460] RTL871X: set pairwise key camid:4, addr:90:72:82:07:61:4c, kid:0, type:AES
[ 36.129891] RTL871X: set group key camid:5, addr:90:72:82:07:61:4c, kid:1, type:AES

Такую ошибку тоже периодически (по ощущениям - раз в 10-15 открытий) вижу. Но у меня так получается через проводный интерфейс. Точнее так: клиент через LTE-роутер, который по проводу подключен к wiren board.

Добрый день.
Не воспроизводится - никак.
Проверил с телефона, подключаясь к точке доступа контроллера ну и с компьютера. Как напрямую так и к контроллеру подключенному к точке доступа в режиме клиента.

На компьютере Chrome 123.0.6312.122 (Официальная сборка), (64 бит), обычный 12 Debian.
Советую попробовать testing, там слегка переработан именно механизм конфигурирования serial.

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

у меня убунту (и 16 и 20 и 22.04), тот же хром…

увидел вашу ошибку… отключите точку доступа на контроллере, вообще… поднимите dhcp клиента, получите айпи на вайфай интерфейсе и на нем тестируйте. видимо это важно

Совершенно без проблем, отключил точку доступа настроил на интерфейсе wlan1 соединение клиентом:

ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether e8:eb:1b:35:10:16 brd ff:ff:ff:ff:ff:ff
4: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether e8:eb:1b:35:13:75 brd ff:ff:ff:ff:ff:ff
5: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether f0:c8:14:49:f2:42 brd ff:ff:ff:ff:ff:ff
6: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether f2:c8:14:49:f2:42 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.126/24 brd 10.0.0.255 scope global dynamic noprefixroute wlan1
       valid_lft 8322sec preferred_lft 8322sec
    inet6 fe80::920e:c468:34a5:4153/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
7: dbg0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 1a:55:89:a2:69:43 brd ff:ff:ff:ff:ff:ff

5 и 5 попыток:


Ну, единственное что из крупного грузится - ответ rpc на 4 мегабайта

ну просто мистика какая то…

У меня была такая же проблема. Ошибка возникает после нескольких дней аптайма, может даже несколько недель.

попробуйте с отключенным inet6 на wlan1

root@wirenboard-AWI3MCGC:~# sysctl -w net.ipv6.conf.wlan1.disable_ipv6=1
net.ipv6.conf.wlan1.disable_ipv6 = 1
root@wirenboard-AWI3MCGC:~# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether e8:eb:1b:35:10:16 brd ff:ff:ff:ff:ff:ff
4: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether e8:eb:1b:35:13:75 brd ff:ff:ff:ff:ff:ff
5: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether f0:c8:14:49:f2:42 brd ff:ff:ff:ff:ff:ff
6: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether f2:c8:14:49:f2:42 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.126/24 brd 10.0.0.255 scope global dynamic noprefixroute wlan1
       valid_lft 8026sec preferred_lft 8026sec
7: dbg0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 1a:55:89:a2:69:43 brd ff:ff:ff:ff:ff:ff

Поведение без изменений. Так же работает.
Советую все ж попробовать testing

да пробовал я…
с ним все работает, но это не то решение…
тестин мне не интересен, т.к. не хочу собирать шишки…

а в ui не может что-то кэшироваться, что не дает открыть конфиг при переключении интерфейса?
я пробовал без рестарта браузера, все в тех же окнах…
попробуйте тоже, открыть 4 таба , 2 со страницей networkManager-a (каждая со своим хостнейм в урле, у меня был wb - беспроводной, wb-eth1 - проводной) и 2 с открытым mqtt-serial конфигом…
и через веб отключать то тот то другой интерфейс… и делать рилоад конфига…

Нет, не пробовал. Это не имеет смысла - я обращаюсь именно к существующему адресу хоста. Если обращаться по mqtt например к недоступному - будет таймаут, причем сразу.

погодите, я поясню…
у вас в хостах есть запаси для обоих интерейсов, скажем:
10.0.0.126 wb-wifi
10.0.0.127 wb-ether

соответственно в хроме открыты:

вы в нетвок менеджере переключаете по очереди интерфейсы и на активном проверяете открытие конфига

что здесь не имеет смысла?
если в хосты допишите имена как выше, то все http ссылки, которые выше, можно просто скопипастить… и проверить

в dhcp добавьте static leases и все

  1. проверить что оба интерфеса подняты
  2. в http://wb-wifi/#!/network-connections/~2Fusr~2Fshare~2Fwb-mqtt-confed~2Fschemas~2Fwb-network.schema.json выключить проводной
  3. в http://wb-wifi/#!/configs/edit/~2Fvar~2Flib~2Fwb-mqtt-confed~2Fschemas~2Fwb-mqtt-serial.schema.json сделать рилоад и увидеть MQTT RPC request timed out MqttTimeoutError
  4. вернуться в http://wb-wifi/#!/network-connections/~2Fusr~2Fshare~2Fwb-mqtt-confed~2Fschemas~2Fwb-network.schema.json, включить проводной, выключить вайфай
  5. перейти в http://wb-ether/#!/configs/edit/~2Fvar~2Flib~2Fwb-mqtt-confed~2Fschemas~2Fwb-mqtt-serial.schema.json сделать рилоад и увидеть рабочий конфиг

Да, имеет смысл, могу. Открываю две инкогнито вкладки.

да.


Нет, я не вижу проблем связанных с изменением транспорта.

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

и вы не захотели парится с днс записями… стоит попробовать чтобы идентичные исходные были…

проблема есть… я выше привел тесткейс который у меня воспроиводит проблему… но пришел я к нему не сразу, а также как и другие авторы, которые здесь высказались… когда конфиг просто переставал открываться…

и мы так и не установили причину

Проверил - не воспроизводится.

Ну, не вижу смысла - но могу, конечно, но скорее завтра.