© scx.hu

Ein WLAN ist eine zentralistische Sache und räumlich rund um den Accesspoint begrenzt. Die bisherigen Linux-Mesh-Implementationen für den Ad-hoc-Modus umwehte der Hauch einer Bastelstube. Die Aufnahme des offiziellen IEEE 802.11s-Codes in den Linux-Kernel könnte das ändern.

Wenig eingesetzt, aber trotzdem möglich: Um ein WLAN zu betreiben, ist ein Accesspoint nicht zwingend. Die meisten Anwender aber verwenden den so genannten Infrastruktur-Modus, bei dem sich alle Clients mit einer Zentrale verbinden. In einem typischen Heim- oder Büronetzwerk sucht jeder Client den Router, der in Funktionsunion oft auch WLAN-Accesspoint ist.

Dabei gibt andere Möglichkeiten WLAN-Netze aufzubauen. Eine davon ist der Ad-hoc-Modus. Bei ihm gibt es keine zentrale Verwaltung. Stattdessen sind alle Teilnehmer gleichberechtigt und gleichzeitig sowohl Client als auch Master. So lassen sich auch ohne feste Infrastruktur schnell kleine Netze aufbauen.

Nur einen Link mittels Ad-hoc-Mode aufzubauen reicht aber nicht aus: IP-Adressen vergibt normalerweise ein DHCP-Server im Accesspoint. Er nennt dem Client auch den Nameserver und das Default-Gateway. Fehlt ein Accesspoint, müssen die angeschlossenen Geräte diese Daten selbst aushandeln. Da Anwender solch kleiner Ad-hoc-Netze primär unkompliziert und schnell eine Datenübertragung aufbauen wollen, genügen meist die Hausmittel der Betriebssysteme, um sie einzurichten.

Rohe Maschen

Nutzen WLAN-Anwender nur den reinen Ad-hoc-Modus, stoßen sie schnell an Grenzen. Unmittelbare Nachbarn sind so zwar erreichbar, aber als Zwischenstationen lassen sich andere Netzteilnehmer auf diese Weise nicht verwenden. Auch auf Treiber-Ebene gibt es Probleme. Manche Betriebssysteme unterstützen beispielsweise nur zwei Clients in einem solchen Netz. Gerade in schnell aufgebauten Netzen möchten sich Nutzer nicht darum kümmern, welche Funkverbindungen zwischen welchen Rechnern sich nun besser oder schlechter eignen. Hier kommt Meshing ins Spiel. Insbesondere der Standard IEEE 802.11s verspricht, die einige diese Hürden zu beseitigen.

Meshing bezeichnet den Zusammenschluss mehrerer Knoten, wie es zum Beispiel in einem Ad-hoc-Netzwerk der Fall ist. Das können Computer, Notebooks, aber auch IP-fähige Smartphones sein. Das Mesh-Protokoll versucht automatisch den bestmöglichen Weg für ein Paket zu wählen. Es bestehen also keine festen Verbindungen zwischen einzelnen Knoten. Das Protokoll sucht selbst für jedes Paket immer wieder die besten Verbindungen heraus.

Sich ändernde Umgebungen

Meshing gleicht seine Daten möglichst oft ab, typischer alle paar Sekunden. So erreicht es eine hohe Dynamik und reagiert auf geänderte Bedingungen, die sich durch bewegende Knoten, Hindernisse oder die Belegung einer Direktverbindung ergeben. Jede aktive Linkstrecke bewertet es nach bestimmten Kriterien und wählt die beste aus. Das Routing ist somit eine der wichtigsten und auch teuersten Aufgaben des Meshings.

Entwickler haben schon auf unterschiedliche Weisen Meshing implementiert [1]. Die bekanntesten sind OLSR (siehe Kasten “Optimized Link State Routing”, [2]) und das sperrige “Better Approach to Mobile Ad-hoc Networking” (siehe Kasten “B.A.T.M.A.N.”, [3]). Beide verwenden Routing auf dem OSI-Layer 3, um Wege im Mesh zu finden. Das neuere Batman Advanced [4], ein unabhängig entwickelter Fork, verwendet dagegen Switching auf OSI-Layer 2. Je nach Einsatzzweck haben das Network- und das Link-Layer ihre jeweiligen Vorteile.

Routing lässt sich intuitiver implementieren und kontrollieren, verbraucht aber auch viele Ressourcen in den Knoten, die häufig nicht mit üppigen CPUs ausgestattet sind.

Das weit verbreitete Linksys WRT54G etwa (siehe Abbildung 1) taktet seine CPU je nach Modell mit zwischen 125 und 240 MHz [6]. In einem Meshnode III [7] versieht eine Geode-CPU mit 500 MHz Taktung ihren Dienst (siehe Abbildung 2). Das ist zwar schon mehr als das Linksys, lässt sich aber dennoch bei weitem nicht mit der Leistung eines typischen PC-Systems vergleichen. Solche kleinen Geräte benötigen daher die 10- bis 20-fache Zeit eines Desktop-Systems, um die Topologie komplett neu zu berechnen.

Für das OLSR existieren Plugins und alternative Berechnungsmethoden, um die hardwarebedingt eingeschränkte Skalierbarkeit auszugleichen. Batman hat diese Problematik bereits bei der Entwicklung berücksichtigt. Beide Protokolle erlauben anzugeben, ob ein Knoten Zugang zum Internet hat und damit als Gateway für andere Knoten agieren kann. Bei Batman lässt sich zusätzlich die Bandbreite angeben, mit der das Gateway das Internet anbindet. Auf diese Weise suchen sich Clients das günstigste Gateway. Kein Client ist dabei auf eine zentrale Stelle angewiesen, die diese Informationen für alle verwaltet.

Abbildung 1: Das unter Linux-Anwendern verbreitete Linksys WRT54G beherrscht Meshing, allerdings ist seine CPU für die komplexen Routingalgorithmen beim Meshing oft etwas schwach.

Abbildung 2: Das Saxnet Meshnode III ist besonders für den vermaschten Betrieb in Gebäuden und im Freien vorbereitet und bringt gleich vier Wireless-Module mit, die eine Geode-CPU organisiert.

Wenn zwei sich streiten …

Die Weiterentwicklung Batman Advanced arbeitet nicht mit Routen, sondern operiert auf dem Link-Layer. Dadurch sieht das Mesh-Netz für einen Benutzer logisch wie Segment aus, das ein Ethernet-Switch verwaltet. Aus Sicht des Anwenders gibt es eine direkte Verbindung zu jedem Teilnehmer, das Protokoll verbirgt alle weiteren Details.

Damit kommt Batman Advanced dem Standard 802.11s am nächsten, indem es komplett auf Layer 2 (Switching) setzt. Leider ist damit aber auch die Funktionalität entfallen, einen Knoten als Gateway bekannt zu machen: Deren Verwaltung liegt in den Händen des Administrators oder eines weiteren auf Batman Advanced aufsetzenden Protokolls.

IEEE 802.11s

Diesen Ansatz verfolgt auch die Taskgroup “s” der IEEE seit 2003. Bisher ist IEEE 802.11s nur ein Draft [8], der wohl auch vor 2010 noch nicht offiziell verabschiedet sein wird. Einige Entwickler bewerten ihn nichtsdestotrotz aber als fortgeschritten genug, um ihn zu implementieren. Das OLPC-Projekt (One Laptop per Child, [9]) hat eine Linux-Implementation initiiert. Seit der Version 2.6.26 unterstützt das Open80211s-Team den Standard rudimentär im Linux-Kernel [10]. Sie baut auf dem vorhandenen »mac80211«-Subsystem auf. Der Code in 2.6.26 erlaubt es jedoch noch nicht, echte Mesh-Netze damit aufzubauen. Mit den aktuellen Entwicklerversionen des Git-Repository »wireless-testing« ist dies dagegen bereits möglich [11].

802.11s basiert wie Batman Advanced darauf, dass jeder Knoten nur seine direkten Nachbarn kennt. Jeder Knoten sendet seine Pakete für einen bestimmten Zielpunkt also an den Knoten, den er für am geeignetsten hält, sie näher zum Zielsystem zu transportieren. Der geht nach dem gleichen Muster vor, bis das Paket schließlich sein Ziel erreicht.

Das Protokoll stellt ebenfalls eine Modellierung eines geswitchten Segmentes bereit, sodass es kein Routing zwischen den Teilnehmern anpassten muss. Das bedeutet aber auch, dass die Teilnehmer Routing-Angaben, wie das Default-Gateway, unabhängig vom Mesh-Netz aushandeln. Auf die Weise lässt sich der Übergang ins Internet umsetzen.

Im Kernel konvergieren die Infrastrukturen

Anwender dürfen sich darauf freuen, dass in folgenden Kernelversionen IEEE 802.11s deutlich einfacher wird, wenn immer mehr WLAN-Treiber das Subsystem »mac80211« unterstützen. Es zwingt die WLAN-Programmierer dazu, ihm eine einheitliche Schnittstelle anzubieten. Mit fortschreitendem Entwicklungsstand erwarten die Entwickler daher auch, dass IEEE 802.11s nicht nur mit wenigen Spezialkarten funktioniert, sondern dass es die Anbieter umfassend in den Treibern implementieren.

Die Vorraussetzungen sind bereits bei allen Treibern vorhanden, die das neue Modell honorieren. Die nötigen Anpassungen für IEEE 802.11s integrieren die Programmierer mit den nächsten Versionssprüngen. Im August 2008 unterstützte der Linux-Kernel Meshing mit dem Treiber »ath5k« mit einem Patch, »b43«, »libertas_tf« und »zd1211rw« sogar nativ. In der Linux-Version 2.6.26 läuft »zd1211rw« bereits mit IEEE 802.11s.

Wer ein Mesh-Netz aufbauen möchte und mehr als drei Knoten plant, hat mehrere Optionen für den Aufbau. Exemplarisch zeigt das Linux-Magazin eine typische Stadtteil- oder Dorfvernetzung.

Maschen aufnehmen

Der Hauptknotenpunkt des Netzes verfügt über eine Standleitung zum Internet, etwa über DSL oder UMTS. Auf ihm richtet der Betreiber auch als einzigem Gerät die Gatewayfunktionialität ein, etwa durch »echo 1 > /proc/sys/net/ipv4/ip_forward« und eventuell entsprechende NAT-Regeln für das Masquerading. Die einzelnen Mesh-Knotenpunkte sollten über mindestens zwei WLAN-Module verfügen. Ab drei Modulen erhöht sich je nach Konfiguration die Verfügbarkeit oder die Zahl der möglichen Clients. Typischerweise läuft ein Modul im Accesspoint-Modus, um als Zugang für Clients zu wirken. Das oder die anderen Module nutzen den Ad-hoc-Modus für das Meshing. Optimalerweise nutzen alle Module Rundstrahlantennen, die einen großen Empfangsbereich abdecken (siehe Abbildung 3).

Abbildung 3: Ein typisches Dorf- oder Stadtteilnetz besteht aus zwei Arten von Teilnehmern: Clients verbinden sich auf herkömmliche Weise per Infrastructure-Mode an die Knoten, die sich untereinander per IEEE 802.11s organisieren. Ein Knoten hat einen Zugang zum Internet.

Hat ein Netzbetreiber mehr Module pro Knoten zur Verfügung, kann er die Antennen flexibler konfigurieren: So lassen sich etwa drei Module mit Sektorantennen für Clients und ein Modul für das Meshing einsetzen – geeignet für sehr viele zu versorgende Clients und nahe beieinander stehende Mesh-Nodes wie bei einer Konferenzveranstaltung. Umgekehrt bietet sich in einer unübersichtlichen Lagerhalle vielleicht an, mehr Module für das Meshing zu verwenden, dafür sind dort weniger Clients anzutreffen.

Knoten in Sicht

Um einen guten Datendurchsatz zu erzielen, sollten WLAN-Geräte optimalerweise in Sichtverbindung zueinander stehen. Wenn eine Station mit einer oder mehreren Stationen verlässlich und dauerhaft erreicht, erhöhen Richtstrahlantennen die Leistungsdaten des Meshs.

Den räumlichen Bereich, in dem sich die Funkwellen zwischen einem Sender und Empfänger vornehmlich ausbreiten, nennen Nachrichtentechniker Fresnelzone. Sie hat eine linsenförmige Form, in deren Brennpunkten Sender und Empfänger stehen (siehe Abbildung 4). Das sie in der Mitte bauchiger wird, sollten Mesh-Teilnehmer die Knoten hinreichend hoch anbringen. Außerdem sollen sie darauf achten, dass möglichst wenig Gegenstände wie Gebäude, Wände oder Bäume in die Fresnelzone ragen, um die Übertragungseigenschaften nicht zu beeinträchtigen.

Abbildung 4: Mesh-Nodes sollten hoch und ohne Hindernisse in der so genannten Fresnelzone angebracht sein, um Dämpfungen des Signals zu vermeiden.

Eine Frage des Standorts

Es kann durchaus passieren, dass bei schlecht gewählten Standorten keine Verbindung zustande kommt. Umgekehrt verringert ein guter Aufstellungort die Anzahl notwendiger Knoten deutlich – in der Praxis erfordert WLAN also immer ein wenig Experimentierfreude.

Nachdem nun jedes Gerät einen Platz und passende Antennen hat, gibt es sicherlich eine Vorstellung, wie die Geräte sich höchstwahrscheinlich verbinden sollten und welche Strecken am besten sein müssten. Dieses Wissen ist wichtig, weil sich nur auf die Art bewerten lässt, ob alle Antennen korrekt ausgerichtet sind und sich so das gewünschte Ergebnis einstellt. Wenn beispielsweise eine Antenne einer Station zwischen zwei wichtigen Knoten nicht korrekt ausgerichtet ist und daher keine Verbindung zu einem nahen weiteren Knotenpunkt hat, funktioniert in aller Regel das Mesh insgesamt weiterhin. Es wäre aber in diesem Fall auf weitere Hops angewiesen.

Solche Probleme entdeckt des Mesh-Architekt schnell, wenn er sich a priori einen groben Plan macht, wie das Mesh aussehen soll und er diesen Plan inkrementell mit der Wirklichkeit abgleicht und gegebenenfalls verbessert.

Auf der Hardwareseite sind Wireless-Module notwendig, die den Standard unterstützen, um ein IEEE-802.11s-Mesh einzurichten. Das Konfigurationsbeispiel in Abbildung 5 beschreibt eine Variante mit einem einzelnen WLAN-Modul, mehr liefern natürlich verlässlichere Ergebnisse.

Abbildung 5: Unterstützt die Wirelesskarte den neuen Mesh-Mode nach IEEE 802.11s, lässt sich ein Mesh-Interface mit dem Kommando »iw« anlegen.

Linux nun standardkonform

Das Git-Repository »wireless-testing« stellt eine aktuelle Version des Kernels mit entsprechenden Treibern bereit:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git

lädt eine aktuelle Version herunter. Um das Meshing zu konfigurieren, wählt der Systemverwalter die Treiberplattform Mac80211, »CONFIG_MAC80211«, und die Mesh-Eigenschaft »CONFIG_MAC80211_MESH« aus. Dazu kommen noch die passenden Treiber, etwa »CONFIG_ZD1211RW« für die WLAN-Karte Zd1211-rw. Danach übersetzt und bootet er den neuen Kernel.

Im Userspace benötigt der Admin das Tool »iw«, um die Netzwerkkarte zu konfigurieren [12]. Das Werkzeug soll langfristig eine einheitliche Alternative zu »iwconfig« und seinen Geschwisterkommandos sein, so wie »ip« eine Variante für »ifconfig« und Konsorten ist. Da es für viele Distributionen noch kein Paket gibt, lädt der Administrator die Quellen für »iw« ebenfalls über Git herunter:

git clone http://git.sipsolutions.net/iw.git

Das Paket hängt von der »libnl« ab, die mindestens die Version 1.0-pre8 haben sollte [13]. Unter Debian oder Ubuntu gibt es dazu das Paket »libnl-dev«.

Neue Netzwerk-Interfaces

Um das Mesh mit dem neuen Werkzeug zu konfigurieren, wählt der Administrator eine Mesh-ID. Er muss sie auf jedem Knoten des Mesh identisch konfigurieren. Die ID darf aus maximal 32 Zeichen bestehen, im Beispiel heißt es »MyMesh«. Danach richtet er beispielsweise das Interface »wmaster0« ein:

iw dev wmaster0 interface add mesh0 type mp mesh_id MyMesh

Mit diesem Schritt entsteht ein neues Interface, das der Administrator für den Betrieb als Gateway 10.0.0.1 einzurichten hat. Um die Einstellungen vorzunehmen, benutzt er die üblichen Kommandos »ifconfig« um IP-Adresse und Netzmaske zu setzen und »iwconfig«, um etwa den Kanal 7 für das Mesh-Netz festzulegen:

iwconfig mesh0 channel 7
ifconfig mesh0 10.0.0.1 netmask 255.255.255.0 up

Nachdem der Systemverwalter diese Schritte auf allen am Mesh beteiligten Geräten ausgeführt hat, baut sich das Mesh-Netz auf. Verifizieren lässt sich das mit dem Befehl:

iw dev mesh station dump

Jeder erreichte Knoten meldet sich hier in der Liste. Auf diese Weise kontrolliert der Admin, ob das Protokoll zwischen den erwarteten Knoten eine Verbindung aufgebaut hat. Zum vorläufigen Abschluss richtet er auf dem Hauptknoten mit Internetzugang noch DHCP und NAT ein.

Weg nach draußen

Unter Debian konfiguriert er das Paket »dhcp3-server« in »/etc/dhcp/dhcpd.conf« wie in Listing 1 beschrieben. Es sieht für das Mesh-Netz »my-mesh.org« das private Subnetz 10.0.0.0/24 vor, konfiguriert auf der Adresse 10.0.0.0.1 das Gateway und teilt den Clients mit, dort ebenfalls nach einem Nameserver anzufragen. Der findet sich im Debian-Paket »bind9«. Der Admin trägt im einfachsten Fall in »/etc/bind/named.conf.options« die IP-Adresse eines bekannten DNS-Servers im Internet in die Sektion »forwarders« ein. Als letzten Schritt aktiviert er noch die Einstellung

net.ipv4.ip_forward=1

in »/etc/sysctl.conf«, um aus dem Mesh-Netz heraus ins Internet zu routen und sorgt zudem mit

iptables -A POSTROUTING -t nat -s 10.0.0.0/24 -j MASQUERADE

für ein Masquerading der privaten Adressen des Funknetzes auf die öffentliche IP-Adresse des Routers. Damit ist der Hauptknoten fertig vorbereitet.

Der Admin konfiguriert das Mesh-Netz auf allen Knoten ebenso mit »iw«. Die IP-Adressen und DNS-Angaben bekommen sie per DHCP mitgeteilt. Sollen sie zusätzlich den Zugang für normale Clients ohne Mesh-Support ermöglichen, richtet der Admin auf diesen Knoten zusätzliche Wireless-Module ein, die den Host-AP-Mode beherrschen [14].

01 subnet 10.0.0.0 netmask 255.255.255.0 {
02   range                       10.0.0.100 10.0.0.199;
03   option routers              10.0.0.1;
04   option domain-name          "my-mesh.org";
05   option domain-name-servers  10.0.0.1;
06   default-lease-time          600;
07 }

Noch am Anfang

Die Implementation von IEEE 802.11s steht erst am Anfang, was nicht zuletzt dadurch deutlich wird, dass der Standard selbst noch nicht endgültig verabschiedet ist. Etwas Zeit wird noch vergehen, bis noch mehr Karten und Treiber verfügbar sind, die den Mesh-Standard beherrschen. Bis dahin ist auch nicht auszuschließen, dass sich Details der Konfigurationswerkzeuge noch ändern. Die richtigen Karten und Tools vorausgesetzt lässt sich die Technik schon heute ausprobieren. Dem experimentellen Bürger-Funknetz im eigenen Viertel steht nichts im Wege.