De când am început să folosesc openwrt pe routerul meu, a început să se întâmple ceva ciudat.

De obicei am 4 dispozitive (2 telefoane și 2 laptopuri) conectate zilnic la AP/routerul WiFi, dar unul dintre laptopuri (și anume un XPS 13 9365) a început să se „deconecteze” brusc. Am citat cuvântul pentru că, teoretic, sunt încă conectat, dar pur și simplu conexiunea la rețea nu mai funcționează.

Este ciudat, deoarece problema pur și simplu nu apare în unele zile, în timp ce alte zile sunt un adevărat coșmar, conexiunea încetând să funcționeze la fiecare două minute. Și numai pentru XPS 13. Alte dispozitive funcționează de minune, chiar și atunci când am ~10 dispozitive conectate simultan.

Iată ce primesc imediat după ce observ că rețeaua se oprește:

$ sudo iw dev link "wlp60s0".
Conectat la **:**:**:**:**:** (pe wlp60s0)
    SSID: my_ap
    frecventa: 2447
    RX: 15583826 octeți (14173 pachete)
    TX: 1550845 octeți (6382 pachete)
    semnal: -40 dBm
    rx bitrate: 144,4 MBit/s MCS 15 GI scurt
    Rata de biți tx: 144,4 MBit/s MCS 15 GI scurt

    steaguri bss: scurt-preambul short-slot-time
    perioada dtim: 2
    far int: 100

Și mai am o adresă IP etc.:

$ lista de adrese ip
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue stare UNKNOWN grup implicit qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
    inet6 ::1/128 scope host 
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
3: enx00e04c6810ec: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN grup implicit qlen 1000
    link/eter **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
5: wlp60s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stare UP grup implicit qlen 1000
    link/eter **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.11/24 brd 10.0.0.255 scope global dynamic wlp60s0
       valid_lft 43060sec preferred_lft 43060sec
    inet6 fe80::fa63:3fff:fe2f:837/64 scope link 
       valid_lft pentru totdeauna preferred_lft pentru totdeauna

Deci, din cele de mai sus, puteți vedea că sunt încă conectat la AP și am un IP valid. Dar indiferent pe cine încerc să pun ping, am pierderi de pachete de 100%. Nici alte moduri de conectare (cum ar fi ssh, browser etc.) nu funcționează. Vedea:

$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) octeți de date.
^C
--- 10.0.0.1 statistici ping ---
2 pachete transmise, 0 primite, 100% pierdere de pachete, timp 1011 ms

De asemenea, am încercat să verific dacă există mesaje de sistem. Fara noroc:

$ dmesg
$

Notă: am emis sudo dmesg -c imediat după pornire pentru a facilita identificarea problemelor și în timp ce rețeaua era încă utilizabilă.

Sunt sub Ubuntu 20.04.3:

$ cat /etc/issue
Ubuntu 20.04.3 LTS \n \l

Dispozitivul meu wireless:

$ lspci | rețeaua grep -i
3c:00.0 Controler de rețea: Intel Corporation Wireless 8265 / 8275 (rev 78)

Ca o soluție temporară, am dezvoltat un script pentru a opri NetworkManager și a reconecta prin linia de comandă. Ceva de genul:

iface="wlp60s0"
essid="my_ap"
tmpfile="/tmp/wpa.conf"
pass="pasul_meu"

sudo systemctl stop NetworkManager.service
sudo iw dev "$iface" del
sudo iw phy phy0 interfață adăugați tipul „$iface” gestionat
sudo ip link setează „$iface”.
sudo wpa_passphrase "$essid" "$pass" > "$tmpfile"
sudo wpa_supplicant -i"$iface" -c"$tmpfile" -B
sudo dhclient -v "$iface"

Acest lucru face viața puțin mai ușoară, dar, desigur, este doar temporară, rudimentară și departe de a fi ideală. Și, de asemenea, nu ajută prea mult, deoarece tot pierd conexiunea din când în când, exact la fel ca atunci când folosesc NetworkManager. Este mai rapid decât să așteptați repornirea NetworkManager...

Ce am incercat pana acum

• Se dezactivează wifi power_save cu sudo iw dev wlp60s0 set power_save off.
• Dezactivarea economisirii energiei wifi prin NetworkManager prin editare /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf și în schimbare wifi.powersave = 3 la wifi.powersave = 2 apoi repornind. (sursă: https://unix.stackexchange.com/a/315400/108418)
• Modificarea securității wifi pe router (WPA -> WEP sau altele) (sursa: 20.04 nu se poate conecta la wifi de 5 Ghz după actualizare)
• Schimbarea modului wifi de la „N” la „Legacy”. Acesta părea să rezolve problema, dar poate pentru că nu l-am folosit suficient de mult. În plus, scăderea vitezei rețelei face evident că această opțiune este impracticabilă.
• Activarea modului de depanare NetworkManager și încercarea de a identifica posibilele probleme.

Nici unul dintre cele de mai sus nu a funcționat.

Alte link-uri pe care le-am vizitat

Acestea au fost câteva dintre încercările mele, dar fie simptomele nu sunt exact aceleași, fie soluția propusă nu a funcționat pentru mine...

https://www.reddit.com/r/linuxquestions/comments/ausg6k/arch_wifi_stays_connected_but_theres_no_internet/ehc3oph/

https://blog.stigok.com/2017/03/26/wifi-loses-connectivity-periodically-wpasupplicant-reason-4.html

Așa că postez toate astea aici, în speranța că cineva a trecut deja prin asta și poate că poate străluci niște lumini...

Mulțumesc foarte mult!

Actualizare #1

Am găsit o modalitate de a reproduce problema. De fiecare dată când vizitez această pagină și răsfoiesc fotografiile (pentru a face browserul să încarce multe fotografii deodată, în paralel), conexiunea se întrerupe.

https://www.facebook.com/terraadentropelomundo/photos/

Mă întreb dacă există probleme cu driverul wireless în gestionarea mai multor conexiuni simultan.

Actualizare #2

După ce am răsfoit pe alte forumuri în speranța unei soluții, am dat peste asta:

Se pare că a devenit mai bine când am schimbat „Beacon Interval” din implicit 100 ms la 50 pe AP-ul meu. Până acum nu există deconectări în trei zile.

EDITAȚI | ×: Se poate confirma, problema pare a fi rezolvată după această modificare.

(sursă: https://bugs.archlinux.org/task/58457#comment185619)

Are sens, având în vedere că am început să mă confrunt cu această problemă după ce m-am mutat la openwrt pe AP-ul meu. Deci, cu siguranță există ceva ciudat cu driverul/firmware-ul Intel, dar schimbarea farului pe AP-ul meu pare să rezolve problema. Voi mai testa câteva zile și voi vedea dacă problema a dispărut.

Actualizare #3

Nu a funcționat. Chiar și folosind beacon 50ms în openwrt, sunt încă deconectat din când în când fără ca mesaje să apară în dmesg...