Es gibt (vorwiegend) ältere Protokolle und Dienste, die mit wechselnden IP-Adressen des Endgerätes nicht so richtig zurechtkommen.
Stelle Dir vor, Du hast an zwei verschiedenen Fenstern der Wohnung je einen Freifunk-Router und Dein Handy bekommt bei jedem Gang durch die Wohnung eine neue IP-Adresse.
Und dann logt sich das Ding beim Mumble-Server, beim IRC-Server etc neu an.
Ach ja, größere Mailversendungen oder Podcast-Downloads müssen auch mindestens resumen oder gar neu von Beginn starten.
(Ja, ich kenne die Workarounds, bitte erklärt sie mir nicht. Ich erläutere lediglich, was das Problem beim Roamen sein kann.)
Mit Verlaub, was Du beschreibst ist weder Roaming noch Handover; »Roaming« ist sowieso das falsche Etikett.
Wenn Du innerhalb eines ESS Dich bewegst, durchquerst Du die Funkzonen mehrerer APs, die aber eine Einheit bilden. Das ist eben der Unterschied zwischen dem Eine-SSID-Ansatz von batman- vs. dem Multi-SSID-Ansatz von OLSR-Netzen. (Ja, es ist nicht schwarz/weiß.)
@lemoer Der Punkt ist: in einem (simullierten) L2-Netz (wie bei Gluon), wo alle APs die gleiche SSID ausstrahlen, muß auch die Adressvergabe „koordiniert“ erfolgen, sprich: jegliche bezogene Konfiguration muß über jeden AP funktionieren. Daher startete Gluon mit zentralem DHCPv4. (Und bereitet bei v6 den Admins Kopfschmerzen.)
Der L2-Ansatz hat seine Grenzen, um aber auf L3, Routing, zu gehen, müßte man sicherstellen, daß die von APx bezogene IPv4-Konfiguration (IP-Adresse, Netzmaske, Gateway) auch auf APy funktional ist, ferner müßten die Routinginformationen im Netz verbreitet werden. (batman-Netze erschlagen das alles durch ein simuliertes L2-Netz.) Oder man gibt „gegend.meine.ssid“ auf und lebt mit „ap###.gegend.meine.ssid“ (mit ### als AP-Nummer). Twitter & Co. laufen mit dem Ansatz auch, Dein Live-Radiostream wahrscheinlich eher nicht (mit jedem AP, der ggf. vorher uch einmal vom Nutzer „freigeschaltet“ werden muß (durch aktive Auswahl), wechselt Deine IP-Konfiguration, ergo brechen alle Verbindungen wg. neuer IP(v4)-Adresse ab).
Ich beschreibe (eines) der Probleme mit mehreren DHCP-Servern in einer Wolke mit mehreren Uplinks.
Aber wenn es Dir besser passt, dann hätte ich dem Fragenden auch antworten können:
„Roaming ist nicht Dein Problem, bitte Stelle die Frage richtig“.
Und ja, es gibt mehrere Probleme, die man mit diversen Workaround teilweise in Schach halten kann.
Aber perfekt natürlich nicht. Wie Du schon schriebst, Du möchtest keinen verteilten DHCP-Server, da es immer timeout-Probleme bei schnellen Bewegungen im Netz geben wird und einem daher die TCP-Sessions noch eher abreissen werden also es „mit EINEM zentralen DHCP-Server“ schon der Fall ist.
@adorfer: Und genau das habe ich nicht verstanden… Wieso sollte die Adresse dabei wechseln müssen?
Meine Annahmen waren:
- Wir befinden uns immer noch in einem großen L2-batman-Netz.
- Der Client bekommt bei Router A ein Lease.
- Der Client „handovert“ oder „roamt“ von Router A zu Router B.
- Das Lease, das er (bei Router A) bekommen hat, ist weiter gültig und funktioniert auch (da gleiches L2-Netz).
- Das Lease läuft irgendwann aus.
- Der Client will es erneuern lassen.
- Der DDHCP Server auf Router B bestätigt die Erneuerung.
- Resultat: Der Client behält die ganze Zeit die gleiche IP.
Übersehe ich dabei etwas?
Gruß,
lemoer
PS: @wusel, ich meine „Handover“ und bin mir auch bewusst, dass „Roaming“ eigentlich der falsche Begriff ist… Da jedoch selbst bei den batman-Entwicklern der falsche Begriff üblich zu sein scheint, wollte ich keine Verwirrung hervorrufen 
Inzwischen ist das meiste gelöst und das letzte Problem sollte hiermit gelöst sein:
und auf dem Gateway:
Wer den ddhcpd schon einsetzt sollte also auf allen gateways diesen branch des mesh-announce installieren, solange das noch nicht gemerged ist: GitHub - TobleMiner/mesh-announce at feature-gw-ipv4-announce
3 „Gefällt mir“
Wir haben heute erfolgreich die erste stable Firmware in Kiel verteilt mit dem ddhcpd.
6 „Gefällt mir“
@tsys hat eine grafana statistik der load erstellt:
anscheinend ist durch den sprung von 2016.2.7 auf 2018.1.x mit ddhcpd ein anstieg der durchschnittlichen last entstanden, nicht klar, wie da der ddhcpd mitspielt, ich schätze, dass die neue firmware 2018.1.x allgemein mehr last erzeugt und ev. der ddhcpd auch sogar den Anstieg gemindert haben könnte. Müsste man mal mit anderen Communities vergleichen, sie da der Versionssprung zum Anstieg der Last geführt hatte.
Der Graph sieht noch richtig harmlos aus. Das kenne ich deutlich schlimmer. Und ja, ohne dhcpd. Daher hier vermutlich kein Thema.
der ddhcpd läuft ja seitdem ganz gut bei uns in Kiel.
Falls es mal jemand ausprobieren will in seiner domain ( @anon68922371 ): man muss den mesh-announce auf seinen gateways laufen lassen und die richtigen Parameter setzen, steht alles dort im Readme.
Was noch wichtig ist, ist das man immer ein dummy interface mit der richtigen mac adresse als erstes in seiner network-config einrichten muss, damit der mesh-announce auch immer die richtige mac sendet. Das sieht bei uns in Kiel so aus im ansible
3 „Gefällt mir“