[Freifunk Franken] zentraler oder dezentraler KeyXchange?

[Christian Dresel]

Hallo Namensvetter :)

On 25.08.2017 22:07, Christian H. wrote:
> Hallo zusammen,
> das Thema wird ja nun schon seit längerem auch in den Treffen
> diskutiert, vielen Dank für die Wortmeldungen und die schriftliche Doku.

gerne

> An den unterschiedlichen SSID's kommen wir - soweit ich verstanden habe
> (IP Vergabe) - nicht vorbei.

ja technisch ist es einfach der richtige Weg, man kann ein Netz
"hinfrickeln" oder man kann es technisch richtig machen und dann braucht
jedes Layer 2 Netz eben ne extra SSID.

> Die Nutzerfreundlichkeit kann man zur Diskussion stellen - der Aufwand
> einmalig zu schauen welche ID jetzt lokal Freifunk bietet - und diese zu
> wählen - sollte machbar sein.

das denke ich auch bzw. ist schon so bei mir, ich hab Handy bestimmt ein
paar dutzend Freifunk SSIDs drinnen (da ich auf meinen Hoods gerne für 5
GHz ne extra SSID ausstrahle und auch immer mal wieder mit "TestSSIDs"
arbeite, sammelt sich da schnell was an) und hab damit kein Problem.

> Das einzige Thema dabei, haben wir mit gedruckten Flyern, Aufklebern,
> Zeitungsartikeln - die eben aktiv die Standard SSID anpreisen.

stimmt :( Da ist es etwas unschön. Nicht umsonst steht auf meinen
Messern keine SSID ;)

> Die technischen Themen unten erläutern glaube ich den grundsätzlichen
> Aufwand bzgl. dezentralem KeyExchange ganz gut.
> Zum Thema: Router sendet Koordinaten und damit wird die Hood festgelegt,
> könnte man das nicht mit als Auswahl in's webui packen?
> Variante 1) ich setze die Koordinaten - alles wie immer

genau, da ändert sich nur der techn. Hintergrund wie die Daten abgerufen
und verarbeitet werden, evtl. bisschen die Einrichtung da nach dem Abruf
der Daten ja das Wifi rekonfiguriert werden muss. Aber ich denke das
wird jeder User der jetzt einen Router einrichten kann auch hinbekommen
außer das einige Zeit bisschen was von selbst passiert und das Wifi mal
verschwindet ist sonst ja alles einzurichten.

> Variante 2) ich habe einen Plan und möchte einer spezifischen Hood
> angehören.
> Bei Variante 2 - muss dann eben die Wifi Konfiguration entsprechend für
> die Hood gestellt werden (automatisch?).

Wenn diese "spezifische" Hood in WLAN-Reichweite ist, werden sich die
Parameter vollkommen automatisch per Wifi heruntergeladen (über den
Hidden AP), der User muss also im best case gar nix tun außer den Router
aufstellen, warten bis er feststellt das er kein WAN hat sich per Wifi
an den Nachbarnode verbinden sich die Infos holt und selbstständig(!)
rekonfiguriert. So kann man sich dann auch problemlos an dezentrale
Hoods wie Hardhöhe anschließen. Ich flashe eine Nanostation M2, richte
sie Richtung Hardhöhe aus, sie stellt fest: "Oh ich hab kein Internet
ich muss mal gucken ob ich ein hidden AP Netz finde", sie schaltet ihr
Wifi aus und versucht sich mit dem hidden config.franken.freifunk.net zu
verbinden, wenn sie das findet connectet sie, konfiguriert sich eine IP,
läd sich von einer festen IP (den Nachbarnode, jeder hat die gleiche IP
wirkt so ähnlich wie aktuell die fdff::1 techn. aber bisschen anders)
die hoodfile herunter, konfiguriert sich so wie es in der Hoodfile steht
(also die Parameter der Hardhöhe Hood) startet neu und ist dann ein
Hardhöhenode. Geil oder? ;)

> Ich denke das würde der Allgemeinheit helfen, sich besser auf eine Hood
> "manuell und bewusst" festzulegen.

auch das ist auf jeden Fall geplant, man nimmt sich eine json config
File (z.b. aus dem Wiki) und C&P die in das WebUI und ist dann manuell
in dieser Hood. Ja das wird auf jeden Fall mit dazu kommen, muss man
halt machen.

> 
> Ein weiterer Punkt für mich, ist die Konfiguration eines Mini-Hood-Gateways.
> Meist wird hier ja ein Router als Gateway konfiguriert und vor Ort
> platziert.
> a) hier sollten wir Standards schaffen - die der Normal-User selbständig
> anwenden kann, um quasi Mini-Gateways vor Ort selber installieren zu können

Tim hat da schon ein Patchset das braucht aber noch viel Liebe ;) Ganz
komplett automatisch wird es aber vermutlich nie werden, da man im Layer
3 Netz eben IP Adressen vergeben muss (manuell!) und auch den DHCP
konfigurieren (mindestens den IP Bereich angeben). Natürlich könnte man
sich die Info auch von einer zentralen Stelle besorgen aber in dem Satz
ist ein Wort drinnen das wir bei Freifunk eigentlich nicht wollen ;)

> b) sollten wir Varianten schaffen, um die bestehenden Haupt-Gateways -
> welche mehrere Hoods bedienen, per webui Auswahl Routerspezifisch
> ansprechen zu können.

verstehe ich gerade nicht ganz worauf sich das bezieht?

> 
> Um den Ruf von Freifunk dabei nicht zu beschädigen, bin ich immer noch
> dafür das "Offline Script" in die Firmware zu packen.
> Falls also eine Verbindung zum Gateway nicht klappt, ändert sich die
> spezifische Router SSID zu OFFLINE_xxx.

das hat mit den KeyXchange aktuell wenig zu tun, wäre evtl. ein eigenes
Thema auf der dev. Liste wert.

> 
> Grundsätzlich sehe ich folgende Ziele:
> - Dezentralität, ja - aber das muss nutzerfreundlich möglich sein
> (Routeraufsteller) - nicht jeder kann programmieren ;-)

das beist sich halt ein bisschen, dezentral heißt nun mal, ich muss mein
Netz verwalten und hab keine zentrale Stelle die das für mich tut. Man
kann es im WebUI schon sehr vereinfachen der Aufwand dazu ist aber nicht
ganz ohne. Die paar wenigen Leute die an der FW mitarbeiten schaffen es
ja kaum aus den Alpha Status herauszubekommen geschweige den ein ganzes
WebUI zu erstellen :(

> - Hood Auswahl - kann man in die Verantwortung des Routeraufstellers legen

siehe oben, der hidden config AP wird da VIEL vereinfachen

> - Gateways/Hoods - sollten zentral - aber auch dezentral möglich sein
> (wie gehabt, und einfache Möglichkeit, dass auch Laien einen Router als
> Gateway programmieren und diesen auswählen können)

wird auch so bleiben

> - Hood Performance hat Priorität - die Aufspaltung per Koordinaten
> bringt uns gerade im Stadtgebiet große Probleme - nicht zukunftsfähig

weil? Wenn die BSSID geändert wird, können problemlos 2 Hoods
nebeneinander existieren da sie dann nicht meshen. Darauf baut ja der
keyxchangev2 bzw. dez. keyxchange auf.

> - "meshen ohne Mitdenken" hat niedrige Prio, wer meshen möchte muss
> Kommunizieren und mit dem Partner einen Weg finden sich zu verbinden
> (automatisch ist schön - wird aber auf Dauer nicht funktionieren) - im
> Gegenteil, die schwachen - unkoordinierten Mesh Verbindungen bieten dem
> Endnutzer nur schlechte Performance - Rufschädigung.

stimme ich dir vollkommen zu, sehen aber leider nur wenige ein... Es
geht immer nur um mehr und mehr Router, alles auf Kanal 1 alles per
Wifimesh und dann wundern das nix geht :(

> 
> Für mich sieht das einfach so aus, wir haben Normal-, Advanced und
> Professional-User.
> Normal läuft weiter wie bisher, Advanced hat einen Plan und wird durch
> Lösungen unterstützt selbständig zu handeln, Professional - baut sowieso
> schon eigene Mini-Hoods.
> 
> Soweit meine Gedanken dazu.
> Wir sollten uns da echt noch mal treffen ... :-)

Wer wollte eigentlich nochmal ein Techniktreffen planen? ;) Wäre echt
mal an der Zeit (und nein ich wars nicht :P)

mfg

Christian

> Grüße Chris
> 
> 
> 
> 
> Am 20.08.2017 um 15:25 schrieb Tim Niemeyer:
>> Hi Christian
>>
>> Am Sonntag, den 20.08.2017, 14:51 +0200 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.
>> Ne, du hast leider völlig Recht. :(
>>
>>> 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.
>> "Zerschlagen" klingt so heftig..
>>
>>> 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) 
>> Ein Schritt wäre mMn sinnvoll.
>>
>>> 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.
>> Hinweis für die Leser: Das wäre beim dezentralen keyXchange genauso.
>>
>>> - 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
>> Problem ...
>>
>>> 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 
>> ... weil der Knoten hier zwischen zwei Hoods liegen könnte und dann
>> immer hin und her "roamen"/"handovern" würde. Das würde dazu führen,
>> dass die Kommunikation dann kaputt geht, weil die Subnetze anders sind.
>>
>> Das Konzept vom dezentralen KeyXchange sieht genau deswegen da ja auch
>> vor, dass die Daten von Knoten zu Knoten kopiert werden. Im Fall des
>> roamen geht im schlimmsten Fall die aktuelle Websession (der Download)
>> kaputt. Das wäre über einen simplen retry leicht handhabbar.
>>
>> Man kann mit dem Problem vielleicht leben oder sogar irgendwie
>> drumherum bauen. Immerhin würde es heute vermutlich sehr selten (wenn
>> überhaupt) passieren, aber ich hoffe in Zukunft doch schon deutlich
>> öfter.
>>
>>> 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).
>> Wenn man da schon das WebUI anfasst, wäre ich dafür, dass die
>> Information zu den dezentralen Hoods nicht im keyXChangeV2 liegen
>> sondern vom Benutzer eingegeben werden. Man könnte dies in einem
>> Oneliner verpacken:
>> hh.freifunk;00:DE:AD:BE:EF:01;13;...
>>
>> Dann wäre man unabhängig von dem zentralen Ding.
>>
>>> 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.
>> Ich finde diesen echten dezentralen Ansatz auch viel viel besser! Aber
>> leider sehe ich nicht, dass wir es schaffen werden alle Freifunk Knoten
>> in so ein Konzept zu überführen.
>>
>>> Ein RFC Patch habe ich heute morgen mal über die Dev-Mailingliste
>>> geschickt:
>>> http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/2017-Aug
>>> ust/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
>> Richtig.
>>
>>> - 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
>> Wobei man das Batman theoretisch auch ohne Änderung des KeyXchange's
>> einführen könnte. Da es aber ein Bruch des Meshings (auch zu den
>> Gateways hin) bedeutet, ist es ein hoher Aufwand und bindet viele
>> Ressourcen. Diesen Schritt mit einem neuen keyXchange zu verknüpfen
>> macht daher mMn nur Sinn, denn dann muss der Aufwand nur einmal gemacht
>> werden.
>>
>>> - Klar wäre ein allgemeiner Wunsch auch gewesen das Netz weiter zu
>>> dezentralisieren, dies bietet der KeyXchangeV2 eindeutig __NICHT__. 
>> Ich würde mir wünschen, dass wir das weitere dezentralisieren nicht aus
>> dem Auge verlieren. Einige von uns haben das ja auch nicht und haben
>> den von dir oben gezeigten neuen Ansatz erprobt. Das ist ja auch ein
>> großer Fortschritt, der halt leider nur noch nicht in der Breite
>> angekommen ist (und so aktuell vermutlich auch nicht ankommen wird).
>>
>>> 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 :(
>> Ja, das Gefühl habe ich leider auch. Vielleicht sollte man da nicht nur
>> von der technischen Seite, sondern auch mit mehr Aufklärung ran gehen?
>>
>>>  Dabei bieten wir in Franken soviele tolle
>>> Möglichkeiten die andere Communitys nicht haben.
>> Da solltest du mehr Werbung für machen. :)
>>
>>> 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.
>> Ich hoffe Stark, dass du noch mehr Rückmeldung bekommst.
>>
>> Hier nochmal meine Meinung etwas zusammen gefasst:
>> - Wir müssen die dezentralen Gateways in der Stadt weiter vorran
>> bringen
>> - Wir dürfen die Masse dabei nicht auf der Strecke lassen
>> - Die Entwicklung der Hood's ist noch nicht abgeschlossen
>>   der letzte Schritt, die ESSID, fehlt noch
>> - Bisher war geplant die korrekten ESSID's mit dem dezentralen
>> keyXchange in die Hoods zu kriegen
>> - Wenn es eine einfache Bessere Lösung gibt, dann her damit
>> - Der keyXchangeV2 ist eine einfachere, aber keine bessere Lösung
>> - Mit dem Ressourcen Problem hast du leider Recht
>>
>> Ich würde mir wünschen, wenn man vielleicht den keyXchangeV2 als
>> Zwischenschritt bis zum dezKeyXchange einbauen könnte, aber so, dass er
>> technisch keine Alternative sondern ein erster Schritt ist. Wenn das
>> Config-AP beim keyXchangeV2 so gebaut werden würde, dass es beim
>> dezKeyXchange 1:1 nutzbar wäre, wäre das ein Traum.
>>
>> Tim
>>
>>> mfg
>>>
>>> Christian
>>>
>>> _______________________________________________
>>> franken mailing list
>>> franken at freifunk.net
>>> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
>>>
>>>
>>> _______________________________________________
>>> franken mailing list
>>> franken at freifunk.net
>>> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> 
> 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> 	Virenfrei. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> 
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> 
> _______________________________________________
> franken mailing list
> franken at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> 

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.freifunk.net/mailman/private/franken-freifunk.net/attachments/20170826/9d0b6501/attachment.sig>