[Freifunk Franken] zentraler oder dezentraler KeyXchange?

Fr Aug 25 12:01:44 CEST 2017

Hallo,

wie ist die Längenbegrenzung für SSIDs? Ich fände es nämlich schön, das dann
als "Subdomains" von franken.freifunk.net zu machen,

also bamberg.franken.freifunk.net statt bamberg.freifunk.net?

Die jetzigen Mini-Hoods sind ja glaube ich ohne franken, also
hugo.franken.net?

Grüße

Adrian

> -----Original Message-----
> From: franken [mailto:franken-bounces at freifunk.net] On Behalf Of
> Christian Dresel
> Sent: Freitag, 25. August 2017 11:52
> To: Steffen Winkler <freifunk at steffen-winkler.de>; Freifunk Franken
> <franken at freifunk.net>
> Subject: Re: [Freifunk Franken] zentraler oder dezentraler KeyXchange?
> 
> Hi Steffen
> 
> > Steffen Winkler <freifunk at steffen-winkler.de> hat am 25. August 2017
> > um 07:54
> > geschrieben:
> >
> > Hallo zusammen,
> >
> > unterschiedliche SSID's ist nicht benutzerfreundlich,
> 
> auch wenn es auf den ersten Blick nicht Benutzerfreundlich ist, ist es
sowohl
> technisch absolut korrekt wie auch auf den 2. Blick viel
benutzerfreundlicher
> 
> > vor allem dann nicht, wenn die Hoods immer kleiner werden.
> 
> nämlich genau aus diesen Grund. Irgendwann kann und wird es auch
> passieren, das auf einen Platz X in der Stadt sowohl Hood A wie auch Hood
B
> auf dem Handy sichtbar ist. Wenn nun beide die gleiche SSID haben, loggt
> sich dein Handy z.b.
> in Hood A ein, bezieht von dort eine IP aus der Hood A, dann läufst du
50cm
> weiter, auf einmal ist der AP von Hood B deutlich stärker, dein Handy
loggt
> sich um behält aber die IP von Hood A da es durch die gleiche SSID "denkt"
> das es im gleichen Layer 2 Netz ist, dies ist aber nicht mehr der Fall und
dein
> Netz wird kaputt gehen am Handy, im günstigen Fall fragt es dann erneut
> den DHCP Server an bekommt eine richtige IP... aber wenn dann Hood A
> wieder stärker wird... man hat mit verschiedene SSIDs einfach die viel
> bessere, manuelle Kontrolle am Endgerät.
> Ich glaub es gibt auch irgendwo ein RFC wo drinnen steht, das verschiedene
> L2 Netze verschiedene SSIDs haben sollen(/müssen?), ich finde es gerade
> nicht, wer es kennt bitte mal Link posten.
> 
> Das ganze wurde schon recht häufig diskutiert und wird auf kurz oder lang
> auf jeden Fall kommen.
> 
> > Das hieße, wenn ich nach Ebermannstadt fahre, habe ich kein Netz mehr,
> > ohne aktiv zu werden. Für BATMAN wäre das egal, wenn jedes anders
> heißen würde.
> 
> du loggst sich 1x in Ebermannstadt ein, dein Handy speichert die SSID und
> nimmt absofort dann immer Ebermannstadt. Ich hab mittlerweile mehrere
> dutzend Freifunk SSIDs im Handy und das coole bei Android ist sogar,
Google
> passt sogar auf meine SSIDs auf, wenn ich ein neues Handy bekomme
> werden alle SSIDs auf wundersame weise wieder am Handy angelegt... echt
> cool ;) ;) Ich vermute mal das Apple genausogut auf unsere Daten aufpasst
;)
> Und wenn nicht muss man es halt selbst tun.
> 
> mfg
> 
> Christian
> 
> >
> > Grüße von Steffen Winkler.
> >
> > Am 20.08.2017 um 16:21 schrieb robert:
> > > 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
> > >
> > > _______________________________________________
> > > 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
> _______________________________________________
> franken mailing list
> franken at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net