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

So Sep 27 16:43:01 CEST 2015

Hi

Ui, das ist schon ne lange Mail geworden. Wir sollten das mal
durchsprechen:

https://dudle.inf.tu-dresden.de/Dev_Meeting/

Als Ort würde ich spontan das Nürnberger Lab vorschlagen, wir können das
aber auch woanders, z.B. in Bamberg oder so, machen.

Tim

Am Sonntag, den 27.09.2015, 16:24 +0200 schrieb Tim Niemeyer:
> 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
> 
> -- 
> 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/f834a28e/attachment-0002.sig>