Speicherort der public fastd Keys für Netzsegmentierung

Auch für die Domäne Regio Aachen ist es so weit, die Domäne sollte aufgeteilt werden.

Separate Firmware ist sehr statisch, daher versuche ich mich an einer Segmentierung wie sie derzeit auch vom Freifunk Stuttgart entwickelt wird.

Dabei gibt es eine default Domäne in die sich neue Knoten verbinden können, anhand der alfred Daten und vorhandenen Nachbarn wird ihr Key einem anderen Netzsegment zugewiesen.
Dort kommt der fastd Key in eine Whitelist, in der default Domäne kommt er in die Blacklist.
Das erzeugen von neuen Segmenten ist in kürzester Zeit möglich.

Ich könnte mir gut vorstellen diese Verwaltung über github zu realisieren, so kann man per pull request die Verschiebung eines Knotens anfordern.

Hat jemand Bedenken die öffentlichen fastd Schlüssel mit Knotenname und Geo Koordinaten öffentlich zu speichern?
Die Alternative wäre unser internes gitlab zu verwenden.

3 „Gefällt mir“

Würden wir dann für Düren eine eigenes Segement bekommen?
Auch wenn ich nicht ganz verstehe, wozu - es klingt auf jeden Fall cool :smiley:

Aber zu Frage: ich sehe nichts, was dagegen spricht, die Schlüssel ins Github zu legen. Die heißen ja nicht ohne Grund öffentliche Schlüssel.

Die Idee dahinter ist ja dass die Segmente relativ dynamisch sein können, je nach Bedarf.

Solange es den Layer-3-Roaming-Daemon noch nicht gibt, gibt es da aber Probleme mit dem Roaming, daher wird man sich in der Praxis vermutlich daran orientieren, die Grenzen da zu ziehen wo möglichst große Mesh-„Löcher“ sind (und auch mittelfristig erhalten bleiben).

Exakt, bei auftretenden kurzschlüssen zwischen den Segmenten wird einfach einer der Verursacher von einer Whiteliste in eine andere verschoben und die vorherige Verbindung gekickt.
Mesh Wlan bleibt überall identisch, dadurch gibt es kein kompliziertes updaten der Wolken.

Das wäre die Frage: Die MeshID bleibt unverändert.
d.h. wenn zwei Knoten sich sehen, die unterschiedlichen Subdomains zugeordnet sind, dann sorgen diese armen Plasterouter dann für den Domain-Kurzschluss.

Verursacht dann nicht jeder neue Knoten einen Kurzschluss?

Neue Knoten können nur in die default Domäne, diese soll möglichst leer sein.

Mit dieser wird es regelmäßig Kurzschlüsse geben, das ist aber nicht weiter schlimm, da sie ja nur eine Hand voll Geräte enthalten soll.

Naja, Kurzschluss „(volle)Arbeitsdomain<>(fast leere)Defautldomain“ wird dann blöd, wenn es davon mehrere gibt und so „über die kleine Defaultdomain“ die Arbeitsdomains kurzgeschlossen werden.
Zumal wenn diese Kurzschlüsse dann auch noch über Wifi-Links passieren.
Also „MeshvpnA1<>WifilinkX1<>MeshvpnD<>MeshvpnD<>WifilinkX2<>MeshvpnA2“