Časté odpojování od WiFi

Zdravím, potřeboval bych poradit. Po nasazení Omnie se nám zhoršilo spojení přístrojů přes WiFi (Android telefony a tablet, PC přes WiFi). Dost často dochází k odpojení od WiFi sítě, přitom s předchozím routerem (obyčejný Netgear) k tomuto nedocházelo. V telefonu mám nastaveno, aby bylo připojení stálé, tj. i v režimu spánku (toto jsem neměnil, mám to tak pořád). Koukal jsem do logu a dost často se tam opakuje následující:

2016-12-21T10:01:01+01:00 info hostapd[]: wlan1: STA 6c:2f:2c:e2:2b:48 IEEE 802.11: deauthenticated due to local deauth request

Je toto jádro onoho problému? Pokud ano, co je příčinou, případně jak to vyřešit? Díky za pomoc.

Dobrý den,
Tohle se tady řeší 2x už v anglické sekci fóra a zítřejší aktualizace by to měla vyřešit:
"

Na čtvrtek 22. 12. 2016 je naplánována aktualizace systému routeru Turris na
verzi Turris OS 3.4.

  • Aktualizace kernelu na nejnovější verzi, přidána podpora pro NEON instrukce.
  • Aktualizace a opravy ovladačů WiFi.
  • Přidány chybějící překlady Forisu a generování QR kódů pro mobilní aplikaci, přidán nový plugin pro generování diagnostických reportů.
  • Nové minipoty pro uCollect - HTTP proxy, Squid proxy a Polipo proxy; drobné opravy.
  • Podpora pro Turris Omnia v python-turris-gpio (modifikovaná verze knihovny RPi.GPIO).
  • Základní podpora tisku přes CUPS.
  • Opravy resolvování DNS záznamů a práce s databází v nástroji Majordomo.
  • Přidání konfigurace Updateru do záloh, podpora konfigurovatelných záloh.
    "

Problem NEBOL aktualizaciou opraveny. Postihuje to len 2,4GHz WiFi (radio1 v mojom pripade) a len jedno zariadenie (lacnejsi tablet). Symptomy su presne ako pisete. Na zariadeni sa to prejavuje tak ze sa javi ako pripojene, no len posiela poziadavky a z Omnie ziadna odpoved… V Omnii som diagnostiku nerobil. Predchadzajuci router Linksys E3200 toto obsluzit zvladol.

Píše Vám to něco v syslogu?

Tak bohužel, k odpojování dochází i po updatu. V logu jsou tyto zprávy:

2016-12-22T21:30:54+01:00 debug kernel[]: [19242.686876] ath10k_pci 0000:02:00.0: ath10k_pci ATH10K_DBG_BUFFER:
2016-12-22T21:30:54+01:00 debug kernel[]: [19242.686887] ath10k: [0000]: 012CBFAE 10004C1D 00437860 00000001 00000000 00000140 012CBFAF 10004C1D
2016-12-22T21:30:54+01:00 debug kernel[]: [19242.686892] ath10k: [0008]: 00437860 00000001 00000004 00000140
2016-12-22T21:30:54+01:00 debug kernel[]: [19242.686896] ath10k_pci 0000:02:00.0: ATH10K_END
2016-12-22T20:30:59+01:00 info hostapd[]: wlan1: STA 6c:2f:2c:e2:2b:48 IEEE 802.11: deauthenticated due to local deauth request

Jestli používáte nightly branch, tak se to tam vyřeší až zítra, protože teď momentálně tam není: kmod-ath10k

"tomorrow’s nightly should have both available and non-ct installed as default "

Docházelo k odpojování i na úplně první verzi Omnie (3.2) nebo to začalo teprve až s 3.3?

Nightly nepoužívám, alespoň ne vědomě. Bohužel, jestli to odpojování bylo i u 3.2 si nejsem jistý, ale mám dojem, že to dělá od začátku.

Také mám problém s výpadky wifi 2.4GHz. Ve verzi 3.2 to bylo bez problémů, verze 3.3 a 3.4. se chovají stejně - wifi přestane fungovat od několika minut do několika hodin. Včera jsem po aktualizaci na 3.4 a výpadku preventivně obnovil tovární nastavení, ale žádná změna. Trochu mne zarazilo, že svítivost LED je po obnovení do továrního nastavení stále snížená, ale vše ostatní se tvářilo jako po úspěšném resetu…

Z toho co napsal petr.dana bych se zeptal, kdy došlo k nasazení, protože to mohlo být už po vydání verze 3.3.

Mám stejný problém. 3.5 má vrátit ovladače zpět. https://github.com/CZ-NIC/turris-os/blob/test/CHANGELOG .
Ovšem nevím, kdy dojde k nasazení. Doufám, že už dnes. Začínají prázdniny a odpojování je opravdu nepříjemné. Jak začít používat NIGHTLY?
Pokuď to dnes nepůjde, asi zapojím starý Mikrotik. Omnie v tuto chvíli neplní svou hlavní roli. Trochu smutné u routeru za takovou cenu. A že měli spoustu času vyladit software (při obrovských prodlevách s hardware…).

Podle @miska , že to píše ATH10K_DBG_BUFFER nevadí. Ta hláška sama o sobě je neškodná akorát to spamuje syslog, ale prý to nelze jednoduše vypnout.

Důležité je, co poslal @petr.dana: "2016-12-22T20:30:59+01:00 info hostapd[]: wlan1: STA 6c:2f:2c:e2:2b:48 IEEE 802.11: deauthenticated due to local deauth request"
Bylo by dobré, kdyby jste @Michelle poslal, zda tam máte to samé. Pokud ano, tak jim to zkuste napsat na twitter, kde psali, že aktualizace na 3.4 vyřeší všechny wifi problémy.

Ještě před tím než přepnete do nightly, které developeři moc nedoporučují vyzkoušejte:

opkg update; opkg remove ath10k-firmware-qca988x-ct; opkg install ath10k-firmware-qca988x; reboot

případně přidat wpa_group_rekey ‘0’ do config wifi-iface

Raději to napíši, ale používáte radio0 pro 5 GHz a radio1 pro 2.4 GHz?

Nechci to zakriknout, ale tohle mi zrejme pomohlo, protoze wifi nevypadla uz skoro 18 hodin. Sice mam ted chybovou hlasku od updateru, ale to je detail…

Error from 2016/12/24 07:02:12
Updater failed:
[string “transaction”]:310: [string “transaction”]:143: Collisions:
• /lib/firmware/ath10k/QCA988X/hw2.0/board.bin: ath10k-firmware-qca988x (existing), ath10k-firmware-qca988x-ct (new)

Zkusil jsem vyměnit ten ovladač, jak bylo uvedeno výše. Jeden den to vypadalo, že to snad pomohlo, ale ne, dnes sleduju, že to už několikrát zase odpojilo a v logu je stále ta hláška “deauthenticated due to local deauth request”

Vyzkoušejte prosím ještě nightly branch, jestli to pomůže. (Vyřeší to pouze ath10k)
Když ne, tak Vám bude muset poradit někdo ze členů Turris teamu.

Mam po poslednich dvou prosincovych upgradech stejny problem na Turrisu 1.1. Wifi se nepravidelne odpojuje a pripojuje. Myslim, ze je zde na foru uz velka rada lidi, kteri maji stejny ci podobny problem a je jasne, ze tento problem nastal az po zminenych upgradech OS. Nema tedy zadny smysl zde zadat kolegy o pomoc. Ta muze prijit jen a jen od lidi z Turris teamu. Oni vypustili nevyladeny software a meli by s tim urychlene neco udelat, jinak jim lide omlati jejich routery o hlavu.

Měl jsem stejný problém po upgrade Turrisu 1.0 na OS 3.3, problém vyřešilo flashnout nejnovější TurrisOS 3.3 z SD karty. Nikoliv pouze tovární nastavení, to vám nahraje Turris 1.0 a bude se stahovat spousta balíku v rámci aktualizace. Postupujte postupu https://www.turris.cz/doc/cs/troubleshooting/sdcard_recovery tím nainstalujete nejnovější verzi OS 3.4 do NOR a proveďte i smazání NAND. Už jen to samo úplně vyřeší problém s odpojováním Wifi na Vašem turrisu. Tento postup mám vyzkoušený a funguje nemá smysl čekat na to že se to nějakým updatem spraví, zřejmě někde zůstala nějaká špatná konfigurace nebo špatná verze čehosi. Novou instalací přímo OS 3.4 to spravíte.

2 Likes

Takze som troska investigoval a problem je ze pri problemovom tablete nemam tieto polozky v syslog-u, co mne ako laikovi vravi, ze nejde DHCP (nepriradi, …) Dane polozky som vyseparoval od ineho android zariadenia, co ide len na 2,4GHz. Co sa tyka nastaveni, tak je jedno ci je AES alebo TKIP, alebo Legacy mode, … proste cokolvek.

2016-12-29T02:00:32+01:00 info dnsmasq-dhcp[3173]: DHCPDISCOVER(br-lan)
2016-12-29T02:00:32+01:00 info dnsmasq-dhcp[3173]: DHCPOFFER(br-lan)

Zdravim,

podarilo za to odpojovanie vyriesit? Ja to na mojom routri na 2.4GHz sieti stale mam. Je to neskutocne otravne.

Vdaka.

Ja to mám tiež, wifi funguje normálne až do momentu než pripojím Samsung Galaxy Tab2, vtedy odpája/pripája každých pár mintút. Postihuje to všetky ostatné zariadenia na 2.4GHz. Keď je tablet vypnutý, problémy niesú

Po testovani som zistil, ze to zrejme robi DHCP. Ked nastavim staticku IP tak problem nemam. To iste vidim v logu, pravidelne sa spusti dnsmasq script, ktory mi zmaze IP, potom ju obnovi. Windows to prezije - SSL VPN sa reconnectne, ale mac to zblbne a pokial nevypnem/nezapnem znova wifi tak to nefunguje.

Dporučuju rozebrat a zkontroval kabely, ja měl jednu anténu úplně odpojednou … jeden kabel odpojený, druhý přetržený, asi od začátku