fastd reload am Knoten reicht nicht (mehr) aus

[mail at adrianschmutzler.de]

Hallo zusammen,

meine Schlussfolgerungen zu dem Problem decken sich mit Christians Aussage:

fastd prüft beim reload nicht, ob sich die Gesamtkonfiguration der peers geändert hat, sondern prüft nur die Identität der Peers, also ob es neue gibt oder alte entfernt wurden. Die Identifikation der Peers erfolgt über den key, d.h. der Key ist quasi die ID eines Peers.

Wird dementsprechend nur die Adresse oder der Port eines Peers geändert, merkt das fastd nicht, da es sich aus seiner Perspektive um denselben Peer handelt. (Theoretisch würde das gleiche Problem auch entstehen, wenn man eine manuell konfigurierte IP oder den Hostnamen im keyserver ändert, z.B. bei einem Serverumzug, ohne den Key zu ändern.)

Ein /etc/init.d/fastd reload ändert also nichts.
Im Gegensatz dazu wird bei einem /etc/init.d/fastd restart alles komplett neu gelesen, und dann ist auch die geänderte config geladen.
vpn-select macht allerdings einen reload.

Es sollte also unbedingt für jede Hood ein eigenes fastd-Keypaar erzeugen und konfiguriert werden!

Bei Servermigration o.ä. sollte dieses im besten Fall dann auch geändert werden.

Darüber hinaus sollte wir uns überlegen, ob wir dieses Problem umgehen, indem wir manuell Checksummen über die fastd peers in der FW bilden und bei Änderung einen fastd restart triggern.

Beste Grüße

Adrian

> -----Original Message-----
> From: Christian Dresel [mailto:fff at chrisi01.de]
> Sent: Samstag, 11. Juli 2020 16:07
> To: mail at adrianschmutzler.de; franken-dev at freifunk.net; franken-
> gateway at freifunk.net
> Subject: Re: fastd reload am Knoten reicht nicht (mehr) aus
> 
> Hallo Adrian
> 
> ist dies das gleiche, was ich damals bei der Fürth Polyhood hatte? Da haben
> die Router auch ihre Verbindung zur "alten" Hood behalten und sie damit
> verbunden. Da hab ich auch behauptet (ohne es sicher zu wissen) es liegt am
> gleichen fastd-key. Seitdem war ganz kleine meine Empfehlung überall
> verschiedene Keys zu verwenden denn damit hat es dann auch bei mir
> damals funktioniert.
> 
> Gruß
> 
> Christian
> 
> On 11.07.20 15:56, mail at adrianschmutzler.de wrote:
> > Hallo zusammen,
> >
> > ich habe meine zwei neuen Hoods getestet und dabei folgendes Problem
> mit fastd festgestellt:
> >
> > Situation: Ich habe einen Router per Koordinaten in eine bestimmte Hood
> konfiguriert.
> >
> > Nun ändere ich die Koordinaten per Hand in /etc/config/fff
> >
> > Danach wechselt der Router nach dem Ausführen von configurehood in die
> neue Hood.
> >
> > Problem: Die Konfiguration ist vollständig umgestellt, aber fastd übernimmt
> die neue Konfiguration nicht.
> > Auch die fastd-Peer-Dateien enthalten die neue Konfiguration.
> >
> > An verbundenen Clients werden somit IP-Adressen aus den alten
> Bereichen vergeben. Da beide Hoods auf demselben Gateway liegen
> funktioniert dies sogar irgendwie so, dass am Client Internet vorhanden ist.
> >
> > Beheben lässt sich das Problem mit /etc/init.d/fastd restart am Router. Ein
> /etc/init.d/fastd reload reicht _nicht_ aus (das ist das, was vpn-select macht).
> >
> > Da in meinem speziellen Fall beide Hoods auf demselben Gateway liegen,
> ist der einzige Unterschied in der fastd-Config der Port (auch die Keys sind
> gleich). Ggf. wird das für den reload nicht überprüft?
> >
> > Falls diese Situation schon länger existiert (und nicht erst mit 19.07
> eingeführt wurde), könnte dies die Erklärung für diverse spannende
> Ereignisse bei Hoodteilungen sein.
> >
> > Dies wurde mit meiner FW getestet, ich sehe aber keinen Grund, warum es
> bei der offiziellen anders sein sollte.
> >
> > Grüße
> >
> > Adrian
> >
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : openpgp-digital-signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 834 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20200711/886927fe/attachment.sig>