LINUX.ORG.RU

Баллада о Network Manager, или «корчен-тулинг» ради Wi-Fi

 , ,


0

2

Итак, пушка в исполнении Корчевателя!

Есть компьютер, абсолютно новый, на Ryzen. На нём стоит Arch. В «арче» - собственно, Network Manager, который, стоило только начаться осени, начал «чудить» (а может, и не он).

Суть проблемы: после ребута из «оффтопика» (ибо игры) в «арч» USB-WiFi-адаптер перестаёт видеть сети. Вообще. При этом сам беспроводной интерфейс преспокойно висит себе в списке интерфейсов и даже в апплете отображается, мол, есть адаптер (это тот апплет, который отдельно ставится. «Родной» из KDE при этом вообще ничего не показывает). Помогает только перезагрузка с последующим «бутом» прямиком в дистрибутив. Плюс скорость значительно просела по сравнению с «виндой» - раз в двадцать (на «вики» был совет о сертификатах, crda, все дела, да только не помог он).

Пробовал с другим дистрибутивом — те же яйца, только в профиль. Ubuntu — точно такие же «непонятки», даже если с «флэшки» загружаться в «живой» образ: загрузился «после» «винды» - не будет никакого «вайфая». При этом если подключить телефон в режиме «раздачи» через кабель - всё прекрасно, всё работает, в любой ситуации.

Первым делом я сразу же полез читать вывод journalctl -u NetworkManager и обнаружил несколько странных строк.

Раз:

Sep 19 18:22:54 RE-Korch NetworkManager[563]: <warn>  [1568906574.7889] platform-linux: do-change-link[3]: failure changing link: failure 16 (Device or resource busy)
Sep 19 18:22:54 RE-Korch NetworkManager[563]: <warn>  [1568906574.7890] device (wlp3s0f0u1): set-hw-addr: failed to set MAC address to 86:DB:16:F4:6C:54 (scanning) (NME_UNSPEC)
Sep 19 18:22:54 RE-Korch NetworkManager[563]: <info>  [1568906574.8693] sup-iface[0x556dcb4d8930,wlp3s0f0u1]: supports 4 scan SSIDs
Sep 19 18:22:54 RE-Korch NetworkManager[563]: <info>  [1568906574.8701] device (wlp3s0f0u1): supplicant interface state: starting -> ready
Sep 19 18:22:54 RE-Korch NetworkManager[563]: <info>  [1568906574.8702] device (wlp3s0f0u1): state change: unavailable -> disconnected (reason 'supplicant-available', sys-iface-state: 'managed')
Sep 19 18:22:57 RE-Korch NetworkManager[563]: <info>  [1568906577.5802] agent-manager: req[0x7fbc3c001dc0, :1.39/org.freedesktop.nm-applet/1000]: agent registered
Sep 19 18:22:59 RE-Korch NetworkManager[563]: <info>  [1568906579.9130] manager: startup complete
Sep 19 18:28:41 RE-Korch NetworkManager[563]: <info>  [1568906921.7866] device (wlp3s0f0u1): set-hw-addr: set MAC address to E6:2F:CD:8A:18:19 (scanning)
Sep 19 18:28:46 RE-Korch NetworkManager[563]: <info>  [1568906926.0060] device (wlp3s0f0u1): supplicant interface state: ready -> disabled
Sep 19 18:28:46 RE-Korch NetworkManager[563]: <info>  [1568906926.0765] device (wlp3s0f0u1): supplicant interface state: disabled -> inactive
Sep 19 18:34:01 RE-Korch NetworkManager[563]: <info>  [1568907241.7850] device (wlp3s0f0u1): set-hw-addr: set MAC address to 62:A8:15:9E:73:04 (scanning)
Sep 19 18:34:06 RE-Korch NetworkManager[563]: <info>  [1568907246.0093] device (wlp3s0f0u1): supplicant interface state: inactive -> disabled
Sep 19 18:34:06 RE-Korch NetworkManager[563]: <info>  [1568907246.0764] device (wlp3s0f0u1): supplicant interface state: disabled -> inactive
Sep 19 18:39:21 RE-Korch NetworkManager[563]: <info>  [1568907561.7882] device (wlp3s0f0u1): set-hw-addr: set MAC address to 8E:11:AC:D7:4A:94 (scanning)
Sep 19 18:39:26 RE-Korch NetworkManager[563]: <info>  [1568907566.0126] device (wlp3s0f0u1): supplicant interface state: inactive -> disabled
Sep 19 18:39:26 RE-Korch NetworkManager[563]: <info>  [1568907566.0763] device (wlp3s0f0u1): supplicant interface state: disabled -> inactive
Sep 19 18:44:41 RE-Korch NetworkManager[563]: <info>  [1568907881.7505] device (wlp3s0f0u1): set-hw-addr: set MAC address to 6E:60:26:18:5E:E5 (scanning)
Sep 19 18:44:45 RE-Korch NetworkManager[563]: <info>  [1568907885.9698] device (wlp3s0f0u1): supplicant interface state: inactive -> disabled
Sep 19 18:44:46 RE-Korch NetworkManager[563]: <info>  [1568907886.0363] device (wlp3s0f0u1): supplicant interface state: disabled -> inactive
Sep 19 18:50:01 RE-Korch NetworkManager[563]: <info>  [1568908201.7898] device (wlp3s0f0u1): set-hw-addr: set MAC address to DA:D6:DD:2A:B9:EC (scanning)
Sep 19 18:50:06 RE-Korch NetworkManager[563]: <info>  [1568908206.0091] device (wlp3s0f0u1): supplicant interface state: inactive -> disabled
Sep 19 18:50:06 RE-Korch NetworkManager[563]: <info>  [1568908206.0762] device (wlp3s0f0u1): supplicant interface state: disabled -> inactive
Sep 19 18:55:21 RE-Korch NetworkManager[563]: <info>  [1568908521.8351] device (wlp3s0f0u1): set-hw-addr: set MAC address to 62:22:DB:F1:22:C4 (scanning)
Sep 19 18:55:26 RE-Korch NetworkManager[563]: <info>  [1568908526.0554] device (wlp3s0f0u1): supplicant interface state: inactive -> disabled
Sep 19 18:55:26 RE-Korch NetworkManager[563]: <info>  [1568908526.1162] device (wlp3s0f0u1): supplicant interface state: disabled -> inactive

После недолгого почёсывания репы пришло «озарение»: что-то NM с MAC-адресами чудит. Был уже когда-то печальный опыт поднятия сети под Debian 9 именно с этим «свистком», поэтому в /etc/NetworkManager/NetworkManager.conf была немедленно «вброшена» следующая комбинация:

[device]
wifi.scan-rand-mac-address=no

Увы, результат нулевой. Как сеть была недоступной после «оффтопика», так и осталась. Менял «no» на «0», без толку (правда, я и сам такой себе специалист по сетям).

Два:

Sep 20 00:33:45 RE-Korch NetworkManager[555]: <info>  [1568928825.6075] device (wlp3s0f0u1): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Sep 20 00:33:49 RE-Korch NetworkManager[555]: <info>  [1568928829.9152] sup-iface[0x55acbe25d930,wlp3s0f0u1]: supports 4 scan SSIDs
Sep 20 00:33:49 RE-Korch NetworkManager[555]: <info>  [1568928829.9160] device (wlp3s0f0u1): supplicant interface state: starting -> ready
Sep 20 00:33:49 RE-Korch NetworkManager[555]: <info>  [1568928829.9161] device (wlp3s0f0u1): state change: unavailable -> disconnected (reason 'supplicant-available', sys-iface-state: 'managed')
Sep 20 00:33:53 RE-Korch NetworkManager[555]: <info>  [1568928833.1316] agent-manager: req[0x55acbe2f41c0, :1.52/org.freedesktop.nm-applet/1000]: agent registered
Sep 20 00:33:54 RE-Korch NetworkManager[555]: <info>  [1568928834.4759] manager: startup complete

Это уже появилось после «корчинга» конфигурационного файла.

Забавный факт: когда «линукс» на компьютере стоял один, никаких глюков с беспроводными сетями (кроме куда меньшей скорости соединения, с торрентов выше полгигабита качать не желает, под «оффтопиком» - под 10 Мб/с) не наблюдалось. Сатья, корченёнок ты наш, что же твои ребята в «десятке» намутили-то?

Забавный факт №2: с другими компьютерами «свисток» работает, как часики, что намекает

Забавный факт №3: подобную проблему наблюдали и на других системах, и везде жалуются на МАС-адреса, а точнее на их рандомизацию. Говорят, что виновата какая-то «обнова» NM (тот же Alt Linux, CentOS, причём на багтрекере этот баг закрыли с пометкой, мол, не будем разбираться, барахтайтесь сами), что заставляет задуматься. Нет, возможно, к моей проблеме эти жалобы не имеют никакого отношения, но упомяну ради справедливости.

Забавный факт №4: примерно в это же время одно из зеркал «легло» (а именно - netweaver.uk или как-то так). Что они там накорчевали, один Кирк Джонсон ведает.

Итак, ваши предложения, кто виноват? «Винда», NM или, может быть, какие-то энергосберегающие настройки в БИОСе подкрутить надо? И что делать: забыть про «игори», менять NM на другую утилиту? Или же проблема в каком-нибудь банальном однострочнике, который мне надо создать?

  1. Версия ядра?

  2. dmesg после возникновения проблемы?

  3. lsusb

Помогает только перезагрузка с последующим «бутом» прямиком в дистрибутив. Плюс скорость значительно просела по сравнению с «виндой» - раз в двадцать

  1. А помогает ли вытаскивание свистка и втыкание его обратно? Можно также попробовать переткнуть в тот же порт и в совсем другой.

перестаёт видеть сети. Вообще.

  1. А сетей несколько или она одна?

  2. Попробуй sudo iw dev wlp3s0 scan.

  3. Покажи вывод iw phy.

  4. Сравни содержимое dmesg и iw phy с работающим нормально и с заглючившим адаптером.

  5. А в качестве WiFi AP какое устройство работает?

Deleted ()
Ответ на: комментарий от Deleted

Версия ядра?

5.2.1, утром обновился до 5.3 - тот же результат. Под «убунтой» - последнее для 19.04.

А помогает ли вытаскивание свистка и втыкание его обратно? Можно также попробовать переткнуть в тот же порт и в совсем другой.

Как ни странно, да, но только с перезагрузкой и втыканием в другой порт. Забавно, но в соседнем торчал шнур от колонок «на питание». Не знаю, могло ли оно влиять, поэтому попробую поиграться с расположением, заодно и выловлю dmesg и iw phy.

Кстати, lsusb в любом случае отображает подключённый адаптер, даже если он не «фурычит».

Bus 003 Device 002: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
Korchevatel ★★★★★ ()
Ответ на: комментарий от Korchevatel

Как ни странно, да, но только с перезагрузкой и втыканием в другой порт.

А перетыкание без перезагрузки?

Deleted ()
Ответ на: комментарий от Deleted

Если рядом с «колоночным» шнуром, то ноль реакции. После этого индикатор перестаёт светиться. Если его подальше втыкнуть, перезагрузить и перевтыкнуть - всё подхватывается.

В «оффтопике» такого вообще не наблюдается, всё работает. Поэтому будем посмотреть вывод логов.

Korchevatel ★★★★★ ()
Ответ на: комментарий от xDShot

dnsmasq «установлен»?

Нет, ставил всё «по-минимуму». NM и апплет, всё. В Live-образе Ubuntu его не видел.

Что мешает в «арче» «играть»?

Wine, увы, не так хорош, как хотелось бы. Плюс, целых десять лет «воздержания» на старом Core2Duo сказываются.

Korchevatel ★★★★★ ()

Провёл небольшую диагностику своего «корча».

Итак, вывод iw phy в обоих случаях абсолютно одинаковый (проверял не «на глазок», а с помощью diff). В dmesg следующее:

Нерабочий «свисток»:

[    4.617705] rt2800usb 1-1:1.0 wlp3s0f0u1: renamed from wlan0

против «рабочего»:

[    4.635003] rt2800usb 3-1:1.0 wlp39s0f3u1: renamed from wlan0
[   31.478192] wlp39s0f3u1: authenticate with c4:6e:1f:43:83:b4
[   31.544771] wlp39s0f3u1: send auth to c4:6e:1f:43:83:b4 (try 1/3)
[   31.547737] wlp39s0f3u1: authenticated
[   31.550020] wlp39s0f3u1: associate with c4:6e:1f:43:83:b4 (try 1/3)
[   31.553812] wlp39s0f3u1: RX AssocResp from c4:6e:1f:43:83:b4 (capab=0x431 status=0 aid=2)
[   31.556429] wlp39s0f3u1: associated
[   31.580649] IPv6: ADDRCONF(NETDEV_CHANGE): wlp39s0f3u1: link becomes ready

В общем, понятно, что непонятно ничего.

Пока что единственным гарантированно рабочим вариантом обойти эту проблему является использование другого USB-порта. Но всё-таки интересно узнать, почему оно так происходит, плюс почему скорость раз в двадцать в сравнении с «виндой» упала (особенно при скачке чего-либо через «торренты», сайты работают хорошо).

UPD: также при «перетыке» в другой порт скорость восстановилась до идеальных значений. Поэтому делаю вывод, что питание колонок по USB в «линуксе» реализовано как-то криво.

Korchevatel ★★★★★ ()
Последнее исправление: Korchevatel (всего исправлений: 1 )
Ответ на: комментарий от Korchevatel

А sudo iw dev wlp39s0f3u1 scan на заглючившем адаптере?

Поэтому делаю вывод, что питание колонок по USB в «линуксе» реализовано как-то криво.

А ещё линукс может взорвать жёсткий диск и сломать пополам монитор!

Дело скорее всего в том, что линуксовый драйвер для этого свистка не умеет полноценно ресетить устройство. В результате, при перезагрузке из венды, устройство уже неким образом инициализировано и настроено, причём несовместимо с тем, что ожидает видеть сам драйвер. Но это просто догадка по твоим противоречивым сообщениям.

Deleted ()
Ответ на: комментарий от Deleted

А sudo iw dev wlp39s0f3u1 scan на заглючившем адаптере?

Делал. Ноль реакции — просто зависает процесс.

Дело скорее всего в том, что линуксовый драйвер для этого свистка не умеет полноценно ресетить устройство. В результате, при перезагрузке из венды, устройство уже неким образом инициализировано и настроено, причём несовместимо с тем, что ожидает видеть сам драйвер.

Несогласен. После «перетыка» «свисток» начал работать как положено, в том числе и при перезагрузке из «винды».

противоречивым сообщениям

Ну уж извините, не баг «репортим». Тем более, что в таких вопросах я ещё слишком мало понимаю, чтобы «правильно» вопросы задавать.

Поскольку решение (хоть и дрянное) найдено, вопрос закрываю.

Korchevatel ★★★★★ ()
Ответ на: комментарий от Korchevatel

Делал. Ноль реакции — просто зависает процесс.

Сколько ждал? А в dmesg при этом что-нибудь сыпалось?

Несогласен. После «перетыка» «свисток» начал работать как положено, в том числе и при перезагрузке из «винды».

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

Если так, то это странно. Обычно, при возникновении каких-то низкоуровневых проблем с USB, в dmesg начинает писаться много всякого дерьма, например про нестабильность линка, и подключенное устройство просто целиком не работает.

Кстати, можно сравнить lsusb -t в случаях с «правильным» и «неправильным» портом. Может эти порты вообще к разным USB-хост-контроллерам относятся и это как-то связано с проблемой.

Ещё можно сравнить вывод lsusb -v.

Deleted ()
Ответ на: комментарий от Deleted

Сколько ждал? А в dmesg при этом что-нибудь сыпалось?

Минут пятнадцать (как раз в туалет приспичило, хе-хе). «Тыкал» dmesg — ничего.

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

Да. Возможно, что ему просто питания не хватало, т.к. рядом торчал шнур на колонки, и оба устройства работали, по сути, с одного хаба.

Korchevatel ★★★★★ ()
Ответ на: комментарий от Korchevatel

Возможно, что ему просто питания не хватало

Но перезагрузка из винды в линукс на такое влиять не должна же.

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.