Wir hatten nun schon öfter das Problem, dass wir unsere fastd Konfiguration auf den Supernodes ändern wollten, sodass sie nicht mehr abwärtskompatibel zur Alten ist. Die MTU zu wechseln ist zum Beispiel eine solche problematische Einstellung. Die Frage ist nun, wie man die Freifunkrouter von der Alten zur neuen Konfiguration migriert.
Erstmal richtet man wohl gleichzeitig eine zweite fastd Instanz auf dem Supernode auf einem anderen Port ein. Nun rollt man eine neue Firmware für die Router aus, in der die neue Konfiguration propagiert wird. Etwas unschön hieran ist, dass man jedes mal einen neuen Port auf den Supernodes vergeben muss. Folgendes Szenario gibt es bei uns zB an einigen Stellen. Falls jemand vor dem Freifunkrouter eine sehr restriktive Firewall betreibt, die nur bestimmte ausgehende Ports zulässt, zerstört man diesen Aufbau.
Um diesen Portwechsel von Extern zu vermeiden habe ich ein wenig in den Tiefen von iptables gewühlt und bin auf „zufällige Portweiterleitung“ gestoßen. Vermutlich war diese Möglichkeit eher zur Lastverteilung gedacht, sie funktioniert aber auch super um mehrere inkompatible fastd Instanzen auf den selben Port zu bringen. Dafür ist nur folgende Regel in der nat Tabelle notwendig:
# fastd migration
iptables -t nat -A PREROUTING -p udp -m udp --dport 10000 -j REDIRECT --to-ports 10000-10001 --random
Die Regel sorgt beim Verbindungsaufbau dafür, dass man zufällig einem der beiden internen Ports zugeordnet wird. Wenn man den falschen erwischt, dann wird keine Verbindung zustande kommen und fastd wird einen neuen Verbindungsversuch in ca 30 Sekunden starteten.
Wichtig hierbei ist, dass der Verbindungsversuch von einem neuen Port kommt. Ansonsten ist die Verbindung für IPTables (genauer gesagt conntrack) nicht „neu“. Wenn man innerhalb von 30 Sekunden wieder vom gleichen Port kommt, dann kennt conntrack die Verbindung noch und man stößt wieder auf die gleiche fastd Instanz [1]. Solange man den fastd nicht explizit auf einen festen Port bindet (also die Konfigoption „bind“ benutzt), wird bei jedem Verbindungsversuch ein neuer Port genutzt. In Gluon wird kein „bind“ verwendet. Die Strategie funktioniert also. Die einzigen negativen Auswirkungen sind, dass eventuell ein paar mehr Verbindungsversuche vonnöten sind. Das ist aber bei vielen Supernodes und nur 30 Sekunden bis zu einem erneuten Versuch beim gleichen Supernode kein wirkliches Problem.
Vielleicht hilft das ja auch anderen 
Gruß,
lemoer
[1] Die NAT-PREROUTING Tabelle wird nur durchlaufen, wenn eine Verbindung im conntrack Sinne neu ist.