Gluon Babel Firmware Test

Aus Opennet
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

ONI Babel Gluon Test-Firmware

Motivation

Wir sind interessiert an der Gluon Firmware. Würde wir diese Firmware bei uns einsetzen, könnten wir an deren Weiterentwicklung partizipieren.

Aktuell (2020-2021) gibt es eine Entwicklung, um das Babel Routing in Gluon anstatt batman zu nutzen.

Gluon Layer3 Doku - von Freifunk Communities

Doku:

Babel Firmware von Klaus_Dieter:

Site Config - Magdeburg:

Gluon Originial:

Opennet: Firmware mit Gluon + Babel + Fastd

Quellcode / Installation / Konfiguration

Im Folgenden wird die (Test-) Opennet Gluon Firmware dargestellt.

Quellcode:

Eine Gluon Firmware besteht immer aus dem Gluon Repo und der Site Repo:

Downloads:

Die letzte gebaute Firmware kann unter https://downloads.opennet-initiative.de/gluon/oni-testing/ heruntergeladen werden.

Installation/Konfiguration:

Eine Anleitung zur Installation + Konfiguration findet ihr bspw. unter https://wiki.freifunk-mwu.de/w/Howto/Gluon_Konfigurieren

Firmware Entwicklung
  • Bauen der Firmware:
sudo apt install build-essential gawk unzip libncurses-dev libz-dev libssl-dev time
git clone git@git.hack-hro.de:opennet-initiative/gluon.git -b v2020.2.2
cd gluon/
git clone git@dev.on-i.de:on_site_babel_test site
make update
make GLUON_TARGET=ar71xx-generic
  • Unser Gluon Repo updaten (Sync mit original Gluon Repo):
git clone git@git.hack-hro.de:opennet-initiative/gluon.git
cd gluon
#sync Opennet Gluon repo with remote (Gluon) respository
git remote add upstream https://github.com/freifunk-gluon/gluon.git
git remote -v
git fetch upstream
git checkout master
git merge upstream/master
git push
  • Baue alle ar71xx Architekturen:
 make -j$(nproc) GLUON_TARGET=ar71xx-generic
rsync -rlv -e ssh --exclude debug/ --delete output/ ruri:/var/www/downloads.opennet-initiative.de/gluon/oni-testing/

Auf dem Download Webserver ist somit immer nur die letzte erstellte Firmware verfügbar. Das Ziel ist es, während des Testings nur eine Firmware zu haben.

IP Adressen (evtl. veraltet)
DNS64/NAT64
  • DNS64 Docker Container auf gai
  • NAT64 (tayga) Container auf gai (siehe für Config User:leo/tayga)
    • MTU Probleme beim NAT64. Aus dem Internet werden große IPv4 Pakete (>1380) geschickt. Nach der IPv4-zu-IPv6 Übersetzung müssen sie durch den fastd VPN Tunnel geschickt werden. Der VPN Tunnel hat aber nur eine MTU von 1380. Ein größeres Paket wird mit ICMP frag-needed abgewiesen. Diese ICMP Meldung wird zum NAT64 GW geschickt. Leider kommt diese ICMP Meldung nicht bis in Internet. Man sieht das ICMP Paket noch auf dem tayga nat64 Interface aber danach "verschwindet" es.

TODO:

Nächsten Schritte

Folgende Features sollten wir auch Testen um uns im klaren über die weitere Entwicklung zu sein.

Hauptunterschiede zwischen Opennet Firmware (2020) und Gluon+Babel

Konzeptionell:

  • User-VPN Tunnel
    • Opennet: Mesh Knoten von Entnutzern bauen einen VPN Tunnel (mit Zertifikat) zum Internet Gateway auf. Abhängig davon, erhält der Knoten (und Endgeräte) Internetzugriff. Opennet bietet hier mehr Sicherheit/Privatheit auf dem Transportweg durch das Mesh.
    • Gluon: In Gluon ist dieses Konzept nicht vorgesehen. Alle Clients haben vollen Zugriff auf das Internet.
  • Roaming
    • Opennet: Feature ist nicht vorgesehen by Design
    • Gluon: mittels l3roamd realisiert. Als Nebeneffekt sind die IPs aller Endgeräte jedem Knoten bekannt. Es gibt nur einen Address-Pool.
  • Weboberfläche
    • Opennet: Umfangreiche Konfigurationsmöglichkeiten für Opennet spezifische Funktionen. Die OpenWRT Oberfläche ist auch weiterhin verfügbar.
    • Gluon: Sehr stark reduziert auf sehr wenige Funktionen.
  • Wifi Konfiguration
    • Opennet: ...
    • Babel: ...

Technisch:

  • L3 Routing Protokoll
    • Opennet: OLSR1 (IPv4), OLSR2 (IPv6)
    • Gluon: Babel
  • VPN Software
    • Opennet: OpenVPN mit tap und tun interfaces
    • Gluon: fastd, tunneldigger, wireguard (in Arbeit), ...

Mögliche Migrationsszenarien

  • L3 Routingprotokoll
    • hier muss von OLSR2 nach Babel gewechselt werden. Das beiden IPv6 only sind, könnte man diese 1:1 austauschen. Es wäre denkbar eine "alte" Opennet Firmware zu bauen, welche anstatt OLSR2 dann Babel unterstützt. Diese Firmware könnte man dann auf den Backbone APs einspielen. Somit wäre im Backbone Babel unterstützt.
  • VPN?

Laborbuch - Fortschritte und Erkenntnisse

24+25.02.2021

Server:

  • auf Server itsuki wurde diese Woche fastd,babeld,l3roamd,mmfd installiert und konfiguriert (siehe Doku in /root/*). Bisher wurde die Babel-Tests auf dem Server gai durchgeführt. Hier soll aber saubergetrennt werden. Der Server itsuki ist ausschließlich für diese Tests nur verfügbar.

Firmware:

Tests:

  • Firmware auf WDR4300 Router installiert.
  • Client am Router bekommt fd02::2/64 als IP. Warum diese IP? Es gibt aber keinerlei IP aus dem Adressbereich der site.conf. Warum nicht?
  • SSH zum AP nur über Link Local möglich:
 ssh fe80::1441:95ff:fe40:f7dc%enp53s0 -l root
  • VPN Verbindung mit fastd erfolgreich aufgebaut
  • Ein Client am AP hat zwei IPs aus dem fd32:d8d3:87da:bab0::/64 Netz genommen/erhalten. Eine temporäre und eine per DHCP (via dnsmasq).
  • Babel: auf AP ist Route zu itsuki zu sehen und damit funktioniert auch Babel:
 root@c4e9847de44a:~# ip -6 route show table all | grep 244
 fd32:d8d3:87da:bab1::244 via fe80::14d5:80ff:fe2b:3606 dev mesh-vpn  src fd32:d8d3:87da:bab1:c6e9:84ff:fe7d:e44a  metric 96
  • Ping vom AP zu itsuki läuft hat(te) komisches Verhalten. Erst nach 160 Pings ohne Antwort, kam dann plötzlich eine Antwort zurück und dann auch dauerhaft. Ich hatte kurz vorher ein tcpdump auf itsuki gemacht, um das Problem zu untersuchen. Ob beides zusammenhängt? Jedenfalls scheint jetzt der Ping zu funktionieren:
 10:32:18.500191 IP6 fd32:d8d3:87da:bab1:c6e9:84ff:fe7d:e44a > fd32:d8d3:87da:bab1::244: ICMP6, echo request, seq 213, length 64
 10:32:18.500254 IP6 fd32:d8d3:87da:bab1::244 > fd32:d8d3:87da:bab1:c6e9:84ff:fe7d:e44a: ICMP6, echo reply, seq 213, length 64
  • Alle erreichbaren Babel Clients sind bspw. zu finden via:
 root@itsuki:~# ip -6 route show table 10
 fd32:d8d3:87da:bab1:c6e9:84ff:fe7d:e44a via fe80::dcc6:50ff:fef2:2f3f dev babel-vpn proto babel metric 96 onlink pref medium
 fd32:d8d3:87da:bab2:82fa:5bff:fe8a:7eac via fe80::dcc6:50ff:fef2:2f3f dev babel-vpn proto babel metric 96 onlink pref medium
 fd32:d8d3:87da:bab2::/64 dev l3roam0 metric 1024 pref medium
  • Vom Client ist derzeit das Internet noch nicht erreichbar. Aber hier muss auf itsuki noch das Forwarding/Firewall konfiguriert werden. Dies liegt u.a. daran, dass die Clients eine ULA als Adresse haben.

Geplante nächste Schritte:

  • in site.conf das prefix6 auf public IP ändern. Zusätzlich das node_prefix6 auf publich ändern. Dann neue Firmware testen. Geht jetzt ping,traceroute,DNS?

Firmware:

Server:

  • fd32:d8d3:87da:bab0::/64 ersetzt in Configs durch 2a0a:4580:1010:8100::/64
  • fd32:d8d3:87da:bab1::/64 ersetzt in Configs durch 2a0a:4580:1010:8101::/64

Tests:

  • Clients bekommen jetzt IP aus 2a0a:4580:1010:8101::/64
  • AP hatte aber noch keine Route für Public Network
  • auf itsuki wurde jetzt in Routing Tabelle 12 eine 2000::/3 Route hinzugefügt
  • Der AP hat nur die 2000::/3 Route per babel bekommen und routet somit public IPv6 Verkehr ins mesh-vpn
  • ping vom Client ins Internet geht noch nicht.

Geplante nächste Änderung:

  • Überprüfen wo auf itsuki das ICMP Paket des Clients verloren geht und korrigieren.

26.02.2021

  • Fehlkonfiguration auf itsuki gefunden und korrigiert
  • Eine Client mit IP aus dem 2a0a:4580:1010:8101::/64 Netz kann jetzt bspw. 2600:: als public IP anpingen
  • Auf dem Client funktioniert jedoch noch keine DNS Auflösung. Die DNS Query wird an 2a0a:4580:1010:8101::1 geschickt und darauf wird ein "Destination unreachable (Port unreachable)" empfangen. Warum?
    • Die DNS Anfrage wird vom dnsmasq auf dem AP in Richtung Google DNS (2001:4860:4860::8844) geschickt.
  IP6 2a0a:4580:1010:8101:c6e9:84ff:fe7d:e44a.61079 > 2001:4860:4860::8844.53: 1913+ PTR? 7.0.b.a.6.e.e.f.f.f.c.5.0.3.0.c.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
    • Die DNS Anfrage wird auf itsuki auf dem babel-vpn Interface empfangen
  IP6 2a0a:4580:1010:8101:c6e9:84ff:fe7d:e44a.8935 > 2001:4860:4860::8844.53: 30256+ PTR? 7.0.b.a.6.e.f.f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (90)
    • Die Anfrage wird jedoch anscheinend nicht ins Internet weiter geroutet. Laut Routingtabelle müsste es funktionieren:
  2001:4860:4860::8844 from 2a0a:4580:1010:8101:c6e9:84ff:fe7d:e44a dev ens2 table babeld proto static metric 1024 iif babel-vpn pref medium
    • Das DNS Anfrage aufgrund des Caching und SERVFAIL schwerer zu debuggen sind, nutzen wir ein Ping vom APs auf zum Google DNS Server zur Fehlersuche. Auch hier funktioniert es nicht.
  • Auf dem AP geht "ping 2001:4860:4860::8844" ins leere.
    • Auf itsuki auf dem babel-vpn Interface ist das Packet noch zu sehen aber auf dem ens2 Interface nicht mehr. Interessanterweise sind jedoch neighbor solication für diese Adresse im tcpdump zu sehen.
  IP6 fe80::5054:ff:fea0:3f00 > ff02::1:ff00:8844: ICMP6, neighbor solicitation, who has 2001:4860:4860::8844, length 32
    • Hier stimmte etwas auf itsuki nicht. Nach Neustart von l3roamd ist aufgefallen, dass die IPv6 default route nicht mehr vorhanden war. Daraufhin networking.service neugestartet. Jetzt nochmals testen.
    • Erkenntnis: itsuki dachte, dass das 2003::/3 Netz direkt Layer2 angeschlossen ist durch einen kleinen Routingtabelleneintragen. Ist nun korrigiert:
  ip -6 route del 2000::/3 dev ens2 table babeld proto static
  ip -6 route add 2000::/3 via fe80::1 dev ens2 table babeld proto static
    • Jetzt sieht man ICMP zum Google DNS und die Antwort kommt auch auf itsuki rein. Jedoch wird die Antwort anscheinend nicht ins babel-vpn geleitet. Warum?
    • Fehler gefunden: In der Routing Policy Database waren Einträge in der falschen Reihenfolge enthalten. Es wurde zuerst die babeld Routingtabelle und dann die mesh Tabelle abgearbeitet. Es muss aber anders herum sein.
 #alt:
 root@itsuki:~# ip -6 rule list
 0:	from all lookup local 
 32748:	from fd32:d8d3:87da:bab2::/64 lookup babeld 
 32749:	from 2a0a:4580:1010:8101::/64 lookup babeld 
 32750:	from all to fd32:d8d3:87da:bab2::/64 lookup babeld 
 32751:	from all to 2a0a:4580:1010:8101::/64 lookup babeld 
 32752:	from fd32:d8d3:87da:bab2::/64 lookup mesh 
 32753:	from 2a0a:4580:1010:8101::/64 lookup mesh 
 32754:	from 2a0a:4580:1010:8100::/64 lookup mesh 
 32755:	from all to fd32:d8d3:87da:bab2::/64 lookup mesh 
 32756:	from all to 2a0a:4580:1010:8101::/64 lookup mesh 
 32757:	from all to 2a0a:4580:1010:8100::/64 lookup mesh 
 32766:	from all lookup main 
 
 #neu:
 root@itsuki:~# ip -6 rule list
 0:	from all lookup local 
 32756:	from all to 2a0a:4580:1010:8100::/64 lookup mesh 
 32757:	from all to 2a0a:4580:1010:8101::/64 lookup mesh 
 32758:	from all to fd32:d8d3:87da:bab2::/64 lookup mesh 
 32759:	from 2a0a:4580:1010:8100::/64 lookup mesh 
 32760:	from 2a0a:4580:1010:8101::/64 lookup mesh 
 32761:	from fd32:d8d3:87da:bab2::/64 lookup mesh 
 32762:	from all to 2a0a:4580:1010:8101::/64 lookup babeld 
 32763:	from all to fd32:d8d3:87da:bab2::/64 lookup babeld 
 32764:	from 2a0a:4580:1010:8101::/64 lookup babeld 
 32765:	from fd32:d8d3:87da:bab2::/64 lookup babeld 
 32766:	from all lookup main
    • Nun funktioniert auch Ping. DNS auf dem AP scheint auch zu funktionieren.
  • DNS auf dem Client geht aber nocht nicht. Der DNS Server des APs scheint nicht zu antworten für den Client. Testen mit:
 nslookup ct.de 2a0a:4580:1010:8100::1
 ;; connection times out

27.02.2021

  • Es stellt sich heraus, dass es ein Firewallproblem auf dem AP ist. Im ip6tables Regelsatz gab es ein target zone_loc_client_input und zone_local_client_input. Im ersten target war kein DNS erlaubt. Beide targets sahen auch sehr redundant aus. Eine Recherche ergab, dass es eine Umbenennung im Sept. 2020 gab (https://github.com/freifunk-gluon/gluon/commit/5b068d7c47ab6059cfefce70e78f4cb2e6a486d6). Mein AP hatte vorher eine Firmware mit der alten target Bezeichnung und mit einer neuen Firmware (v.2020.02) kam die neue target Bezeichnung. Aber anscheinend funktioniert irgend ein Migrationsscript nicht sauber. Ich habe die Einstellung auf meinem AP alle gelöscht und jetzt gibt es nur noch das target zone_local_client_input. Und jetzt funktioniert auch DNS problemlos.
  • Nächster Schritt: NAT64+DNS64
  • tayga wurde auf itsuki installiert und konfiguriert (inkl. Routing+Firewall)
  • neue Firmware mit Google DNS NAT64 Server (für erste Tests) kompiliert (gluon-oni-0.6+exp20210227).

28.02.2021

  • der tayga Dienst auf itsuki ist nun reboot-fest (64:ff9b::/96 Route wird automatisch ins Babelrouting eingetragen)

Nächste Schritte:

  • andere Personen testen lassen und über weitere Ziele sprechen

Bekannte Bugs:

  • wenn l3roamd Service auf itsuki neugestartet wird, wird anscheinend die IPv6 default route gelöscht. Man kommt per IPv4 danach noch an den Server ran.


Debug Kommandos/Informationen

  • Wie komme ich vom Client auf den AP?
    • Jeder AP hat die Adresse 2a0a:4580:1010:8100::1 (next_node IP). Somit kann man von einem angeschlossenen Client per Webbrowser auf http://[2a0a:4580:1010:8100::1] oder per SSH mit folgenden Kommando auf den AP zugreifen:
  #Beachte, dass dein SSH Key auf dem Gerät eingetragen sein muss. Dies kann man beim Einrichten machen.
  ssh root@2a0a:4580:1010:8100::1
  • ...
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge