Experimenteller Server für verteiltes DHCP

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 :wink:

Ich sitz da natürlich nicht wie eine Glucke drauf :rooster: 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?

Nope, war mir dann doch zu kompliziert bzw zu groß… :frowning:

@sargon sitzt dran: http://git.toppoint.de/sargon/ddhcpd/

2 „Gefällt mir“

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 :wink:

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?