ich habe Probleme mit meinem TP-Link WR841N v9. Ich habe gluon 0.7.3 installiert (Freifunk Emscherland). Es ist in der Tat schwer zu beschreiben was genau das Problem ist. Genaugenommen funktioniert nichts bis auf sporadischen SSH-Zugriff. Wenn der Router an ist können sich Clients mit ihm verbinden und bekommen IPv6 Adressen keine IPv4er. Ich weiß nicht ob man das schon als Fehler werten darf oder ob das so gewollt ist. Diese IPv6 Adressen helfen dem Client dann aber herzlich wenig. Der mit ausgelieferte DNS-Server liefert keine Antworten. Man kann den Node so nicht benutzen. Was aber noch viel schlimmer ist, sind permanente Abstürze des Routers. Aktuell fast alle 10 Minuten. Ich hatte die letzten 3 (fast 4) Tage keine Abstürze und man konnte sogar ins Internet. Ich dachte schon die Probleme hätten sich behoben aber jetzt ist alles wieder wie sonst auch.
Ich weiß nicht ob das etwas mit der Sache zu tun hat aber der Node ist vor ca. 1,5 Monaten umgezogen. Also config Mode neuer Name und neue Koordinaten eingetragen.
Um die Probleme zu beheben habe ich die Kiste einmal komplett neu aufgesetzt einmal die uci firstboot nummer durchgezogen, natürliche manuelle Neustarts versucht und mal die Dienste dnsmasq und fastd neugestartet. Das ganze ist aber voll deprimierend weil man keine Ahnung hat was auf dem Gerät passiert. Kann mir jemand verraten ob man auf dem Router logfiles von fastd und dnsmasq findet? Oder hat jemand eine Idee was ich noch tun kann um den Router schön reliable und stable zum laufen zu bekommen?
Wenn deine Clients keine IPv4 kriegen, liegt das in der Regel an überlasteten Supernodes oder Wartungsarbeiten. Da alle Communities aktuell dem Wachstum hinterherrennen, kann das mal passieren, diese Häufigkeit ist allerdings extrem seltsam.
Die Abstürze des Routers können kein Supernode-Problem sein. Benutzt du ein Originalnetzteil?
IIRC sind die Logdateien auf dem Router flüchtig wegen des geringen Speichers.
Wie kommst Du zu der Aussage, dass das Gerät „abstürzen“ würde, wenn Du selbst sagst, dass Du es gar nicht genau weisst, warum die beschriebenen Symptome auftreten.
Anders gesagt: Auf Deine Definition von „Absturz“ wäre ich sehr gespannt.
(Ich gehe davon aus, dass Du Wie Debugge ich einen nicht funktionierenden Node bereits durchgearbeitet hast, und festgestellt hast, dass es NICHT am Netz Deiner Community liegt, sondern speziell an der lokalen Hardware.)
Good morning guys, vielen dank für die flotten Antworten. Das gefällt mir, das ich nicht alleine gelassen werde . Nun mal zu dem eigentlichen Beitrag:
überlastete Supernodes: oh das ist natürlich schade. Bekommt man irgendwo raus ob nen Supernode überlastet ist? Vielleicht ne Statuspage ähnlich wie beim node das man wenigstens die Load o.ä. einsehen kann?. Gibt es sowas bei Emscherland? Was macht denn der Supernode? Ist das nur der Endpunkt für fastd? Oder macht der noch mehr? Du sagtest wenn die IP-Adressvergabe hängt kann es sein das es an dem überlasteten Supernode liegt. Spricht also dafür das der Supernode die Adressvergabe/DHCP macht. Wenn der Node überlastet ist dann sollte doch gar keine Adressvergabe stattfinden oder? Merkwürdig das v6 geht aber v4 nicht.
Netzteil/Stromversorgung: Ich verwende das Originalnetzteil ich hab mal nen bisschen an den Steckern rumgewackelt aber der Node bleibt an. Das sieht erstmal gut aus. An der Steckdose hängen noch ein paar andere Geräte aber ich glaube nicht das das stören sollte. Alle anderen Geräte an der Steckerleiste funktionieren wunderbar.
Ok nun zu meiner Definition von Absturz. Vielleicht ungewollter Neustart? Ich merke wenn ich per SSH eingelogged bin das die Session einfriert und wenn ich mich neu verbinde liegt die Uptime bei 0 Minuten. Danke übrigens für den Link dort hab ich den Befehel logread gefunden. Den lasse ich jetzt mal nebenher laufen. Vielleicht sagt der Router vor seinem nächsten Tod ja nochmal was ihn gestört hat Und nein ich kann leider nicht eingrenzen ob es an meinem Router liegt oder am Netz der Community. Aber angenommen alles Netzseitige bei der Community stürzt ab oder ist nicht mehr zu erreichen so sollte meiner Meinung nach der Router weiterlaufen.
In der Praxis sind Abstürze (Freezes) sehr selten.
Sofern die Firmware selbst nicht bug-geplagt ist.
Gerade bei 841ern ist das sehr selten.
Es gibt da andere Modelle, die prozentual häufiger betroffen sind.
Wenn ein 841er nicht richtig läuft, dann ist es meist entweder das Netz der Community, welches überlastet oder sonstwie disfunktional ist. Und sei es, dass es mangels sinnvoller Netzplanung dafür sorgt, dass die Plasterouter irgendwann keinen freies RAM mehr haben und in Panik einen Reboot durchführen. (Was dann aber kein Absturz ist, sondern schlicht ein vom Watchdog ausgelöster Neustart.)
Aus Deiner Beschreibung entnehme ich jetzt, dass es zumindest kein Absturz (Freeze) zu sein scheint, sondern "nur ein Reboot, wenn der Router „danach“ wieder auf die Füße fällt.
Ich konnte das Problem jetzt tatsächlich dank des Logreads eigrenzen. Der Route macht den ungewollten Reboot genau dann wenn sich ein Client verbinden möchte. Ein logread -f hatte als letze Meldung immer:
Fri Dec 18 15:59:32 2015 daemon.info hostapd: client0: STA XX:XX:XX:XX:XX:XX IEEE 802.11: authenticated
Fri Dec 18 15:59:32 2015 daemon.info hostapd: client0: STA XX:XX:XX:XX:XX:XX IEEE 802.11: associated (aid 1)
Danach war der Router down und kurz danach wieder zu erreichen. (Dann aber mit einer angegebenen Uptime von 0m). Danach habe ich nochmal folgendes Setup ausgeführt:
Über SSH angemeldet ein while true do date sleep 1 done
ausgeführt damit man was zu gucken hat wie lange der Router noch Lebenszeichen von sich gibt. Das könnte ich wahrscheinlich beliebig lang weiterlaufen lassen. Wenn man sich mit einem Client dann am Node anmeldet meldet sich das logread ein letztes Mal mit der oben genannten Meldung und der Node verabschiedet sich.
zu stützen habe ich mal das WLAN ausgeschaltet (per Knöpfcken). Im logread steht dann Sat Dec 19 17:09:00 2015 kern.info kernel: [ 137.980000] device client0 left promiscuous mode Sat Dec 19 17:09:00 2015 kern.info kernel: [ 137.980000] br-client: port 3(client0) entered disabled state Sat Dec 19 17:09:00 2015 daemon.notice netifd: Network device 'client0' link is down Sat Dec 19 17:09:00 2015 kern.info kernel: [ 138.070000] batman_adv: bat0: Interface deactivated: mesh0 Sat Dec 19 17:09:00 2015 daemon.notice netifd: Network device 'mesh0' link is down Sat Dec 19 17:09:00 2015 daemon.notice netifd: Interface 'mesh_radio0' has link connectivity loss Sat Dec 19 17:09:00 2015 kern.info kernel: [ 138.210000] batman_adv: bat0: Removing interface: mesh0 Sat Dec 19 17:09:00 2015 daemon.notice netifd: Interface 'mesh_radio0' is disabled Sat Dec 19 17:09:00 2015 daemon.notice netifd: mesh_radio0 (2109): ./batadv.sh: eval: line 1: can't create /sys/class/net/mesh0/batman_adv/mesh_iface: nonexistent directory
Mein endlos Dateskript läuft dann fröhlich weiter und der Node bleibt auch an. Wenn ich nun aber das Knöpfchen wieder drücke und das WLAN wieder anschalten möchte dann kommt folgende Meldung im logread und der Node verabschiedet sich:
Sat Dec 19 17:09:16 2015 kern.info kernel: [ 154.100000] IPv6: ADDRCONF(NETDEV_UP): client0: link is not ready Sat Dec 19 17:09:16 2015 kern.info kernel: [ 154.130000] device client0 entered promiscuous mode
Also meine Vermutung hat ganz gut hingehauen. Ich hatte den Router jetzt für 3 Stunden am laufen hab dann WLAN übers Knöpfchen wieder angestellt und dann war er wieder weg. Ich hab den Router jetzt einfach mal im Betrieb mit der Strom weg Methode neugestartet und siehe da. Et funzt wieder
In der Tat ja der Router lief danach wieder. Sogar für 2 Tage am Stück. Aber danach ging es wieder los Abstürze im 5 Minutentakt auf unerklärliche Weise. Auch reflashen hat nichts geholfen. Bis mir auf einmal aufgefallen ist, dass der Router abstürzt wenn ich ihn anhebe. Sah alles nach Wackelkontakt aus. Beim bewegen des Netzkabels stürzte der Router immer ab. Also mal Netzteil durchgemessen und siehe da es kommen nur 5,2V an. Einen Blick aufs Netzteil zeigte dann auch das es nicht (auch wenn ich oben das Gegenteil behauptet habe) das Original 9V TP-Link Netzteil ist. Das erklärt dann auch warum der Router nach dem Umzug nicht mehr wollte. Da hab ich wohl Netzteile vertauscht. Vielen Dank für eure Hilfe und die der Jungs vom c3RE und nochmal ein extrasorry an @SenorKaffee. Du hattest mir schon den richtigen Tip gegeben und ich schlage den Rat in den Wind…
Nagut, vielen dank. Ich bin happy mit meiner epischen Uptime von inzwischen fast einem Tag
Danke für die Auflösung!
so etwas habt ein Kollege mal mit einer Fritzbox geschafft, die auch so unzuverlässig war. Klar, Wenn man sie an einem 12V/700mA-Netzteil betreibt statt einem mit 1A…
. Nun mal zu dem eigentlichen Beitrag:
Und nein ich kann leider nicht eingrenzen ob es an meinem Router liegt oder am Netz der Community. Aber angenommen alles Netzseitige bei der Community stürzt ab oder ist nicht mehr zu erreichen so sollte meiner Meinung nach der Router weiterlaufen.