In eurem wiki beschreibt ihr, dass ihr auf jedem Router eine eigene öffentliche SSID vegebt, die mit „Freifunk Dresden…“ anfängt:
http://wiki.freifunk-dresden.de/index.php/Knoten_Spezifikation
Wäre es nicht sinnvoll auf allen Routern z.b. nur die einheitliche SSID „Freifunk-Dresden.de“ zu verwenden? Damit dann mobile Endgeräte zwischen den Stationen roamen könnten.
eine einheitliche ssid ist nicht möglich, da jeder konten einen eigenen
dhcp server hat und die ips nur für diesen knoten gelten.
ein roaming ist damit nicht möglich, was auch nicht wirklich notwendig
ist.
würde man sich mit einer ip adresse, die von knoten A vergeben wurde
über Knoten B
zugreifen, so ist diese nicht bekannt oder wurde bereits an andere
clients vergeben.
→ ip konflikt.
für situationen, in denen man mehrerer router zusammen schliessen will
und quasi ein
roaming zulassen will, darf es nur einen master-knoten geben, der die ip
adressen vergibt.
diese knoten werden dann zu knoten-gruppen zusammen geschlossen. der
splash-screen und dhcp
und internet traffic geht dann immer über einen master-knoten innerhalb
einer node-group.
aber das ist noch nicht implementiert 
Ebenso gibt es somi die möglichkeit stadteil bezogen oder Event-bezogen,
die
SSID zu gestalten, was das roaming ja sowieso dann verhindert.
wir nutzen in dd bmxd und nicht bmx-advanced. bei glueon wird bmxd-adv
verwendet und dadurch wird ein gigantisch grosser switch realisiert.
diese freifunknetze haben dann 2-3 Server, die dchp für jeden client
verteilen
und als internet gateways arbeiten.
das problem ist, wenn diese drei server ausfallen (wie es in chemnitz
der fall war)
ist das gesamte netz nutzloss. nichtmal interne verbindungen
funktionieren.
der ansatz in dresden ist komplett anders. jeder knoten kann alleine
betrieben werden,
kann kleine subnetze aufspannen und kann als gateway fungieren. es ist
in dd bereits so,
dass wir mehrere solcher gateways haben. würden jetzt alle vserver
ausfallen,
bleiben teilnetze voll funktionstüchtig.
es ist sogar so, dass knoten untereinander backbone verbindungen
aufbauen können und somit
wird das netz sehr stabilisiert.
wir verwenden allerdings nur ipv4. aber ipv6 braucht man in einem
solchen netz garnicht, denn
soviele knoten gibt es nicht und internet datenverkehr kann immer in
ipv6 an den gateways durch
den provider getunnelt werden.
bei glueon ist es so, dass ein gateway solange fest zugeordnet bleibt,
bis sich der client
abmeldet. es erfolgt hier keine auswahl nach leitungsqualität oder
auslastung.
der client stellt seine (bei glueon) dhcp anfrage und der zufällig am
schnellsten antwortende
Server (einer von 3) wird gewählt. egal ob das gateway gut oder schlecht
ist.
Server können nicht einfach nachgerüstet werden, sondern müssen
überschneidende ip bereiche verhindern.
da ist immer organisations aufwand notwendig.
in dd arbeitet jeder vserver identitsch zu jedem freifunk knoten. nur
hat er eine andere spezifikation,
da er kein „hotspot“ darstellt. sonst ist aber alles komplett gleich und
es gibt keine sonderstgellung.
hoffe ich konnte die gründe und unterschiede im netz deutlich machen.
viele grüße
stephan
Dies ist nicht ganz richtig, das Freifunk Netz funktioniert auch bei Gluon weiterhin. Allerdings nur via IPv6, lediglich der Uplink ist nicht mehr vorhanden. Theoretisch kann auch in diesem Fall ein lokaler Gateway aufgesetzt werden und an den Gluon Node angeschlossen werden um der lokalen Wolke als Uplink zu dienen.
Hi, auch wenn ich grade nicht die Intention des Threadstarters begreife ;), ein, zwei Korrekturen bzgl. Gluon.
[quote=„ddmesh, post:2, topic:7025“]
wir nutzen in dd bmxd und nicht bmx-advanced. bei glueon wird bmxd-adv verwendet und dadurch wird ein gigantisch grosser switch realisiert.[/quote]
Ich denke, Ihr setzt in Dresden auf BMX6 (Layer 3), ähnlich wie libre-mesh, Gluon basiert derzeit auf batman_adv (Layer 2).
Jein; die Anzahl der Gateways ist 1-n, typischerweise sollte wenigstens die Hälfte der Gateways laufen, das ist wohl wahr Fallen alle GWs aus, ist die Wolke nur noch ein Haufen lokaler Pfützen um die jeweiligen APs herum … internes Meshing tut weiter, Clients werden aber keine IPv4-Adresse bekommen (DHCP läuft bei batman_adv zentral, ja) und damit die Verbindung verschmähen — obwohl sie weiter (je nach Setup) ULA- oder gar globale IPv6-Adressen zugewiesen bekommen (okay, eigentlich Prefixe für Autoconfig). Gluon ohne zentrales Gateway geht nicht wirklich. Und durch die CPU-Last durch den VPN-Tunnel (fastd) kann ein Gateway auch nur eine begrenzte Anzahl an Knoten bedienen — das Ende von CPU-Zeit markiert den Anfang von grottiger Performance für die Clients …
[quote]
bei glueon ist es so, dass ein gateway solange fest zugeordnet bleibt, bis sich der client abmeldet.[/quote]
Jein, er behält seine IPv4-Config (IP, Default-GW) bis zum Ende der Leasetime, die je Community unterschiedlich kurz gewählt wird. Da Clients sich faktisch nie abmelden, sondern »nur« den abgedeckten Bereich schleichend verlassen, sind hohe Leasetimes kontraproduktiv (binden IPs, ohne daß Clients sie nutzen würden). Zu geringe Leastime wiederum kann trotz funktionalem Roaming zu Verbindungsabbrüchen führen, denn …
… das Gegenteil ist der Fall batman_adv manipuliert optional den DHCPv4-Verkehr (bei Gluon aktiviert), die „Client-sucht-Server“-Broadcasts wandelt batman_adv in Unicasts zum »besten« Gateway lt. batman-Metrik um — es bekommt also nur ein (batman-) Gateway tatsächlich eine DHCP-Anfrage, nicht alle. Da batman_adv von fastd aber nichts weiß und nur nach Packetloss seine Metriken aufbaut, könnte es durchaus sein, daß als DHCP-Server ein Gateway gewählt wird, welches gar nicht das direkt per fastd verbundene ist. Da der DHCP-Server i. d. R. auch sich selbst als Default-Gateway setzt, könnte dies zu unnützem Inter-Gateway-Traffic über’s Mesh führen. (Ich habe aber keine Zahlen oder auch nur ein Gefühl, wie oft dies passiert, oder ggf. auch nicht.)
Auch dies ist genau umgekehrt: alle Gateways eines Meshes müssen im gleichen (Sub-) Netz arbeiten. Die DHCP-Server hingegen müssen unterschiedliche Adressbereiche aus diesem (Sub-) Netz vergeben, damit keine IP doppelt vergeben wird. Weitere Gateways sind insofern kein Problem, sofern man noch ab /23 an Adressen frei hat. Man muß vermeiden, daß Clients keine IPs mehr wegen „no free leases“ bekommen, und jedes GW sollte schon ca. 50% der Clients mit IPs versorgen können. Insofern ist die IP-Planung schon nicht unkritisch, je mehr GWs ich mit lokalen DHCP-Servern habe, desto größer muß der Adressebereich des Meshs sein 
Alternative wäre DHCP-Relay, das probieren wir demnächst aus (dann gibt’s, wie in professionellen Netzen, zwei autoritative DHCP-Server, einer Master, einer Standby, die dann in jedem Fall die IP (und das Gateway) vergeben. Trickreich wird da, das korrekte (lt. batman_adv ja „beste“ und damit hoffenlich näheste) Default-Gateway zurückzugeben (sprich: im Grunde die IP, die den Request weitergeleitet hat).
Fazit aus meiner SIcht:
Der geniale Vorteil an Gluon ist es, daß man einfach Knoten flashen und hinstellen kann: tut, das Netz erweitert sich von alleine, ohne irgendeine Koordination/Konfiguration. Das ist bei gerouteten Netzen AFAIK (noch?) nicht so. Auch libre-mesh bietet mir auf den ersten Blick keine annähernd charmante Lösung; da muß ich vorher wissen, ob ich Teil eines Meshs werde oder Einzelkämpfer nach Dresdener oder Berliner Modell. Der große Nachteil an Gluon ist der „Switch-Overhead“, der in manchen größeren Netzen schon mindestens DSL6000 (=500k Uplink) voraussetzt, um noch Bandbreite für Nutzdaten zu haben … TANSTAAFL
ja, stimmt. Hatte eine Denkfehler.
Muß man sich irgendwie absprechen bezüglich des ip Bereiches, wenn man einen uplink aufbaut? Oder geht die Auswahl eines Präfix automatisch?
Was passiert wenn ein solcher langsamer
Knoten dhcp anfragen für die clients ganz schnell beantwortet, aber der Internettraffic extrem langsam ist?
vg Stephan
Wenn Du einen batman_adv zum Gateway machst, wird dies im Mesh kommuniziert; ein dort laufender lokaler DHCP-Server bekäme dann wohl zumindest aus der näheren Umgebung immer die DHCP-Anfragen, auch wenn die große Wolke sich wieder manifestiert hat. Und ja, die iP-Bereiche müssen leider abgesprochen sein, s. o., sonst gibt’s ggf. doppelt vergebene IPs.
Das finde ich ein sehr wichtiger Ansatz!
Und falls ihr überlegt Euer Netz mal zu upgraden, wäre es vielleicht am besten dann gleich sowas wie den einzubauen:
Also eine dynamische IP-Vergabe die auch in abgeschnittenen kleinen Wolken noch funktioniert
Hi,
danke für die gute Ausführung.
in Dresden nutzen wir bmxd und nicht bmx6 oder bmx-adv.
bmx6 ist zu groß, um noch weitere Tools wie vtund/fastd und weitere eigene Anpassungen in 4mb unter zu bringen.
Ich hatte es vor 1, 5 Jahren getestet, aber es war mit den ganzen Tunneln, die es aufbaut zu instabil. Die Idee fand ich super und man hätte Dienste durch ipv6 Adressen als ein überlagertes Netz adressieren können und es wäre egal wo dieser läuft.
Ich hatte mit Axel direkten Kontakt bezüglich der Fehler. Er hatte eine ganze Liste bekommen und er hat diese Instabilitäten bestätigt. aber er war an anderen Entwicklungen dran, so dass ich nichts mehr von ihm gehört habe.
Daher habe ich aus Speichermangel, der Möglichkeit Routing rules zum verhindern von Umleitungen, dynamische Gateway Auswahl, hna mich für bmxd entschieden.
Leider gibt es absolut keinen Support dafür, da bmx6 als Nachfolger gesehen wird. nur hat es die genannten Nachteile.
In der Zwischenzeit habe ich einige Fehler behoben und bin gerade dabei eine NetworkId einzuführen, damit Netz getrennt bleiben und man ein Netz teilen kann, wenn es zu groß wird. Auf github (ddmesh) ist diese in der Firmware zu finden.
vg Stephan
Freifunk Dresden
möglich ist viel, aber phyton auf Router zu installieren ist bestimmt nicht günstig. zum Schluss hat man zig Interpreter, libs zu installieren, die nur von einem Programm verwendet werden. dann ist es besser auf bestimmte Sachen zu
verzichten und dafür preiswerte Geräte mit wenig Ressourcen nutzbar bleiben.
Bisher hat sich in der Praxis kein wirklicher bedarf ergeben, immer alles coole ein zu bauen. es muss ja auch ausgiebig getestet und gewartet werden.
vg Stephan
Das meinte @tcatm mal
Ah, danke; wieder was gelernt. Muß gestehen, mit bmx* habe ich mich nie wirklich auseinandergesetzt bislang, daß es bmxd, bmx6 und bmx-adv gibt, ist an mir vorbeigegangen 
Die Pythonimplementierung ist wirklich nur ein proof-of-concept. Für die Knoten soll das nochmal ein schön kompaktes (<100kb) C Programm implementiert werden.