Funktion
B.A.T.M.A.N. wird bei uns als Layer-2-Routing-Protokoll (ja, klingt kaputt – ist es auch) eingesetzt, um WLAN-Mesh zu ermöglichen. Für Linux gibt es dafür das B.A.T.M.A.N.-Advanced-Kernel-Modul.
Installation
B.A.T.M.A.N. Advanced wird mit dem Kommando batctl gesteuert. Das muss entsprechend installiert werden. Dabei kann sowohl die Version aus den Debian Paketquellen oder eine Selbstkompilierte verwendet werden (siehe weiter unten).
apt install batctl
Die Version, die beim Kernel von Debian Stretch mit dabei ist (v2016.4) ist Compat15, was die aktuell verwendete Compat-Version ist. (siehe [1]). Für unser KeyXchangeV2 Setup wird zum aktuellen Zeitpunkt ausschließlich Compat Version 15 verwendet.
Es sollte möglichst immer die gleiche Version für batman-adv und batctl verwendet werden. Daher entweder beides aus den Paketquellen installieren, oder beides selbst kompilieren.
Hinweis: Wird der Kernel aktualisiert, müssen alle selbstkompilierten Kernelmodule erneut gegen die aktualisierte Kernelversion gebaut und danach installiert werden! Folglich muss ein selbstkompiliertes batman_adv nach jedem Kernelupdate neu gebaut und installiert werden. Für den Anfang empfiehlt es sich, mit dem mitgelieferten batman_adv zu arbeiten.
Das Kernel-Modul kann testweise mit folgendem Befehl geladen werden:
modprobe batman-adv
Im Kernel Log sollte das Laden protokolliert werden:
~# dmesg | grep batman_adv batman_adv: B.A.T.M.A.N. advanced 2018.0 (compatibility version 15) loaded
Die aktuell eingesetzte Version von batctl und batman-adv (kann unterschiedlich sein) erfährt man mit
batctl -v
Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules der Eintrag "batman-adv" hinzugefügt wird:
.. batman-adv
DKMS für batman-adv
Wenn man Batman-adv aus dem Quellen selbst kompiliert, wird bei einem Kernelupdate wieder eine alte Version installiert. Damit hier automatisch wieder die aktuelle Version gebaut wird, kann DKMS verwendet werden.
Unter /usr/src einen Ordner anlegen mit NAME-Version z.b. batman-adv-2019.1 (zum aktuellen Zeitpunkt die aktuelle Version). Hier hinein entpackt man nun die Batman-adv sourcen und legt eine dkms.conf ebenfalls in dem Ordner an:
PACKAGE_NAME=batman-adv PACKAGE_VERSION=2019.1 DEST_MODULE_LOCATION=/extra BUILT_MODULE_NAME=batman-adv BUILT_MODULE_LOCATION=net/batman-adv MAKE="'make'" CLEAN="'make' clean" AUTOINSTALL="yes"
danach kann man das ganze Testen mit
dkms add -m batman-adv -v 2019.1 dkms build -m batman-adv -v 2019.1 dkms install -m batman-adv -v 2019.1
Wenn dies erfolgreich durchläuft, sollte beim nächsten Kernelupdate automatisch neu gegen den aktuelleren Kernel gebaut werden.
Konfiguration
In der Datei /etc/network/interfaces ...
vi /etc/network/interfaces
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:
.
.
.
# device: bat0
iface bat0 inet manual
post-up ip link set dev $IFACE up
##Einschalten post-up:
# IP des Gateways am B.A.T.M.A.N interface:
post-up ip addr add 10.50.32.5/21 dev $IFACE
# Regeln, wann die fff Routing-Tabelle benutzt werden soll:
post-up ip rule add iif $IFACE table fff
post-up ip rule add from 10.0.0.0/8 table fff
post-up ip rule add to 10.0.0.0/8 table fff
# Route in die Fuerther Hood:
post-up ip route replace 10.50.32.0/21 dev $IFACE proto static table fff
# Start des DHCP Servers:
post-up invoke-rc.d isc-dhcp-server restart
##Ausschalten post-down:
# Loeschen von oben definieren Routen, Regeln und Interface:
post-down ip route del 10.50.32.0/21 dev $IFACE table fff
post-down ip rule del from 10.0.0.0/8 table fff
post-down ip rule del to 10.0.0.0/8 table fff
post-down ip rule del iif $IFACE table fff
post-down ip link set dev $IFACE down
iface bat0 inet6 static
address fd43:5602:29bd:x::1/64
# zusätzliche Link Local für Hoodfile und Default-Gateway
post-up ip -6 addr add fe80::1/64 dev $IFACE nodad
post-up ip -6 addr add fe80::IRGENDWAS/64 dev $IFACE
post-up ip -6 rule add iif $IFACE table fff
post-down ip -6 rule del iif $IFACE table fff
# "catchall"
post-up ip -6 rule add from all iif $IFACE lookup fff
# ip route
post-up ip -6 route replace fd43:5602:29bd:x::/64 dev $IFACE proto static table fff
post-down ip -6 route del fd43:5602:29bd:x::/64 dev $IFACE proto static table fff
post-up invoke-rc.d radvd restart
# VPN Verbindung in die Fuerther Hood
iface ffffuerthVPN inet manual
post-up batctl -m bat0 if add $IFACE
post-up ifconfig $IFACE up
post-up ifup bat0
post-down ifdown bat0
post-down ifconfig $IFACE down
In diesem Beispiel sind:
- IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21
- IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.
Diese müssen gegen die reservierte IP/Netzmaske des Gateways der Hood und gegen die Netzwerk-IP/Netzmaske der Hood, in die das neue Gateway soll, ausgetauscht werden.
Der Eintrag "ip route add 10.50.32.0/21 dev $IFACE table fff" fügt in der fff Routingtabelle eine Route in das Netzwerk "Fürther Hood" ein. Für Hassberge müsste dieser Eintrag z.B. in 10.50.56.0/22 geändert und für die IP-Adresse des Gateways eine aus dem statischen Bereich der Hassberger Hood reserviert und verwendet werden (s.o.).
Die Regeln definieren, das Traffic der
- aus dem Netzwerk 10.0.0.0/8 kommt
- das Netzwerk 10.0.0.0/8 zum Ziel hat
- oder über die B.A.T.M.A.N Schnittstelle übermittelt wird
von der fff Routingtabelle behandelt wird. Die Einträge sind so allgemein formuliert, dass sie für das gesamte Freifunk Franken Netz Gültigkeit haben sollten.
Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.
Hinweis: Die MTU darf nicht verstellt (vergrößert) werden, diesbezügliche Laufzeitmeldungen von batman_adv bitte ignorieren! Weil durch das Internet nur 1500bytes durchpassen und man daher den Tunnel nicht größer machen darf da er sonst nicht mehr durchs Internet passt
Beim loopback device bitte noch
iface lo inet loopback
up ip rule add to 10.0.0.0/8 lookup fff
up ip -6 rule add to fc00::/7 lookup fff
## Möglicherweise möchte man die gleichen rules auch nochmal als Destination-rules (from statt to) anfügen.
#Eintragen, damit das Gateway weiß, dass die Freifunk-IPs durch die fff Routingtabelle durchgehen
Public IPv6
Wenn man Public IPv6 Adressen vergeben möchte, muss dazu eine IP an das batX Interface gehangen werden und eine route in die Routingtabelle eingetragen werden. Dies kann man z.b. folgendermaßen tun:
[...] # Public IPv6 post-up ip -6 addr add 2001:DB8:aaaa:bbbb::1/64 dev batX post-up ip -6 route add 2001:DB8:aaaa:bbbb::/64 dev $IFACE proto static tab fff </br> [...]
Zuerst wird eine einzelne Adresse des /64 Netzes an das bat Interface gehangen. Anschließend wird für dieses Subnetz eine Route mit "proto static" angelegt, damit Babel die Route auch weiter announced. Gleichzeitig wird die route dafür verwendet, den Traffic für das Subnetz auch auf das Interface zu routen.
