Bridge-профили ломают список сетевых соединений в UI - AI Conversation

i.fink 2026-08-24

Тема

После настройки bridge по документации становится недоступен весь список сетевых соединений в UI

Описание

На контроллере настроен прозрачный сетевой мост по официальной документации Wiren Board с помощью nmcli:

wb-bridge — интерфейс br0, IPv4 по DHCP;
bridge-slave-eth0 — eth0, порт моста br0;
bridge-slave-wifi — wlan0, Wi‑Fi AP, порт моста br0.

Мы понимаем, что настройка bridge через веб-интерфейс не поддерживается — это прямо указано в документации. Мост поэтому и был настроен через консоль.

Однако в документации не указано, что после появления bridge-профилей веб-интерфейс перестаёт открывать весь список сетевых соединений и показывает:

invalid config file
/etc/wb-connection-manager.conf

В результате через UI нельзя просматривать или редактировать даже обычные соединения, не относящиеся к мосту.

Версии ПО

Debian GNU/Linux 13 (trixie)
NetworkManager 1.52.1
wb-nm-helper 1.39.0
wb-mqtt-confed 1.18.1
wb-homeui-backend 2.246.5

Контроллер:

hostname: wirenboard-A3HBOQYG

Результаты диагностики

Сам /etc/wb-connection-manager.conf:

доступен;
имеет права 0644;
является корректным UTF-8/JSON;
успешно загружается кодом ConfigFile из wb-nm-helper;
принимается работающим wb-connection-manager.service.

То есть сообщение invalid config file не связано с повреждением этого файла.

В журнале wb-mqtt-confed:

Invalid config file /etc/wb-connection-manager.conf
ui.connections.0: ipv4 is required
ui.connections.1: ipv4 is required

Вывод wb-nm-helper содержит:

bridge-slave-eth0
type: 01_nm_ethernet
missing: ipv4

bridge-slave-wifi
type: 04_nm_wifi_ap
missing: ipv4

У bridge-портов отсутствие собственной секции IPv4 корректно: IP-адрес настроен на br0. При этом схема wb-network.schema.json требует ipv4 для любого Ethernet- и Wi‑Fi-профиля.

Также wb-mqtt-nm-helper регулярно пишет:

Unable to read connectivity for ...: 'ipv4'

Фактическое поведение

Наличие корректно настроенных bridge-портов приводит к тому, что:

wb-nm-helper выводит их как обычные Ethernet/Wi‑Fi-соединения без ipv4.
Результат не проходит схему wb-network.schema.json.
wb-mqtt-confed объявляет весь /etc/wb-connection-manager.conf некорректным.
В UI становится недоступен весь список сетевых соединений.

Ожидаемое поведение

Мы не ожидаем возможности настраивать bridge через UI, поскольку документация прямо сообщает об этом ограничении.

Но хотелось бы, чтобы веб-интерфейс:

пропускал или показывал bridge-профили только для чтения;
не требовал ipv4 у профилей с connection.port-type=bridge;
не объявлял весь конфигурационный файл некорректным;
продолжал показывать и редактировать остальные поддерживаемые соединения.

Если такое поведение пока не планируется исправлять, просьба явно добавить в документацию предупреждение: после ручной настройки bridge страница сетевых соединений в UI полностью перестанет работать.

Дополнительная проблема

Сразу после настройки мост работал, контроллер получал по DHCP адрес 192.168.2.11, а конфигурация успешно пережила перезагрузку. Позже доступ по SSH к этому адресу пропал.

Просьба также подсказать безопасный порядок диагностики через Debug Console и проверить, может ли wb-connection-manager, в конфигурации которого остались wb-eth0 и wb-eth1, вмешиваться в работу вручную настроенного wb-bridge.

AIbot 2026-08-24

По приведённым данным это похоже на дефект совместимости wb-nm-helper/wb-mqtt-confed с профилями NetworkManager типа bridge-port, а не на повреждение /etc/wb-connection-manager.conf. Порты bridge-slave-eth0 и bridge-slave-wifi действительно не имеют собственного IPv4, поскольку адрес назначен мосту br0; требование ipv4 для каждого Ethernet/Wi‑Fi-профиля приводит к ошибке всей конфигурации.

В документации wb-nm-helper предусмотрен режим скрытия соединения из HomeUI через user.data.read-only=true, однако отдельного описания bridge-профилей и их исключения из проверки схемы я не нашёл: wb-nm-helper — README.md. Поэтому ваш запрос выглядит обоснованным: необходима обработка bridge-портов как служебных или read-only-профилей, чтобы они не блокировали остальные соединения. В найденной теме форума по bridge разработчики также запрашивают nmcli device, nmcli connection, brctl show, ip link и диагностический архив: Bridge между портами eth0 и eth1.

Для безопасной диагностики потери SSH через Debug Console выполните:

Зафиксируйте адреса и состояние NetworkManager:

nmcli device
nmcli connection show
nmcli -f GENERAL,IP4,IP6 connection show wb-bridge
ip -br addr
bridge link

Проверьте, какой профиль назначен каждому интерфейсу и не активировались ли параллельно wb-eth0/wb-eth1:

nmcli -f NAME,UUID,TYPE,DEVICE,AUTOCONNECT connection show
nmcli connection show wb-eth0
nmcli connection show wb-eth1

Посмотрите события NetworkManager и менеджера соединений:

journalctl -u NetworkManager -n 200 --no-pager
journalctl -u wb-connection-manager -n 200 --no-pager
journalctl -u wb-mqtt-nm-helper -n 200 --no-pager

Проверьте DHCP именно на br0, а не на bridge-портах:

ip -4 addr show dev br0
ip route
networkctl status br0 2>/dev/null

Оставшиеся wb-eth0 и wb-eth1 могут вмешиваться, если они продолжают автоматически подключаться или менеджер считает их приоритетными: в штатном примере wb-connection-manager.conf эти профили входят в список tiers.high. Это нужно проверить по фактическим параметрам autoconnect, connection.interface-name, connection.master и connection.slave-type; удалять или отключать профили до проверки не следует.

Точную причину последующей потери адреса 192.168.2.11 по описанию установить нельзя: возможны повторная активация портового профиля, смена DHCP-аренды или событие NetworkManager после перезагрузки. Для обращения разработчикам приложите вывод четырёх групп команд выше и диагностический архив. В документации Wiren Board точного обещания поддержки bridge-профилей в UI я не нашёл.

Здесь может понадобиться мнение инженера Wiren Board. Для уверенного ответа мне может не хватить контекста — если можете, приложите логи или результаты тестов, я уточню гипотезы точнее.

Примечание: я — ИИ-ассистент, а не сотрудник-человек; в ответе возможны неточности. Если пришлёте уточняющие данные/логи, я смогу проверить гипотезы точнее.

i.fink 2026-08-24

Полный вывод запрошенных команд:

wb-network-diagnostics.txt (129 КБ)

AIbot 2026-08-24

По выводу видно, что сам мост сейчас работает корректно:

br0 поднят и имеет адрес 192.168.2.11/24;
eth0 и wlan0 находятся в состоянии forwarding и являются портами br0;
активен именно профиль wb-bridge;
wb-eth0 не активируется (autoconnect: no).

Причина повторяющихся событий

Проблемным является профиль wb-eth1:

connection.interface-name: eth1
connection.autoconnect: yes

eth1 не входит в мост, находится в состоянии DOWN, а в NetworkManager нет carrier. Поэтому NetworkManager и wb-connection-manager примерно раз в минуту пытаются активировать wb-eth1 и получают:

device has no carrier

Это не ломает br0 напрямую, но создаёт постоянные неудачные попытки подключения и может влиять на логику менеджера сетевых соединений. В штатном примере wb-connection-manager.conf профили wb-eth0 и wb-eth1 входят в список соединений высокого приоритета: wb-nm-helper — README.md.

Безопасное исправление, если eth1 не используется отдельно:

sudo nmcli connection modify wb-eth1 connection.autoconnect no
sudo nmcli connection down wb-eth1 2>/dev/null || true

После этого проверьте, что попытки прекратились:

journalctl -u NetworkManager -n 50 --no-pager
nmcli -f NAME,DEVICE,AUTOCONNECT connection show

Не изменяйте bridge-slave-eth0 и bridge-slave-wifi: оба профиля сейчас корректно привязаны к br0.

Потеря SSH

В показанном состоянии адрес на br0 есть, мост имеет UP, а оба его активных порта находятся в forwarding. Поэтому по этому фрагменту нет признака, что SSH пропал из-за разрушения моста. Сначала проверьте:

ip route
ping -c 3 192.168.2.1
ip neigh show dev br0

Если шлюз отвечает, но SSH недоступен, проверьте службу SSH и прослушиваемый адрес:

systemctl status ssh --no-pager
ss -lntp | grep ':22'

Адрес 192.168.2.11 мог измениться после обновления DHCP-аренды; проверяйте текущий адрес именно на br0, а не на eth0 или wlan0.

Ошибка UI

Логи подтверждают две отдельные проблемы:

wb-mqtt-nm-helper не умеет корректно обработать активное соединение bridge-port без собственной секции IPv4:
```
Unable to read connectivity ... 'ipv4'
```
wb-mqtt-confed отклоняет весь конфигурационный объект из-за обязательного ipv4 у bridge-портов.

Добавление IPv4 на bridge-slave-* для обхода ошибки нежелательно: IP-адрес должен оставаться на br0. Настройка user.data.read-only=true предусмотрена для скрытия соединения из HomeUI, но в найденной документации нет подтверждения, что этот механизм исключает профиль из схемной проверки. Поэтому точного безопасного обхода для текущих версий wb-nm-helper 1.39.0 и wb-mqtt-confed 1.18.1 я не нашёл.

Для обращения разработчикам приложите диагностический файл и отдельно укажите, что после отключения автоподключения wb-eth1 исчезают ли ошибки no carrier, но ошибки missing: ipv4 и Unable to read connectivity ... 'ipv4' остаются. В найденной теме по bridge разработчики также запрашивают сетевую диагностику и архив: Bridge между портами eth0 и eth1.

i.fink 2026-08-24

Выполнил предложенную проверку.

Для wb-eth1 установил connection.autoconnect=no, но wb-connection-manager продолжил примерно раз в минуту пытаться активировать профиль, поскольку wb-eth1 оставался в tiers.high файла /etc/wb-connection-manager.conf.

После удаления wb-eth1 из tiers.high и перезапуска wb-connection-manager попытки активации прекратились. Мост при этом продолжает работать штатно:

br0 — UP, адрес 192.168.2.11/24;
eth0 и wlan0 — порты br0, состояние forwarding;
wb-connection-manager — active;
wb-eth1 — неактивен, autoconnect=no.

Таким образом, сообщения device has no carrier устранены, но основная проблема UI осталась. wb-mqtt-nm-helper продолжает регулярно выдавать:

Unable to read connectivity for /org/freedesktop/NetworkManager/ActiveConnection/4: 'ipv4'

Проблему с локальным доступом по SSH решать не требуется — она не относится к данному обращению. Облачный SSH работает, текущая конфигурация моста и адрес 192.168.2.11 сохраняются. Просьба сосредоточиться только на ошибке отображения сетевых подключений в UI.

Просьба передать вопрос инженеру Wiren Board: как штатно использовать документированную конфигурацию моста с bridge-slave-eth0 и bridge-slave-wifi, если из-за отсутствия собственной IPv4-конфигурации у портов моста интерфейс показывает invalid config file и полностью перестаёт отображать список сетевых подключений?

AIbot 2026-08-24

Принятые результаты подтверждают: после исключения wb-eth1 из tiers.high проблема с его активацией устранена, а ошибка UI остаётся независимо от wb-connection-manager. Причина — именно обработка bridge-slave-* в связке wb-nm-helper → wb-mqtt-confed:

bridge-slave-eth0: missing ipv4
bridge-slave-wifi: missing ipv4

Для bridge-портов это корректная конфигурация NetworkManager: IPv4 должен находиться на br0. Добавлять фиктивный IPv4 к eth0/wlan0 не следует — это изменит смысл схемы моста и может привести к конфликтующей сетевой конфигурации.

В документации wb-nm-helper указано, что сервис формирует данные для web-интерфейса совместно с wb-mqtt-confed, а также поддерживает скрытие соединения через wb.read-only=true; при этом отдельной обработки bridge-портов в найденной документации нет: wb-nm-helper — README.md. Полная схема опубликована здесь: wb-network.schema.json.

Вывод для инженеров Wiren Board

Текущий сценарий документированной ручной настройки bridge на контроллере с указанными версиями ПО штатно не поддерживается UI: bridge работает в NetworkManager, но его служебные порты не проходят схему конфигуратора, из-за чего отклоняется весь /etc/wb-connection-manager.conf.

Ожидаемое исправление должно быть на стороне ПО, например:

не включать профили с connection.port-type=bridge в список обычных редактируемых соединений;
не требовать ipv4 у bridge-портов;
либо показывать их как read-only и валидировать только профиль br0;
не отклонять из-за них остальные соединения.

На данный момент в найденных источниках нет подтверждённого штатного обходного пути для wb-nm-helper 1.39.0 и wb-mqtt-confed 1.18.1. Параметр wb.read-only=true предназначен для скрытия соединения из HomeUI, но документация не подтверждает, что он отключает последующую проверку схемы; поэтому считать его решением этой проблемы нельзя.

Для передачи обращения инженерам приложите:

контроллер и релиз прошивки;
версии wb-nm-helper, wb-mqtt-confed, wb-homeui-backend;
диагностический архив;
минимальное воспроизведение: br0 с DHCP и два порта bridge-slave-*;

сообщения:

ui.connections.0: ipv4 is required
ui.connections.1: ipv4 is required
Unable to read connectivity ...: 'ipv4'

Форумная тема по ручному созданию bridge также остаётся релевантной для этого обращения: Bridge между портами eth0 и eth1.

i.fink 2026-08-24

Собрал данные через SSH

Дополнительная информация для воспроизведения проблемы.

1. Контроллер и релиз

Контроллер: Wiren Board rev. 7.4.2 (A40i)
RELEASE_NAME=unstable.latest

SUITE=testing

TARGET=wb7/trixie
Debian GNU/Linux 13.6 (trixie)

2. Версии пакетов

wb-nm-helper       1.39.0
wb-mqtt-confed     1.18.1
wb-homeui-backend  2.246.5

3. Диагностический архив

Диагностический архив приложен к сообщению отдельно.

4. Минимальное воспроизведение

Настроены три профиля NetworkManager:

wb-bridge: type: bridge interface: br0 ipv4.method: auto bridge-slave-eth0: type: 802-3-ethernet interface: eth0 controller: br0 port-type: bridge

bridge-slave-wifi: type: 802-11-wireless interface: wlan0 controller: br0 port-type: bridge mode: ap

Текущее состояние:

br0    UP    192.168.2.11/24
eth0   master br0, state forwarding
wlan0  master br0, state forwarding

То есть используется минимальная конфигурация: мост br0 получает адрес по DHCP, а eth0 и wlan0 являются двумя портами bridge-slave-*.

После создания этих профилей страница сетевых подключений в HomeUI показывает invalid config file и перестаёт отображать весь список подключений.

5. Сообщения об ошибках

При проверке конфигурации:

ui.connections.0: ipv4 is required
ui.connections.1: ipv4 is required

В журнале wb-mqtt-nm-helper примерно каждые 20 секунд:

Unable to read connectivity for /org/freedesktop/NetworkManager/ActiveConnection/4: 'ipv4'

IPv4 намеренно настроен только на br0. Добавлять отдельную IPv4-конфигурацию портам bridge-slave-eth0 и bridge-slave-wifi считаю некорректным.

Проблему локального доступа по SSH решать не требуется. Просьба рассматривать только ошибку обработки bridge-профилей и исчезновение списка сетевых подключений в HomeUI.

приложен диагностический архив, доступен только сотрудникам поддержки

(1,7 МБ)

AIbot 2026-08-24

Дополнительные данные подтверждают воспроизводимую ошибку в текущем ПО для WB7 7.4.2 / Debian 13 trixie:

br0 получает IPv4 по DHCP;
eth0 и wlan0 корректно работают как порты моста;
IPv4 у bridge-портов отсутствует намеренно и должен отсутствовать;
wb-mqtt-confed требует ipv4 у этих портов и отклоняет весь объект;
wb-mqtt-nm-helper дополнительно не обрабатывает connectivity для активного bridge-port без ipv4.

Это не ошибка конфигурации пользователя. Официальная инструкция сама создаёт именно такую структуру: IPv4 на wb-bridge, а bridge-slave-eth0 и bridge-slave-wifi — без отдельного адреса. В ней также указано, что мост настраивается через nmcli, а Wi‑Fi AP можно объединять с Ethernet в мост: Networks.

Что следует считать штатным решением сейчас

Для сохранения рабочего моста:

оставлять IPv4 только на wb-bridge;
не добавлять фиктивный IPv4 к bridge-slave-eth0 и bridge-slave-wifi;
не включать bridge-порты в tiers файла /etc/wb-connection-manager.conf;
не пытаться исправлять ошибку UI изменением NetworkManager-профилей.

Иными словами, сам bridge сейчас настроен штатно, но его отображение через HomeUI не поддерживается текущей реализацией валидатора и wb-mqtt-nm-helper. Удаление bridge-профилей из wb-connection-manager.conf не устраняет ошибку, поскольку UI получает список профилей непосредственно от wb-nm-helper.

Формулировка обращения инженерам

На WB7 7.4.2, wb-nm-helper 1.39.0, wb-mqtt-confed 1.18.1, wb-homeui-backend 2.246.5 воспроизводится ошибка при использовании bridge-конфигурации из официальной инструкции Networks.

Конфигурация: wb-bridge (br0, DHCP), bridge-slave-eth0 и bridge-slave-wifi (port-type=bridge, без IPv4). Мост работает: br0 UP, порты в состоянии forwarding.

HomeUI показывает invalid config file, а wb-mqtt-confed сообщает:
ui.connections.0: ipv4 is required
ui.connections.1: ipv4 is required

wb-mqtt-nm-helper каждые 20 секунд пишет:
Unable to read connectivity ...: 'ipv4'

Просьба исправить обработку bridge-профилей: не требовать IPv4 у профилей с connection.port-type=bridge, не включать их в обычную схему редактирования либо отображать как read-only, не отклоняя остальные соединения.

В найденной документации и на форуме нет указания на готовый обходной путь или версии, где это уже исправлено. Тему с минимальным воспроизведением и диагностическим архивом следует передать разработчикам wb-nm-helper/wb-mqtt-confed: Bridge между портами eth0 и eth1.