A közelmúltban szolgáltatót váltottam, és jelenlegi szolgáltató egy FRITZ!Box 7530-as modem/router/WALN AP kombót adott. Amióta ez az eszköz van, a WLAN hálózatra való feljelentkezésnél (notebook boot vagy wakeup) időnként (teljesen véletelnszerűen) az AP elutasítja a WLAN kapcsolatot "PREV_AUTH_NOT_VALID" indokra hivatkozva. Ha a netctl@wlan0 service-t kézzel újraindítom, akkor zokszó nélkül felcsatlakozik.
Nagyjából 2 hete harcolok az AVM (FRITZ!Box) supporttal, de reménytelen velük eredményre jutni. Először hülyeségeket mondtak, pl. hogy állítsam a WLAN AP IP címét 1 végződésűre, aztán megállapították, hogy ez a notebook driver hibája, és majd a driver update megoldaj, aztán amióta végképp sarokba szorítottam őket, azóta csak azt hajtogatják, hogy ők RFC konformak, és a hiba csak nálam lehet. Szerintük távolítsam el az internet kapcsolatot, indítsam újra a gépet, és telepítsem újra az internet kapcsolatot. Mindezt azok után, hogy nem tudom hány körben tisztáztuk, hogy linux van a gépen, és folyamatosna linuxos logokat küldtem nekik ... siralmas.
Amit nem voltak hajlnadóak elárulni (az indokot mindenkinek a fantáziájára bízom), hogy a FRITZ!Box miért jelez authentikációs hibát, és miért bontja a kapcsolatot. Szóval OK, hogy a notebook a hibás, de miben és hogyan? A driver update szerintem több, mint valószínűtlen, mivel az authentikációt nem a driver végzi, amennyire én tudom, illetve ez a gép hosszú éveket ment hibamentesen egy másik AP-val.
Ha valaki futott már ilyenbe, vagy van valami ötlete, örömmel fogadnék egy kis segítséget.
Hozzászólások
A sokadik hülye ötlet után ma megkaptam az AVM support végleges válaszát: nem tudják mi a hiba, de biztos nem náluk van. Forduljak a notebook gyártójához. Hát süt belőlük a hozzáértés.
És igazuk is volt.
"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."
Örülök, hogy te a probléma és a supporttal folytatott kommunikáció részletes ismerete nélkül ilyen hozzáértéssel tudsz nyilatkozni. Szerencsére voltak itt olyanok (külön köszönet answ-nak), akik értelmes segítséget adtak. Ha elolvastad volna figyelmesen az itteni beszélgetést, és végigolvastad volna azt, amit answ linkelt, akkor látszik, hogy a kérdés közel sem ilyen egyszerű és egyértelmű.
Sajnos az AVM support még a problémát sem igazán értette meg, gyakorlatilag a szokásos hárítós dumákat tolták. Remélem, hogy ha te majd esetleg hozzájuk kell, hogy fordulj akkor ezzel a nyegle és szakmaiatlan supporttal elégedett leszel.
"Reménysugár a megoldásra:
Talán egyszer lesz olyan kernel verzió, amelyikben jobb ath9k driver van, és nemcsak az EAPOL szekvenciát küldi lassabban, de még a wakeupnál sem vágja a wlan interfacet softblockba. (Jelenleg ugyanis minden 4.14-est követő stabil kernelverzió a softblockos problémát (is) adja, tehát ha az EAPOL szekvencia még OK is lenne, akkor sincs hálózat. Így az állás egyelőre 2:0 az ath9k javára.)"
Akkor hol is van a hiba, a routernél vagy a kliensen?
"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."
Valószínűleg mindkettőben, a jelek szerint egyiket sem implementátlák elég robusztusan. Csak az AP-nál nincs remény a megoldásra, pontosan a kiváló support miatt, aminek szerinted igaza van. De ha elolvastad volna az itt összegyűjtött információkat, megspóroltad volna ezt a posztot. Nyilván nem kerülte volna el a figyelmedet, hogy van olyan AP, amivel sok évet problémamentesen ment at ath9k driver sok kernel verzióval, többek között az éppen aktuálissal is. De ennél még többet is találtál volna, mert mások (többek között Linus is) tapasztaltak hasonlót. Csak a jelenség elég ritka , mert elég sok eszköz robusztusra van megcsinálva, így vagy az AP vagy a STA megoldja a problémát. Akkor van gond, ha mindkettő szar. És itt ez az eset áll fenn. Még akkor is, ha ez a távolról beleokoskodással nem kompatibilis...
Tehát a kínos igazság az, hogy az öreg Pirelli AP sokkal jobb, mint az AVM vadiúj szara, és az AVM support sajnos szakmaitlanul és ostobán adta elő magát.
Ez így nagyon kevés.
Más kliens eszközzel is ezt csinálja az AP?
Más operációs rendszer (például Windows) alatt is ezt csinálja az AP a notebookkal?
Teljesen más linux disztribúció / kernel verzió esetén is ugyanez a helyzet?
Milyen wireless chipseted van?
Milyen driver van betöltve hozzá?
Milyen verziójú a kerneled?
Milyen messze próbálod az AP-től? Egész közel is csinálja?
Próbáld különböző szabványokra kényszeríteni, hogy azon is csinálja-e? (például csak 2.4 GHz, csak N vagy csak 5 GHz AC vagy fix 1-es csatorna, 20 MHz sávval, stb..)
"Más kliens eszközzel is ezt csinálja az AP?"
Egyelőre nem tapasztaltam. Ez az elsődleges otthoni gépem, más eszközt nem használok ilyen gyakorisággal, és a hiba nagyjából 1-2 naponta egyszer jelentkezik.
"Más operációs rendszer (például Windows) alatt is ezt csinálja az AP a notebookkal?"
Azon a gépen, amin tapasztalom csak linux van. Van még 2 windowsos munkahelyi notebook, amelyik huzamosabb ideig fent szokott lenni a hálón, azokkal egyelőre nem jött elő.
A linuxos gép azóta hozza a hibát, amióta az új AP van, ez a logokból egyértelmű.
"Teljesen más linux disztribúció / kernel verzió esetén is ugyanez a helyzet?"
Nincs ilyen heterogén eszközpark. Kernelverziót elvileg tudnék próbálni, a gond az, hogy a 4.14.x utáni összes stable kernel softblockba teszi a wlant sleep módban.
"Milyen wireless chipseted van?"
Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) (rev 01)
"Milyen driver van betöltve hozzá?"
Ezt csak pénteken tudom majd megválaszolni.
"Milyen verziójú a kerneled?"
4.14 lts, talán 145 körüli, pontosat ebben is csak pénteken tudok mondani.
"Milyen messze próbálod az AP-től? Egész közel is csinálja?"
Igen.
"Próbáld különböző szabványokra kényszeríteni, hogy azon is csinálja-e? (például csak 2.4 GHz, csak N vagy csak 5 GHz AC vagy fix 1-es csatorna, 20 MHz sávval, stb..)"
Köszi, fogok ilyen kísérleteket tenni.
"Milyen driver van betöltve hozzá?"
ath9k driver van betöltve, a teljes modul lista, ami releváns lehet:
ath9k, ath9k_common, ath9k_hw, ath, mac80211, cfg80211
"Milyen verziójú a kerneled?"
4.14.150-1-lts414
Ugyanaz az SSID van beállítva a 2.4 GHz-es és 5 GHz-es frekvenciához is FritzBox AP-ben?
Igen, de az 5Ghz nincs engedélyezve.
Lehet hogy bugos a FritzBox és band steeringgel próbálkozik. A leírásában az szerepel, hogy ha más az SSID akkor nem csinálja, de ha nagyon hülyék voltak, akkor kikapcsolt 5 GHz esetén is megpróbálja :)
Átneveztem az 5GHz-eset, kíváncsi vagyok.
A hibajelenséghez még érdekes adalék, hogy a hibát úgy észleltem, hogy van egy nyitott AP hatósugáron belül, és amikor ez az autentikációs hiba jelentkezett, akkor automatikusan megpróbált egy másik AP-t elérni. Mivel a nyitott AP beengedte, de az internetre már nem jutott ki, így nem volt internet kapcsolat. Most WPA suppplicant konfiguráciját úgy módosítottam, hogy csak az általam megaodtt SSID-jű nyitott AP-ra jelentkezhet fel, így a nyitott AP titlva van és aFRITZ!Box AP-nál próbálja automatikusan újra. Amikor újra próbálja, akkor sikeresen fel is kapcsolódik. Viszont határozottan úgy tűnik, hogy csak wakeup esetén próbálkozik újra, hiszen ekkor már él az interface. Ezzel szemben boot esetén, ha sikertelen az autentikáció, akkor ejti az interfacet.
A logokból viszont szépen követhető, hogy ha wakeup esetén jelentkezik a hiba. A bootnál meg más jelekből is elég nyilvánvaló.
"Átneveztem az 5GHz-eset, kíváncsi vagyok."
Sajnos ez nem oldotta meg a problémát.
Itt egy másik Atheros chipről egy igen érdekes beszélgetés van, ami hasonlónak tűnik a problémádhoz:
https://ath9k-devel.ath9k.narkive.com/nbbw7wEp/ar9462-problems-connecti…
Hát ez telitalálatnak tűnik! Ngayon köszi!
Gyakorlatilag az derül ki, hogy az EAPOL frameknél a küldési ferkevencia gyorsabb, mint amit az AP fogadni tud. És mivel egy csomó AP tudja fogadni, ezért ez nem probléma, és ráadásul a legtöbb STA lassú ütemben küldi a kezdeti EAPOL frameket, ezért ez hiba általában azoknál az AP-knál sem jön elő, akik nem tudnak gyors ütemben fogadni.
Az én AP-n rögzített wireshark logom is egyértelműen EAPOL race conditionre utalt, de ez eléggé megerősíti ezt.
Már csak az a kérdés, hogy mi ateendő. Ez egy 5 éves szál, azóta elvileg a kernelben javítaniuk kellett. Hogy most miért nem működik, az jó kérdés.
Még egy kis adalék: Megnéztem egy másik, a családban használt elvileg azonos (gyakorlatban ugyanaz a széria kicsit más felszereltségű) linuxos notebook logját, ott nincs semi gond. És valóban, egy teljesen másik wlan adapter van bene: Intel Centrino Advanced-N 6200.
Így a lehetséges megoldások közé felkerült, hogy elveszem a gyerek gépét. :-)
Hiba esetén az EAPOL szekvencia úgy néz ki (a wireshark vizualizáció alapján), hogy:
AP -> STA: EAPOL Key (Message 1 of 4)
STA -> AP: EAPOL Key (Message 2 of 4)
AP -> STA: EAPOL Key (Message 3 of 4)
STA -> AP: EAPOL Key (Message 4 of 4) <-- valószínűleg ezt nem fogadja az AP, és újrakezdi az authentikációt, amire nem kap választ majd bontja az összerendelést (kapcsolatot)
AP -> STA: EAPOL Key (Message 1 of 4)
AP -> STA: EAPOL Key (Message 1 of 4)
AP -> STA: EAPOL Key (Message 1 of 4)
AP -> STA: EAPOL Key (Message 1 of 4)
Ilyenkor tipikusan még az association request / response is duplán jön, de ott az időzítés teljesen változó, hogy melyik EAPOL üzenetváltások közé kerülnek be. Szóval látszik, hogy a kommunikáció szétcsúszik.
Esetleg a driver(ek) paramétereinél nem tudsz lassabb küldést megadni? Csak egy ötlet.
Csak akkor szólok hozzá egy témához, ha értelmét látom.
Sajnos nem találok ilyen paramétert.
ath9k:
Parameters:
blink = "0"
bt_ant_diversity = "0"
btcoex_enable = "0"
led_active_high = "-1"
nohwcrypt = "0"
ps_enable = "0"
mac80211:
Parameters:
beacon_loss_count = "7"
ieee80211_default_rc_algo= "minstrel_ht"
max_nullfunc_tries = "2"
max_probe_tries = "5"
probe_wait_ms = "500"
cfg80211:
Parameters:
bss_entries_limit = "1000"
cfg80211_disable_40mhz_24ghz= "N"
ieee80211_regdom = "00"
Én azért végigpróbálgatnám.
parm: minstrel_vht_only:Use only VHT rates when VHT is supported by sta. (bool)
parm: max_nullfunc_tries:Maximum nullfunc tx tries before disconnecting (reason 4). (int)
parm: max_probe_tries:Maximum probe tries before disconnecting (reason 4). (int)
parm: beacon_loss_count:Number of beacon intervals before we decide beacon was lost. (int)
parm: probe_wait_ms:Maximum time(ms) to wait for probe response before disconnecting (reason 4). (int)
parm: ieee80211_default_rc_algo:Default rate control algorithm for mac80211 to use (charp)
Csak akkor szólok hozzá egy témához, ha értelmét látom.
Sosem használom a szolgáltató wifijét, maradok a saját mikrotik ap-nál.
Az jó legalább segíthetsz. :-)))
Nálam otthon a Xiaomi Note 10 csinálja ugyanezt Mikrotik AP mellett. A régi telefonom teljesen jól ment vele, az új authentikácós hibát jelez, miközben a WIFI jelszó biztosan stimmel.
Mikrotikot érdemes frissíteni, illetve érdemes ránézni a logjára, hogy ilyenkor mit mond.
Az informatív: 4-way handshake-timeout a válasz. A jelszó jó.
Letöröltem az interfészt, visszarakta, most épp jó.
Nálam is hasonló a jelenség itthon, de nekem egy tp link van openwrtvel. Akkor sem volt egy csúcs, most sem az. Mivel nálam a háló is lassú az eszköz miatt ezért nálam valószínű csere lesz. A chipet megnézem majd ha gépnél vagyok.
[WORKAROUND]
Ha megoldás nincs is egy wokraround-ra rájöttem. A network manager szolgáltatások tipikusan egyszeri kapcsolatfelépítésre alapoznak. Ezzel szemben a dhcpcd serivce egy folyamatos kapcsolatkarbantartást végez. Ugyan az eredeti probléma továbbra is létezik, de a dhcpcd addig fogja próbálni a kapcsolatot felépíteni amíg nem sikerül. Így az ilyen időnként jelentkező problémát szépen elfedi.
Szóval váltottam netctl service-ről dhcpcd service-re, és minden megy. Igaz, hogy időnként a wakeup-nál néhány másodpercig még nincs hálózat, de hamarosan megéled.
Alternatív megoldás (igazából 2. számú workaround) még az lehetett volna, hogy visszarakom a régi AP-t - ami hibátlanul működött és a régi szolgáltató nem kéri vissza - az új modem egyik LAN portjára, de ekkor két eszközt kellene folyamatosan táplálni, mert a régi AP DSL modem beállításai zárolva vannak, így modemként nem tud az új szolgáltatóval együttműködni.
Győzött az 1. workaround a környezetvédelem és az egyszerűség jegyében.
Reménysugár a megoldásra:
Talán egyszer lesz olyan kernel verzió, amelyikben jobb ath9k driver van, és nemcsak az EAPOL szekvenciát küldi lassabban, de még a wakeupnál sem vágja a wlan interfacet softblockba. (Jelenleg ugyanis minden 4.14-est követő stabil kernelverzió a softblockos problémát (is) adja, tehát ha az EAPOL szekvencia még OK is lenne, akkor sincs hálózat. Így az állás egyelőre 2:0 az ath9k javára.)