Broadcom-wl и переключение интерфейсов

Сомневаюсь, что была такая тема. Драйвер переключить интерефейс не может, может из-за ошибки или ещё чего интерфейс падает, сессия разрывается, но прописать маршрут по умолчанию драйвер не может. У вас там NetworkManager или что похуже управляет интерфейсами?

И изучите подробнее, что вобще происходит после этого переключения, wifi интерейс вобще работает и не хватает только маршрута или wifi интерфейс вобще не работает и через него никакие пакеты не ходят?

Наверно надо знать модель карточки и возможно ноута, если ноут. Сетевуха падает, свободного драйвера могли не завести, но возможно кто то уже сталкивался с такой картой/чипом и знет что делать.

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

Карточка, если не ошибаюсь, TP-Link Archer T6E. Чипсет у нее как раз работает с проприетарным драйвером broadcom-wl, это к вопросу kirill_rrr.

Управляется все в гноме 3 через NM, да. Как я понимаю, сетевуха не падает, поскольку wifi не отключается. Как я писал в первом посте - мне приходится отключать и включать wifi заново, чтобы исправить ошибку. Индикатор показывает сетевое подключение, а не беспроводное, будто бы интерфейс wlan - это ethernet.

Я нагуглил ошибку на Вики арча, где подробного описания проблемы нет, но зато есть ссылка на proper device naming. Как я это все понял, интерфейс должен называться не wlan, а wl, и тогда проблем не будет. Но как его переименовать там не сказано, а информация напоминает справку.

Сейчас потыкать это все и посмотреть не могу, так что наверное придется вечером.

К слову, у меня в системе есть systemd, но вот названия интерфейсов все равно старые - eth, wlan.

Вот https://bbs.archlinux.org/viewtopic.php?id=110501 развёрнутое описание проблемы типа «Interfaces swapped with broadcom-wl», это происходит один раз при загрузке системы (обнаружении интерфейсов), но не через час работы. И там корень проблемы в том, что не понятно, какое имя интерфейса указывать в настройках для поднятия wifi сессии, в вашем случае этой проблемы нет.

Посмотрите, запищите в файл и сравните состояние сетевых интерфейсов и маршрутов (вывод ″ip addr″ и ″ip route″) в трёх случаях. До поднятия wifi, во время нормальной работы wifi и после того, что вы называете переключени интерфейсов.

Может у вас на ethernet приходит новый ip-адрес по dhcp и заодно и прописывается новый маршрут по умолчанию.

Спасибо, попробую зафиксировать.

Но у меня к компьютеру ничего не подключено, только по wifi интернет приходит, поэтому вряд ли там какой-то ip меняется.

У меня раньше стоял другой адаптер на чипсете от atheros, там таких проблем не было, драйвер был открытый.

Сравнения провел. Результаты во всех трех состояниях (выключенном, включенном и переключенном) отличаются.

Как показать результаты? Я выхлопы в три отдельных текстовика загонял и сравнивал потом через Meld.

Посмотрел на вывод iwconfig по интерфейсу при подключении и сборе - разницы нет.

Попытка сделать ping на любой ресурс в «переключенном» (буду так это пока называть) состоянии выводит ошибку «Временный сбой в разрешении имен».

Теперь к выводам ipadr и iproute.

ipadr

• Выключенный WIFI
• Включенный WIFI
• Измененное состояние

iproute

Выключенный WIFI
25.0.0.0/8 dev ham0 proto kernel scope link src 25.60.122.126 

Включенный WIFI
default via 192.168.0.1 dev wlan2 proto static metric 600 
25.0.0.0/8 dev ham0 proto kernel scope link src 25.60.122.126 
192.168.0.0/24 dev wlan2 proto kernel scope link src 192.168.0.106 metric 600 

Измененное состояние
25.0.0.0/8 dev ham0 proto kernel scope link src 25.60.122.126 

Как видно, первый и третий выхлопы iproute вообще ничем не отличаются.

В ipadr некоторые МАКи затёр, но они не изменяются во всех состояниях.

Ну сейчас хотя бы понятно, что такое «переключенное» состояние — у вас исчезает ip-адрес с интерфейса и маршрут по умолчанию. Почему это происходит не понятно, посмотрите, что пишет ядро по поводу wlan2 (dmesg | grep wlan2),если там в момент ″переключения″ будет про этот интерфейс, что он down/up, тогда одно, а если там чисто и wifi линк не разрывался тогда вобще странно.

Итак, результат.

[    1.874538] wlan0: Broadcom BCM43a0 802.11 Hybrid Wireless Controller 6.30.223.271 (r587334)
[    1.875301] wl 0000:07:00.0 wlan2: renamed from wlan0
[    2.545370] IPv6: ADDRCONF(NETDEV_UP): wlan2: link is not ready
[    4.549685] wlan2 Scan_results error (-22)

Никакого сообщения во время потери ip нету.

Было тоже самое с tp-link 725 и приходилось пересобирать ядро.

К счастью, через пару месяцев все работать стало из коробки

Я помню времена, когда мне для усб-адаптера с чипом ralink приходилось пересобирать драйвер руками на Fedora при каждом обновлении ядра.

А потом драйвер адаптера в ядро поместили, и он тоже стал из коробки работать.

Думаю, с wl-драйвером такое вряд ли случится, он же вроде как проприетарный.

UPD

Спустя какое-то время, я переустановил систему и вынул из компьютера адаптер от Броадкома, который, как я думал, работает криво из-за драйвера. Проблема описана в первом посте, так что повторяться не буду.

Установил я Debian Stable. Собственно, точно так же как и ранее, я ставил liquorix-ядро, поскольку мне нужно реалтаймовое ядро, и так же ставил rt-ядро из официальных репозиториев дебиана.

И с тем и с другим, адаптер уже на чипе Atheros демонстрирует точно такое же поведение, как и адаптер на чипе Broadcom - теряет IP.

Выходит, дело не в драйверах и не в адаптерах.

Вот выхлоп dmesg с WiFi:

dmesg | grep wlp
[    2.969926] ath9k 0000:06:00.0 wlp6s0: renamed from wlan0
[    3.536311] IPv6: ADDRCONF(NETDEV_UP): wlp6s0: link is not ready
[    3.546119] IPv6: ADDRCONF(NETDEV_UP): wlp6s0: link is not ready
[    3.648484] IPv6: ADDRCONF(NETDEV_UP): wlp6s0: link is not ready
[    3.732620] IPv6: ADDRCONF(NETDEV_UP): wlp6s0: link is not ready
[    7.436563] IPv6: ADDRCONF(NETDEV_UP): wlp6s0: link is not ready
[    7.508476] wlp6s0: authenticate with MAC
[    7.516594] wlp6s0: send auth to MAC (try 1/3)
[    7.517517] wlp6s0: authenticated
[    7.519495] wlp6s0: associate with MAC (try 1/3)
[    7.527214] wlp6s0: RX AssocResp from MAC (capab=0x11 status=0 aid=1)
[    7.527321] IPv6: ADDRCONF(NETDEV_CHANGE): wlp6s0: link becomes ready
[    7.527343] wlp6s0: associated
[ 8906.625475] wlp6s0: deauthenticating from MAC by local choice (Reason: 3=DEAUTH_LEAVING)
[ 8909.141865] IPv6: ADDRCONF(NETDEV_UP): wlp6s0: link is not ready
[ 8909.215807] IPv6: ADDRCONF(NETDEV_UP): wlp6s0: link is not ready
[ 8912.905578] IPv6: ADDRCONF(NETDEV_UP): wlp6s0: link is not ready
[ 8912.974129] wlp6s0: authenticate with MAC
[ 8912.982009] wlp6s0: send auth to MAC (try 1/3)
[ 8912.982971] wlp6s0: authenticated
[ 8912.988757] wlp6s0: associate with MAC (try 1/3)
[ 8912.990109] wlp6s0: RX AssocResp from MAC (capab=0x11 status=0 aid=1)
[ 8912.990198] wlp6s0: associated
[ 8912.990254] IPv6: ADDRCONF(NETDEV_CHANGE): wlp6s0: link becomes ready

Обратите внимание на строку:

[ 8906.625475] wlp6s0: deauthenticating from MAC by local choice (Reason: 3=DEAUTH_LEAVING)

Беглый гуглёж указал мне на эту переписку, в которой говорится что именно в Debian Stretch (напомню - в данный момент, стабильном релизе Debian) есть ошибка, которая заключается в том, что systemd создает длинные имена интерфейсов, которые не очень хорошо работают с некоторыми firmware.

В переписке предлагается использовать «костыль» следующего вида:

ln -s /dev/null /etc/systemd/network/99-default.link

Попробую использовать это, посмотрю как будет работать. Если это сработает - обновлю шапку и закрою тему.