Doch Andreas, ein sysupgrade ohne verwerfen der Config ist die Ursache. Das Ergebnis ist dann eine Mischung der alten UND der neuen Config.
Da der Tunnelaufbau, bzw vielmehr die Auswahl des Tunnels mehr oder weniger zufällig ist, hat man dann nicht zwangsläufig sofort, aber irgendwann die Situation das ein Tunnel in die alte Infrastruktur und der andere Tunnel in die neu hinzu geflashte Infrstruktur zeigt. Und schon hat man eine tofte Bridge von einem Netz in das andere Netz über die leistungsschwache CPE und vergleichsweise kleine Endkundenleitung.
Den „Gateway Speed“ legt man selber im batman fest, einfach ein Anzeigewert, der mit in die Metrikberechnung einbezogen wird. Im Ruhrgebiet steht die Bandbreite auf 48Mbit/48Mbit, im Rheinufer und Möhne glaube ich auf 96Mbit/96Mbit. Generell waren in allen Configs die ich bislang gesehen habe immer Werte zwischen 48Mbit/48Mbit und 96Mbit/96Mbit. das ist nun das erste Mal gewesen das wir fremde Supernodes im Netz hatten die einen höheren Wert hatten.
Vorsatz wird es nicht sein, einfach entweder fehlendes Wissen das man spätestens beim Infrastrukturwechsel mit sysupgrade -n flashen muss oder ein Flüchtigkeitsfehler.
Wir bräuchten, wie schon mehrfach von mir vorgeschlagen, einen kleinen Security Daemon, der die Ausgabe von ‚batctl gwl‘ fortlaufend überwacht und sobald ein Gateway auftaucht das im Feld Next-Node keine identische Mac Adresse zum Gateway hat, muss die fastd Registrierung der Node mit der Next-Node Mac-Adresse gelöscht werden und wenn vorhanden sowohl an die Adminz wie auch an die Mail des Node-Betreibers aus den Alfred Daten eine entsprechende Email gesendet werden. Das würde zumindest die meisten Fehler dann direkt im Keim ersticken und man müsste nicht mehr selber manuell die Node aus den Alfred Daten raussuchen, anhand des Namens die fastd Registrierung suchen und dann die Registrierung für den fastd löschen.