Проблемы в работе сетевого интерфейса WB 8.4

Контроллеры Wiren Board
1

Добрый день.

Начальные условия:
Контроллер WB: 8.4.4A/4G 1.2B-4G/1
S/N: AKK237GJ

Контроллер подключен к сети через порт eth0 (в коммутатор на скорости 100 Мбит/с). Это основной интерфейс, в нем же прописан шлюз. Сегмент выделеный для “технологической” сети.
Так же на контроллере установлено подключение к Wi-Fi сети в режиме клиента. В этой сети не был прописан шлюз по-умолчанию так как подключение предполагалось для резервного доступа и обнаружения Apple TV моста HomeKit в SprutHub-е (слава богу я предусмотрел такой резерв).
Также есть LTE-модем с двумя сим-картами.

В целом все это работало исправно около года (с момента запуска).

Проблема:
Недавно обновился на 2507, не могу утверждать, что проблема достоверна с этим связана, но до обновления такого точно не было.
Собственно проблема в том, что просто перестает работать проводное подключение. При этом Wi-Fi и LTE работают нормально.
На интерфейсе горит только оранжевый светодиод. Иногда кратковременно гаснет.

В процессе диагностики удалось выяснить, что проблема не в патч-корде и не в коммутаторе. Менять провод, менял порт на коммутаторе и подключал к другому коммутатору другим патч-кордом. Поведение не меняется никак.

Включение и выключение программно так же не исправляют ситуацию (что логично, так как интерфейс не отключает интерфейс а только “стирает” его настройки).

Отключение и включение кабеля также не помогают. Второй интерфейс (eth1) при этом работает нормально (по крайней мере на нем видны пакеты прилетающие, настраивать его вместо первого пока не настраивал).

После перегрузки контроллера eth0 начинает работать нормально, но работает не долго (последний раз хватило на 3 с небольшим часа).

Проблема началась пару недель назад (может чуть больше). По началу интерфейс отваливался, но через какое-то время “приваливался” обратно сам, без посторонней помощи. Но со временем провалы становились длиннее и чаще пока в итоге он не начал отваливаться “на совсем”. Спасет только перегрузка, но не на долго.

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

4w4d: %LINK-3-UPDOWN: Interface FastEthernet1/0/27, changed state to down
4w4d: %LINK-3-UPDOWN: Interface FastEthernet1/0/27, changed state to up
4w4d: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/27, changed state to up
4w4d: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/27, changed state to down
4w4d: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/27, changed state to up
4w4d: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/27, changed state to down
4w4d: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/27, changed state to up
4w4d: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/27, changed state to down
4w4d: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/27, changed state to up
4w4d: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/27, changed state to down
4w4d: %LINK-3-UPDOWN: Interface FastEthernet1/0/27, changed state to down
4w4d: %LINK-3-UPDOWN: Interface FastEthernet1/0/27, changed state to up

И иногда “моргает” сам линк.

В системе это тоже видно, что адаптер перезапускается драйвером:

Sep 04 19:55:09 wirenboard-AKK237GJ kernel: dwmac-sun8i 5020000.ethernet eth0: NETDEV WATCHDOG: CPU: 0: transmit queue 0 timed out 9296 ms
Sep 04 19:55:09 wirenboard-AKK237GJ kernel: dwmac-sun8i 5020000.ethernet eth0: Reset adapter.
Sep 04 19:55:09 wirenboard-AKK237GJ kernel: dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
Sep 04 19:55:09 wirenboard-AKK237GJ kernel: dwmac-sun8i 5020000.ethernet eth0: PHY [gpio-0:00] driver [RTL8201F Fast Ethernet] (irq=POLL)
Sep 04 19:55:09 wirenboard-AKK237GJ netplugd[3895]: eth0: state INSANE flags 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,10000 -> 0x00001003 UP,BROADCAST,MULTICAST
Sep 04 19:55:09 wirenboard-AKK237GJ netplugd[3895]: eth0: state INSANE flags 0x00001003 UP,BROADCAST,MULTICAST -> 0x00001002 BROADCAST,MULTICAST
Sep 04 19:55:09 wirenboard-AKK237GJ netplugd[332374]: /etc/netplug/netplug eth0 probe -> pid 332374
Sep 04 19:55:09 wirenboard-AKK237GJ avahi-daemon[316]: Interface eth0.IPv6 no longer relevant for mDNS.
Sep 04 19:55:09 wirenboard-AKK237GJ avahi-daemon[316]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::3187:71bf:fc:da5f.
Sep 04 19:55:09 wirenboard-AKK237GJ kernel: dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
Sep 04 19:55:09 wirenboard-AKK237GJ kernel: dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
Sep 04 19:55:09 wirenboard-AKK237GJ kernel: dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
Sep 04 19:55:09 wirenboard-AKK237GJ kernel: dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rmii link mode
Sep 04 19:55:09 wirenboard-AKK237GJ netplugd[3895]: eth0: state PROBING flags 0x00001002 BROADCAST,MULTICAST -> 0x00001003 UP,BROADCAST,MULTICAST
Sep 04 19:55:09 wirenboard-AKK237GJ avahi-daemon[316]: Interface eth0.IPv4 no longer relevant for mDNS.
Sep 04 19:55:09 wirenboard-AKK237GJ avahi-daemon[316]: Leaving mDNS multicast group on interface eth0.IPv4 with address 10.50.52.100.
Sep 04 19:55:09 wirenboard-AKK237GJ avahi-daemon[316]: Withdrawing address record for fe80::3187:71bf:fc:da5f on eth0.
Sep 04 19:55:09 wirenboard-AKK237GJ avahi-daemon[316]: Withdrawing address record for 10.50.52.100 on eth0.
Sep 04 19:55:09 wirenboard-AKK237GJ avahi-daemon[316]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.50.52.100.
Sep 04 19:55:09 wirenboard-AKK237GJ avahi-daemon[316]: New relevant interface eth0.IPv4 for mDNS.
Sep 04 19:55:09 wirenboard-AKK237GJ avahi-daemon[316]: Registering new address record for 10.50.52.100 on eth0.IPv4.
Sep 04 19:55:09 wirenboard-AKK237GJ netplugd[3895]: eth0: state PROBING_UP pid 332374 exited status 0
Sep 04 19:55:09 wirenboard-AKK237GJ avahi-daemon[316]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::5134:f76:3a95:cfd8.
Sep 04 19:55:09 wirenboard-AKK237GJ avahi-daemon[316]: New relevant interface eth0.IPv6 for mDNS.
Sep 04 19:55:09 wirenboard-AKK237GJ avahi-daemon[316]: Registering new address record for fe80::5134:f76:3a95:cfd8 on eth0.*.
Sep 04 19:55:11 wirenboard-AKK237GJ ntpd[1758]: Deleting interface #378 eth0, 10.50.52.100#123, interface stats: received=0, sent=0, dropped=0, active_time=148 secs
Sep 04 19:55:11 wirenboard-AKK237GJ ntpd[1758]: Deleting interface #379 eth0, fe80::3187:71bf:fc:da5f%2#123, interface stats: received=0, sent=0, dropped=0, active_time=139 secs
Sep 04 19:55:11 wirenboard-AKK237GJ netplugd[3895]: eth0: state INACTIVE flags 0x00001003 UP,BROADCAST,MULTICAST -> 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,10000
Sep 04 19:55:11 wirenboard-AKK237GJ netplugd[332393]: /etc/netplug/netplug eth0 in -> pid 332393
Sep 04 19:55:11 wirenboard-AKK237GJ NetworkManager[500]: <info>  [1757004911.6404] device (eth0): carrier: link connected
Sep 04 19:55:11 wirenboard-AKK237GJ kernel: dwmac-sun8i 5020000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
Sep 04 19:55:11 wirenboard-AKK237GJ netplugd[3895]: eth0: state INNING pid 332393 exited status 256
Sep 04 19:55:14 wirenboard-AKK237GJ ntpd[1758]: Listen normally on 380 eth0 10.50.52.100:123

И такой цикл примерно каждые 3 минуты.

К сожалению по неизвестной мне причине недавно контроллер экстренно перезагрузился, после чего повредились БД wb-mqtt-db и логи частично побились и полный журнал за долгое время не достать. Но проблемы с сетью начались существенно раньше и на прямую это не связанные вещи скорее всего.

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

3

Новые подробности:
Вчера отключил на интерфейсе автосогласование и offloading, перезагрузил контроллер. Утром сеть в итоге не работала вообще, отвалился даже Wi-Fi который до этого работал вообще без нареканий. При этом контроллер Wi-Fi видел активное подключение, mac и IP контроллера, он просто не отвечал.
Все настройки касались только eth0, поэтому их влияние на wi-fi исключено. Пока такое было один раз, возможно просто совпадение. Пришлось контроллер жестко перезагружать, после чего все снова заработало нормально, только LTE автоматически на поднялся. Вручную же подключился потом нормально.

При этом выяснилось, что ночью контроллер поймал перегрев и экстренно перезагрузился, возможно после этого Wi-Fi и не поднялся нормально. Сложно сказать с чем связан перегрев, раньше не бывало никогда на ровном месте. Пару раз бывало при выполнении длинных нагруженных системных задач, что тоже странно, но ладно.

Также дополнительно выяснил, что на интерфейсе залипает только исходящая очередь. То есть даже когда интерфейс зависает, входящие пакеты он видит (tcpdump-ом проверил). Исходящих (TX) же 0. И коммутатор как следствие даже Mac на порту не видит.

Полный журнал за 3 последние перезагрузки.
wb-boot-log.txt (670,3 КБ)

В логе:
1-й перезапуск штатный, после изменения параметров сетевого драйвера.
2-й В результате перегрева.
3-й Я руками перезагружал по питанию, так как отвалились все сетевые интерфейсы.

Также заметил, что в /mnt/data/var/lib/wirenboard в файлах eth0_mac.conf и eth1_mac.conf не верные Mac-и прописаны. Вряд ли это причина проблемы, но на всякий случай уточняю.

Также заметил, что если eth0 подключать вручную, все подключается нормально. Если же вернуть обратно (снимал на время диагностики) галочку подключаться автоматически, то сеть подключается, но интерфейс системы при этом пишет статус подключение и в “зеленое” состояние не переходит. Хотя все работает.

5

Upd2:

За это время удалось с высокой долей вероятности локализовать проблему драйвером dwmac-sun8i/st_mac100.

В логе, при инициализации драйвера была обнаружена ошибка:

Current syscon value is not the default 58000 (expect 0)

которая, если верить интернету может означать некорректную ссылку на регистры syscon. Не понятно, влияет это на работу драйвера и была ли эта шибка ранее, но на всякий случай DT-шным оверлеем регистр был перенацелен в нужное место (на указатель sun50i-h616-system-control), после чего ошибка при инициалазации драйвера исчезла. Эту черную магию я сам не особо понимаю, но тем не менее ошибка в логе исчезла. Кстати до применения overlay в системе не работало ip link set down, а после применения заработало.

Также в качестве эксперимента пробовал включать/выключать offloading и flow controll. На экспериментальном уровне “помучал” wb-connection-manager – работает исправно, по крайней мере я не увидел ничего криминального. Все отрабатывает как должно в принципе.

Тем не менее, проблема все равно есть, хоть и стала проявляться реже, точнее хватает на дольше. Если раньше после перезапуска системы хватало на 3-4 часа, теперь может и 12 отработать без проблем. Но все равно иногда “ловит клин”. Причем я не могу соотнести это никак с внешними факторами, то ли их нет совсем, то ли они весьма не очевидны.

В данный момент единственный рабочий вариант исправления проблемы (не считая перегрузки контроллера, разумеется) переинициализация драйвера при возникновении ошибки (или по крону). перезапуск интерфейса средствами ip link set или ethtools эффекта не дает, сброс порта со стороны коммутатора тоже, только выгрузка и обратная загрузка драйвера через /sys/bus/platform/drivers/dwmac-sun8i/(un)bind

Также в качестве эксперимента отключал LTE (в том числе и убирал питание с модема), отключал второй порт (в том числе и выгружал его драйвер совсем). Пока достоверного влияния всех этих манипуляций на зависание драйвера не выявлено.

Так как проблема плавающая и иногда проявляется спустя более 12 часов диагностика занимает очень много времени.

Такие дебри систем мне не сильно знакомы, особенно ARM систем.
У меня идеи кончились, куда еще можно копнуть?

6

Добрый день.

Это, скорее, похоже на аппаратную проблему.
Проверил, на стендовом 8.4 подобного не вижу равно как и проблем с регистрами.
В описании вполне достаточно информации чтобы поменять контроллер гарантийно.

Давайте мы бесплатно поменяем вам оборудование. Курьер привезёт новое оборудование и заберёт старое:
WB8 4Gb - 1 шт.

Перед отправкой - извлеките внутренние модули расширения, они остаются у вас.

Для возврата напишите, пожалуйста, письмо на info@wirenboard.com.
В письме укажите:

  • ссылку на эту тему,
  • серийный номер устройства, AKK237GJ,
  • (для курьера) ваш действующий телефон, адрес доставки, ФИО получателя.