[Freifunk Franken] zentraler oder dezentraler KeyXchange?

So Aug 20 16:21:21 CEST 2017

Hallo Cristian,

vielen Dank, dass du das mal fuer uns zusammengeschrieben hast!

Wenn ich das richtig verstanden habe, geht es darum, dass die Hoods
nicht mehr meshen. Die Loesung, jeder Hood ne igene SSID, BSSID zu
geben, wird ja schon laenger diskutiert. Ich finde es erstmal auch ok,
die Loops nerven wirklich. Und das Generieren dezentraler Hoods wird
auch leichter. Ob hierin eine Gefahr besteht, dass sich unser fff-Netz
zu sehr aufspaltet und wir irgendwann nicht mehr von Freifunk Franken
sprechen koennen, kann ich nicht beurteilen. Man sollte das aber im Auge
behalten.

Es wird dann auch fff-Router geben, die sich sehen aber nicht meshen.
Hm, wiederspricht irgendwie der Grundidee. Waere beim dezKeyXchange aber
auch so.

In der Einfuehrung des Configwlans sehe ich potential. Da kann man
bestimmt irgendwann mal noch mehr mit machen.

Robert

Am 20.08.2017 um 14:51 schrieb Christian Dresel:
> Hallo zusammen
>
> auf den gestrigen F3 Netze e.V. Sommercamp wurde auch ein wenig über den
> dezentralen KeyXchange gesprochen.
>
> Ich hab mit nach Hause genommen, dass den schon gerne die meisten Leuten
> hätten es aber aktuell wirklich schwierig ist den fertig zu stellen, es
> fehlt einfach die Man-Power. Um genau zu sein ist es aktuell ja kaum
> möglich alle Patches einzuspielen geschweige denn eine Beta/Release
> hinzubekommen. Da ist es (mittlerweile glaube ich nicht nur mehr) mir
> schleierhaft wie man den dezentralen KeyXchange fertig stellen will und
> auch warten, pflegen und Bugs entfernen will.
> Ich persönlich sehe das aktuell als sehr schwierig an und ich glaube
> mittlerweile bin ich da nicht mehr ganz alleine.
>
> Vor einiger Zeit hab ich mal drüber nachgedacht ob man nicht den
> zentralen KeyXchange etwas erweitern kann indem er einfach die wireless
> Settings mit an die Knoten sendet und die sich drauf konfigurieren.
> Wurde dann damit zerschlagen das ja Meshknoten dann nicht wissen wie sie
> das Meshnetz erreichen können, da dies ja für jede Hood unterschiedlich
> wird.
>
> Gestern kam die Idee dann wieder auf, dass man dies mit dem (auch im
> dezentralen KeyXchange geplanten) Hidden AP lösen könnte. Ich versuche
> hier mal das Konstrukt möglichst Fachunspezifisch zu erklären so das es
> hoffentlich jeder (auch nix Linuxianer) versteht:
>
> - Wir haben den Fall, das ein neuer Knoten einfach per WAN ans Internet
> angeschlossen wird:
>
> In diesem Fall werden ganz normal im WebUI die Koordinaten gesetzt, der
> Knoten fragt den zentralen KeyXchangeV2 an und bekommt erstmal seine
> Gatewayliste zurück. Gleich danach fragt er den KeyXchangeV2 nochmal an
> (oder vllt. direkt im ersten Schritt mit, muss man noch überlegen) und
> bekommt Wirelesssettings zurück. D.h. er bekommt eine eigene SSID (Name
> den das Handy anzeigt) und eine BSSID (womit das Mesh einzigartig wird,
> verschiedene Hoods können sich dann techn. nicht mehr vermeshen -> keine
> versehentliche Loopprobleme mehr) zurück und kann diese Konfiguration
> übernehmen. Daraus folgt das jede Hood auch eine einzigartige SSID bekommt.
>
> - Nun haben wir den Fall, das man einen Meshknoten in Betrieb nehmen will.
>
> Da dieser ja nicht weiß wie die SSID/BSSID lautet (wird ja im ersten
> Fall je nach Hood anders gesetzt), kann er sich nicht ins Freifunknetz
> verbeinden. Daher müssen andere Knoten einen weiteren Accesspoint
> aufmachen (hidden -> Man sieht ihn am Handy nicht) über den man
> ebenfalls in Freifunknetz/Internet kommt und IMMER gleich ist. Der
> Meshknoten scant nun, nachdem er feststellt das er über WAN kein
> Internet hat, nach diesen immer gleichen (in allen Hoods) hidden Netz,
> wenn er eins findet bucht er sich dort als Client ein und hat dann
> Zugang zum KeyXchangeV2 (über das Freifunknetz&Internet). Er bekommt nun
> auch seine SSID/BSSID zugeschickt, kann diese konfigurieren und dann mit
> den Knoten meshen der neben ihn steht.
>
> - Der 3. Fall man möchte den Knoten nun in eine neue dezentrale Hood
> (Hardhöhe, StPaul, marterlach, etc.) bringen
>
> Bisher hat man hier die Knoten manuell konfigurieren MÜSSEN (kann man
> danach immer noch, es bleibt also dezentral!). Jetzt kann man diese Hood
> in den KeyXchangeV2 einpflegen lassen und im WebUI kann ein Menü
> erstellt werden:
> - Lade alle Hoodinformationen herunter
> Dies könnte funktionieren sobald der Knoten "irgendwie" Zugang ins
> Freifunknetz/Internet hat (entweder weil er per WAN angeschlossen ist
> oder im config Netz eingebucht ist). Darin befinden sich dann auch die
> dezentralen Hoods, man kann sie im WebUI anwählen und der Knoten
> konfiguriert sich dann für diese dezentrale Hood (die Informationen wie
> er das machen muss, bekommt er ja vom KeyXchangeV2 geliefert).
>
> Vorteil von KeyXchangeV2 gegenüber den dezentralen KeyXchange:
> - Ich persönlich sehe die Umsetzung als deutlich einfacher an
> - Ich sehe das ganze als deutlich wartungsärmer und pflegeleichter an
> - Wir führen nicht zuviel neues Zeug ein was Probleme bereiten kann
>
> Nachteil von KeyXchangeV2 gegenüber den dezentralen KeyXchange:
> - Ganz klar wir behalten eine zentrale Stelle.
> Wobei ich dieses Nachteil persönlich entkräften möchte:
> Wer aktuell dezentral sein will und nicht Abhängig vom KeyXchange soll
> einfach mal nach Fürth oder mittlerweile auch Nürnberg gucken. Folgende
> Hoods kann mittlerweile NUR NOCH der Besitzer abschalten und keine
> "zentrale Instanz"/"einzelne Person" mehr (höhere Gewalt, Zerstörung,
> etc. ausgeschlossen)
> - Hardhöhe
> - Unterfürberg
> - StPaul
> - reddog
> - Neunhof
> - FabLab
> - Hugennottenplatz
> - marterlach
>
> darin stecken mittlerweile 3 Personen die das Konzept nahezu
> selbstständig umgesetzt haben und ich persönlich sehe auch diesen Aufbau
> als die Zukunft an. Man ist damit viel flexibler, man tunnelt weniger,
> kann viel besser mit Richtfunkstrecken arbeiten,... usw. Nachteil ist
> das man zumindest ein Gateway "in der Stadt" immer zumindest ein
> bisschen händisch konfigurieren muss.
>
> Ein RFC Patch habe ich heute morgen mal über die Dev-Mailingliste geschickt:
> http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/2017-August/012491.html
>
> Vielleicht noch kurz das Thema:
> Warum nicht einfach so weitermachen wie bisher? Das hat mehrere Gründe:
> - Da jeder Knoten immer noch nicht weiß, in welcher Hood er ist haben
> wir immer und immer wieder das Problem das sich Hoods verbinden. Das
> muss man einfach mal endlich lösen
> - Batman 2013.4 was wir verwenden ist schon sehr veraltet. Leider ist
> das neuere Batman nicht mit den alten kompatibel. Man muss also das Netz
> von vorne neu aufbauen. Daraus folgt auch, ein vermeshen zwischen den
> alten KeyXchange und den "geplanten neuen" KeyXchangeV2 ist NICHT
> möglich, dies wäre aber beim dezentralen KeyXchange genau das gleiche
> gewesen
> - Klar wäre ein allgemeiner Wunsch auch gewesen das Netz weiter zu
> dezentralisieren, dies bietet der KeyXchangeV2 eindeutig __NICHT__. Mein
> Gefühl sagt mir aber das 90% (oder mehr...?) der Freifunker einfach nur
> einen Router aufstellen möchten der geht und dezentralität anscheinend
> egal ist... Schade :( Dabei bieten wir in Franken soviele tolle
> Möglichkeiten die andere Communitys nicht haben.
>
> Ich würde mir hier gerne eine Diskussion wünschen wie es denn nun mit
> Freifunk Franken weiter gehen soll. Ich denke meine persönliche Meinung
> hab ich in der Mail ganz gut rüber gebracht, bin mal gespannt was die
> Community so denkt.
>
> mfg
>
> Christian
>
>
>
> _______________________________________________
> franken mailing list
> franken at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/mailman/private/franken-freifunk.net/attachments/20170820/e8f9cd83/attachment.html>