Ich kann diesen ganzen Quatsch mit der SSID-Erweiterung um Regionen nicht nachvollziehen!
Wenn ich in Wuppertal bin, dann weis ich das i.d.R. auch ohne aufs Smartphone zu schauen, und brauch sicher nicht die Bestätigung über die SSID.
Als Gast in einer Stadt ist es mir auch völlig egal, wer dort das Netz betreibt, und ich hab auch besseres zu tun, als überall zuerst mal nachzuschauen, ob ich irgendwo eine Freifunk-ähnliche SSID finde!
Mir kommt das eher so vor, als ginge es hier darum das Ego einiger Leute zu streicheln, die dann behaupten können:
„Schau mal: diese Firmware hab ich selbst compiliert!“
Auf jeder FF-Webseite steht sinngemäß ganz oben
„Freies WLAN für Alle“
Wenn das unser Anpruch ist, dann bitte auch so benutzerfreundlich wie möglich und unterschiedliche SSIDs bewirken das genaue Gegenteil.
Ich verstehe auch diesen ganzen drang zu Ripe usw nicht und könnte daher genauso behaupten dass machen manche nur wegen ihrem Ego. So eine Argumentation führt zu nix und trollt andere Menschen nur. Also komm mir nicht auf die Tour und pass bissl auf deine Worte auf ;).
Sehe ich als valides Argument! Dann wäre die Unterscheidbarkeit gegeben und dennoch der erwähnte Benutzervorteil da. Werde ich mal in unsere Runde einkippen. Danke für den Ansatz!
Sorry, aber ich laß mir nicht meine Meinung verbieten, und ich mein das ganz genauso wie ich das geschrieben habe, und habe niemand persönlich angegriffen,
Wenn du dich damit angesprochen fühlst, und dir das nicht gefällt - so what
Also @CHRIS es sieht so aus als würden wir bei den nächsten Updates auch auf „Freifunk“ umrollen und und dann die Ad-Hoc local branden. Endgültig ist die Besprechung da noch nicht durch, denke das kommt auch bei uns
DHCP ist aber Layer-3, und muß daher nicht zwingend etwas von Änderungen auf darunterliegenden Schichten mitbekommen. ESSID „foo“ bedeutet eben, AFAIR, daß dies ein zusammengehöriges (Funk-) Netz „foo“ ist, alle APs von „foo“ also in einem Layer-2-Netz hängen. Und mithin ist keine Layer-3-Aktivität notwendig. Und eben deshalb wäre es relativ blöd, eine [E]SSID „foo“ für völlig unterschiedliche APs zu verwenden. DHCP dürfte allein vom Timeout getriggert agieren, da die Netzwerkschicht ja von identischem Netz ausgeht. Bei direktem Übergang würden die Clients also trotz vorhandenem Netz offline sein, da sie ihr (Layer-3-) IPv4-Default-Gateway nicht mehr erreichen können (IPv6 ist wieder andere Baustelle); Nichterreichbarkeit des IPv4-GWs ist aber kein Trigger für DHCP.
Jemand sprach im Verlauf des Threads von „zumindest bei uns im Verein“, darauf zielte ich ab. Effektiv haben wir für GT uns an http://wiki.freifunk.net/ESSID.freifunk.net und den existierenden Nachbarn orientiert, und, wie dargelegt, sehe ich nicht, daß heute „Freifunk“ als ESSID eine valide globale Alternatative darstellen würde. Konkret würde ich, da eben nicht als homogene Wolke organisiert, auch innerhalb des Rheinland e. V. davon abraten, sofern nicht sichergestellt ist, daß ein Client binnen des DHCP-Lease-Timeouts keinesfalls zwei unterschiedliche FFRL-Domänen erreichen kann. IMHO, YMMV.
DHCP ist ein auf IP aufsetzender Dienst, ob Du da als Layer-2 Ethernet oder eben Brieftauben nimmst, ist irrelevant. Solange das Interface nicht down geht, und bei einem reinen Zellwechsel bei Funkzellen mit identischer ESSID tut es das AFAIR nicht, arbeitet DHCP nur auf Basis des Leasetimeouts.
Zutaten: 1 x Laptop, 2 x Freiffunk-Router mit identischer SSID (In diesem Fall via mesh verbunden). 1 x IPv4 mit Konfiguration via DHCP.
Durchführung: Laptop mit Freifunk-Router A verbinden (wlan0). Es wird eine IP-Adresse zugewiesen. Ping starten und laufen lassen. Sich von Router A entfernen. Wenn man in die richtige Richtung geht, dann wechselt der Laptop irgendwann zu Router B. Dabei wird kein DHCP Verkehr auf den Wlan gesehen. Ping läuft ohne Verlust durch.
Fazit: wenn Router A und Router B den Laptop in verschiedene Layer3 Netzwerke leitet, dann müssen Router A und B auch verschiedene SSIDs anbieten, wenn Client vernünftig roamen können soll, da der Wechsel der Zelle nicht zu einer neuen Anfrage am DHCP-Server führt.
Dass die beiden Router via mesh verbunden sind, sollte unerheblich sein, da der Client davon nichts wissen kann. Ein solches Szenario kann vorkommen, wenn zwei Router unterschiedlicher Domänen in Reichweite zueinander stehen.
Wo liegt jetzt der Fehler? In der Wahl der SSID, oder in der Entscheidung zwei verschiedene (kooperierende) Domains in unmittelbarer Umgebung zu betreiben?
„wenn Client vernünftig roamen können soll“ - IMHO ist das kein „Roaming“. Was wir in Gluon-Netzen normalerweise sehen sind Handover, „Roaming“ kann WLAN von Haus aus IMHO nicht. Mobile-IP(v6) wäre da ggf. ein Kandidat, aber mehr, als man selbst beim Mobilfunk bekommt.
Ein Fehler wäre es, innerhalb des DHCP-Timeouts von „Heimatdomain“ eine inkompatible (lies: andere Supernodes oder IP-Ranges oder NAT-Gateways) Infrastruktur unter der gleichen [E]SSID anzupreisen. Dies bedeutete für einen hinüberwechselnden Client daß er offline wäre bis zum Ablauf der DHCP-Lease.
Ob nun welches OSI layer oder wie auch immer, mir kommt das ein wenig wie Begriffsklauberei vor.
Aber vielleicht bin ich dazu dann doch zu wenig Techniker.
Was das Handover anbelangt: Ich hatte mir gemerkt: Wenn die SSID identisch ist, die ESSID aber unterschiedlich, dann sendet der Client doch einen DHCP-Request ab, nur bei ESSID auf „ANY“ lässt er das sein.
Aber das mag veraltet sein inzwischen.
Falls wir wirklich ein Problem mit mindestens einem Teil der RealWorld-Clients haben sollen in unserem Setup, dann sollten wir die Lease-Time vielleicht auf Werte von 60s (oder geringer) reduzieren, damit „Clients in Bewegung“ zumindest nicht ewig ohne funktionsfähiges Netz bleiben.
Spannend, kaum kommen technische Themen contra eine SSID auf, sind diese auch wieder nicht so richtig wichtig …
Was das Handover anbelangt: Ich hatte mir gemerkt: Wenn die SSID identisch ist, die ESSID aber unterschiedlich, dann sendet der Client doch einen DHCP-Request ab, nur bei ESSID auf "ANY" lässt er das sein.
*kopfkratz* Alleine das "ANY" irritiert mich, woanders steht "" oder "*" als Mittel, eine LISTE von SSIDs zu bekommen, mit der konkreten Verbindung hat das aber nix zu tun, die ist immer mit/gegen einen konkreten Namen. (Und AFAIK ist ESSID == SSID. BSSID ist was anderes.)
Falls wir wirklich ein Problem mit mindestens einem Teil der RealWorld-Clients haben sollen in unserem Setup, dann sollten wir die Lease-Time vielleicht auf Werte von 60s (oder geringer) reduzieren, damit "Clients in Bewegung" zumindest nicht ewig ohne funktionsfähiges Netz bleiben.
Jau. Logischer Schritt; anstelle anzuerkennen, daß "one SSID fits them all" vielleicht doch einfach verfrüht ist, die Clients dazu bringen, alle 30 Sekunden (Leasetime/2) nach einer neuen Lease zu fragen. Zwar brechen noch immer alle bestehenden Verbindungen ab, aber dann halt schon nach 30 Sekunden. (Wohingegen sie bei unterschiedlichen SSIDs vom Gerät auf Teufel komm raus zu halten versucht würden, denn dem Gerät wäre ja klar, daß der Wechsel von a.ss.id zu b.ss.id fatal wäre ...)
So schnell bist Du doch gar nicht in der Lage Dich zwischen Kollisionsdomänen hin und her zu bewegen, zumal der Link Down beim Wechsel zwischen den Access Points ein DEHCPREQUEST auf das alte Lease auslöst, der dann die oben bereits angegebene Kette auslöst.
Wie Paulo zeigte, sobald Deine Prämisse nicht mehr zutrifft – und für Rheinland mit seinen direkt aneinandergrenzenden Domänen sehe ich nicht, wie das dauerhaft sichergestellt wurde –, hast Du das Problem, daß Clients behindert werden. Und da ich erwarte, daß die Gebiete der Kollisionsdomänen (lies: der Layer-2-Meshes) in Zukunft geographisch kleiner und heute zusammenhängende Gebilde gesplittet werden, macht schon eine einheitliche SSID pro Community nicht zwingend Sinn.
Mal gucken, ob/wann Hamburg und Paderborn an entsprechende Grenzen stoßen; Du sebst hast in #6 noch technische Gründe angesprochen, die gegen beliebig große Layer-2-Wolken sprechen. Jede Layer-2-Wolke benötigt aber für saubere Funktion eine eigene SSID, damit DHCP (und NAT) richtig funktioniert – oder es bedarf einer freifunklosen Pufferzone zwischen den fälschlicherweise identischen SSIDs.
Jedenfalls gibt es also technische Gründe, die ganz klar dafür sprechen, mindestens jeder technischen Infrastruktur (DHCP-Pool, NAT-Gateway/„Supernode“-Gruppe) eine eigene SSID zu spendieren und keinesfalls verschiedene Infrastrukturen unter der gleichen SSID anzupreisen.