Od mniej więcej 2 miesięcy zaczęła mi kaszleć sieć bezprzewodowa
na laptopie z Ubuntu. Niezbyt często ale regularnie (zwykle 1-2 razy dziennie)
sieć znika, ani automatyczne ani ręczne próby odnowienia połączenia
przez aplet menedżera sieci nic nie dają, okazyjnie pojawia się pytanie
o hasło Wi-Fi ale jego podanie też nic nie daje.
Problem jest nie tylko mój, więc zapiszę,
jak sobie z nim radzę.
Pod spodem
W logach widziałem parę odmian błędów. Najczęściej pojawia się nawała wpisów:
[ 6302.094539] iwlagn 0000:03:00.0: Error setting new RXON (-28) |
[ 6302.094541] iwlagn 0000:03:00.0: No space for Tx |
[ 6302.094543] iwlagn 0000:03:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -28 |
[ 6302.094545] iwlagn 0000:03:00.0: Error setting new RXON (-28) |
[ 6302.094552] iwlagn 0000:03:00.0: No space for Tx |
[ 6302.094555] iwlagn 0000:03:00.0: Error sending REPLY_TX_POWER_DBM_CMD: enqueue_hcmd failed: -28 |
ale bywają i inne:
May 19 23:35:42 banach kernel: [ 6254.060157] iwlagn 0000:03:00.0: Error setting new RXON (-110) |
May 19 23:35:43 banach kernel: [ 6254.560156] iwlagn 0000:03:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms. |
May 19 23:35:43 banach kernel: [ 6255.060126] iwlagn 0000:03:00.0: Error sending REPLY_RXON: time out after 500ms. |
Abstrahując od detali, daje to wyraźną informację jaki moduł jądra (tu - iwlagn
)
ma problemy.
Najprostszą metodą sprawdzenia czy/jakie tego typu informacje
zostały zalogowane jest napisanie - gdy sieć się rozłączy
Można też przeglądać /var/log/kern.log i /var/log/syslog.
Rozwiązanie
Żadną z klikanych technik nie udało mi się w takiej sytuacji
zreanimować połączenia, dlatego napisałem sobie następujący
krótki skrypt (prawdopodobnie trochę nadmiarowy ale nie mam motywacji
by sprawdzać, czego mógłbym się z niego pozbyć):
sudo ip link set wlan0 down |
sudo ip link set wlan0 up |
Zapisałem go jako ~/bin/wlan_restart
, ustawiłem uprawnienia do
wykonania (chmod a+x ~/bin/wlan_restart
), dorobiłem skrót na
pulpicie (prawe kliknięcie, Create Launcher, typ Application in
Terminal, kojarząca się z siecią ikonka i
/home/marcin/bin/wlan_restart
jako wykonywane polecenie) i gdy sieć
się rozłączy, albo klikam tą ikonkę, albo (gdy akurat jestem w
terminalu) piszę ~/bin/wlan_restart
. Efektem jest przejście przez
aplet zarządcy sieci w tryb nawiązywania połączenia, który po krótkiej
chwili kończy się sukcesem.
Co robi ten skrypt? Najpierw usuwa moduły jądra obsługujące moją
kartę bezprzewodową (rmmod
), potem ładuje je ponownie (modprobe
)
a na koniec, dla pewności, zatrzymuje i uruchamia interfejs sieciowy.
Na innych urządzeniach
Ani problem ani rozwiązanie nie są związane z używaną przeze
mnie kartą Intela. Konrad doszedł
do takiego rozwiązania:
Sądzę, że wystarczyłoby przeładować samo ath9k
albo ath9k
i ath
,
ale cytuję przetestowany oryginał.
Jak ustalić jakie moduły jądra przeładować? Nazwa kluczowego
powinna być widoczna we wspominanych wpisach do loga. Powiązane
moduły zaprezentuje polecenie
na przykład w moim wypadku pokazało:
led_class 3732 3 iwlcore,sdhci,asus_laptop |
mac80211 238128 2 iwlagn,iwlcore |
cfg80211 148386 3 iwlagn,iwlcore,mac80211 |
a u Konrada:
led_class 5256 2 acer_wmi,ath9k |
cfg80211 109144 3 ath9k,mac80211,ath |
w lewej kolumnie są załadowane przez jądro moduły, w prawej
informacje czy/jaki inny moduł używa modułu wpisanego z lewej.
Na przykład z powyższego widać, że ath
używa ath9k
zaś cfg80211
używa
ich obu a także mac80211
.
Kolejność rmmod
powinna być ustalona tak, by moduł używający
usunąć przed używanym. Można to robić albo na podstawie lsmod
albo
eksperymentalnie - błędna kolejność zaowocuje błędami podobnymi do:
ERROR: Module iwlcore is in use by iwlagn |
widząc coś takiego rozumiemy, że iwlagn
trzeba usunąć wcześniej niż iwlcore
.
Kolejność modprobe
powinna być odwrotna.
Metoda
Problem z siecią zapewne zostanie w niezbyt dalekiej przyszłości
rozwiązany. Zanotowałem go także dlatego, że bardzo podobne techniki
mogą być przydatne w wielu innych sytuacjach, gdy jakieś urządzenie
nie jest obsługiwane albo jakiś sterownik nie działa poprawnie.
Technika rmmod
i modprobe
w bardzo wielu wypadkach pozwala
uniknąć rebootu (w pewnym sensie jest to selektywny reboot fragmentu
jądra).