Die Software ist alles anderes als vollständig und bisher nur für grobe Tests geeignet. Sie kann jedoch schon:
eine Subnetz zwischen verschiedenen Instanzen aufteilen
Konflikte bei Netsplits/joins erkennen und auflösen
IPs und Leases an Clients verteilen und verwalten
Zum Ausprobieren passt man config.py seinen Vorstellungen an (bitte keine Supportanfragen, wie man das genau macht. Das wird noch einfacher, aber im Moment muss man alles manuell einstellen.). Das hier kann helfen offene Fragen zu beantworten: Packet types · GitHub
Starten tut man es (als root, wegen Port 68) mit sudo ./pyddhcpd.py.
Ich (bzw. auch einige Gluonentwickler und Nutzer) wollen DHCP nicht auf wenige Server zentralisieren sondern die IPs direkt von den Knoten an die Clients vergeben lassen. Dazu ist es nötig, ein IPv4 Subnetz auf die Knoten aufzuteilen, damit es keine Konflikte gibt. pyddhcpd ist der Proof-of-Concept für ein in den letzten zwei Jahren erarbeitetes Konzept. Sobald der gut läuft, wird ein dazu kompatibler Server in C geschrieben, der dann auf den Knoten selber laufen kann. Das Projekt ist völlig unabhängig von Gluon und kann (hoffentlich!) auch in OLSR Netzen sinnvoll eingesetzt werden.
Hauptsache ihr schließt die räumlich nebeneinander stehenden Router zusammen jeweils bestehend aus 1 DHCP Server und daneben stehenden DHCP Forwardern. Ansonsten bekommt ihr Probleme mit dem Roaming von Clients wie z.B. Adressüberschneidungen wenn sie sich von einem zum anderem Router bewegen, da dann iin der Regel keine neue IP gezogen wird. Es sollte entweder einen Automatismus geben, der das z.B. aus Alfred ableitet oder in der Config Oberfläche eine Option für Forwarder und Server geben.
@christian1980nrw Das ist genau der Anwendungsfall für den ddhcp konzipiert wurde. Roamende Clients behalten ihre IP und Konflikte werden vermieden oder schnell aufgelöst. Das funktioniert auch schon fast. Den dazu noch fehlenden Code implementiere ich morgen.
@yayachiken Ja, das geplante OpenWrt Paket soll auch von Gluon verwendet werden.
Mir bereitet die Kommunikation zwischen den Servern Kopfzerbrechen.
Wie soetwas mit UDP passiert sehen wir beim Alfred.
In einem Netz „an der Saturationsgrenze“ (egal wo nun der viele Traffic herkommt, könnte ja auch mal echte Nutzlast von vielen Clients sein, Festival-Szenario…) besteht die Gefahr Netsplits (als false-positive), einfach weil niemand das Announce/Claim gehört hat.
Man wird also alles doppelt und dreifach broadcasten wollen.
Und trotzdem noch periodisch retransmitten… was dann auch für Traffic sorgt wenn das zu viele Nodes machen.
Vielleicht wird man dann um eine Hierachie von selbsternannten Supernodes in der Wolke (die mit der größten Uptime, dem besten Netz) nicht herumkommen, die dann mit den normalen Nodes per TCP kommunizieren. (nur so als Vorschlag, um den Broadcast-Traffic zu reduzieren und die Zuverlässigkeit zu erhöhen.)
Gut finde ich das Konzept (wenn ich’s richtig verstanden habe), bei mangel an Leases die neuen AP-Clients ein lokales RFC1918er per NAT zu sperren. (wieder: Festival-Szenario)
Die Claims sollten später sowieso für länger gelten (Tage bis Wochen), so dass auch ein temporärer Netsplit nicht zu split-brain führt.
Der einzig riskante Vorgang ist das Inbesitznehmen eines Blockes, von dem man glaubt er sei frei. Dort sind aktuell bereits drei Broadcasts im Abstand einiger Sekunden vorgesehen um sicherzugehen, dass ihn aktuell niemand belegt.
Alfred’s UDP Probleme sind anders gelagert und werden hierbei nicht so auftreten. Die Pakete werden bewusst klein gehalten, so dass sie auf jeden Fall in einen Frame passen.
@tcatm das hört sich doch gut an.
Wichtig wäre dann auch noch bei lokalem DHCP, sobald kein Netz mehr da ist die SSID umzubenennen oder abzuschalten, damit sich die Smartphones dann wieder vom Accesspoint lösen und 3G verwenden.
@christian1980nrw Die SSID hat nichts mit DHCP zu tun. Smartphones sind mitlerweile intelligent genug 3G und WLAN gleichzeitig, je nach Verfügbarkeit, gerne auch für IPv6 und IPv4 unterschiedlich, zu verwenden. Alles weitere aber bitte außerhalb dieses Threads.
Frage: Wenn das ein reiner Mesh-Knoten ist und er gerade keine Verbindung zum Netz hat. Vergibt er dann trotzdem IPs? Denn dann hängt der Client in der Luft. Bisher bekommt er einfach keine IP und kann sich nicht anmelden.
Jetzt driften wir ja doch ab… erstmal geht es nur darum überhaupt IPs ohne zentrale Vergabestelle zu verteilen. Sobald die Funktion in Gluon verfügbar wird (optional, damit die Abwärtskompatibelität erhalten bleibt), wird es allerdings so laufen, dass Knoten auch ohne jegliche Nachbarn bereits IPs an Clients verteilen um diesen die Kommunikation untereinander zu ermöglichen. Eines der Designziele hinter Gluon ist es, dass ein Einzelknoten bereits ein möglichst nützliches Netz bereitstellt und zusätzliche Knoten es nur erweitern. Dazu gehören IP Adressen und später nach Möglichkeit auch DNS Auflösung.
Ich werde wenn ich die Zeit finde (vielleicht schon morgen) das manuell auf Server und Knoten im lokalen Mesh (5 in der Zahl) aufsetzen. Dann sehen wir ja was es hergibt.
Sorry, das sollte nicht arrogant rüberkommen. Ich hab da nur drei unvollendete Gedanken gelesen, die sich eigentlich durch Lesen des im Eingangspost verlinkten Gists klären sollten. Was ist deine Frage?
Was genau meinst du mit Fragmentierung und was mit „globalen Layer2“? Das zu verteilende Prefix wird in kleinen Blöcken zu aktuell je 4 IPs verwaltet. Wie die Blöcke auf die DHCP Server verteilt sind, ist dabei unerheblich. Selbst ein /16 wird bei der späteren C Implementierung weit unter einem Megabyte RAM belegen.
Die DHCP Server selber sollen eine zu starke Fragmentierung ihrer Blöcke vermeiden indem sie Leases mit ähnlichen Timeouts in einem Block verwalten. Blöcke können auch zwischen Servern verschoben werden (wenn z.B. der einzige Client den Server wechselt). Außerdem wird davon ausgegangen, dass das Prefix nie vollständig belegt wird sondern immer etwas Luft bleibt.
