На контроллере (WirenBoard 7.4.4, releasewb-2606 (astesting)) собран сетевой мост из wlan0 и eth1. Установлен Tailscale. Клиенты wi-fi через контроллер пробрасываются в сеть роутера, подключенного к контроллеру проводом. После перезагрузки всё работает как нужно.
Через некоторое время ssid сети wi-fi контроллера пропадает из обнаружения, клиенты отваливаются. В нормальном состоянии сеть работает от нескольких часов до нескольких дней.
Что делалось:
сносился и заново собирался мост
отключались все остальные интерфейсы
мост переносился на wlan1 и eth0
на wlan фиксировался режим и канал
общение с ИИ не помогло однозначно понять проблему, из последнего - результат вывода dmesg | grep -iE ‘wlan0|wlan1|firmware|error|fail’ - повторяющийся блок:
Ошибки RTW в dmesg указывают не на настройки сети, а на зависание самого Wi-Fi модуля. Проблема ниже уровня NetworkManager, поэтому пересборка моста и перенос на другие интерфейсы не помогали.
Чтобы локализовать проблему, сделайте, пожалуйста, следующее.
Когда точка доступа пропадёт в очередной раз, проверьте, восстанавливается ли она без перезагрузки. Подключитесь по проводу или через Tailscale и выполните nmcli connection down <имя AP-соединения> и nmcli connection up <имя AP-соединения>
Имя соединения можно посмотреть командой nmcli connection show. Если не помогло, выгрузите и загрузите модуль драйвера Wi-Fi через modprobe -r и modprobe (имя модуля покажет lsmod | grep -i 87). Напишите, какой из шагов вернул сеть.
Соберите в веб-интерфейсе диагностический архив и прикрепите к теме.
На контроллере установлен testing-релиз wb-2606. Такие релизы могут содержать ошибки, диагностику мы ведём на стабильных релизах. Так как контроллер стендовый, проверьте, пожалуйста, воспроизводится ли проблема на последнем стабильном релизе.
Соединение переподключено примерно в 12:20, отслеживание пинга до хоста показало отвал в 12:53:48 (проверяется раз в 10 минут). Полный лог всех сервисов прилагаю
Судя по логам у вас после down/up чип работает, но остается в сбойном состоянии. Поэтому для полной картины попрошу вас, пожалуйста, отправить архив с диагностической информацией контроллера. Создание архива описано в документации.
Предварительно попробуйте еще вместо down/up полностью перезагрузить драйвер Wi-Fi:
Найдите имя модуля командой lsmod | grep -i 8733
Выполните nmcli con down <имя AP-соединения>, затем modprobe -r <модуль>, modprobe <модуль> и nmcli con up <имя AP-соединения>
Понаблюдайте за dmesg | grep -i txfifo. Хочу увидеть исчезают ли ошибки после полной перезагрузки драйвера и через какое время появляются снова. После обычного down/up они вернулись через полминуты
Также не помешает серийный номер контроллера.
А переход на stable можем не проводить. Просто помните, что testing-релизы мы не гарантируем, и если дойдёт до разработчиков, то воспроизведение можем запросить именно на стабильном релизе.
Сбор диагностического архива в GUI повисает, через консоль выдает:
root@wirenboard-AVKE6YTO:~# wb-diag-collect diag
Start data collecting
Traceback (most recent call last):
File “/usr/lib/python3.9/asyncio/subprocess.py”, line 135, in wait
return await self._transport._wait()
File “/usr/lib/python3.9/asyncio/base_subprocess.py”, line 235, in _wait
return await waiter
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “/usr/lib/python3.9/asyncio/tasks.py”, line 492, in wait_for
fut.result()
asyncio.exceptions.CancelledError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File “/usr/bin/wb-diag-collect”, line 10, in
sys.exit(main())
File “/usr/share/wb-diag-collect/wb/diag/diag_collect.py”, line 71, in main
asyncio.get_event_loop().run_until_complete(
File “/usr/lib/python3.9/asyncio/base_events.py”, line 642, in run_until_complete
return future.result()
File “/usr/share/wb-diag-collect/wb/diag/collector.py”, line 32, in collect
await self.execute_commands(tmpdir, options[“commands”], options[“timeout”])
File “/usr/share/wb-diag-collect/wb/diag/collector.py”, line 121, in execute_commands
await asyncio.wait_for(proc.wait(), timeout=timeout)
File “/usr/lib/python3.9/asyncio/tasks.py”, line 494, in wait_for
raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
Мда, похоже, что полностью сбросить его пока может только ребут контроллера.
Падение сборщика, известная проблема старых его версий, в свежих версиях исправлено. Поэтому план такой:
Перезагрузите контроллер, если нужен Wi-Fi прямо сейчас.
Выполните apt update && apt install wb-diag-collect. Обновится только этот пакет, сюита и релиз не меняются. Затем соберите архив и прикрепите к теме. Если сборщик снова упадёт, пришлите вывод dpkg -s wb-diag-collect | grep Version.
Периодически поглядывайте dmesg | grep -i txfifo. надо поймать, когда появится первая ошибка, сразу после загрузки или ближе к отвалу.
И расскажите, пожалуйста, как именно вы настраивали мост и точку доступа, по какой инструкции или какой последовательностью команд. Состав моста из первого сообщения помним, интересуют именно команды. Хотим собрать такой же стенд и воспроизвести проблему у себя.
приложен диагностический архив, доступен только сотрудникам поддержки
(1,8 МБ)
принял
Мост настраивался полностью по статье wiki.wirenboard.com. На момент создания моста (с wlan0) на wlan1 существовало подключение в режиме клиента. После создания моста сетевые настройки в GUI стали недоступны. Также настраивался tailscale по статье (на моменте “apt update && apt install iptables-persistent” помню, были ошибки, маскарадинг слетал после перезагрузки, пробовал nftables-persistent. Что конкретно помогло, к сожалению, не помню, но маскарадинг между мостом и tailscale перестал слетать).
До этого устанавливался tailscale (без моста), вручную прописывал маршруты и правила между интерфейсами. Насколько помню, не разобрался как сохранить настройки после перезагрузки, удалил tailscale, перешёл к настройке моста.
В текущем состоянии, после сегодняшней перезагрузки, за два часа нет ни одной ошибки. То есть сейчас чип работает чисто, а деградация включается каким-то событием позже, и этот момент нам нужно поймать. Поэтому, если есть время и возможность, то настройки пока не меняйте, пусть система живёт как есть. Когда точка отвалится в следующий раз, выполните и пришлите до перезагрузки:
dmesg | grep -i txfifo | head -1` и `uptime`
А и спасибо, что написали ваш путь настройки. Передам коллегам.
Да, по свежему архиву видно, что после down/up чип продолжает жить в деградированном режиме, ошибки идут каждые 2 минуты до сих пор, хотя точка вещает.
Первая ошибка совпала с отключением неактивного клиента, а у этого семейства драйверов Realtek такие зависания часто провоцирует энергосбережение. В исходниках драйвера, оно включено и управляется параметром. Давайте исключим эту ошибку, отключив временно энергосбережение wifi модуля:
После перезагрузки проверьте, что настройка применилась, команда cat /sys/module/8733bu/parameters/rtw_power_mgnt должна показать 0. Откат простой (если потребуется) - удалить файл и перезагрузиться.
Дальше пользуйтесь как обычно и поглядывайте dmesg | grep -i txfifo. Если с отключённым энергосбережением деградация не наступит, то виновник локализован. Жду обратной связи
В общем, чтобы утренний отвал не пропал для диагностики, пришлите, пожалуйста, несколько выводов:
cat /usr/lib/wb-release и uname -r, чтобы понять, на каком релизе и ядре вы теперь.
cat /sys/module/8733bu/parameters/rtw_power_mgnt, пережила ли настройка энергосбережения обновление.
Успели ли вы до утреннего отвала применить настройку из прошлого сообщения и перезагрузиться, и показывала ли проверка 0.
journalctl --list-boots, найдите в списке загрузку, во время которой случился утренний отвал, и для неё выполните journalctl -b <номер> -k | grep -i txfifo | head -1.
Дальше наблюдаем как раньше. При следующем отвале до перезагрузки dmesg | grep -i txfifo | head -1 и uptime.
Тогда следующий кандидат, фоновые сканирования эфира со второго интерфейса wlan1. Он делит один радиочип с точкой на wlan0. Предлагаю вывести wlan1 из-под управления NM, снова одно изменение:
printf '[keyfile]\nunmanaged-devices=interface-name:wlan1\n' > /etc/NetworkManager/conf.d/unmanage-wlan1.conf
nmcli general reload
Обязательноая проверка такая - в выводе nmcli device wlan1 должен получить статус unmanaged. Если статус не сменился, выполните systemctl restart NetworkManager, сеть при этом кратковременно моргнёт. Если нужен будет откат, то нужно будет удалить файл и снова nmcli general reload. На точку и мост это не влияет, wlan1 у вас не используется.
И три коротких вывода для полноты картины:
Строка про загрузку a1c7c550 из journalctl --list-boots, нужно время её старта.
journalctl -b a1c7c550ae2f4c519aa86a0325b18540 -k | grep -m1 -B10 txfifo, что происходило перед первой ошибкой.
