Vielleicht nicht 100% hier richtig aber ist es geplant einen DNS Cache auf den Routern zu machen (dnsmasq)? Weil meist die pings zu den GW’s ja relativ hoch sind. So sollten Anfragen ins Internet doch schneller sein oder?
Die Router haben schon einen DNS-cache. Man muss ihnen nur per radvd einen IPv6 DNS zuteilen und den Clients die Anycast-Adresse der Router per DHCP mitteilen.
In Freifunk Nord publizierten wir RDNS Einträge auf den Gateways. Das sollte den job tun
@Admin: bitte abtrennen dies ist hier in der tat ein ganz anderes Thema
Bist Du dazu gekommen?
Nope, war mir dann doch zu kompliziert bzw zu groß… 
Cool, da scheint sich ja einiges getan zu haben.
Sind die Entwickler hier im Forum aktiv?
Frage: Ich hätte echt Bock da mal eine Testdomäne aufzusetzen. Wenn ich die Idee richtig verstehe, soll das Ding doch dann auf jedem Knoten oder wenigstens auf jedem mit Uplink laufen, richtig? Wie biegt man dann in Batman die DHCP-Anfragen um, die bisher explizit zum nächsten Gateway geleitet werden?
Sargon erreichst du über #ffki im Hackint oder unter:
Auf dem 33C3 wurde der erste testknoten erfolgreich mit dem ddhcpd bespielt.
Es fehlt noch:
- automatisches Ermitteln im batman netz der IP4 des benutzten Gateways
- die debug messages müssen noch MIPS tauglich gemacht werden
- … @sargon: was noch?
ansonsten verteilt der schon fleissig IP4 adressen an die Clients ohne mit einem Gateway verbunden zu sein.
Dadurch wird das Gluon Freifunk Netz endlich auch auf IP4 dezentral 
10 „Gefällt mir“
Der neueste Stand ist z.z. hier: https://git.toppoint.de/benbe/ddhcpd/
Es fehlt jetzt noch die Funktionalität, dass die Clients zwischen verschiedenen Knoten roamen
https://git.toppoint.de/sargon/gluon-ddhcpd/ ist ein Gluon Paket, in dem allerdings noch nicht der neueste stand-alone c-code eingepflegt ist
1 „Gefällt mir“
Was ist denn das Problem beim roamen?
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“