© taa22 / 123RF.com

Nachdem es im ersten Teil um die Begriffe und die grundsätzliche Funktionsweise von WLAN-Meshes ging, wechseln wir nun zur Praxis: Die Installation steht an.

Wie bereits im ersten Teil dieses Workshops [1] in der letzten Ausgabe erwähnt, gibt es Gründe, nicht nur ein, sondern, sondern mehrere Mesh-Netze aufzubauen und sie miteinander zu verbinden. Dafür existieren mehrere Anwendungen.

Für die schnelle Datenübertragung wählt man idealerweise das 5-GHz-Band, in dem allerdings Reichweite und Durchdringung deutlich schlechter ausfallen als im 2,4-GHz-Band. Dadurch kann es vorkommen, dass sich einzelne Räume oder Etagen nicht im 5-GHz-Band erreichen lassen. Dann braucht man ein weiteres Mesh im 2,4-GHz-Band, um diese Räume anbinden zu können. Trotzdem will man nicht auf die schnelle Datenübertragung im Hauptbereich verzichten. Bei 802.11s müssen sich aber alle beteiligten Mesh Points (MP) auf demselben Funkkanal befinden und sich “sehen”. Daher lassen sich zwei Frequenzbereiche nicht in einem einzigen 802.11s-Mesh zusammenfassen.

Die Anbindung von Freiflächen oder durch Freiflächen vom Hauptgebäude getrennten anderen Gebäuden ist im 5-GHz-Band per Mesh legal nicht möglich. Im Freien darf man (zumindest in Deutschland) im 5-GHz-Band nur Kanäle benutzen, die DFS verwenden. Die eignen sich aber nicht für ein IEEE-802.11s-Mesh, da es keinen Mechanismus gibt, um den nötigen Frequenzwechsel aller Mesh Points zu synchronisieren. Ein solcher Wechsel würde nötig, nachdem ein Wetterradar erkannt wurde, das in diesem Frequenzbereich den Vorzug erhalten muss. Damit würde das Mesh unweigerlich zerfallen. Freiflächen lassen sich also legal nur im 2,4-GHz-Band überbrücken oder versorgen.

Für den Datendurchsatz im Mesh ist es ungünstig, nur einen Mesh Portal Point (MPP) mit Übergang ins kabelgebundene Netz zu haben. 802.11s sieht durchaus mehrere MPPs vor. Mit mehreren MPPs ergäbe sich aber die Möglichkeit, die Mesh-interne Kommunikation via Gbit-LAN zu führen statt über die im Vergleich dazu langsame Funkverbindung. Diese Möglichkeit bietet 802.11s als reines Funkprotokoll jedoch nicht.

Kommerzielle Mesh-Lösungen entsprechen diesen Anforderungen mit jeweils eigenen, proprietären Ansätzen. Sie funktionieren technisch gut, sind aber nicht miteinander kompatibel, woraus als Ergebnis ein Vendor-Lock-in resultiert. Es gibt jedoch Möglichkeiten, um solche Installationen ohne Herstellerbindung aufzubauen.

OLSR

Das ältere der beiden hauptsächlich eingesetzten Protokolle, das Optimized Link State Routing Protocol (OLSR [2]), benutzt Hello- und Topology-Control-Nachrichten, um die Topologie eines Netzes zu erfassen und die Routen darin dynamisch festzulegen und zu verteilen. Jeder Mesh Point hält eine lokale dynamische Routing-Datenbank vor.

Da Funknetze über unzuverlässige Datenpfade laufen, lässt sich dafür nur schwer ein zuverlässiger Algorithmus finden. OLSR versucht das gar nicht erst, sondern flutet das Netz in so kurzen Abständen mit Multipoint Relay Messages (MPRs), dass die verteilte Routing-Datenbank nicht für längere Zeit unsynchronisiert bleibt.

OLSR berücksichtigt nicht die Qualität einer Verbindung, die bei WLAN häufig und stark schwankt. Die Linux-Implementierung OLSRd bringt allerdings ab Version 0.4.8 eine Qualitätsüberwachung mit. Ein weiterer Nachteil des Protokolls: Es braucht selbst merklich Bandbreite und auch CPU-Leistung.

B.A.T.M.A.N.

Insbesondere die Freifunk-Community hat ein Interesse daran, ein effizienteres Protokoll als OLSR einzusetzen. Seit 2006 gibt es daher aus diesem Umfeld B.A.T.M.A.N. (Better Approach To Mobile Adhoc Networking [3]). B.A.T.M.A.N. startete zunächst auf Layer 3 des OSI-Modells (IP-Adressen) und verteilte die Routing-Informationen über UDP. Ab 2007 wurde an einem Routing auf OSI-Layer 2 (MAC-Adressen) gearbeitet. Diese Version heißt B.A.T.M.A.N. advanced (Batman-adv), ist seit 2011 Bestandteil des Linux-Kernels (ab Version 2.6.38) und wird aktiv weiterentwickelt.

Bei Batman-adv hält nicht jeder Knoten die gesamte Routing-Tabelle des Meshs in einer lokalen Datenbank wie bei OLSR, sondern kennt nur seine eigenen Nachbarn. Er teilt diese Information inklusive einer Qualitätsbewertung der einzelnen Verbindungen per Broadcast allen Nachbarn regelmäßig mit, die geben die Information weiter. So kennt jeder Knoten den Zustand des Meshs und kann seine eigene Routing-Tabelle anpassen.

Da Batman-adv auf OSI-Layer 2 funktioniert, erscheint das Mesh nach außen als ein einziger virtueller Switch. Alle Protokolle und Software ab Layer 3 (IP) aufwärts wissen nichts von dem Mesh, sondern schicken ihre IP-Pakete wie an einen lokalen Nachbarn im Netz. Daher braucht ein Knoten im Mesh zur Teilnahme keine IP-Adresse, und es lassen sich beliebige Protokolle über das Mesh fahren (IPv4, IPv6, DHCP, IGMP, etc.). Die Adressvergabe kann über DHCP von außen erfolgen. Das gilt auch für Endgeräte, die über Access Points am Mesh teilnehmen.

Es gibt allerdings eine Ausnahme: Existieren im Batman-adv-Mesh mehrere Übergabepunkte ins Internet, lässt sich die Information, welcher Übergabepunkt benutzt werden soll, innerhalb des Meshs über DHCP verteilen. In diesem Fall arbeitet Batman-adv sowohl auf Layer 2 als auch auf Layer 3. Das kann beispielsweise dann der Fall sein, wenn man mehrere Standorte über VPN verbindet, die über eigene Internet-Gateways verfügen (DSL, FTTH6, Standleitung). Im Freifunk-Netz gilt diese Topologie als Standard.

Anwendung mit OpenWrt

OpenWrt [4] verwendet als Basis ein IEEE-802.11s-Mesh. Für den Einsatz von Batman-adv schalten Sie den in 802.11s enthaltenen Forwarding-Mechanismus aus. IEEE 802.11s routet dann keine Nutzdaten mehr, sondern baut lediglich die physische Funkverbindung zwischen den Knoten auf. Das Routing übernimmt stattdessen Batman-adv.

Die Konfiguration des 802.11s-Meshs fassen wir hier verkürzt zusammen. Zunächst einmal müssen Sie die Default-Installation ändern (Listing 1, erste zwei Zeilen) und neue Komponenten installieren (letzte Zeile). Nun legen Sie auf jedem Gerät unter »/etc/config/wireless« einen Mesh-Point an (Listing 2), wobei alle denselben Kanal, dieselbe Mesh-ID und dasselbe Passwort verwenden. Lediglich das Device (»radioX«) müssen Sie gegebenenfalls anpassen..

# opkg remove wpad-mini
# opkg remove wpad-basic
# opkg install wpad-mesh-openssl

config wifi-iface 'mesh0'
  option network 'nwi_mesh0'
  option device 'radio0'
  option mode 'mesh'
  option mesh_id Mesh-ID
  option encryption 'psk2/aes'
  # oder encryption 'none'
  option key Passwort
  option mesh_fwding '0'

Die Einstellung »option mesh_fwding ‘0’« schaltet das Routing nach IEEE 802.11s ab und ermöglicht den Einsatz von Batman-adv. Das Interface »nwi_mesh0« muss identisch geschrieben in der Konfiguration des Batman-adv-Interfaces in »/etc/config/network« auftauchen.

Um ein weiteres Mesh im zweiten Frequenzband anzulegen, verwenden Sie einfach ein zweites Interface mit anderem »radioX«. Dualband-Geräte haben zwei Radio-Devices, Triband-Geräte drei, gegebenenfalls kommen noch weitere Devices für USB-WLAN-Sticks hinzu. Das Mesh muss eine eigene Mesh-ID und einen eigenen Interface-Namen erhalten.

Damit ist die Konfiguration der 802.11s-Mesh-Netze erledigt. Aktivieren Sie sie auf allen MPs mit »wifi down«, gefolgt von »wifi up« und »logread -l 20 -f«. Nun baut sich das Mesh automatisch auf.

Einsatz von Batman-adv

Bei der Installation von Batman-adv folgen Sie am besten der Anleitung im OpenWrt-Wiki [5]. Im Wesentlichen genügen die Kommandos »opkg update« und »opkg install kmod-batman-adv«, gefolgt von »opkg install batctl-full«.

Nun gilt es, das Batman-adv-Kontroll-Interface anzulegen und die 802.11s-Mesh-Netze unter die Kontrolle von Batman-adv zu stellen. Die Konfiguration des Kontroll-Interfaces zeigt Listing 3. Die Werte stammen direkt aus dem Batman-adv-Projekt, die Anleitung zu »batctl« beschreibt die Parameter. Im Allgemeinen müssen Sie hier nichts anpassen. Die mit »gw_« beginnenden Einstellungen benötigen Sie nur, wenn Sie mehrere verschiedene Übergänge ins Internet konfigurieren müssen. Die OpenWrt-Anleitung empfiehlt als Protokoll »BATMAN_IV«, da sich das neuere »BATMAN_V« im praktischen Betrieb noch als zu instabil erweist.

config interface 'bat0'
  option proto 'batadv'
  option routing_algo 'BATMAN_IV'
  option aggregated_ogms 1
  option ap_isolation 0
  option bonding 0
  option fragmentation 1
  #option gw_bandwidth '10000/2000'
  option gw_mode 'off'
  #option gw_sel_class 20
  option log_level 0
  option orig_interval 1000
  option bridge_loop_avoidance 1
  option distributed_arp_table 1
  option multicast_mode 1
  option network_coding 0
  option hop_penalty 30
  option isolation_mark '0x00000000/0x00000000'

Nun müssen Sie noch die beiden 802.11s-Mesh-Netzwerke der Kontrolle von Batman-adv unterstellen. Listing 4 setzt dabei die MTU auf 2304, das Maximum, das 802.11s-Netze unterstützen. Sie darf freilich nicht größer werden als die maximale MTU des verwendeten Links. Die MTU sollte außerdem 1532 nicht unterschreiten, damit Batman-adv typische 1500-Byte-Ethernet-Pakete ohne Fragmentierung routen kann.

config interface 'nwi_mesh0'
  option mtu '2304'
  option proto 'batadv_hardif'
  option master 'bat0'
config interface 'nwi_mesh1'
  option mtu '2304'
  option proto 'batadv_hardif'
  option master 'bat0'

Wie bereits erwähnt, müssen Sie den Namen des Interfaces (»nwi_meshX«) genauso schreiben wie bei der Deklaration in »/etc/config/wireless«. Die Funktion des aus zwei zusammengeschalteten 802.11s-Mesh-Netzen bestehenden Batman-adv-Meshs prüfen und steuern Sie mit dem Kommandozeilenwerkzeug Batctl. Die OpenWrt-Web-GUI LUCI bietet keine Integration von Mesh-Netzwerken, weder für 802.11s noch für Batman-adv. Wie Sie die Funktion der zugrunde liegenden 802.11s-Mesh-Netze überprüfen und steuern, wurde bereits im ersten Teil dieses Workshops detailliert dargestellt.

Um in den Ausgaben von Batctl nicht nur die (schwer wiedererkennbaren) MAC-Adressen zu sehen, tragen Sie nun noch in die Datei »/etc/bat-hosts« eine Liste der MAC-Adressen der an den Mesh-Netzen beteiligten Geräte ein (Listing 5). Da Batman-adv auf Layer 2 arbeitet, haben diese Namen keinerlei Bezug zu den gegebenenfalls vorhandenen IP-Adressen oder DNS-Namen der Geräte, sondern dienen lediglich der Lesbarkeit der Ausgaben von Batctl (Listing 6).

F4:F2:6D:B6:BB:B4  c2600.5ghz
F4:F2:6D:B6:BB:B5  c2600.2ghz
d4:ee:07:61:ac:86  newifi-d2.2ghz
d0:ee:07:61:ac:86  newifi-d2.5ghz

# batctl n
[B.A.T.M.A.N. adv openwrt-2019.2-7, MainIF/MAC: eth0.3/f4:f2:6d:b6:bb:b6 (bat0/ae:ff:80:88:81:a8 BATMAN_IV)]
IF        Neighbor      last-seen
  mesh1   c2600_2.2ghz     0.590s
  mesh1     mir3g.2ghz     0.430s
  mesh0   c2600_2.5ghz     0.350s
  mesh0      c7v2.5ghz     0.900s

Das Kommando »batctl n« zeigt die Nachbarn des Knotens an. Die Ausgabe umfasst den Namen des 802.11s-Meshs, den Namen aus /»etc/bat-hosts« (oder die MAC-Adresse) und die Angabe, vor wie vielen Sekunden der Nachbar das letzte Mal gesehen wurde.

Im Beispiel aus Listing 6 ist ein Gerät (»mir3g.2ghz«) nur über das Mesh auf dem 2,4-GHz-Band angebunden. Es handelt sich um eine Komponente in der vom Hauptgebäude durch eine Freifläche getrennten Garage, wo das 5-GHz-Mesh nicht mehr zu empfangen ist. Auf der IP-Ebene merkt man davon nichts und kann das Gerät ganz normal über seine IP-Adresse erreichen, also auf Layer 3. Für die lokalen Endgeräte dagegen stellt es wiederum die allgemein im Netz verwendete SSID sowohl im 5-GHz- als auch im 2,4-GHz-Band bereit.

Das Kommando »batctl o« zeigt die Originators an, also die Rohdaten der einzelnen Knoten im Netz. Diese Liste kann recht umfangreich ausfallen, daher haben wir sie in Listing 7 stark gekürzt.

# batctl o
[B.A.T.M.A.N. adv openwrt-2019.2-7, MainIF/MAC: eth0.3/f4:f2:6d:b6:bb:b6 (bat0/ae:ff:80:88:81:a8 BATMAN_IV)]
   Originator    last-seen (#/255) Nexthop        [outgoingIF]
   c2600_2.2ghz  0.500s    ( 78)   newifi-d2.2ghz [     mesh1]
   c2600_2.2ghz  0.500s    (  0)   newifi-d2.5ghz [     mesh0]
   c2600_2.2ghz  0.500s    (  0)       r6800.5GHz [     mesh0]
      mir3g.eth  1.330s    (  0)        c7v5.2ghz [     mesh1]
      mir3g.eth  1.330s    (  0)        c7v2.2ghz [     mesh1]
      mir3g.eth  1.330s    (  0)        c7v5.5ghz [     mesh0]

Das Batman-adv-Mesh ist damit betriebsbereit. Bisher kann aber noch kein Endgerät das Mesh nutzen – das erfordert noch einen Access-Point-Eintrag. Außerdem müssen Sie den Access Point mit dem Mesh und dem LAN-Anschluss in eine Bridge zusammenschalten.

Access Points anlegen

Der Access Point muss zwar nicht auf demselben Sendeempfänger laufen, darf das aber durchaus. Listing 8 zeigt ein Beispiel für einen Access Point im 2,4-GHz-Band innerhalb eines 5-GHz-Meshs. Das zugehörige Device heißt in diesem Fall »radio1«. Sie dürfen zu jedem »radioX« mehrere Access Points mit verschiedenen SSIDs und Kennwörtern definieren, auch mit Isolation zwischen den angebundenen Endgeräten. Um am Mesh und am Übergang zum LAN teilzunehmen, gilt es, in allen Definitionen das richtige Bridge-Interface (hier: »lan«) zu verwenden.

config wifi-iface 'prod_radio1'
   option device 'radio1'
   option mode 'ap'
   option ssid 'SSID'
   option key '01234567890123456789'
   #  wird gebridged mit 'lan',
   #  siehe /etc/config/network
   option network 'lan'
   option ieee80211w '1'
   option ieee80211r '1'9
   option mobility_domain '6f68'
   option disabled '0'
   option ft_over_ds '1'
   option ft_psk_generate_local '1'
   option encryption 'psk2'

OpenWrt beherrscht seit Version 19.07 auch WPA3, viele Endgeräte aber nicht. Daher gibt es den WPA2/WPA3-Mixed-Mode. Ein beim ersten Versuch abgewiesener Client versucht es einfach erneut. Allerdings agieren manche Endgeräte beim Wiederverbinden nach einem misslungenen Versuch recht träge, sodass die Standardvorgabe von einer Sekunde in OpenWrt dafür deutlich zu kurz ausfällt. Das Endgerät wird dann für lange Zeit (10 Stunden) geblockt. Abhilfe verschaffen unter Umständen diese Einstellungen aus Listing 9. Allerdings gibt es trotzdem Endgeräte, die sich nicht mit einem solchen Access Point verbinden, obwohl sie WPA2 beherrschen.

# WPA2/WPA3 mixed
option encryption 'sae-mixed'
# MFP optional
option ieee80211w '1'
# Reassociation deadline
option reassociation_deadline '10000'

Bridge einrichten

Im letzten Schritt richten Sie jetzt noch eine Bridge (hier »lan«) ein, die den Datenverkehr über das Batman-adv-Interface »bat0«, die definierten Access Points und den Ethernet-Anschluss für das LAN zusammenschaltet. In der »/etc/config/network« definieren Sie dazu die Netzwerk-Bridge »lan« mit mindestens einem physikalischen Interface, es muss aber kein Kabel verbunden sein. Das Anschließen eines LAN-Kabels macht dabei automatisch aus einem MP/MAP einen MPP. Im Beispiel aus Listing 10 kommt nur IPv4 zum Einsatz, kein IPv6.

config interface 'lan'
  option type 'bridge'
  option proto 'static'          # statische IP
  # option proto 'dhcp'          # für DHCP
  option netmask '255.255.255.0'
  option broadcast '10.10.0.255'
  option ipaddr '10.10.0.10'     # IP des Geräts
  option gateway '10.10.0.1'     # IP des externen Routers
  list dns 'x.x.x.x'
  list dns 'y.y.y.y'
  list dns '8.8.8.8'        # Google DNS
  option igmp_snooping '1'  # wenn Multicast ins WLAN soll
  option stp '1'            # Spanning Tree Protocol anschalten
  option delegate '0'       # IPv6-Funktionalität ausschalten
  option ifname 'eth0 bat0' # LAN-Buchse und Batman-adv

Fazit

OpenWrt konfiguriert einiges “automagisch”. Der Eintrag »option network ‘lan’« in den Wi-Fi-Interfaces für die APs und das Vorhandensein des Interfaces »lan« in »/etc/config/network« bewirken zusammen mit der Auflistung von »bat0« und »eth0« in der LAN-Bridge, dass der Access Point mit dem Mesh und auch dem aufgeführten Ethernet-Port gebridged wird. Das klappt ohne jede weitere Konfiguration.

Ein entsprechend aufgesetztes Gerät arbeitet ohne Änderungen als MP, MPP, MAP oder Kombination daraus. Um die MAP-Funktion abzuschalten, setzen Sie lediglich in der Access-Point-Konfiguration den Wert für »disabled« von 0 auf 1 und starten das WLAN neu. (jcb/jlu)