rofl, ich schmeiss mich weg…
1 „Gefällt mir“
Können wir die MTU Diskussion hier bleiben lassen? (nicht böse gemeint)
Aber da gibts viele andere Threads zu…
Es gibt ein MTU-Wechselszenario in Wupper. Ihr wünscht Euch eine MTU und kommuniziert sie. Einige Server werden entsprechend angepasst und Ihr bekommt einen neuen fastd-Port. Mit diesem wird neue Firmware gebacken und die Knoten bekommen ihr Autoupdate. Nachdem alle Knoten migriert wurden, wird der alte fastd-Port deaktiviert. So eine Umstellung sollte weniger als eine Woche dauern.
Szenario ist gut 
Können wir das mit der MTU 1312 machen?
1 „Gefällt mir“
Go …
tut mir leid, dass es so lange gedauert hat, ich bin gerade eben dazu gekommen …
viel Spass und Erfolg
Bitte um ein „Go“ zum Abschalten des alten Ports, nachdem alle Knoten migriert sind
ein NOGO … Port wurde deaktiviert. Batman verursacht KernelPicknick durch fehlerhafte Implementierung der Fragmentierung … ich melde mich, wenn das Problem behoben wird
1 „Gefällt mir“
GO – W2 hat jetzt die neue MTU … und nur die neue MTU … bitte sorge mit eigenem Server für den Kurzschluss zwischen alt und neu.
Hi @phip
Irgendwas ist faul. Welcher Supernode hat jetzt welche configs?
Hier Verbinden sich nodes zu w2 und nutzen diesen auch als GW, bekommen aber keine IP! Wenn der Port geändert wurde kann das ja eigentlch garnicht sein.
Kannst du bitte nochmal nachsehen?
~ $ for i in {0..3}; do echo ${i}; ssh root@${i}.wupper.ffrl.de "ip l | grep fastd-tro"; done
0
5: fastd-tro: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1406 qdisc pfifo_fast master bat-tro state UNKNOWN mode DEFAULT group default qlen 500
1
9: fastd-tro: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1312 qdisc pfifo_fast master bat-tro state UNKNOWN mode DEFAULT group default qlen 500
2
10: fastd-troalt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1406 qdisc pfifo_fast master bat-troalt state UNKNOWN mode DEFAULT group default qlen 500
15: fastd-tro: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1312 qdisc pfifo_fast master bat-tro state UNKNOWN mode DEFAULT group default qlen 500
3
18: fastd-tro: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1406 qdisc pfifo_fast master bat-tro state UNKNOWN mode DEFAULT group default qlen 500
ich glaube auf dem w2 läuft was schief
Hast du denn nur die MTU oder auch den Port geändert?
Hier haben ALLE nodes nen VPN zu Wupper2 … die haben aber alle die alte MTU in der FW
ich habe auf dem w2 doch für den Kurzschuss gesorgt … ich lasse den bestehen, passe aber die MAC usw. noch an …
Kurz Zusammengefasst (bitte korregieren wenn ich falsch liege):
Wupper0: MTU 1406 Port 53840
Wupper1: MTU 1312 Port 53842
Wupper2: MTU 1312 Port 53842
Wupper3: MTU 1406 Port 53840
So wie ich es sehe alle als GW Announced und w2 macht den MTU Kurzschluss
korrekt zusammengefasst
~ $ for i in {0..3}; do echo ${i}; ssh root@${i}.wupper.ffrl.de "
ip link show dev fastd-tro
ip link show dev fastd-troalt
batctl -m bat-tro if"
done
0
5: fastd-tro: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1406 qdisc pfifo_fast master bat-tro state UNKNOWN mode DEFAULT group default qlen 500
link/ether 04:74:05:d0:4f:00 brd ff:ff:ff:ff:ff:ff
Device "fastd-troalt" does not exist.
fastd-tro: active
1
9: fastd-tro: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1312 qdisc pfifo_fast master bat-tro state UNKNOWN mode DEFAULT group default qlen 500
link/ether 04:74:05:d0:4f:10 brd ff:ff:ff:ff:ff:ff
Device "fastd-troalt" does not exist.
fastd-tro: active
2
15: fastd-tro: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1312 qdisc pfifo_fast master bat-tro state UNKNOWN mode DEFAULT group default qlen 500
link/ether 04:74:05:d0:4f:20 brd ff:ff:ff:ff:ff:ff
10: fastd-troalt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1406 qdisc pfifo_fast master bat-tro state UNKNOWN mode DEFAULT group default qlen 500
link/ether 04:74:05:d0:4e:20 brd ff:ff:ff:ff:ff:ff
fastd-tro: active
fastd-troalt: active
3
18: fastd-tro: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1406 qdisc pfifo_fast master bat-tro state UNKNOWN mode DEFAULT group default qlen 500
link/ether 04:74:05:d0:4f:30 brd ff:ff:ff:ff:ff:ff
Device "fastd-troalt" does not exist.
fastd-tro: active
w3 wird gleich auch auf den neuen (April) Batman umgestellt, ich lasse die MTU aber bei der alten. Du kannst das Update ausrollen. In GL lief es sehr schnell. Sollte im Batman doch noch fehlerhafter Code für die Fragmentierung vorliegen, stürzen erst mal nur 2 Superknoten ab und nicht alle
1 „Gefällt mir“
So sehr wir jetzt über die Batman-Dauerbaustelle fluchen: Besteht denn Grund zur Hoffnung, dass künftige MeshVPN Protokolle weniger solche Effekte zeigen?
Zum Batman-Unheil mit der 1312(?) habe ich die Vermutung gehört, dass das eine Condition sein könnte, dass dann Paketgröße exakt „1280+Batman“-Header ist.
(Wäre dann ein Bug wenn das deswegen kracht, aber nicht außerhalb des Bereiches des Vorstellbaren.)
1 „Gefällt mir“
1312(!)
…
Hast du versucht zwei Interfaces mit unterschiedlicher MTU ins gleiche bat0 hinzuzufügen? Das erzeugte auf einem unserer Supernodes auch Kernel Panics, auf dem anderen wiederum nicht. Die Call Traces waren dabei so allgemein gehalten, dass man nicht klar daraus lesen konnte, dass batman-adv Schuld trägt. Vermutung geht auf einen versemmelten Locking-Mechanismus oder Memory Corruption. Leider keine Zeit das mit den Entwickler von batman-adv auszuknobeln.
1 „Gefällt mir“
Mir wurde gerade gemeldet, das Troisdorf die MTU Umstellung abgeschlossen hat. Ich werde im Laufe des Tages die alten Ports abschalten.
ja.
OT – Nach einen Update auf 2015.0 vom 2015-04-28 ist das Problem jedoch nicht mehr aufgetreten. Ich habe hier im Forum dieses Problem bei Anderen gesehen. Ich werde die im Forum beschriebenen Tests durchführen …
immernochOT – wir nutzen mein 2tes Paket 2015.0-2 auf https://firmware.freifunk-wuppertal.net/deb/ – nichts anderes als http://downloads.open-mesh.org/batman/releases/batman-adv-2015.0/batman-adv-2015.0.tar.gz mit DKMS …