Ist nicht kompliziert. Passende Firmware auf Router installieren und Einstellungen im Configmod setzen. Router ans Internet hängen und fertig ;-). Was der Router macht, kann man dann hier sehen.
1 „Gefällt mir“
danke, genau das interessiert mich. Ich bin selber SuperNode Admin und will mal schauen, was das hier kann. Das meinte ich mit einlesen.
Gruß
Chrisno
1 „Gefällt mir“
Das sind allerdings nur Standard Infos. Wie es mit dem DHCP klappt, kann man wohl nur im GW-Log richtig sehen. Oder halt auf deinem Knoten.
2 „Gefällt mir“
Gibts denn schon Erfahrungswerte, wie zuverlässig die Sandboxdomäne ist?
Ich hab hier zwei „Produktiv“-Knoten, die ich umflashen könnte, wo so meistens mindestens 5-10 Clients online sind. Würde ich aber nicht machen, wenn die Sandbox 50% oder so Downtime hätte.
Gibts eine Möglichkeit die Sandbox Domain als Uplink zu nehmen und die anderen 841er meshen mit der SB Box? (Router ausserhalb meines einflusses) Die Sandkasten Domain hat für mich einen wesentlichen höheren Down / Upstream, und alle meine Geräte erhalten eine IP per DHCP was in der produktiv Domäne nicht immer der Fall ist.
Nein, das geht leider nicht. Wenn du Mesh-Partner in der Nähe hast würde ich das für keine gute Idee halten, auf Sandbox umzustellen.
Wenn du einzeln stehst, wäre das Flashen mit Sandbox Firmware eine gute Idee, um tcatm mit dem Testen zu helfen. Der verteile DHCP wird meiner Vermutung nach ein integraler Bestandteil, um kleinere BATMAN-Netze zu haben, und damit die Last auf den Supernodes zu verringern, was hoffentlich zu mehr Bandbreite führt (aber zumindest den Communities viel Geld spart)
1 „Gefällt mir“
Danke für’s Testen. Jetzt ist wirklich etwas mehr los. Soweit ich das sehe funktioniert das Konzept derzeit auch schon ziemlich gut, sodass experimentierfreudige Communities sogar schonmal anfangen könnten den pyddhcpd einzusetzen. Demnächst werde ich noch eine sinnvollere Logginginfrastruktur einbauen und kleinere Verbesserungen einpflegen.
4 „Gefällt mir“
Könnte man das heute schon auf Nodes bringen? Oder bräuchte es dafür erst noch den Überbau mit den lokalen IPv4-NATs in den Wolken?
(ich weiss, dass es in C umgeschrieben werden soll aus performance- und speichergrößen-Gründen. Aber auf etwas kräftigen Routern mit viel Ram und CPU könnte man es ja vielleicht trotzdem lokal versuchen.)
Wie wird das dann eigentlich funktionieren bei Wolken mit einer größeren Menge an Meshvpn-Routern an den Kanten? Wer darf dann dhcp-server spielen und wer nicht? Ist der DHCP-Server dann automatisch auch der Router für alle Clients, denen er IP-Adressen gegeben hat?
Ich weiß nicht wie es mit Python 3.4 auf OpenWrt aussieht (wahrscheinlich schlecht), aber wenn die Voraussetzungen erfüllt sind, kann das auch gerne dort ausprobiert werden.
Für den Einsatz unter Gluon ist geplant die default Routen per RIP im Netz bekannt zu geben und einen der möglichen Router per DHCP an den Client durchzureichen. Code, der so etwas tut, existiert noch nicht. Später sollen dann alle Gluonknoten DHCP Server werden.
Layer3 Routing werden wir danach erproben.
Wenn Interesse besteht, ich kann Dir hier eine kleine Testwolke, die ich mit herüberziehen könnte. Da könnte ich Dir auch „aside“ eine VM Deiner Wahl ins Vlan kleben.
Wenn du eine Testwolke mit in die Sandbox ziehen möchtest: Gerne! Weitere Server möchte ich gerade eher nicht selber administrieren.
Ich habe dann mal 5 weitere Nodes mit hinein gezogen und denke, dass da morgen auch ein paar Clients auftauchen werden.
Ich hab mal angefangen die ffnord-example Test Community mit pyddhcpd auf den gateways anzupassen: GitHub - rubo77/ffnord-example at pyddhcpd
Funktioniert schon mit Debian wheezy VMs als Vagrantboxes. Ich stecke da gerade fest was ich alles in der config.py anpassen muss.
Vielleicht kann mir da jemand ein paar Tipps geben?
in der sandbox geht DHCP aktuell gar nicht, gibt also wohl Probleme mit Server.
bekomm auch keine IPv4 oder IPv6
Im Chat wurde gerade geschrieben, dass die DHCP-Server gerade offline sind.
Ich habe auf den beiden Nodes die scripte dann mal neu gestartet.
Wäre natürlich toll, wenn die Reboot-fest wären.
Der pyddhcpd läuft nun testweise im Lübecker Mesh (und auch wieder in der Sandbox). Dabei habe ich noch einige Bugs behoben und Support für das Senden von Unicastpaketen eingebaut. Letzteres war nötig, da ansonsten alle Antworten per Broadcast im Mesh verteilt wurden.
Skripte für das automatische Starten in der Sandbox kann ich bauen, sobald jemand die Sandbox auf ein aktuell Debian mit systemd aktualisiert hat – oder jemand anderes schreibt Initskripte, die /root/pyddhcpd/pyddhcpd.py starten und die Logs (stdout) sinnvoll verfügbar machen.
2 „Gefällt mir“
Selbst auf die Gefahr hin hier beschmunzelt zu werden, aber wäre es für Freifunk nicht eine Alternative IPv6 only zu machen und dann für die Legacy Verbindungen NAT64 zu nutzen?
Also ich rechne fest damit, dass in ein paar Jahren der Großteil des Internet IPv6 kompatibel sein wird. Alles andere wäre Madness.
3 „Gefällt mir“
Das Problem ist das aktuelle Endgeräte IPv4 voraus setzen. Gerade eben mal getestet bei mir im LAN. DHCPv4 am Router deaktiviert. Public IPv6 von Kabel Deutschland liegt im LAN an.
Android: Versucht die ganze Zeit eine IP Adresse abzurufen und switcht dann wieder ins Freifunk WLAN um.
iPhone: Verbindet sich, aber selbst IPv6 Seiten lassen sich dann nicht öffnen. Nach etwas Wartezeit wird dann zurück auf 3G umgeschaltet und die Seite wird geladen.
1 „Gefällt mir“