Gluon OLSRv2 Firmware Test

ONI OLSRv2 Gluon Test-Firmware (Stand 2025)

Motivation

Wir sind interessiert an der Gluon Firmware, weil die Pflege einer eigenen OpenWrt Firmware sehr aufwändig ist. Würde wir diese Firmware bei uns einsetzen, könnten wir an deren Weiterentwicklung partizipieren.

Desweiteren ist unsere Opennet Firmware aktuell (2025) sehr umfangreich und benötigt viele Hardware-Ressourcen wegen der vielen Skripte im Hintergrund. Auch die Weboberfläche ist für viele Geräte mittlerweile sehr langsam. Wir versprechen uns durch eine schlankere Firmware eine bessere Kompatibilität zu nicht-highend Geräten.

Seit kurzem ist OLSRv2 in Gluon verfügbar (dank dem Projekt Funkfeuer). Daher können wir hier ansetzen.

Es gab vor ein paar Jahren auch den Versuch die Gluon Firmware mit Babel zu nutzen Gluon_Babel_Firmware_Test. Hierbei gab es nur einen Prototypen und kein Weiterentwicklung.

Source Code & Download

• ONI Gluon: https://github.com/opennet-initiative/gluon
• ONI Gluon Site Config: https://github.com/opennet-initiative/gluon-site-olsrv2
• Firmware Download: https://matrix.x-pol.net/gluon/images/sysupgrade/

IP Adressen (evtl. veraltet)

siehe auch Adressierungsschema

Gateway Server & IPv6 Präfixe für Clients

Es stellt sich heraus, dass unterschiedliche Gateway Server mit unterschiedlichen IPv6 Präfixen ein großes Problem sind.

Angenommen Gateway A hat das Präfix 2001:db8:1234:5600::/56 vom ISP bekommen und Gateway B das Präfix 2001:db8:1234:7800::/56. In diesem Fall stellt sich die Frage, welches Präfix die Clients im Netz haben müssen, damit die Pakete richtig geroutet werden können. Bei IPv4 wurde alles über NAT gemacht und somit bestand diese Frage nicht.

Abhängig vom "genutzen" Gateway müsste ein AP seinen Clients das zugehörige Präfix mitteilen.

Bei Gluon können Clients roamen und mehrere APs müssten somit das gleiche Prefix für Clients nutzen. An dieser Stelle eine Flexibilität für einen Schwenk zum Gateway zu implementieren ist alles andere als trivial.

Im Gegensatz zu Gluon ist die Opennet Firmware bei Usern bereits fest mit einem Gateway verbunden (nennt sich User VPN). Hiermit wird sichergestellt, dass der User zwischen beliebigen Gateways wechseln kann. Dieses User VPN gibt es für IPv4 und (experimentell) auch für IPv6 (on-uservpn-v6).

Vielleicht ist genau dieses Problem der Präfixe und unterschiedlichen Gateways ein Grund nicht Gluon nehmen zu können. Denn in Gluon ist dieses Konzept so nicht vorgesehen und schwerer zu lösen als in der Opennet Firmware.

Laborbuch - Fortschritte und Erkenntnisse (2025)

• Es wurde eine Firmware gebaut.
• Der Versuch den Endnutzern public IPv6 Adressen zur Verfügung zu stellen, brachte viele Fragen auf.
  • Wo kommt das IPv6 Prefix her?
  • Müssen alle Internet Gateways sich ein public IPv6 Prefixe teilen (benötigt dann PI Adressbereich und BGP zum ISP)?
  • Nachfrage im Gluon IRC brachte leider auch keine weiteren Erkenntnisse weil in Gluon nur sehr wenige FF Vereine OLSR nutzen (FF Graz/Funkfeuer).
  • Es fehlen auch Personen, welche aktiv die OLSR Integration in Gluon verbessern/fixen. Damals hat Funkfeuer die Integration erstellt, ist dann aber mit ihrem Custom Gluon "steckengeblieben" und nimmt weniger an Gluon master teil.
• Dann wurde plötzlich OLSRv2 aus OpenWrt master entfernt weil die Compilerfehlern mit aktuellen gcc14 in Debian nicht gefixt wurden. Hier wurde nochmals deutlich, welche Konsequenzen hat hat, wenn niemand den Quellcode des Routingprotokolls pflegt.
• Somit wurde wieder deutlich, dass veraltete und nicht gepflegte Routingprotokolle ein grundlegendes Problem für Opennet werden können.
• An dieser Stelle war der Gluon-OLSR Firmwaretest beendet weil eine Fokussierung auf OLSR nicht mehr gerechtfertigt ist.
• Wie kann eine mögliche Firmware in der Zukunft aussehen? Es wurde jetzt (erneut) begonnen über einen kompletten Wechsel auf Gluon mit batman zu wechseln (siehe Meeting Notizen).

• Im Dezember 2025 wurde olsr2 upstream gefixed und weiterentwickelt. In openwrt fehlt es zukünftig, läßt sich aber ohne größeren Aufwand in unsere Firmware integrieren (getestet von Kai-Uwe mit openwrt-24.10 und 25.12). In der Zukunft kann es aber zu Mehraufwand und Problemen führen, so daß ein Wechsel auf babel oder ähnliches ratsam erscheint.