Freebsd 10.3 Router friert nicht nachvollziehbar ein

pbtraveller

Well-Known Member
Hallo zusammen,

ich habe ein APU.1C4 von pc-engine (http://www.pcengines.ch/apu.htm) mit einer Samsung SSD 840 EVO 250GB mSATA EXT41B6Q und einer WLE200NX Atheros Karte (AR9280) (mit hostapd) als Router am laufen. Der äußere Netzwerkport ist über ein Cisco-Kabelmodem verbunden und bekommt seine IP per dhcp. Auf der Kiste läuft noch ein DHCP-Server für das interne Netzwerk, OpenVPN und ein, zwei Jails. NAT mache ich per pf. Die Kiste friert in letzter Zeit immer mal wieder ohne erkennbaren Grund ein bzw. ist nicht mehr erreichbar. Das äußert sich für mich immer dadaruch, dass WLAN, dass ja per hostapd betriebe wird, nicht mehr erreichbar ist. Aber auch von anderen Kisten, die per Ethernet mit dem Router verbunden sind, ist dieser nicht mehr erreichbar. In dem Fall hilft nur noch "Steckerziehen" und neu booten.
Ach ja, als filesystem setze ich ZFS ein, da so praktisch mit den snapshots und eigentlich auch stabil.

Ein Blick in /var/log/message gibt keine Auskunft darüber, warum das System nicht mehr erreichbar ist. Ich musste heute das System um 12:40 neustarten. Davor ergeben sich aus /var/log/messages nur folgende Einträge:


Apr 12 12:33:19 Router ddclient[1663]: WARNING: cannot connect to checkip.dyndns.org:80 socket: IO::Socket::INET: Bad hostname 'checkip.dyndns.org'


Kann mir jemand beim debuggen helfen? Da ich kein Muster erkenne, weiß ich nicht so richtig, wo anfangen. Kann ich irgend wie den generellen log-level hochdrehen?

Vielen Dank und viele Grüße

pbtraveller
 
Sieht für mich so aus (wegen der Fehlermeldung), dass das Netzwerkinterface den Dienst quittiert. Komisch aber, dass dann auch das WLAN weg ist. Was sagt dmesg, bzw. /var/log/dmesg.* ?

Rob
 
Was in /var/log/dmesg.yesterday auffällig ist, ist folgender Eintrag:

bridge0: Ethernet address: 02:bf:68:4c:1c:00
re0: link state changed to DOWN
re1: link state changed to DOWN
re2: link state changed to DOWN
wlan0: Ethernet address: 04:f0:21:0c:9a:24
re1: promiscuous mode enabled
bridge0: link state changed to DOWN
re2: promiscuous mode enabled
wlan0: promiscuous mode enabled
re0: link state changed to UP
re1: link state changed to UP
bridge0: link state changed to UP
pflog0: promiscuous mode enabled
tun0: link state changed to UP
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: device timeout
ath0: stuck beacon; resetting (bmiss count 4)

Der letzte Eintrag wiederholt sich ständig.

Gruß

pbtraveller
 
Nach allem, was ich gelesen habe, kann es helfen einen weniger genutzten WLAN-Kanal zu nutzen.
BTW: Welches System setzt du ein?

Rob
 
das scheint dann so weiterzugehen.. Am Ende von /var/log/dmesg.yesterday steht dann noch

ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)
ath0: device timeout
re1: link state changed to DOWN
bridge0: link state changed to DOWN
re1: link state changed to UP
bridge0: link state changed to UP
re1: link state changed to DOWN
bridge0: link state changed to DOWN
re1: link state changed to UP
bridge0: link state changed to UP
re1: link state changed to DOWN
bridge0: link state changed to DOWN
re1: link state changed to UP
bridge0: link state changed to UP
re1: link state changed to DOWN
bridge0: link state changed to DOWN
re1: link state changed to UP
bridge0: link state changed to UP
ath0: stuck beacon; resetting (bmiss count 4)
ath0: stuck beacon; resetting (bmiss count 4)



Ansonsten die aus meiner Sicht üblichen Einträge beim hochfahren.

Gruß

pbtraveller
 
Nach allem, was ich gelesen habe, kann es helfen einen weniger genutzten WLAN-Kanal zu nutzen.
BTW: Welches System setzt du ein?

Rob

Werde mir heute Abend mal umstellen (geht gerade nicht, da andere User dran hängen). Allerdings kann ich mir kaum vorstellen, dass das der Grund ist, bzw. es würde es mich doch etwas wundern, wenn FreeBSD, das ja u.a. für seine Stabilität bekannt ist, in die Knie geht, weil ich auf eine Kanal verwende, der auch von anderen WLAN hotspots in der Gegend verwendet wird....
 
Guter Punkt! Ich muss mir erst noch mal einen USB-Adapter kaufen, da ich meinen gerade in einer anderen Umgebung einsetze....
 
ich habe in meinem Alix (mit pfSense also mehr oder weniger FreeBSD 10.1) auch eine Atheros, allerdings eine Atheros 9220 drin. Die selben Fehlermeldungen habe ich auch und als ich das letzte mal danach gesucht habe, war das ein bekannter Bug, fuer den sich aber niemand fand ihn zu beheben. Das ganze N-WLAN Zeug ist auch gar nicht mal so trivial und der Treiber muss immer mehr von dem erledigen, was frueher die Chips gemacht haben. Bei mir fängt sich die WLAN Karte aber meist nach ein paar Sekunden wieder und ich bekomme wieder Daten durch. Auf absehbare Zeit werd ich mir aber was anderes überlägen muessen, denn das nervt schon.
 
Zurück
Oben