Lampertheim Blücherstraße uplink hakt

Hier ist Mal das logfile vom LA-BL26-1043, der bis zum 31. Oktober dort parallel als Test am uplink hing.

Sogar ich sehe darin interessante Warnungen und EInträge. Vielleicht bringt uns das weiter?

Hier also das logfile: https://paste.ffrn.de/?1b6f7d2b9caa79e1#84B3FcJT2KbMl9UVhNuirJP7MOPGKJvq6iHYTL5SnpY=


(Bitte zukünftig https://paste.ffrn.de zum teilen von Logfiles nutzen, sonst wird es hier sehr unübersichtlich, danke. Ich habe es rüberkopiert. Gruß, @Cheatha)

Danke Cheatha fürs pasten. Ich habe den link jetzt in den Bookmarks, für zukünftige Fälle

LA-RW-BL26 ist leider schon wieder länger offline. Der Knoten wurde heute Morgen neu gestartet udn ist aber seither noch nicht wieder online !! Sobald ich ds DIng erwische,werde ich logread ausführen, oder rgr kanndas machen?
Wenn der Wifi-Bug dafür sorgt, dass die Knoten nicht mehr meshen sollte der Knoten aber doch weiterhin per ssh erreichbar sein, wenn er am uplink hängt??

Das ist richtig. So war die Situation beim Repairschop. Die CPE war zwar auf Wifi taub, hatte aber über Kabel noch Uplink. Ich konnte daher über den Uplink auf die CPE drauf, ihr die Ohren durchblasen und darauf hin hat die Verbindung ins Parkhaus und zum Rest auch wieder funktioniert.

Hier ist es anders - die Geräte sind aktuell nicht anpingbar, daher komme ich nicht drauf. Da hängt es offenbar daran, dass sie keine Verbindung zu den Gateways her stellen können - die Frage ist warum.

In dem Logfile des 1043 sehe ich nichts spezielles, außer dem Zeitsprung. Ich nehme an das ist das Protokoll unmittelbar nach dem Start, oder?

Jetzt wäre es gut zu sehen was in den Protokollen der beiden Nodes steht ohne sie neu zu starten. Das geht aber nur wenn dort direkt vor Ort entweder per Kabel oder Wifi ran geht (falls das Wifi dort tut)

Heisst das also, dass das Protokoll beim Neustart gelöscht wird? Auf dem 1043 er war doch auch noch das alte Protokoll vom 31. Oktober drauf, und der stand 14 Tage ohne Strom rum.

Der LA-RW-BL26 wurde ja heute morgen neu gestartet, erfahrungsgemäss kommt er dann irgenwann online. Dann eben schnell das PRotokoll erhaschen. Wenn das nicht funktioniert, werde ich den guten Leuten Mal wieder einen Besuch abstatten. Die haben da einen zeimlcih guten Kaffee :-)

Das Protokoll wird nicht wie bei einem normalen Computer auf der Festplatte gespeichert, sondern ist ein „Ringspeicher“ also begrenzter Speicherplatz wo hinten alles raus fällt, was vorne rein geschoben wird.
Beim booten entstehen so viele Meldungen, dass die neueren die alten überschreiben. Daher ist es immer wichtig zeitnah zu schauen, weil sonst vielleicht wichtige Meldungen schon wieder von unwichtigen überschrieben wurden.

Beim Start stimmt meistens die Uhrzeit nicht, soweit ich weiss haben die Nodes auch keine eingebaute Uhr (keine Batterie) und holen sich daher beim Start die Uhrzeit. Du siehst im Protokoll folgende Zeilen:

Mon Oct 31 11:23:02 2016 daemon.info fastd[1420]: new session with <mesh_vpn_backbone_peer_gw06> established using method `null’.
Tue Nov 15 15:52:52 2016 cron.err crond[1055]: time disparity of 21869 minutes detected

Wenn Du die Minuten umrechnest dann stellst Du fest, dass es genau die 15 Tage Unterschied sind. Ich deute das so, dass für den Node nach dem Start 31.10. (Jahr?) 11:20 war und als er die Vebindung zum Gateway hatte (fastd - established) hat er sich die Uhrzeit geholt und festgestellt „hoppla, hier ist ja eine Zeitdifferenz von 15 Tagen, ich stell mal eben meine Uhr neu und schreib das ins Protokoll“.

Und wenn die einen guten Kaffee haben - dann würde ich da einfach mal vorbei gehen. Die Node sollte nach ein paar Minuten Verbindung zum Gateway haben. Wenn der neustart irgendwann heute morgen war dann sollte sie längst da sein, wenn nicht auf der Karte dann zumindest anpingbar. Da sie es nicht ist jammert sie bestimmt gerade im Protokoll rum dass sie niemanden erreichen kann und sie keiner lieb hat - davon sollte man sie erlösen ;-)

1 „Gefällt mir“

So , jetzt ist der Knoten Mal wieder online. Ich habe hier das Logfile
https://paste.ffrn.de/?d6a6a94e41ffd3b1#Atnpyhta7WitqIrwxamWHaZb1Ab/zLNR4pWK20JCxDY=
Ich hoffe, jemand hat bahnbrechende Erkenntnisse
Laut GRafana ist die Verbindung zum Gateway seit 20:30 Uhr wieder da

Hm, nicht wirklich. Da steht auch wieder nur, dass er es halt bei allen Gateways probiert hat und einer ihn rein gelassen hat. Die Zeilen von vorher sind leider schon weg.
Etwas seltsam finde ich, dass es so lange dauerte - 3 Minuten.

Wie sind die Geräte dort jetzt aktuell verkabelt?

Das Gerät hangt per LAn Kabel am Ehternetport der Fritzbox

Ich erinnere mich gerade dunkel dran, vor ein paar Jahren mal das Problem nicht funktionierender Verbindungen bei einer FB gehabt zu haben. Damals war es der Eco Modus der Box der einfach ziemlich Zufällig den Link abgeschaltet hat. Nur so als Idee.

Die Performance ist unterirdisch. v4 scheint in Ordnung zu sein, das geht direkt über die Box, aber v6 bekomme ich maximal 1MBit (durch den Tunnel.

Hat eines der Gateways für Fastd noch einen anderen Port offen?

Ist vielleicht 6to4 in der Fritz!Box aktiv? Damit hatte ich damals bei meinen ersten Gehversuchen mit IPv6 auch immer unterirdische Performance.

Oder MTU beim IPv6 Tunnel falsch eingestellt?

IPv6 wurde in der FB vor ein paar Tagen deaktiviert. Das war einer der Vorschläge. Hat also leider nichts gebracht. ECO MOdus ausschalgen habe ich weitergegeben, Mal sehen,ob es hilft!

Ich habe per Screen permanent eine Sitzung mit logread -f offen. Die ist heute morgen 0:15h abgerissen. Die Einträge die ich jetzt sehe sind von 06:45h wie sich fastd verbindet (und dazu 4 Minuten braucht).

Mal eine kurze Zwischenbemerkung: ich finde es toll, wie das Problem hier gemeinsam analysiert und eingegrenzt wird und wie viel Unterstützung geleistet wird! Vielen Dank an alle Beteiligten :-)

2 „Gefällt mir“

Ich habe heute Vormittag mal verschiedene Messungen gemacht:

https://paste.ffrn.de/?f6bb1561671f5bf1#aMg34etlOTzLarJefGWXx4UMIR3VyzQ5NI1+8FAetrk=

Meine Beobachtungen:
a) Latenz auf dem Gerät ist grausam. Sekunden vergehen nach einem Tastendruck
b) pings an die Fritzbox sind unverdächtig
c) pings ans Gateway haben keinen Packetloss
d) traceroutes zeigen dass die Verbindung ab der Fritzbox lahmt
e) Speedtests bringen nur ca 20MBit vom Anschluss (50 sollen es sein)

Alle Messungen sind direkt vom Node an der FB, gehen also nicht durch den Tunnel, ich habe die Geschwindigkeit gemessen mit der Daten ankommen.

Ich hätte folgende Bitten:

a) Wäre es möglich einen Geschwindigkeitstest mit einem Laptop direkt an der FB zu machen? Am Besten per Kabel, Wifi würde aber notfalls auch reichen. Die Frage ist ob man da wesentlich mehr als 20MBit bekommt

b) wäre es möglich für die Tests ein anderes Gerät dort hin zu stellen, irgendwas was größer ist als der 841? Kann irgendein Leihgerät sein, damit man auch mal iPerf installieren und messen kann.

Wenn die Vergleichsmessungen gemacht sind würde ich ipV6 wieder einschalten um zu testen ob es aus auf einem der Wege einen Unterschied gibt. Dazu wäre es gut @leah, wenn Du ermöglichen könntest, dass http://files.leahoswald.de/bigfile auf den Nodes downloadbar ist, die SSL-Weiterleitung verhindert das im Moment.

Ist eigentlich aus Performanceprobleme mit Unitymedia etwas geworden?

Okay, super, dass du dich drum kümmerst.
Ich stelle morgen dort wieder den LA-BL26-1043 auf , der da schon Mal testhalber parallel lief. Du merkst es dann ja und kannst deine Tests machen.
IP 6 soll ich dann wieder anmachen?
Gelichzeitug werden wieder ECO MODe kontrollieren an der FB
Nochmals Danke

Dieser Effekt, dass Tastendrücke über die Konsole mit Sekunden Verzögerung kommen, habe ich noch bei anderen Knoten

v6 bitte erst dann anmachen wenn ich Bescheid gebe, ich will mit dem 1043 parallel messen. Und bitte nicht vergessen vor Ort direkt an der FB mit einem anderen Gerät zu testen.

Okay. Also der 1043 er ist seit 20 Uhr aktiv, hat bloß 2 h gebraucht , um online zu kommen. Der 841 er ist jetzt abgeklemmt? War das falsch?
IPv6 ist nicht wieder an.
Der 1043er hängt jetzt an Lan 1, wo ausdrücklich der Power Mode ( 1 GBit) angesschaltet ist. Soweit alles richtig?

> Und bitte nicht vergessen vor Ort direkt an der FB mit einem anderen Gerät zu testen.
Das verstehe ich nicht

841 weg passt, v6 aus auch.
Mit dem Test meine ich dass Du entweder Dein Handy nimmst, Dich direkt in das Netz der FB anmeldest (nicht Freifunk) und einen Speedtest machst.
Alternativ einen Laptop mit Netzwerkkabel, dort an den Netzwerkanschluss der FB gehen und dann einen Speedtest machen. Sinn der Sache: Testen, was der Anschluss für normale Geräte für eine Geschwindigkeit hat.

Naja verkauft wird er als 50 MBIT

Getestet hatte ich schon länger Mal gute 25 MBIT

Ich werde Thomas bitten, nochmals zu testen.

Aber warum braucht der Router so ewig ( viele Stunden) , online zu kommen, und warum bricht die Verbindung ab?? Das würde mich sehr interessieren