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

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

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

2. lsusb

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

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

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

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

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

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

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

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

Версия ядра?

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

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

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

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

Bus 003 Device 002: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

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

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

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

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

dnsmasq «установлен»? Что мешает в «арче» «играть»?

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

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

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

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

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

Итак, вывод 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 в «линуксе» реализовано как-то криво.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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