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“
Das ist natürlich ein hartes Argument. Zwar auch dafür meinen Vorschlag erstmal nicht umzusetzen, aber noch viel mehr dafür dass die OS Hersteller mal anfangen in das nächste Zeitalter abzutauchen.
Das Problem ist wirklich, dass Endgeräte IPv4 „wollen“. Android kann zwar ganz gut IPv6 only ab 5.0 und iOS soll’s auch hinbekommen, aber viele Linuxdistributionen und andere Betriebssysteme kommen damit noch nicht klar. Langfristig wäre das aber wohl ein guter Plan für Freifunk. „Der Plan“ sieht ja ohnehin vor IPv4 mittelfristig im Mesh in IPv6 zu verpacken und darüber zu routen.
Solange die Mobil Betriebssysteme IPv6 nur als optional ansehen, quasi als Nice to Have neben IPv4, wird sich das so schnell nicht ändern. Denn in den meisten Mobilfunk Netzen wird ja immer noch IPv4 only gesprochen via CGN. Ich sehe auch noch nicht das dieses sich so schnell ändern wird, solange ein Großteil des Internets noch IPv4 spricht.
1 „Gefällt mir“
#Ich denke dieses Projekt ist im Moment das wichtigste für gluon
Ein Server für verteiltes DHCP in unserer Firmware auf jedem Router würde Freifunk erst zu dem machen, was es eigentlich sein soll: ein unabhängiges dezentrales autarkes Netz
Deshalb sollten wir möglichst bald diesen Dienst in ein C Paket konvertieren, das wir in gluon einbinden können.
Wer kann das machen? Ev sollten wir dafür eine bountysource aussetzen.
5 „Gefällt mir“
Sind wir denn schon so weit? Ich meine… Sind wir aus der Experimentier-Phase denn schon raus?
Ich sehe da den letzten Commit vor 3 Monaten.
Jedenfalls bringts ja nichts irgendwas in C zu bauen, was im Experimentierbaukasten namens „Python“ noch nicht richtig tut.
Oder hab ich hier ein ganz großes Heureka von @tcatm verpasst?
Wie angekündigt: Spätestens Ende Oktober sitzt jemand dran. Dann bin ich nämlich mit dem Studium fertig und überbrücke eine Lücke im Lebenslauf 
Ich sitz da natürlich nicht wie eine Glucke drauf 
falls vorher jemand was tun möchte, soll er das auf jeden Fall bitte tun!
Ich denke, das ist nur das zweitwichtigste Projekt.
Wichtiger ist, dass Batman durch Babel ersetzt wird und da arbeitet tcatm derzeit dran.
3 „Gefällt mir“
Batman_adv komplett ersetzen, oder nur zu den Gateways hin, quasi die angedachte Hybrid Lösung?
Komplett. Übergangsweise als Hybrid und dann weg damit ;). So hab ich tcatm zumindest verstanden.
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?