~ $ 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
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.)
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.