Nebeneinander von geographisch überlappenden Communities

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 :wink:

Harry

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

Wie sieht eure Ad-Hoc SSID aus?

Grüße
Johannes

3 „Gefällt mir“

In der Domäne Ruhrgebiet sieht es so aus:
Mesh24-ESSID wifimesh-ruhrgebiet
Mesh5-ESSID wifimesh-ruhrgebiet5

https://wiki.freifunk-rheinland.net/Ruhrgebiet

Ich habe 18 Beiträge in ein neues Thema verschoben: Nutzung von SSID / ad-hoc zur Lokalisierung

1 „Gefällt mir“

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 Layer2 und vergibt dann erst die für die Layer3 Konnektivität erforderlichen IP-Adressen, wäre sonst auch ein Teufelskreis :wink:

„DHCP ist Layer2“ Bitte?!

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.

Hallo,

DHCP ist Layer 7 (OSI Application Layer) (http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol).

Gruß Jörg

Ein Sonderfall, da als Service Application eben noch vor der Adressvergabe - für die er zuständig ist - unterwegs sein muss…

Aber es ging ja auch vielmehr um das was passiert, und das ist:

  • Client verliert direktes Nutzungsrecht, durch Zeitablauf, durch Reboot, durch Link-Down
  • Client ist wieder verbunden und sendet einen DHCPREQUEST
  • Server antwortet mit DHCPNAK, gefolgt von DHCPOFFER
  • Client sendet DHCPREQUEST mit der neu geofferten IP
  • Server sendet DHCPACK
  • Client macht ein reconfigure und ist mit der neuen IP und sonstigen Parametern per IP im Netz verbunden
1 „Gefällt mir“

Versuchsaufbau:

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?

1 „Gefällt mir“

Ack, mein Fehler. Jedenfalls meilenweit weg von Layer-2, das war die intendierte Aussage :wink:

Danke Paulo!

„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.

Bei den teils nahe beieinanderliegenden Domains des FFRL sollte dies ggf. zum Nachdenken führen: aaaa](https://forum.freifunk.net/uploads/default/_optimized/6bf/e25/286e7b9ff3_622x500.png)

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.

1 „Gefällt mir“

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 ...)

»… mache mir die Welt, … wie sie mir gefällt.« :frowning:

Wie war das mit den Äpfeln und den Birnen? :wink:

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.

Dem kann ich nicht folgen was die SSID mit der Funktion der Kollisionsdomäne zu tun haben soll?