Mesh-Problem zwischen Router in verschiedenen Hoods: Lösungsansatz

So Sep 27 16:24:40 CEST 2015

Hi

Am Sonntag, den 27.09.2015, 15:37 +0200 schrieb delphiN:
> Am 27.09.2015 15:27, schrieb Tim Niemeyer:
> > Ja, bis hierhin ist der Aufwand noch ganz gut und recht
> > überschaubar. Aber aber .. Was machen wir mit Knoten, die gar kein
> > VPN haben und ergo auch den keyXchange nicht abfragen?
> 
> haha...du hast recht...
> 
> Man könnte natürlich für jede Hood automatisch eine neue Firmware
> generieren :-|
Richtig. Dann gehen aber Hood-Splits nur noch sehr sehr schwerfällig.
Ich denke damit würden wir unser Netz ganz schön zerflücken.

> Oder den Key-Exchange auch abfragen, wenn garkeine VPN benötigt wird.
> Dazu müsste der Keyxchange aber in der lokalen Hood erreichbar sein.
Da stellt sich mir die Frage, was die lokale Hood ist.

Beispiel: $Jemand stellt einen Knoten A auf. Dieser hat VPN und bekommt
nun eine Hood zugewiesen. Danach stellt $Jemand Knoten B auf. B hat kein
VPN und kennt seine Hood nicht. Er hat also keine Verbindung zu A und
auch sonst keine Verbindung zum restlichen Netz. Er wird den keyXchange
also nie erreichen können.

Ich denke daher dies ist kein gangbarer Weg.

> Oder man hat ein Webinterface um die Hood manuell auszuwählen.
Das ist irgendwie so der Mittelweg aus der "Firmware pro Hood" und
"Discovery" Lösung. Vor allem für eine erste Lösung halte ich das aber
für einen sehr guten Weg. Leider sehe ich aber hier auch einige Probleme
die noch geklärt werden müssen:
a) Wir brauchen erstmal ein Webinterface dafür.
b) Wie kommen die Hood-Informationen (Name, BSSID, Kanal, VPN-Server,
etc) in das Webinterface?
c) Woher sollen die Leute wissen, welche Hood sie auswählen sollen?
Woher soll man z.B. wissen, ob man in Nürnberg Süd, Nürnberg Nord oder
gar Fürth ist?

Den Punkt a) sehe ich durch aus als lösbar an. Man könnte das OpenWRT
System verwenden und auf unsere Bedürfnisse anpassen. Man kann aber auch
das von Bielefeld nehmen und ebenfalls anpassen.

Den Punkt b) haben wir bereits angefangen hier zu beschreiben:
https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:HoodAnnouncement
Bisher steht da nur grob welche Informationen in etwa übermittelt werden
müssten. Auch eine Signierung ist vorgesehen, denn wir wollen ja nicht
dass irgendein Spaßvogel alle Informationen überschreibt, löscht oder
sinnlose/kaputte hinzufügt. Dadurch, dass diese Daten irgendwie
synchronisiert werden müssen, würde eine Manipulation an einer einzigen
Stelle das gesamte Netz zerstören, wenn man keinen Sicherungsmechanismus
vorsieht.
Es ist allerdings noch nicht klar, wie genau die Informationen
ausgetauscht werden sollen. Wie kann man z.B. sicher verhindern, dass
die zu synchronisierten Daten nicht ungewollt gelöscht werden und so
eine Hood verschwindet, die aber noch aktiv sein sollte. Vor allem aber
bleibt das Problem: Wie kommen die Informationen zu einem Knoten, der
_gar kein_ Netz hat? Meiner Meinung nach kommen wir also _auch_ um die
"Discovery" Lösung nicht rum. In so einem Fall würde ein Knoten das
Discovery regelmäßig machen und dann die Mesh-Netz die gefunden werden
durchprobieren. So bald ein Mesh Netz funktioniert muss er sich die
Hood-Daten downloaden/synchronisieren.

Ich denke Punkt c) kann man durch eine Automatik umgehen. Der
Knotenbetreiber wird in Zukunft den Router-Standort am Knoten eintragen,
und da die Hood-Daten ja einen Standort enthalten, kann der Knoten dann
die am nächsten liegende Hood automatisch wählen. Das sollte natürlich
im Webinterface auch manuell fest zu setzen sein.

Als super großes Plus bekommen wir bei dieser Lösung auch ein Fix für
den keyXchange. Der wäre dann ja nicht mehr nötig.

> Oder man macht ein Discovery der existierenden Batman Netze und nimmt
> dann eins von denen.
Wie ich oben schon schrieb, wird man um das hier nicht rum kommen. Die
Idee auf dem Camp war, dass ein Discovery immer gemacht wird, wenn kein
VPN da ist und keine Hood manuell gewählt wurde. Man sollte mMn z.B.
immer periodisch suchen, auch wenn man einige batman Originators sieht.
Es kann ja sein, dass der Knoten sich mit einem zweiten Knoten verbunden
hat, der selbst keine weiteren Knoten verbunden hat, obwohl rings herum
noch viele andere Knoten sind. Ein versehentlicher Split sollte dadurch
ja dann wieder zusammenfügbar sein.

> Mehr fällt mir grade nciht ein.
Ja, du hast die essentiellen Punkte schon gefunden. Ich denke man kann
jetzt ganz gut erkennen, wieso es nicht mit einem $irgendwas getan ist.
Hier greifen einfach viele Dinge ineinander und die müssen irgendwie
alle angepackt werden. Aber es ist gut, dass jetzt endlich mal etwas
Diskussion aufkommt. Vielleicht hat ja auch jemand noch eine Idee, wie
wir das alles viel einfacher lösen können.

Für mich persönlich ist ein ganz großer Blocker auch noch das Netmon.
Wir haben stand Heute noch keine Alternative. Und das Netmon muss
aktuell in jeder Hood ein L2-Bein haben. Das ist noch realisierbar, wenn
immer VPNs eingesetzt werden, aber spätestens, wenn wir mal eine Hood
machen, die wirklich nur per Funk angebunden ist sieht das wieder anders
aus. Wir müssen entweder etwas ganz anderes für das Monitoring haben
oder dem Netmon beibringen mit gerouteten Adressen umzugehen. Wenn wir
routen wollen, führt fast kein Weg an IPv6 im Freifunk ausrollen vorbei
(was wieder ein riesem Thema für sich ist). Vielleicht finden wir ja
noch eine bessere Lösung mit irgendwelchen Zwischen-Einsammlern, die
lokal über Link-Local einsammeln/entgegennehmen und dann an eine
zentrale Anzeige Einheit weiterreichen oder so. Wenn wir am Netmon
festhalten müssten wir weiter umbauen, dass die Geo-Koordinaten vom
Knoten selber kommen. Eigentlich braucht es dann nicht mal mehr einen
Benutzer-Account am Netmon, da ja alle notwendigen Daten dann vom Knoten
selbst kommen. Aber auch das ist wieder ein riesen Arbeitspaket für
sich.

Ich denke wir sollten das gesamt Bild, wo wir mal hin wollen, nochmal
besser diskutieren und dokumentieren. Wenn wir uns dann einig sind, was
wir eigentlich bauen wollen, dann sollten wir mal ein Projekt-Plan
machen, damit wir auch die Abhängigkeiten untereinander sehen.
Vielleicht kriegen wir dann auch Arbeitspakete hin, die man auch gut
delegieren kann?

Tim

> 
> delphiN
> 
> 
> 
> -- 
> franken-dev mailing list
> franken-dev at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20150927/622b44ac/attachment-0002.sig>