Ich habe seit einer knappen Woche einen TP-Link WR841N mit der FFKA-Firmware ausgestattet und eingerichtet.
Das Gerät funktioniert danach auch tatsächlich , aber immer nach einer guten Stunde ist es über das WAN (über mein Intranet) nicht mehr über einen Ping erreichbar.
Das Client-Netzwerk fällt dann auch nicht mehr auf dem LAN-Port raus.
Das Gerät an sich zeigt äußerlich keine Zeichen einer Störung (die LEDs blinken weiterhin fröhlich).
Ich habe aktuelle das Meshing über WLAN sowie WAN aktiviert, da ich noch ein Raspberry als reine VPN-Node betreibe.
Das Netzteil habe ich mal getauscht, aber der Fehler besteht weiterhin.
Habt ihr noch Ideen, bzw. wie bekomme ich die letzten “Worte” des Gerätes in einen nicht-flüchtigen Speicher?
Hast du sonst noch Änderungen am Standard-Image vorgenommen? Falls nein, magst du einfach mal testen ob es ohne Mesh-on-WAN auch auftritt?
Spontan fällt mir nur ein, dass dein Knoten seine IP im lokalen Netz verliert und daher nicht mehr erreichbar ist (und auch keinen Uplink mehr hat). Du könntest versuchen den Knoten mittels seiner IPv6 link local Adresse zu erreichen, um nach möglichen Fehlern auf dem Gerät suchen zu können. Darüber sollte er nämlich auch ohne IPv4 Adresse erreichbar sein.
Du könntest schauen. ob Du mit v6 noch lokal auf das Gerät kommst - link local funktioniert auch dann noch wenn v4 auf Grund von dhcp nicht mehr tut.
Logfiles auf nicht flüchtigem Speicher ist schwierig - da das Gerät aber nur eine Stunde läuft am Besten per SSH drauf gehen und drauf bleiben - und logread -f laufen lassen bis es abbricht.
Das Mesh auf der WAN-Seite habe ich aktiviert, als das Problem schon ein paar Mal aufgetreten war.
Ich habe sonst keine Änderungen am Image gemacht.
Ein Problem mit meinem DHCP-Server schließe ich (erst mal) aus, da hier die Leasetime auf 4 Tage eingestellt ist.
Über IPv6 werde ich es mal versuchen, danke.
Sat Dec 17 19:24:40 2016 daemon.notice netifd: client (1413): cat: write error: Broken pipe
Diese Meldung war die letzte.
Ich werde nun beim nächsten Vorfall mal über IPv6 probieren.
Vorher kam immer wieder regelmäßig
Sat Dec 17 18:40:41 2016 daemon.info fastd[1370]: refreshing session with <mesh_vpn_backbone_peer_alb2>
Sat Dec 17 18:40:42 2016 daemon.info fastd[1370]: sending handshake to <mesh_vpn_backbone_peer_alb2>[78.47.79.227:10000]...
Sat Dec 17 18:40:42 2016 daemon.info fastd[1370]: received handshake response from <mesh_vpn_backbone_peer_alb2>[78.47.79.227:10000] using fastd v17
Sat Dec 17 18:40:43 2016 daemon.info fastd[1370]: 78.47.79.227:10000 authorized as <mesh_vpn_backbone_peer_alb2>
Sat Dec 17 18:40:43 2016 daemon.info fastd[1370]: new session with <mesh_vpn_backbone_peer_alb2> established using method `null+salsa2012+umac'.
Sieht ok aus - ja.
Am Besten immer eine ssh -Session per v6 und v4 offen halten und dann schauen wie die Situation ist.
Notfalls halt serielle Konsole anhängen.
Ich hab gerade mal einen Reboot gemacht und nun wird im Log ca. alle 3 Sekunden immer wieder dieser Fehler ausgeworfen:
Fri Dec 16 21:24:01 2016 kern.emerg kernel: [ 637.840000] unregister_netdevice: waiting for bat0 to become free. Usage count = 4
Fri Dec 16 21:24:02 2016 kern.emerg kernel: [ 638.100000] unregister_netdevice: waiting for primary0 to become free. Usage count = 1
Danach habe jetzt mal (um zusätzlich einen Hardwaredefekt auszuschließen) das Gerät von der Hardwareversion V9 zu einem Gerät mit der Hardwareversion V10 getauscht.
Jetzt werde ich mal beobachten, ob ich hier die gleichen Symptome habe.
Leider hat die Version 10 einen anderen CPU/WLAN-Chipsatz, sodass man hierdurch leider nicht wirklich beurteilen kann, ob es nun wirklich an der Hardware liegt, oder an einem Problem in Kombination mit einem Treiber/Kernelmodul.
Also mit der V10 habe ich zumindest mal sichtbare Probleme im Log.
Sieht irgendwie aus, als hätte er Probleme mit dem WLAN
Da ich nicht mehr als 32.000 Zeichen schreiben darf, hier der Link zum Download der Textdatei: https://www.kirgus.net/cms_filesys6/public/44d885
Könnt Ihr daraus was lesen?
Nachdem der Fehler das Log zugemüllt hatte, war das Gerät noch ca. 30 Minuten über IPv4/IPv6 erreichbar. Danach wurden die Ping-Zeiten schlechter und die SSH-Verbindungen brachen dann gleichzeitig ab.
Sieht nach Kernelproblemen aus - habe ich so noch nicht gesehen. So ganz platt gefragt - Du bist sicher die richtigen Images zu haben?
Mal Standard Lede/Openwrt probiert?
Ich habe beide Geräte mittels der TFTP-Methode geflasht.
Beim flashen lagen die Firmware-Dateien zwar im gleichen TFTP-Verzeichnis auf dem PC, aber sie waren anders benannt. Der Bootloader hätte (oder wenn ich es noch in Erinnerung habe) hat sich aber die korrekte Datei gezogen.
Wie bekomme ich den am laufenden System raus, welches Image bzw. welche Kernelmodule im Image drin sind?
Die beiden Dateien für die V9 sowie V10 sind bei mir lokal schon mal von der Prüfsumme unterschiedlich, also 2 Mal doppelt geladen habe ich Sie nicht.
Hab eben mal auf meinem v9er geschaut - ich habe keine solche Fehlermeldungen im log. Ist also nicht normal.
Woher die Hardwareinfos kommen weiss ich nicht, cat /proc/cpuinfo wäre eine mögliche Quelle.
Ich würde mir per wget die Datei nach /tmp holen und mit sysupgrade -n nochmal schreiben - nur um sicher zu gehen dass beim tftp nix schief ging.
Ich habe nun nochmal meine 9er-Version geflashed und neu eingerichtet. Dann habe ich mal in meiner IPv6-Firewall nachgeschaut und ich hatte festgestellt, dass dort immer wieder der Port 10.000 geblockt wurde. Also habe ich den Port einfach zum Test mal den Port freigegeben und nun verbindet er sich anscheinend auch über IPv6.
Ich hatte schon gedacht, das war der Fehler.
Aber leider hat er nach ca. 2 Stunden wieder unschön das eigene Mesh-WLAN sowie das Client-Netz fallen gelassen. Die LEDs blinken zwar immer noch, allerdings kein Netzwerk mehr an den LAN-Ports sowie kein Ping mehr über IPv4/IPv6 möglich.
Das geniale: Das Gerät hat wirklich funktioniert und 1 Gerät konnte sich auch mit der “lokalen Wolke” verbinden.
Das Internet funktioniert, wenn auch relativ langsam.
Die Zeit, nach welcher das Gerät aussteigt ist allerdings unterschiedlich. Mal sind es 10 Minuten, manchmal auch 2 Stunden.
Ich finde es komisch, dass ich diesen Fehler bei beiden Versionen 10 + 9 der Geräte habe. Einen Hardwaredefekt wäre sehr unwahrscheinlich…
Etwas ist mir aufgefallen:
Ich wollte testweise auf die Beta umsteigen, dies funktioniert bei mir zumindest aktuell nicht: Nach der Änderung des Trains mit uci und einem autoupdate -f
wird versucht eine Verbindung mit http://0.updates.services.ffka.net herzustellen.
Nach ein paar Sekunden kommt die Meldung “No route to host”.
Andere Adressen im Internet kann ich vom TP-Link aus anpingen (IPv4+IPv6, google.de, heise.de)
Zur gleichen Zeit konnte ich mit einem Client im Client-Netz auf das Internet zugreifen.
Ich hab mal ein Screenshot von der Node gemacht und angefügt.
Ich habe übrigens einen 3600er der ähnliche Wifi-Probleme hat - aktuell ganz massiv. Den wollte ich ebenfalls mit der Beta testen um zu sehen ob es mit dem bekannten Wifi-Bug zusammen hängt.
Die aktuelle Beta habe ich mittels sysupgrade nun geflashed.
Leider habe ich immer noch Probleme.
Wenn ich beide WLAN-Netzwerke deaktiviere, hat der Router ca. 2 Stunden funktioniert, dann hat er leider auch auf der LAN-Seite wieder aufgegeben. Ein logread -f fördert leider weiterhin nur
root@KA-RH-FOBienwald:~# logread -f
Tue Jan 10 23:27:44 2017 daemon.info fastd[1344]: refreshing session with <mesh_vpn_backbone_peer_alb7>
Tue Jan 10 23:27:44 2017 daemon.info fastd[1344]: sending handshake to <mesh_vpn_backbone_peer_alb7>[[2001:41d0:c:ac6::127]:10000]...
Tue Jan 10 23:27:44 2017 daemon.info fastd[1344]: received handshake response from <mesh_vpn_backbone_peer_alb7>[[2001:41d0:c:ac6::127]:10000] using fastd v18
Tue Jan 10 23:27:45 2017 daemon.info fastd[1344]: [2001:41d0:c:ac6::127]:10000 authorized as <mesh_vpn_backbone_peer_alb7>
Tue Jan 10 23:27:45 2017 daemon.info fastd[1344]: new session with <mesh_vpn_backbone_peer_alb7> established using method `null+salsa2012+umac'.
zu Tage.
Kann man hier noch ein detaillierteres Log anzeigen?
Während der “online”-Zeit des Routers konnte ich zwar auf den LAN-Ports surfen, allerdings sehr langsam, Seitenaufbau ca. 40 Sekunden, Bilder dauern teilweise noch länger.
Gibt es aktuell Engpässe bei den Exit-Nodes?
Ja es bestehen leider immer noch die selben Engpässe bei der Supernode Infrastruktur.
Zur Zeit stehen uns wieder 2 Server zur Verfügung, wobei der Server mit dem du verbunden warst, der deutlich stärke ausgelastete ist. Die Lastverteilungs-Skripte werden noch eine weile Brauchen bis die Auslastung wieder einigermaßen gleich auf beiden Servern liegt.
Ich habe nun folgendes herausgefunden (oder zumindest eine Vermutung):
Der AP liegt bei mir ca 50 cm entfernt von einem LANCOM-Access-Point.
In der Nähe sind auch noch TV, Receiver & Co.
Ich habe den TP-Link mal mit einem längeren LAN-Kabel 2m entfernt von dem “Hotspot” betrieben und er hielt mehrmals hintereinander ca. 5 Stunden durch. Das ist bisher Record!
Kann es sein, dass sich der TP-Link durch Induktion irgendwelchen Blödsinn einfängt und deshalb einfach ohne Logeintrag aussteigt?
Hat hier jemand schon mal solche Erfahrungen gemacht?
, aber immer nach einer guten Stunde ist es über das WAN (über mein Intranet) nicht mehr über einen Ping erreichbar.
