Stark schwankende Latenz zum Node - TL-WR841N v10

Ich habe jetzt einen funktionierenden (?) Node in Betrieb, aber leider ist die WLAN-Verbindung unzufriedenstellend.

Einmal läuft alles super, dann fällt Traffic komplett aus für mehrere Sekunden, dann kommen die Pakete (aus dem Puffer?) nach.

Das Problem ist reproduzierbar mit einem Befehl wie

ping6 -i 0.2 -c 100 fe80::f6f2:6dff:fe4a:2e%wlan0

Ausgabe sieht so aus wie es sich anfühlt:

PING fe80::f6f2:6dff:fe4a:2e%wlan0(fe80::f6f2:6dff:fe4a:2e) 56 data bytes
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=1 ttl=64 time=2546 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=14 ttl=64 time=1.23 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=15 ttl=64 time=3.25 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=16 ttl=64 time=1.74 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=17 ttl=64 time=1.09 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=18 ttl=64 time=1.06 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=19 ttl=64 time=266 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=20 ttl=64 time=1471 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=21 ttl=64 time=1367 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=22 ttl=64 time=1164 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=23 ttl=64 time=956 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=25 ttl=64 time=586 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=26 ttl=64 time=379 ms
64 bytes from fe80::f6f2:6dff:fe4a:2e: icmp_seq=27 ttl=64 time=171 ms
(...snip...)

Um einen Problem seitens meiner PCs auszuschließen, habe ich diesmal das Problem mit zwei Notebooks verifiziert (unterschiedliche OS, unterschiedliche WLAN-HW), verifiziert dass das Problem mit meinem normalen AP nicht passiert, und auch ein Reboot von Notebook oder FFRN Node nicht¹ hilft.

¹ direkt nach dem Reboot des FFRN-Node war die Verbindung wunderbar stabil, aber nach ca. 1 Minute gingen die Probleme wieder los.


Bei einer Verbindung über die internen LAN-Ports kann ich den TPLink mit Pings zuflooden und bekomme stabile 0.x ms Antwortzeit, ohne Paketverluste bei >10k Stück Paketen. Ich denke also nicht, dass er CPU-Bound ist, sondern eher ein Problem mit der WLAN-{Hard,Firm}ware vorliegt.

(1) Kann es sein, dass ich ein “Montagsgerät” erwischt habe?
(2) Ich weiß dass die v10 noch recht neu ist, gibt es ggf. experimentelle Firmware an deren Testung ich mich beteiligen könnte? Aktuell läuft 0.5.2-20160307 / gluon-v2016.1-1-g07175ba und automatische Updates stehen auf stable.
(3) Ich habe SSH-Key-Zugriff auf den Node. Gibt es bestimmte Befehle, deren Ausgabe nützliche Infos enthalten könnte?

Schonmal vielen Dank für eure Zeit,

  • Danny

Hm, das ist eigentlich sehr überraschen. Normal funktionieren die Geräte ziemlich gut.

Ja du könntest mal folgenden Befehl ausführen: `iw dev client0 station dump

Es gibt bald eine neue Experimental Firmware auf Basis von Gluon 2016.1.2. Sollte sich dein Problem nicht lösen, kannst du es mal damit probieren.
`

Station 00:15:af:xx:xx:xx (on client0)
	inactive time:	400 ms
	rx bytes:	481823
	rx packets:	4041
	tx bytes:	416237
	tx packets:	3050
	tx retries:	429
	tx failed:	73
	signal:  	-71 [-73, -75] dBm
	signal avg:	-70 [-72, -74] dBm
	tx bitrate:	54.0 MBit/s
	rx bitrate:	48.0 MBit/s
	expected throughput:	3.808Mbps
	authorized:	yes
	authenticated:	yes
	preamble:	short
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
Station 00:21:5c:xx:xx:xx (on client0)
	inactive time:	450 ms
	rx bytes:	73056
	rx packets:	699
	tx bytes:	45077
	tx packets:	330
	tx retries:	45
	tx failed:	6
	signal:  	-65 [-66, -75] dBm
	signal avg:	-65 [-65, -74] dBm
	tx bitrate:	86.7 MBit/s MCS 12 short GI
	rx bitrate:	130.0 MBit/s MCS 14 short GI
	expected throughput:	3.752Mbps
	authorized:	yes
	authenticated:	yes
	preamble:	short
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no

Die Clients machen zur Zeit nichts anderes, als ping6 (endlos, im Sekundentakt) auf die o.g. Link-Local-Adr. des Node (was eigentlich™ unabhaengig von evtl. Uplink-Netzwerkdingen sein sollte). Die Antwortzeiten sind entweder im 0-10 ms Bereich, oder >400 bzw. Timeouts oder gleich Verbindungsverluste von > 10sec.

Es fallen aber stets beide gleichzeitig aus (sieht man sehr schoen, wenn beide Pings stehenbleiben).

Die 00:15:af Karte ist meine alte ath5k Atheros, die 00:21:5c ist eine Intel 4965agn – derartiges Verhalten legen beide Rechner sonst nicht an den Tag, und Signalstaerke ist laut i3status bei beiden > 80%.

Jeder Knoten hat auch die IPv4 Next Node Adresse 10.142.255.1 du könntest diese mal testen um zu gucken ob es ein v6 Problem oder ein allgemeineres Problem ist.

“Destination Host Unreachable”, dann mal eine Antwort, dann wieder ewig nichts, dann ein paar Antworten 1 ms/1000ms/4000ms/Timeout.

Ich tippe auf “was ernstes” : )

Um einen Hardwaredefekt auszuschliessen: Kann ich irgendwie™ die Gluon/Node/VPN-Config sichern, die Stock-Firmware aufspielen und dann ggf. wieder auf FFRN wechseln ohne $stuff neu einzustellen?

Das fuehlt sieh naemlich so an, als ob der Linuxkernel die Verbindung zur WLAN-Netwerkkarte verliert – antwortet nicht auf arp who-has, daher die Host Unreachable bei v4 – bei v6 gebe ich ja direkt die MAC an.

Nop, einfach ist das nicht möglich. Du kannst mal versuchen den /etc/conf/ Ordner zu sichern, aber darauf würde ich mich nicht verlassen. So nen Knoten ist aber auch schnell neu eingerichtet und konfiguriert.

Kaum steht das Geraet vorm Henker^H^Hauf der Werkbank, ist natuerlich die Latenz stabil bei 1.xx ms und nix mit Paketverlusten.

Hat wohl Angst vor der Originalfirmware : )

Ich lasse die beiden Laptops nochmal eine Stunde pingen, das letzte Mal begann das Chaos schliesslich auch erst nach einer Weile Betrieb.

Ansonsten muss ich wohl die physikalischen Gegebenheiten der Raume untersuchen; irgendeinen Grund muss es ja haben, dass die Verbindung zum zwei Stockwerke entfernten Mikrotik stabil war, aber die zum TP Link im Nebenraum nicht, obwohl i3status > 80% gemeldet hat…

Falls jetzt alles lauft, schonmal sorry for the noise. Aber ich melde mich nochmal

Nachdem ich den Node jetzt vom Keller-Nebenraum auf den Dachboden bewegt habe (und die Signalstaerke auf 30% reduziert habe) funktioniert alles wunderbar…

Ich habe zwar keine Ahnung warum, aber hey, never touch a running system : )

Die nodes (mittlerweile 2 an der Zahl) kommunizieren jetzt auch brav per Mesh, und demnächst™ bekommt -001 auch noch einen eigenen Uplink. Ernsthafte Probleme kann ich nicht mehr feststellen.

1 „Gefällt mir“