kann jemand mal einen kleinen Abriss machen über babel (was das genau ist, l3roamd??) und evtl auch wie das in zukunft in gluon hereinkommen soll - bzw.was sich in bezug auf batman-adv ändern würde?
hi
ich beobachte das ganze schon ein wenig und kann dir folgendes sagen:
Babel ist ein Layer 3 Routingprotokoll und würde Batman-adv ersetzen. Da aber auf Layer 3 eigentlich kein Roaming möglich wäre (wenn du den AP wechselst, wechselt sich dein IP Bereich, du brauchst eine neue IP → Roaming kaputt) wurde l3roamd entwickelt. Mit l3roamd wird das irgendwie „magisch“ ermöglicht, wie genau kann ich nur raten. Ich vermute das wird in etwa so laufen, das jeder Router die gleiche IPv6 hat. Somit bleibt für den Client das Standartgateway gleich. Damit die Rückroute funktioniert wird wohl l3roamd ins Babelnetz die IPs der Clients announcen, wenn du den AP wechselst, bleibt deine GatewayIP gleich zeigt aber auf nen anderen Router, dieser Router „erkennt“ dich und announced deine IP ins Babelnetz damit die Rückroute dann über diesen Router funktioniert.
Meine ganz persönliche Meinung dazu:
Ich glaube das skaliert zwar eine Ecke besser als Batman aber bei ein paar 1000 Clients und 4 stelligen Routerzahlen wirds auch da Probleme geben (jeder Router und jeder Client wird einzeln in das System announced… puuuhhhh). Dazu kommt das in diesem System IPv4 nicht vorgesehen ist (meine armen NodeMCUs / ESP8266 
). IPv4 Server können wohl nur über NAT64 o.ä. Systeme erreicht werden.
Ich werde die Entwicklung weiter beobachten und bin sehr gespannt wie es ausgehen wird, werde aber nicht auf den Zug aufspringen, wir/ich hab(en) andere Pläne.
mfg
Christian
2 „Gefällt mir“
Unabhängig von der Skalierung, ändern sich die Tools, mit denen man arbeiten würde: Statt dubiosen Batman-Tools kann man dann wieder normale Pings, traceroutes und mtrs einsetzen, weil es normales Layer-3 ist.
Bzw. Skalierung denke ich, dass es langfristig dahin geht, dass man nur noch in lokalen Wolken roamen können wird. Nicht mehr von einem Ende der Stand zum anderen, was in der Praxis auch wenig Relevanz hat.
Grüße
Matthias
hi
naja die Batmantools funktionieren schon sehr gut. Das Problem wird, wenn es mehrere 100 Nodes gibt, dass dann ein batctl o einfach NIEMAND mehr freiwillig auseinander friemelt 
In meinen lokalen Wolken mit 4-10 Router macht Batman genau das was es soll und sogar richtig richtig gut und das obwohl noch das alte 2013.4 im EInsatz ist, da es aber Miniwolken sind, ist ein Update eigentlich kein Problem ich muss es nur mal wollen
Zum rest geb ich dir recht. Roaming durch die Stadt brauch (ich) nicht. Batmanwolken pro aufenthaltsbereich/Strassenzug und das ganze per L3 verbinden. Genau das ist das, was ich mir heir aufbaue (und auch andere).
Wer in seiner Wolke dann ein Babel/l3roamd anstatt Batman fahren will, kann das ja auch tun 
man ist von niemanden mehr abhängig.
Die ganzen (bisher ausschließlich Batman) Wolken werden bei uns übrigens auch per Babel verbunden aber ohne l3roamd.
mfg
Christian
1 „Gefällt mir“
Geht so, wir haben teilweise den Effekt, dass Pakete einfach nicht ordnungsgemäß transportiert werden und da kann man in das Kernelmodul nur sehr schwer reinsehen. So Effekte wie batctl p funktioniert, aber auf die IP nicht. Da hilft dann nur ein Neustart.
Das interessiert mich sehr. Aus welcher Community bist du? Kannst du bitte mal eure site.conf und site.mk verlinken? Ich würde mir das gerne mal ansehen, da ich das hier auch gerne machen würde.
Grüße
Matthias
OT: Wir hatten ein ähnliches Problem. Der Distributed ARP Table wurde nicht immer richtig aktualisiert. Seit dem wir ihn abgeschaltet haben ist das Problem verschwunden. Habe das gleiche auch aus anderen Communities gehört.
2 „Gefällt mir“
Der @tcatm hat einen wunderbaren Überblicksblog geschrieben in dem die Art der Zusammenarbeit der Komponenten festgehalten wird.
Daneben gibt die Wikiseite von FreifunkFFM einen kurzen Überblick über den aktuellen Status. In Kurz: Gegenwärtig gibt es ein IPv6-only Testnetz über das man eine Verbindung ins Internet herstellen kann und in dem Infrastruktur aufgebaut wird. Routing und DNS gehen, am Autoupdate arbeiten wir gerade, damit die Tests leichter werden. Außerdem wird noch Nat64 aufgebaut damit ein echter Testbetrieb ermöglicht wird, denn IPv6-only-Internet macht im Moment abseits von google-Diensten keinen Spaß.
Im Bezug auf Änderung gegenüber Batman sehe ich folgende Punkte:
- Man ist nicht mehr von einem Kernelmodul abhängig, damit dürfte es leichter werden, Geräte ins Mesh einzubinden. Alle, die batman für den raspberrypi kompiliert haben als es noch nicht im Kernel-Tree war, wissen wovon ich spreche. Die Situation mit Batman im Kernel ist besser geworden, aber eine Abhängigkeit weniger ist immer gut. Insbesondere weil die Anzahl der Leute die Batman nutzen vergleichsweise klein ist, Routing benutzt aber nun wirklich fast jeder. Der für ein Babelnetz erforderliche Kernelcode ist also hervorragend getestet.
- Durch Nutzung von Routing auf allen Nodes werden die Rollen zwischen Gateways und Nodes aufgeweicht. Wird einmal der prefixd entwickelt, ist es möglich IPv6-Prefixe im lokalen Freifunk zu teilen und so kann traffic ohne Frickelei lokal ausgeleitet werden. Gateways haben dann nur noch die Funktion Mesh-Wolken zusammenzuhalten, die keine direkte Wifi-Konnektivität haben.
- Gegenwärtig ist ein Node-zu-Node-VPN im großen Stil in Batman-Netzen problematisch (vergleiche dazu #378) weil es die Batman-Datenstrukturen mit jeder VPN-Verbindung deutlich vergrößert. In einem Babelnetz entfällt dieses Problem, sodass (vgl. vorheriger Punkt) sogar ein Gateway-loses Netz denkbar ist.
Die Babel-Integration in gluon behandelt aktuell nur IPv6. Ursache ist aber nicht, dass IPv4 nicht ginge, sondern dass ich erstmal überhaupt einen Netzwerkstack laufen sehen will bevor ein zweiter von mir bearbeitet wird. Das muss natürlich keinen sonst abhalten: Mit dem ddhcp von sargon sind alle konzeptuell erforderlichen Bausteine vorhanden um auch IPv4 in einem Babelnetz zu implementieren. Es muss nur jemand tun. Insofern ist die Aussage von @ChrisD in diesem Punkt nicht vollständig korrekt.
Im Bezug auf Skalierung muss man in der Tat sehen ob Roaming über eine mesh-vpn-Verbindung hinweg wirklich sinnvoll ist (sehr wahrscheinlich nicht) und wie man es schafft, den l3roamd auch in so einem Szenario effizient arbeiten zu lassen. Im Moment ist der l3roamd noch nicht vollständig implementiert. Wichtige Features fehlen und im Hinblick auf Effizienz wurde noch nicht optimiert. Meine bisherigen Tests sehen für den frühen Entwicklungsstand in dem das Programm ist erstaunlich gut aus.
Auch der mmfd ist in einem ähnlichen Zustand. Er funktioniert soweit ich das in dem kleinen Testnetz beurteilen kann, benötigt für einen Einsatz im großen Stil noch Effizienztuning, sodass die mit dem mmfd übermittelten Pakete nicht mehr im kompletten Mesh geflutet, sondern sinnvoll geforwarded werden. Dennoch ist der Zustand sehr ermutigend. Wir haben Babel-only-Freifunk-Nodes und ein paar Metriken auf unserer Map.
EDIT: Es gibt daneben noch Dokumentation der einzelnen Komponenten inklusive der Firewall.
8 „Gefällt mir“
hi
die von dir genannten Effekte kenne ich auch, wird umso schlimmer je größer das Netz ist. In einem Netz mit 10-15 Routern klappt Batman vorzüglich 
ich komme aus Freifunk Franken. Bei uns gibt es kein site.conf oder site.mk, wir nutzen kein Gluon
Bisher muss ich gestehen gibt es auch erst 4 Standorte die das System nutzen, wovon 1 noch bei mir im Wohnzimmer rumsteht weil ich noch nicht aufs Hochhaus durfte, ein 2. Standort erst seit heute läuft (in den letzten 3 Stunden gerade dran gebastelt) und ein 3. noch auf Olsr läuft (muss ich endlich mal umbauen auf Babel). Es sind aber noch einige Standorte in Planung.
Ansonsten hält Babel bei uns die Backbone zusammen, unser Netz ist ansich schon in Hoods (eigene L2 Netze) geteilt (durch voronoimap, jede „Hood“ hat ihre eigenen Gateways und so), die Gateways unterhalten sich untereinander per Babel (zum größten Teil, früher war das noch Olsr, ein paar Betreiber müssen endlich mal umbauen).
Das ganze ist einfach aktuell ein großer Umbau, viel wird manuell konfiguriert (Die Babelrouter an den Standorten werden fast nur manuell eingerichtet → Babel und dnsmasq in unsere firmware – Freifunk Franken
mfg
Christian
1 „Gefällt mir“
Ein Jahr ist rum. Der l3roamd arbeitet nun eventbasiert und läuft seit mehreren Monaten in einem Frankfurter Testnetz. Das Netz ist gut benutzbar und IPV6-only. Zugang zum V4 Internet wird über jool ermöglicht.
In einem privaten Netz teste ich gegenwärtig die kürzlich entwickelte ipv4-Unterstützung des l3roamd.
In gluon wurden schon einige Baustelne gemerged, das zentrale Paket gluon-mesh-babel steht noch aus und Arbeiten an der Statuspage sind noch erforderlich.
13 „Gefällt mir“
Der ipv6-babel-support ist in gluon gemerged. Damit DNS zuverlässig funktioniert muss ein gepatchtes Babel eingesetzt werden, welches im Frankfurer(Main) package feed unter dem Namen babeldev enthalten ist.
Serverseitig sind ab Kernel 4.16 ebenfalls Patches erforderlich - bei älteren Kernels kann man das 1.8.2er Release einsetzen.
6 „Gefällt mir“
Mit babel release 1.8.3 sind keine zusätzlichen Patches erforderlich.
Unterstützung für Wireguard-Support wurde als PR 1534 an gluon gestellt. Es werden ausschließlich geroutete Netze unterstützt. Ein Broker übernimmt die Verhandlung des servseitigen Ports.
Es gibt noch zwei Stolpersteine
- Ungepatchtes Babel unterstützt bis zu 20 Netzwerk Interfaces. Serverseitig sind mehr erforderlich (PR ist an babel gestellt)
- Unter bestimmten noch nicht näher beschriebenen Bedingungen glaubt babel fest daran, dass ein mesh interface down ist obwohl es aktiv ist. flush und re-add des interface genügen nicht um das Interface wieder verfügbar zu machen - ein Neustart von babeld ist erforderlich. Das Problem wird von mir untersucht.
7 „Gefällt mir“
Babeld ist in Version 1.9.1 in Openwrt verfügbar.
Neben verschiedenen Reparaturen ist folgendes neu:
- bis zu 1000 mesh interfaces unterstützt werden
- Die Metrikberechnung nun mit linearem Aufwand erfolgt anstatt mit quadratischem
- src-specific routing wurde überarbeitet und ist damit mit babeld Version <=1.8 nicht mehr kompatibel. Das feature wurde bislang noch nicht genutzt, wird es jedoch zukünftig
- Es lassen sich für jede von babeld eingefügte Route die korrekte src-Adresse angeben
- babeld läuft nun auch in Docker
Mit Dem Vorgänger Babel 1.8 wurde bereits auf der Breminale eine größere Installation mit 1K clients im Feld getestet. Bei dieser Anzahl Clients war die CPU-Last zu groß und das Setup ist explodiert.
Danach wurden die Optimierungen umgesetzt. Synthetische Last konnten ca 50 000 routen unterstützen, das entspricht einer Clientanzahl von >10000.
Der mmfd und das babel-Modul des respondd wurden optimiert sodass nun auch bei hohem Routenaufkommen viel weniger CPU-Last anfällt. Ein Patch für babel upstream wurde erstellt um die Last noch weiter zu senken.
Außerdem wurde das XLAT-Modul von Codefetch und der ddhcp von sargon integriert. Dadurch ist natives IPv4 für die Endgeräte möglich. Die bisher vorhanden Schwierigkeiten einiger Androidversionen treten nun nicht mehr auf.
Nun haben wir eine gute Grundlage um daran zu arbeiten, Freifunk dezentraler zu machen.
Hier sind ein paar Ideen dazu: decentral_network/decentral_freifunk.md at master · christf/decentral_network · GitHub
10 „Gefällt mir“
Die bislang bestehenden PMTU-Discovery Probleme im IPv4-Bereich wurden nun verstanden. Gestern konnte ich erstmalig über ein Babelnetz mit nativem ipv4 große Datenmengen zwischen zwei IPv4-Hosts transportieren. Dabei kam das von Codefetch integrierte und noch etwas gepatchte clat-Modul zum Einsatz. Über einen TL-WR740 kamen über FFRL bei Nutzung von wireguard, babel und clat nun sowohl via nativem IPv4 als auch über IPv4 via jool als auch über nativem IPv6 17MBit beim Client an.
Vielen Dank an @t-8ch für die Unterstützung bei der monatelangen Analyse!
7 „Gefällt mir“
Hallo Klaus_Dieter,
kann man eure Testfirmware selbst ausprobieren? Ich würde sie gern besser verstehen wollen. Hintergrund ist, dass wir von der Opennet-Initiative überlege auf Gluon zu wechseln. Eine Grundvoraussetzung hierfür wäre aber Layer3 Funktionalität. Bisher entwickeln wir unsere eigene Firmware aber nur sehr schleppend. Daher überlegen wir die Layer3 Entwicklung in Gluon zu unterstützen, sodass dies für uns später auch genutzt werden kann.
Gruß, Martin
3 „Gefällt mir“