Od pulnoci nefunguje wlan0

Software [CZ] SW chyby-diskuze [CZ]
1

Nekdy po pulnoci prisla zprava ze updater nenasel repo.turris.cz … , rano jsem to neresil, vse fungovalo dobre.

Bohuzel po prichodu z prace zjistuji, ze zadna wifina neprijima zadneho klienta (Android, Win10, RPI3) …
Zbezna kontrola pres Foris a Luci (nevidim seznam zadneho dhcp klienta), blizsi pohled odhali, ze kabelem pripojeni klienti jedou v pohode. Tak jsem si dal start pkgupdate, dobehl, zadna chyba, reboot, stale problem.
Tak jsem zkusmo odebral klienta z hostnames a ze static leases . Dal jsem si rollback do “pre-update” snapshotu a stale nic. Tak jsem sel o kus dal. Ale az moc dozadu se mi nechtelo. Pak najdu na foru ze problem je pri prechodu z 3.10.8 na 3.11.x a zapnutem ddns … tak okey, rollforward …do posledniho cron-snapshotu …
Vypnuto, zakazano ddns, reboot, pkgupdate … a stale nic…
Chm, pak najdu poznamku ve vlakne na foru, ze nejaky dalsi dhcp muze donutit ten na TOS byl odporoucen. Tak pro jistotu sundam pihole v kontejneru, schodil jsem i ruzne ostatni virtualy a box managery…
Zrusil jsem guest-wifi, guest-network, prekontroloval dhcp/dns nastaveni. Omrknul interejsy jestli jsou nastaveni … a ja uz fakt netusim. Me to prijde vse v poradku z pohledu Foris/Luci , a v logu zadne errory kolem wifi/dhcp/

Reboot a tak …
A stale kazdy bezdrat klient zkousejici ziskat ip adresu vygeneruje v logu , pak to blikbe a o vterinu ci dve pote se objevi to same …

info hostapd

2019-02-05 20:07:14 info hostapd[]: wlan0: STA 34:80:b3:fe:1f:f8 IEEE 802.11: authenticated
2019-02-05 20:07:14 info hostapd[]: wlan0: STA 34:80:b3:fe:1f:f8 IEEE 802.11: associated (aid 2)
2019-02-05 20:07:14 info hostapd[]: wlan0: STA 34:80:b3:fe:1f:f8 RADIUS: starting accounting session 7B394BF2CEEC79CF
2019-02-05 20:07:14 info hostapd[]: wlan0: STA 34:80:b3:fe:1f:f8 WPA: pairwise key handshake completed (RSN)

A jako stale se objevuje v logu jeste toto
2019-02-05 19:53:08 err dhcp_host_domain_ng.py[]: Wrong host format '/srv/kresd/hints.tmp' in host file
Ale ja jen v konfigu zmenil jeho destinaci , ne format (a predtim pred updatem na 3.11.x s tim ten dhcp_host_main_ng.py) nemel problem…

Jdu jeste pohledat po foru, co za tim muze byt a kam mam sahnout. Kazdopadne budu rad za postouchnuti. Fakt netusim mamli resit sluzby ci jen konfigy (dhcp,resolver) a pro jakou z tech ruznejch sluzeb (hostapd,odhcpd,kresd,dnsmasq …)

EDIT: “triggerfile” co pozada refresh/reread lease fajlu, dany fajl nenachazi a duvodem je zrejme obsazeny port 53 jinou sluzbou … tak ted fakt nevim co to cele jakoze rozbouralo. dle hostapd je v cajku, hostnames taktez, ale neco blbne mezi dnsmasq/odhcp/kresd …
Ale fakt ted netusim co je treba (kde ) overit pripadne opravit (a hlavne v jakem poradi).

2

Defaultní stav Omnie je pouze jeden kresd proces na portu 53 + žádný DNS port pro dnsmasq (což vyjadřuje ten “port 0”).

3

Osobně bych zkusil tzv. vylučovací metodu:

  1. na WiFi klientovi nastavit statickou IP (IP, masku, dns (DNS v našem případě není až tak důležité))
  2. z klienta zkusit http://192.168.1.1 a musí se objevit stránka routru.
  3. Pokud se stránka objeví, pak jde o přiřazení IP z dnsmasq démona a tam bude bota, pokud neobjeví, jdeme na další bod.
  4. prověříme v LuCI, jestli wlan0 je fizicky spojena s rozhraním LAN (Síť - Rozhraní - LAN - Fizické nastavení - Rozhraní - zaškrtnuto wlan0
  5. smažeme soubor /etc/config/wireless, retartujeme router a znovu nastavíme WiFi
  6. a asi to nejhorší - provedeme reset do továrního nastavení.
  7. a pokud ani z výše uvedených bodů nepomůže, zkustetechnickou podporu.
    Pokud si ještě na něco vzpomenu, tak to editem dopíši.

Předpokládám, že v průběhu noci do routru nikdo nezasahoval a výpadek provedl pravděpodobně updater - zde mohlo dojít ke komplikacím a né korektně se updatovaly věci ohledně WiFi (ovladač, démoni, kernel apd.) a asi nezbyde nic jiného, než-li tovární nastavení (je to smutné, ale já updater nepoužívám a po určité době reflashnu medkitem na novější buid).

1 Like
4

ad_porty:
Port 53 je uveden v sekci “common” (kde je preffered_resolver=kresd), v kresd sekci port explicitne specifikovan nemam , dnsmasq ma nastaveno 0 (server port), “any(sedivy text, tedy nevyplneno)” (query port). No jdu prohledavat forum a tak kolem, treba nekde najdu nejakou inspiraci :slight_smile:

ad_navod: 1-2-3 jdu zkusit aspon budu vedet kterej z tech “bazmeku” za to cele muze :slight_smile: , wifi jsem uz restartoval (plne i castecne, odebiral jsem i guest-lan/wlan) … , interfejsy a jejich “dhcp” jsem overoval … to by melo bejt oukej. (zony i bridge) …

A predpoklad je spravny. A to v oblasti dns/dhcp mam skoro vse v zakladu jen jsem si nastavil hostnames(pripadne static.leases+hosts) a tak, ale nedelal jsem nic kolem user configu pro kresd/unbound ci tak. Neprehazoval jsem porty ani nedaval nove, zadne “full” balicky at uz kresd nebo dnsmasq … V tomto smeru se nesnazim vybocovat :smiley:

5

Tak bota asi nalezena. Pri statice projdu.

No rano me cekalo prekvapko, V pet probehl dalsi update a rano koukam ze i “dratove” stroje maji problemy se siti. Rychlej rollback a i tak jsem na te hlavni musel dat statiku, abych se vubec mohl mrknout pres shell. Muzu nejak vynutit “default” nastaveni pro dns/dhcp (predpokladam ze pres opkg s force installem? )
Ted asi hlavni otazka, co s tim dnsmasq ? Po praci zkusim prepsat konfigy tema defaultnima a zacnu od toho(treba mam nejake optiony v rozporu …, zajimave ze to doposud fungovalo, resolve na aliasy, shortnames, fullnames …sluzby umely vnitrne pouzivat jmena …, pak se udal update na 3.11.1 a nektere lxc kontejnery vnitrne meli pak problem na sebe videt …ale to jsem moc neresil. Ted s 3.11.2 ani nedostanou ipecko. (ani kdyz ho specifikuj v lxc configu …) …lan klienti stejny neduh jako wlan klienti. Coz uz trapi vic.

No uvidime , drzte mi palce :slight_smile:

6

update … , po prichodu z prace (pozoruji, ze updater dokoncil nejake sve procesy a nad ramec predchoziho seznamu balicku jeste dodatecne v dalsi instanci doinstaloval ddns,pakon a jeste nejake navazne balicky).

Zrusil jsem static leases, odmazal vsechny zaznamy v luci hosts. Odstranil jsem lokalni domenu, trosku zmenil nastaveni dns/dhcp/resolver , aby to bylo vice blize k “default” nastaveni. A razem jsou klienti obsluhovani korektne (jen asi 1/4 klientu dostala ipecko, ktere je v luci-network-hostnames …)
Ale to uz si snad poresim sam. Kazdopadne diky za hinty at uz verejne ci z privatnich zprav.