Turris zamrzá po několika minutách – factory reset proveden

Mám 3 Turrisy, z toho 1 Omnia. Každý je na jiné síti, úplně jiné zapojení. Omnia je opakovač z UPC routeru přes Wi-Fi z 2.4GHz na 5GHz + NAT, jeden modrý Turris je jako sekundární rozšíření sítě za klasickým DSL O2 modem, klasika WAN/LAN a třetí Turris napojený kabelem na místního providera (Airwaynet), klasika WAN/LAN.

Dříve jsem Turrise využíval na různé tooly, monitoringy, vpn, apd… Někdy v roce 2018 se mi začaly všechny routery vysypávat a od té doby jsou nespolehlivé. Proto jsem postupně všechny přeinstaloval do továrního nastavení, absolutně nic na nich nenastavuji na rámec nezbytného minima, aby routovali internet (všechno výhradně jen klikačka přes Forris ve Quick-setupu po spuštění). Někteří z vás mi pomohli zde: Nemožnost restartovat Omnii

Společné symtomy

Po překlopení do továrního nastavení a minimální konfiguraci routery fungují bezvadně nějakou dobu. Ta doba je různá, ale pozoruji zkracovací trend. Nyní je to cca 1-2 týdny.

Jako první přestane fungovat DNSSEC. Stránky s jeho podporou nejdou načíst, protože vrací NXDOMAIN, popř. NSERROR. Pomůže DNSSEC na routeru úplně vypnout. Jakékoliv pokusy o přenastavení forwardování selhávají. Po restartu to funguje několik minut a pak zase konec.

Zpravidla jsem to poznal hned tím, že mi CZ.NIC poslal e-mail „ Upozornění od Vašeho routeru Turris“, ve kterém bylo, že se router neohlásil. Po přihlášení do Forisu tam byly desítky notfikací, že připojení na servery turris.cz se nepovedlo a že si Turris nemohl sáhnout na aktualizace.

Po několika dalších dnech se vysype DNS resolver úplně. Na Androidu už naštěstí je nativní podpora DoT, tam to nepoznám, ale ostatní fungují jen když se jim nastaví 1.1.1.1 nebo 8.8.8.8.

Po dalších týdnech dochází k úplnému zamrzání. Kontrolky sice poblikávají, ale přes router projde jen ICMP, ten routuje na výbornou, takže PING i konektivita funguje skvěle. Stejně tak funguje vysílání SSID, i připojení na Wi-Fi. Ostatní provoz ne, ani routování ven, ani připojení na Foris/LuCi/SSH.

(další popis už se vztahuje jen na Omnii, protože tu mám u sebe doma, ostatní jsou v nájemních bytech, kde nemám čas je hodiny pozorovat)

Pomocí httping jsem vypozoroval, že několik sekund před smrtí je postupně zvyšuje request-loss.

Nově jsem vypozoroval, že dokud funguje, tak je chladný, jakmile se objevují problémy, začne být jeho tělo citelně teplejší. Ale není tomu důvod, protože například teď je opravdu znatelně teplý, ale htop vykazuje Load average: 0.00 0.00 0.00. Nenašel jsem nic, co by narůst teploty mohlo vyvolat.

Jak už jste se mohli dočíst ve shora odkazovaném vláknu, snažil jsem se pozorovat příčiny, když nastupuje zámrz. Jenže tou dobou už je zpravidla jakýkoliv přístup do routeru mrtvý (Forris, Lu-Ci i SSH dávno po smrti, rspt. neomunikují). Výjimečně vidím, že htop mi ještě pošle pár obrazovek (otázkou je, jak jsou aktuální, zda to není nějaký buffer z minulosti), na kterých není vidět žádná anomálie.

Momentálně jsem ve stavu, že router vydrží cca 5 minut po restartu, než se v síti ztratí. Je to tedy zatím nejexrémnější stav, jaký jsem kdy pozoroval.

Co s tím?

Ukázalo se, že Omnia má do listopadu prodlouženou záruku, takže je možná ideální příležitost to poslat na reklamaci. Jenže je v tom háček:

  1. Chyba se objevuje na všech 3 Turrisech, které němají nic společného, je to vada kusu, nebo jěkaký jiný problém?
  2. Předpokládám, že servis standardně provede restart do továrního nastavení a tím „problém vyřeší“. Ale taková oprava je na prd, to už jsem dělal asi 10x, pokaždé to pomůže sotva na pár týdnů.

Moc ocením nápady, jakým směrem se vydat.

Závěrem

Nejsem nijak extra linuxák, netuším, jak se pohrabat v síťových protokolech, kde najdu jaké logy, z čeho se Turris skládá a proč to dělá to, co to dělá. Koupil jsem si zařízení za 5000 Kč právě proto, abych podobné věci nemusel řešit a na zařízení se mohl spolehnout. Kdybych se tím chtěl zabývat, rotuval bych si domácnost na vlastním levnjěším HW.

Nějaké err v systémovém logu Luci ? Nějaký proces, který vytěžuje CPU … viz htop v terminálu ?

Jak jsem psal, v htop nepozoruju žádnou anomálii, žádný proces nic nevytěžuje až do okamžiku “smrti”. Po ní bohužel neumím zjistit nic, protože SSH umře také.

To samé jsou logy, jak se k nim dostanu, když mi to umře? Po restartu jsou, hádám, pryč.

Ne, vážně se ptám, je možnost nějak zajsitit, aby logy přežily restart? Mám SD karty a flešky, jestli to pomůže. Pokud ano, prosím naveďte mě, klidně odkazem na nějaký článek. Jaké konkrétní logy mám sbírat?

Zkoušel jsem nějaké logy sledovat i přes tail -f, ale vím prd, který by měl být “zajímavý” v dané situaci. Budu rád za jakákoliv hint.

Nemyslím log v okamžiku smrti, ale běžný log. Žádné error záznamy?

Moje Omnie před smrtí interní paměti (a přechodem na SSD) bylo, že LED indikace startu, provozu, indikace barev a kontroly stavu připojení vypadala bez vady, ale router nepřidělil IP stanicím do LAN. Tak byl nedostupný.

cat /var/log/messages |grep " err "

Proto se ptám na jakékoli !!! err záznamy z běžného provozu. Ještě se kouknu co mi to hlásilo.

Pokud se projevuji shodně problémy u tří kusů … jsou alespoň routery v jedné síti? Co mají společného? Zmizí na wifi nebo i přes kabel? Jsou dostupné přes terminál. Já bych asi dočasně povolil forward z nějakého atyp portu na port 22 pro dostupnost terminalu pro další analýzy.

Díky, logy tedy ukazují toto:

root@turris:~# tail -n 300 -f /var/log/messages |grep " err "
2019-10-07 12:44:03 err kernel[]: [    4.925158] cpu: dev_pm_opp_of_cpumask_add_table: couldn't find opp table for cpu:0, -19
2019-10-07 12:44:03 err kernel[]: [   13.505681] firmware ath10k!pre-cal-pci-0000:02:00.0.bin: firmware_loading_store: map pages failed
2019-10-07 12:44:03 err kernel[]: [   13.535137] firmware ath10k!cal-pci-0000:02:00.0.bin: firmware_loading_store: map pages failed
2019-10-07 12:44:03 err kernel[]: [   13.643032] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
2019-10-07 12:44:06 err kresd[2586]: [ ta ] warning: overriding previously set trust anchors for .
2019-10-07 12:44:10 err kresd[2798]: [ ta ] warning: overriding previously set trust anchors for .
2019-10-07 13:00:11 err server_uplink[]: Failed to get registration code

Nicméně tohle se objevilo krátce po restartu a pak tak přiskočil ten poslední řádek, ale když to znovu chcíplo, tak logy mlčely.

K dozatům:

Pokud se projevuji shodně problémy u tří kusů … jsou alespoň routery v jedné síti?

Nejsou, jsou každý v úplně jiném městě.

Co mají společného?

Majitele. A stejný účet, jakým jsou registrovány na turris.cz. A když je spravuju, tak ze stejného Maca. Jinak snad už nic.

Zmizí na wifi nebo i přes kabel?

Zmizí na WiFi, kabel jsem nezkoušel, bo router je v jiné místnosti. Ale dobrý point, to zkusím prověřit.

Jsou dostupné přes terminál.

Nevím, myslíte klasický terminál, nebo seriovou linku, nebo? Tavím, tak hluboko se nepouštím.

Já bych asi dočasně povolil forward z nějakého atyp portu na port 22 pro dostupnost terminalu pro další analýzy.

Pardon, nerozumím ani slovu.

Zdá se, že přes kabel to funguje dobře.

To mě navedlo s tím experimentovat a nakonec jsem se dostal do stavu, že hraním si s nastavením wifi tato spadne a nekomunikuje až do restartu routeru. V logu se pak objevovaly zprávy jako:

2019-10-08 09:18:35 notice netifd[]: radio0 (6412): wlan0: interface state COUNTRY_UPDATE->DISABLED
2019-10-08 09:18:35 notice netifd[]: radio0 (6412): wlan0: AP-DISABLED
2019-10-08 09:18:35 notice netifd[]: radio0 (6412): wlan0: Unable to setup interface.
2019-10-08 09:18:35 notice netifd[]: radio0 (6412): wlan0: interface state DISABLED->DISABLED
2019-10-08 09:18:35 notice netifd[]: radio0 (6412): wlan0: AP-DISABLED
2019-10-08 09:18:35 notice netifd[]: radio0 (6412): wlan0: CTRL-EVENT-TERMINATING
2019-10-08 09:18:35 notice netifd[]: radio0 (6412): hostapd_free_hapd_data: Interface wlan0 wasn't started
2019-10-08 09:18:35 notice netifd[]: radio0 (6412): nl80211: deinit ifname=wlan0 disabled_11b_rates=0

V mém případě zapojení je to rozhraní Qualcomm Atheros QCA9880 802.11bgnac (radio0), které používám jako LAN ve vnitřní síti.

Odhaduji tedy správně, že možná jen umírá WiFi karta?

Existuje nějaký test, kterým bych mohl kartu otestovat, jestli se zasekává ona, nebo problém tkví v něčem jiném?

Zkusil bych ještě resetovat nastavení wifi ve Foris. ale nedávám tomu velkou naději. Snad výše uvedený log napoví chytřejšímu než já.

Kanál wifi 2,4Ghz máš automatická volba nebo napevno ? Pokud je to 5 Ghz, který kanál je zvolen ? U 5Ghz není vhodné volit vyšší frekvence DFS, které kontrolují kolizi s metorologickými radary.

Reset zkusím.

2,4 GHz funguje jako client, takže se řídí frekvencí vysílače – ale koukám, že je to zadané napevno.

5 GHz používám na frekvencích bez DFS a všechny pásma jsou tu prakticky volná. Jaká frekvence tam byla, nevím, teď to zkouším, zda bude fungovat, když mu nechám auto. Zatím funguje.