IEEE 802.11s Mesh Network - Allgemeines

IEEE 802.11s Mesh Network - Allgemeines

Hochschule RheinMain — Master Informatik — Masterprojekt
IEEE 802.11s Mesh Network
auf SoHo Routern mit OpenWRT
Thomas Wagner
26. August 2012
Inhaltsverzeichnis
Inhaltsverzeichnis
I
Abbildungsverzeichnis
III
1 Einführung
1.1 Wireless Mesh Networks . . . . . . . . . . . . .
1.1.1 Einsatzgebiete . . . . . . . . . . . . . .
1.2 Überblick über IEEE 802.11s . . . . . . . . . .
1.2.1 Komponenten eines 802.11s-Meshnetzes
1.2.2 Einsatzgebiete . . . . . . . . . . . . . .
1.3 OpenWRT . . . . . . . . . . . . . . . . . . . .
1.4 Das Projekt . . . . . . . . . . . . . . . . . . .
1.4.1 Ziel des Projektes . . . . . . . . . . . .
1.4.2 Anpassung des Projektzieles . . . . . .
1.4.3 Projektabschluss . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 IEEE 802.11s-Meshnetzwerk im Betrieb
2.1 Erweiterung des 802.11-Frames . . . . . . . . . . . . . . . . .
2.2 Vermaschung . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Address Resolution Protokoll . . . . . . . . . . . . . . . . . .
2.4 Hybrid Wireless Meshprotokoll . . . . . . . . . . . . . . . . .
2.4.1 Aufbau eines Pfades . . . . . . . . . . . . . . . . . . .
2.4.2 Reaktiver Modus . . . . . . . . . . . . . . . . . . . .
2.4.3 Proaktiver Modus . . . . . . . . . . . . . . . . . . . .
2.4.4 Vor- und Nachteile der verschiedenen Routingvarianten
2.5 Überblick über die verschiedenen Kommunikationsebenen . . .
3 IEEE 802.11s-Meshnetzwerke unter Linux
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
3
4
4
5
5
5
5
.
.
.
.
.
.
.
.
.
6
6
8
8
9
10
11
11
12
12
13
Inhaltsverzeichnis
3.1
3.2
Verhältnis zwischen Mesh Points und Mesh Access Points . . . . . . . . . . 14
Meshframehandling im Linuxkernel . . . . . . . . . . . . . . . . . . . . . . 15
4 IEEE 802.11s-Meshnetzwerke unter OpenWRT
4.1 UCI - das OpenWRT-Konfigurationstool . . .
4.1.1 802.11s per UCI einrichten . . . . . .
4.1.2 LUCI - Webkonfigurationsinterface . .
4.2 Verschlüsselung . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
5 Troubleshooting
5.1 Kein Datenaustausch im 802.11s-Meshnetzwerk .
5.1.1 Manuelles Füllen der Tabellen . . . . . .
5.2 ARP-Verabeitung . . . . . . . . . . . . . . . . .
5.2.1 ARP-Filterung per sysctl . . . . . . . . .
5.3 Open11s-Funktionen in der MAC80211-Schicht .
5.4 Welche Frames erreichen die MAC80211-Schicht
5.5 Fehlerbehebung . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
17
18
18
.
.
.
.
.
.
.
19
19
20
20
20
20
20
21
6 Zusammenfassung
23
6.1 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.1 LUCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.2 Auth SAE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A 802.11s-Meshnetz mit iw verwalten
A.1 Aufsetzen eines 802.11s-Meshnetzes
A.2 Netzstatus abfragen . . . . . . . . .
A.3 Mesh-Parameter . . . . . . . . . . .
A.4 Verschlüsseltes Mesh einrichten . . .
B 802.11s-Meshnetz unter OpenWRT
B.1 Mesh Point . . . . . . . . . . .
B.2 Mesh Portal (MPP) . . . . . . .
B.3 Mesh Access Point (MAP) . . .
B.4 Mesh-Parameter . . . . . . . . .
B.5 Verschlüsselung . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
einrichten
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
25
26
27
.
.
.
.
.
28
29
31
34
36
36
C OpenWRT mit 802.11s für WRT160NL kompilieren
38
Literaturverzeichnis
41
II
Abbildungsverzeichnis
1.1
1.2
Wireless Mesh Network mit direktem Path und Path über mehrere Hops . . . .
Netzwerk mit Mesh Point, MPP und MAP . . . . . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
Standard-802.11-Frame wird um das Mesh-Control-Field erweitert .
Sequenznummer bei Broadcast . . . . . . . . . . . . . . . . . . . .
Peerbildung nach Beacon-Empfang . . . . . . . . . . . . . . . . . .
Erwartungsgemäßes Verhalten der Verarbeitung eines ARP-Request.
Path Request nach Senden des Rootannouncments . . . . . . . . .
3.1
3.2
Das Open 11s-Projekt steuert 802.11s-Erweiterungen für Linux Wireless bei. . . 13
Treiber übergibt Frame an MAC80211 . . . . . . . . . . . . . . . . . . . . . . 15
5.1
ARP-Reply kann wegen fehlenden Pfades nicht gesendet werden. . . . . . . . . 19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Quelle der in den Abbildungen verwendeten Cliparts: openclipart.org, Public Domain.
III
.
.
.
.
.
1
3
. 6
. 7
. 8
. 9
. 11
Kapitel 1
Einführung
Dieses Kapitel vermittelt zunächst die Grundlagen, auf denen dieses Projekt aufbaut.
Abschnitt 1.1 beschreibt allgemeine (Wireless) Mesh Networks. Anschließend geht Abschnitt 1.2
auf den Spezialfall IEEE 802.11s ein. Zum Betreiben des Meshnetzes kommt in diesem Projekt das
in Abschnitt 1.3 beschriebene OpenWRT als Betriebssystem zum Einsatz.
Nach Vermittelung der Grundlagen werden in Abschnitt 1.4 die Ziele dieses Masterprojektes genauer
beschrieben.
1.1
Wireless Mesh Networks
Wireless Mesh Networks (WMN) sind kabellose Ad-hoc-Netzwerke, die ohne feste Infrastruktur auskommen. Netzaufbau und Konfiguration finden automatisch statt. Knoten, die im direkten Funkkontakt stehen, bauen einen virtuellen Datenkanal (Peer ) zueinander auf, wie Abbildung 1.1 zeigt.
Abbildung 1.1: Wireless Mesh Network mit direktem Path (gelb) und Path über mehrere
Hops (orange).
1
1.2. Überblick über IEEE 802.11s
Über diesen Datenkanal können benachbarte Knoten direkt miteinander kommunizieren. Nachrichten an entfernte Knoten müssen von den WMN-Teilnehmern entsprechend weitergeleitet werden.
Die Strecke von Datenquelle (sendender Knoten) zu Datensenke (empfangender Knoten) wird als
Pfad bzw. Path bezeichnet. In der Regel haben Meshnetzwerke auch keinen zentralen Knoten bzw.
Master-Knoten. Alle Teilnehmer sind gleichberechtigte Kommunikationsparter. Peers und Paths
zwischen den Knoten werden ständig aktualisiert. Dies erlaubt eine hohe Dynamik hinsichtlich der
Topologie des Netzwerkes. Außerdem zeichnet sich ein Meshnetz durch eine gute Skalierbarkeit
aus. Die Knoten können sich also jederzeit in ein Mesh ein- und ausbuchen, sowie ihre Position
innerhalb des Netzwerkes verändern.
1.1.1
Einsatzgebiete
Wireless Mesh Networks sind vielseitig einsetzbar. Nachfolgend werden beispielhaft zwei Einsatzszenarien erläutert.
Sensornetzwerke:
In einem Sensornetzwerk werden die einzelnen Sensoren häufig über ein
Meshnetz miteinander verbunden. Dieses Meshnetz (WSN, Wireless Sensor Network) kann von
außen als eine einzige logische Sensorenplattform betrachtet werden.
Internet in strukturschwachen Regionen:
In strukturschwachen Regionen, in denen kein
DSL oder vergleichbar schnelle Internetanbindungen verfügbar sind, werden Meshnetze genutzt,
um einzelne Haushalte per Funk an das Internet anzuschließen. Die einzelnen Häuser werden mit
Antennen ausgestattet und vernetzen sich untereinander. Zusätzlich wird mindestens ein Haus per
Richtfunk mit einem Sendemast verbunden, der dann den Zugang zum Internet für das gesamte
Meshnetz zur Verfügung stellt.
1.2
Überblick über IEEE 802.11s
Das Institute of Electrical and Electronics Engineers (IEEE) hat seine WLAN-Spezifikation 802.11
mit der Teilspezifikation 802.11s [11s] um einen Standard für Meshnetzwerke erweitert. Die Spezifikation hat zur Zeit den Status Draft. Sie ist also noch nicht endgültig abgeschlossen. Das besondere
dabei ist, dass das Routing auf MAC-Ebene stattfindet (Layer 2 des OSI-Modells) und nicht wie
sonst üblich auf IP-Ebene (OSI-Layer 3). Dies macht das Routing sehr effizient hinsichtlich Bearbeitungszeit, Ressourcenbedarf und Energieverbrauch. Für die Anwendungsebene wird das Routingverfahren transparent gehalten. Anwendungen können über normale IP-Sokets kommunizieren.
Es müssen keine speziellen MAC-Sockets implementiert werden. Dies geschieht durch das Address
Resolution Protokoll (ARP), welches IP-Adressen auf MAC-Adressen abbildet (siehe [ARP]).
Wie in Meshnetzen üblich, können auch in 802.11s-Netzen ständig Teilnehmer wegfallen und
neue hinzukommen. Daher wird auf die Verwendung von DHCP verzichtet. Gemäß der Spezifikation ist nämlich nicht gewährleistet, das ein DHCP-Server immer verfügbar ist. Die IP-Adressen
2
1.2. Überblick über IEEE 802.11s
müssen von den Meshteilnehmern statisch konfiguriert werden. Kapitel 2 erläutert die wichtigsten
Vorgänge im Betrieb eines 802.11s-Meshnetzes, wie die Vermaschung der Knoten und das Routing
der Datenpakete.
Parameter eines 802.11s-Meshnetzes:
• Mesh-ID: Identifiziert ein Meshnetz und ist somit das Pendant zur ESSID im herkömmlichen
WLAN-Netz. Alle Netzwerkteilnehmer mit derselben Mesh-ID bilden ein Meshnetz.
• Kanal/Frequenz: Es werden die im 802.11-Standard-üblichen Kanäle und Frequenzen genutzt. Die Teilnehmer eines Meshnetzes müssen denselben Kanal verwenden.
• Bandbreite: Standardgemäß wird eine Bandbreite von 20 MHz genutzt. Optional kann, wie
beim IEEE 802.11n-Standard, auch eine Bandbreite von 40 MHz gewählt werden.
Verschlüsselte Kommunikation:
Da laut Spezifikation ein 802.11s-Meshnetzwerk stark skaliert, kann es keinen zentralen Knoten als Authentifizierungsserver geben. Die Authentifizierung
muss Peer-2-Peer über einen Preshared-Key erfolgen. Hierfür können die in IEEE 802.11i definierten Authentifizierungsmethoden wie WPA2 eingesetzt werden.
Als Alternative definiert 802.11s mit [SAE] ein eigenes Authenfizierungs- und Verschlüsselungsprotkoll: Simultaneous Authentication of Equals (SAE, Auth SAE). Auth SAE wendet Zero-KnowledgeProof an. Es ist sicher gegenüber aktiven und passiven Attacken, so wie Wörterbuchattacken.
1.2.1
Komponenten eines 802.11s-Meshnetzes
Abbildung 1.2: Netzwerk mit Mesh Point (MP), Mesh Portal (MPP) und Mesh Access
Point (MAP)
Die Teilnehmer eines 802.11s-Meshnetzwerkes werden als Mesh Point (MP) bezeichnet. Ein MP
kann ein Router sein, aber auch ein 802.11s-fähiges Laptop, dass sich mit dem Mesh verbunden hat.
Die Mesh Points können zusätzlich zwei Sonderrollen einnehmen. Ein Mesh Access Point (MAP)
gehört zum einen zu einem Mesh wie ein gewöhnlicher MP, zum anderen gibt er sich als normaler
802.11a/b/g/n-Access Point aus und macht somit das Mesh für herkömliche WLAN-Endgeräte
3
1.3. OpenWRT
nutzbar. Ein Mesh Portal (MPP) verbindet das Mesh mit einem andren Netzwerk (Gateway). Es ist
möglich, einen Meshknoten gleichzeitig als MAP und MPP zu konfigurieren. Abbildung 1.2 zeigt
ein Meshnetz mit verscheidenen Komponenten.
1.2.2
Einsatzgebiete
Der Einsatzzweck von 802.11s liegt hauptsächlich im Ersatz kleinerer interner Netzwerke, sowie im
Last-Mile-Internetaccess (siehe [Abid]). In kleineren Firmen könnte das Intranet durch ein 802.11sMeshnetzwerk realisiert werden. Das Verlegen von Kabeln und die Installation von Switches ist somit
überflüssig. Relativ teure Businesshardware kann durch günstige SoHo-Produkte ersetzt werden. Ein
Firmengebäude kann problemlos mit WLAN abgedeckt werden, ohne dass Repeater, welche in der
Realität oft Probleme verursachen, zum Einsatz kommen müssen.
Auch im Heimbereich kann 802.11s zum Einsatz kommen. In älteren Häusern mit stark abschirmenden Wänden kann das Meshnetz für flächendeckenden Netzwerkzugriff sorgen. Dieses Konzept
kann auf große Wohnalagen ausgedehnt werden. In einem Studentenwohnheim oder einem Hochhaus gäbe es dann einen zentralen High-Speed-Internetzugang. Die einzelnen Wohnungen nutzen
diesen gemäß dem Last-Mile-Internetaccess-Konzept dann über das Meshnetzwerk.
In San Francisco wird dieses Konzept bereits angewandt, um in sozialen Brennpunkten kostenlosen Internetzugang anzubieten. Ein Meshnetz wird hier über ganze Häuserblocks verteilt.
Auch das One Laptop per Child-Projekt1 nutzt den 802.11s-Standard. Im Gegensatz zu den vorher
genannten Einsatzgebieten existiert hier keine feste Infrastruktur, also keine fest installierten Router. Die Laptops vernetzen sich direkt im freien Feld miteinander. Dies ist dank der Dynamik und
Skalierbarkeit der 802.11s-Netze problemlos möglich.
Damit sind Meshnetze auch für den Katastrophenschutz, Rettungsdienst oder die Polizei eine
denkbare Möglichkeit, eine mobile Vernetzung an größeren Einsatzorten umzusetzen. Ein Einsatzleitfahrzeug dient als Gateway zum Internet bzw. zum Polizei-Intranet. Weitere Einsatzwagen vernetzen sich mit dem Einsatzleitfahrzeug. Zudem können Akkubetriebene Router die Reichweite des
Netzes erweitern.
1.3
OpenWRT
OpenWRT ist eine minimale Linuxdistribution, die für den Einsatz auf Embedded Devices, insbesondere für Router, konzipiert worden ist. Die OpenWRT-Community2 stellt sowohl fertige Images
der Stable-Version zum Download, als auch den kompletten Quellcode zusammen mit einer auf Menuconfig basierenden Toolchain über SVN bereit. Der Einsatz von OpenWRT auf SoHo-Routern
bringt diverse Vorteile gegenüber dem Betrieb mit der originalen Firmware. OpenWRT nutzt die
1
2
One Laptop per Child verteilt 100-Dollar-Laptops an Kinder in Entwicklungsländern.
OpenWRT-Homepage: http://www.openwrt.org/; Projektmanagement: https://dev.openwrt.org/
4
1.4. Das Projekt
technischen Möglichkeiten der Hardware nahezu komplett aus, während die Herstellersoftware oft
nur einen bestimmten Bereich an Funktionen zulässt. Kapitel 3 zeigt, dass 802.11s-Meshnetze
unter Linux mit Hilfe des Kernelmoduls MAC80211 betrieben werden. MAC80211 ist für SoftMAC-WLAN-Karten zuständig. Die meisten SoHo-Router setzen diese relativ günstige Variante
von WLAN-Karten ein. OpenWRT kann somit mit sehr vielen Routern 802.11s-Meshnetze aufbauen, auch wenn die Konfiguration noch nicht ganz ausgereift ist, wie in Kapitel 4 zu sehen ist.
1.4
1.4.1
Das Projekt
Ziel des Projektes
Ziel des Projektes ist es ein Meshnetzwerk nach IEEE 802.11s-Standard mit SoHo-Routern aufzubauen. In dem Projekt kommen fünf Router vom Typ Linksys WRT160NL3 zum Einsatz. Diese
werden mit OpenWRT Backfire 10.03.1 (Stable, Dez. 2011) oder der Entwicklerversion Attitude
Adjustment (Version: r32582) aus dem SVN-Trunk geflasht. Es soll dokumentiert werden, wie ein
Meshnetzwerk unter OpenWRT konfiguriert und aufgebaut werden kann. Bisher fehlende Konfigurationsmöglichkeiten sollen durch entsprechende Erweiterungen ergänzt werden. Mit diesem
Dokument werden wichtige Komponenten von 802.11s erläutert und die Umsetzung von 802.11s
unter Linux und OpenWRT betrachtet.
1.4.2
Anpassung des Projektzieles
Das Meshnetzwerk ließ sich mit der gegebenen Hardware zwar aufbauen, aber das Austauschen
von Daten zwischen den einzelnen Knoten schlug fehl. Das Projektziel wurde dementsprechend
angepasst. Höchste Priorität hatte das Auffinden und Beheben des Fehlers, der den Datenaustausch
zwischen den WRT160NL-Knoten in dem Meshnetzwerk verhinderte. Kapitel 5 beschreibt den Weg
der Fehlerbehebung.
1.4.3
Projektabschluss
Alle Ziele konnten innerhalb des Projektes umgesetzt werden. Kapitel 6 erläutert die erreichten
Ziele genauer. Die im Rahmen des Projektes erstellten Erweiterungen sind über das VS-Wiki der
Hochschule RheinMain4 verfügbar.
3
4
Informationen zu OpenWRT auf dem WRT160NL http://wiki.openwrt.org/toh/linksys/wrt160nl
https://wwwvs.cs.hs-rm.de/vs-wiki/index.php/MasterProjekte/802.11s auf SoHo-Routern
5
Kapitel 2
IEEE 802.11s-Meshnetzwerk im
Betrieb
In erster Linie sind 802.11s-Meshnetzwerke eine Spezialform von generellen 802.11-WLAN-Netzwerken.
Sie nutzen die Standard-802.11-Frames, mit einer in Abschnitt 2.1 beschriebenen Erweiterung. Zudem kommt Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) zum Einsatz. Dieser
Mechanismus soll das gleichzeitige Senden zweier 802.11-WLAN-Geräte auf der selben Frequenz
verhindern. Bevor ein 802.11-Frame abgeschickt wird, muss der Sender überprüfen, ob auf der
Frequenz gesendet wird und gegebenenfalls die zusendende Frame solange zurückhalten, bis die
Frequenz wieder frei ist.
2.1
Erweiterung des 802.11-Frames
Abbildung 2.1: In 802.11s Meshnetzen wird der Body eines Standard-802.11-Frames um
das Mesh-Control-Field erweitert.
6
2.1. Erweiterung des 802.11-Frames
Wie in Abbildung 2.1 zu sehen ist, werden auch in 802.11s-Meshnetzen Standard-802.11-Frames
zur Datenübertragung verwendet, die um ein Mesh-Control-Field erweitert sind. Das Mesh-ControlField nutzt die ersten Bytes des Frame-Bodys. Die Nutzdaten folgen anschließend. WLAN-Geräte,
die nicht 11s-fähig sind, behandeln das Mesh-Control-Field daher als Teil eines normalen FrameBodys. 11s-Frames können also mit den Standard 802.11-Mechanismen verarbeitet werden und
stellen für nicht 11s-fähige WLAN-Geräte, die sich mit einem Meshnetzwerke die Frequenz teilen,
keinen unnötigen Ballast dar. Der 11s-Frame wird von ihnen als netzwerkfremd erkannt und verworfen. Adressfeld 1 und 2 werden für einen Hop des Datenpaketes verwendet. Adressfeld 3 und
4 werden für die Absender- (BSSID) und Ziel-MAC-Adresse innerhalb des Meshnetzes genutzt.
Im Flags-Field des Mesh-Control-Fields kann durch das Setzen der ersten beiden Bits die Nutzung von Adressfeld 5 und 6 bekannt gegeben werden. Diese werden als globale Absender- und
Empfängeradresse genutzt und benötigt, wenn Empfänger und Sender außerhalb des Meshnetzes
liegen. Beispiel: Zwei Computer kommunizieren miteinander. Sie sind mit verschiedenen MAPs
(vgl. Abschnitt 1.2.1) verbunden, die sich im selben Meshnetz befinden. Adresse 5 ist in diesem die
MAC-Adresse des sendenden Computers und Adresse 6 die Adresse des empfangenden Computers.
Abbildung 2.2: Router B erhält bei einem Broadcast identische Nachrichten auf verschiedenen Wegen. Anhand der MAC-Adresse des Absenders und der Sequenznummer wird die
Dublette erkannt.
Ein TTL-Feld (Time-to-live) verhindert, dass Pakete endlos lange im Netz weitergeleitet werden.
Außerdem wird jede Nachricht vom Sender mit einer Sequenznummer versehen. Diese kommt bei
Broadcasts zum Einsatz und soll das Wiederholen identischer Nachrichten und somit überflüssigen
Datenverkehr vermeiden, wie Abbildung 2.2 zeigt. Die Netzwerkknoten loggen, welche Nachrichten
sie von welcher MAC-Adresse mit welcher Sequenznummer erhalten haben. Sollten identische Nachrichten über verschiedene Wege denselben Knoten erreichen, wird die Dublette anhand Sender-MAC
und Sequenznummer erkannt und die Nachricht nur einmal weitergeleitet.
7
2.2. Vermaschung
2.2
Vermaschung
In 802.11s-Meshnetzen ist die Netzbildung (Vermaschung) streng von der Routingebene getrennt.
Alle Peers werden in der so genannten Stationtable eingetragen. Zum Eintrag gehören auch Informationen zur Verbindungsqualität und zum Datendurchsatz. Theoretisch könnten anhand der
Einträge der Stationtable der Pfad zu benachbarten Knoten direkt abgeleitet werden. Durch die
Trennung von Vermaschung und Routing ist dies aber nicht mehr möglich. Somit hält man sich
die Möglichkeit offen, neben dem Standard-Routingprotokoll HPWM auch zusätzliche Protokolle
optional zuzulassen.
Abbildung 2.3: Nach Empfang des Beacons (1) wird per Peer Request (2) und
Peer Reply (3) der Peer (4) zwischen den Knoten etabliert.
Jeder Netzwerkknoten sendet in regelmäßigen Abständen ein Beacon, mit dem unter anderem
auch die Mesh-ID publiziert wird. Empfängt nun ein anderer Knoten mit derselben Mesh-ID den
Beacon in ausreichendener Qualität, stellt er daraufhin einen Peer-Request an den Beacon-Sender.
Dieser quittiert dies mit einem Beacon-Reply (siehe Abbildung 2.3). Die beiden Knoten sind nun
über einen Peer verbunden. Der Peer ist ein logischer Datenkanal, der vom unterliegenden Routingprotokoll zum Datenaustausch genutzt wird.
2.3
Address Resolution Protokoll (ARP)
Möchte ein Knoten mit einer bestimmten IP-Adresse kommunizieren, kommt das Address Resolution Protokoll (ARP) zum Einsatz. Wie in klassischen WLAN-Netzen üblich, existiert eine ARPTabelle, in der IP-Adressen MAC-Adressen zugeordnet werden. Hat der Router einen entsprechenden
Eintrag in dieser Tabelle, kann das Datenpaket an die korrekte MAC-Adresse adressiert werden.
8
2.4. Hybrid Wireless Meshprotokoll
Ist dies nicht der Fall, wird ein ARP-Request per Broadcast durch das Meshnetz geschickt. Der
ARP-Request enthält die gesuchte IP-Adresse, sowie IP- und MAC-Adresse des Senders. Er wird
mit einen ARP-Reply quittiert. Die Quittierung erfolgt über einen Path als Unicast. Standardgemäß
werden 802.11s-Meshnetze mit dem in Abschnitt 2.4 beschriebenen HPWM Protokoll betrieben.
Wird der reaktive Modus dieses Protokolls genutzt, kann es durchaus vorkommen, dass noch kein
Abbildung 2.4: Erwartungsgemäßes Verhalten der Verarbeitung eines ARP-Request.
Path für diesen Unicast besteht. Der ARP-Reply wird dann so lange zurückgehalten, bis der Path,
wie in Abschnitt 2.4.2 beschrieben, aufgebaut ist. Abbildung 2.4 veranschaulicht das Prinzip.
2.4
Hybrid Wireless Meshprotokoll (HPWM)
Das Hybrid Wireless Meshprotokoll (HPWM) ist das Standardprotokoll für das Routing innerhalb
von 802.11s-Meshnetzen. 802.11s erlaubt es zwar, eigene Routingprotokolle zu nutzen. Diese können
aber nur optional hinzugefügt werden. Bei der vollständigen Implementierung des Standards ist das
Vorhandensein von HPWM Pflicht.
Wie der Name schon sagt, handelt es sich bei HPWM um ein hybrides Protokoll. Standardgemäß befindet sich das Meshnetz im reaktiven Modus. Jeder Knoten erfragt den Path zu einem
bestimmten Ziel genau dann, wenn er zu diesem Ziel auch Daten senden will. Im proaktiven Mo-
9
2.4. Hybrid Wireless Meshprotokoll
dus hat ein Knoten die Rolle eines Rootknotens und stellt in einer Treetopologie Paths zu allen
anderen Netzteilnehmern her. Sollte der Rootknoten ausfallen, wird automatisch in den reaktiven
HPWM-Modus gewechselt. [Conn] zeigt einen guten Überblick über beide Routingmodi.
HPWM speichert alle aktiven Pfade in einer Meshpath-Tabelle ab. In einem Tabelleneintrag
wird einer Empfänger-Adresse eine Next-Hop-Adresse zugeordnet. Die Next-Hop-Adresse muss über
einen Peer erreichbar sein. Wenn Sender und Empfänger über einen Peer miteinander verbunden,
sind Next-Hop-Adresse und Empfänger-Adresse identisch. Aus HPWM-Sicht ist nicht der komplette
Pfad zu einem Empfängerknoten bekannt, sondern immer nur der nächste Hop.
2.4.1
Aufbau eines Pfades
Für den Aufbau von Pfaden innerhalb von 802.11s-Meshnetzen wird eine Variation des Ad-hoc
On-demand Distance Vector-Routingalgorithmus (AODV) verwendet. [AODV] sieht hierfür vier
Nachichtentypen vor: Route Request (RREQ), Route Reply (RREP), Route Error (RERR) und Reply
Acknowledgement (RREP-ACK). HPWM nutzt Variationen dieser Nachichtentypen: Path Request
(PREQ), Path Reply (PREP), Path Error (PERR) und Path Reply Acknowledgement (PREPACK). Für den Aufbau eines Pfades, wird von einem Knoten zunächst ein PREQ-Paket gesendet.
Im Adressfeld 4 ist die Ziel-MAC-Adresse wie bei einem Unicast eingetragen. Als Hop-Zieladresse,
ist aber die MAC-Broadcast-Adresse (FF:FF:FF:FF:FF:FF) eingetragen. Wie bei einem gewöhnlichen Broadcast werden die Pakete über alle vorhandenen Peers weitergeleitet. Kommen nun auf
verschiedenen Wegen identische Nachrichten bei einem Knoten an, werden die Dubletten nicht wie
sonst üblich anhand der Kombination von Sender-MAC-Adresse und Sequenznummer verworfen.
Stattdessen kommt eine Erweiterung des AODV-Konzepts zum Tragen, die in [Abid] beschriebene
Best Path Metric. Pakete werden nur dann verworfen, wenn sie eine schlechtere Path Metric haben,
als bereits empfangene identische Pakete.
Best Path Metric:
Die Path Metric beschreibt die Qualität eines Pfades. Hierfür wird die
Airtime eines Paketes auf einem Pfad gemessen. Die Airtime beschreibt die Dauer, die ein Paket von
der Quelle zum Ziel braucht. Die Netzwerknoten messen zusätzlich die Zeit interner Verzögerungen,
welche in der Regel durch den Einsatz von CSMA/CA zustande kommen. Um die Path Metric zu
bestimmen wird von der Airtime diese Verzögerungszeit abgezogen. Der Pfad mit dem geringsten
Wert erfüllt nun das Best Path Metric-Kriterium.
Der Zielknoten bekommt nun über jeden Peer genau eine Kopie des PREQ-Paketes zugestellt,
sofern der Knoten einen möglichen Pfad zum Sender des PREQ-Paktes hat. Der Zielknoten trägt
nun in seiner Meshpath-Tabelle die MAC-Adresse des PREQ-Senders ein. Als Next-Hop wird die
MAC-Adresse eingetragen, von der das PREQ-Paket kam, welches das Best Path Metric-Kriterium
erfüllt. Nun wird über diesen Pfad der PREP gesendet. Alle Hop-Knoten tragen nun nach dem
selben Schema die MAC-Adresen von PREQ-Sender und Empfänger ein. Als Next-Hop für die
Empfänger-MAC wird die PREP-Quelle eingetragen und als Next-Hop für die Sender-MAC die
10
2.4. Hybrid Wireless Meshprotokoll
PREQ-Quelle genommen, die das Best Path Metric-Kriterium erfüllt. Kommt nun das PREP-Paket
beim PREQ-Sender an, quittiert er den Pfad mit einem PREP-ACK-Paket.
2.4.2
Reaktiver Modus
Im reaktiven Modus wird ausschließlich die im Abschnitt 2.4.1 beschriebene Variation von AODV
verwendet. Ein Pfad wird erst dann aufgebaut, wenn Daten an eine bestimmte MAC-Adresse versandt werden sollen. Hierfür wird die Meshpath-Tabelle überprüft. Ist für die Zieladresse kein Eintrag
vorhanden, wird zunächst der Pfad, wie in Abschnitt 2.4.1 beschrieben ist, aufgebaut. Anschließend erfolgt der Datenversand. Wird der Pfad nicht mehr genutzt, gilt er nach einem Timeout als
ungültig.
2.4.3
Proaktiver Modus
Im proaktiven Modus übernimmt ein Knoten die Root-Rolle und signalisiert dies den anderen Knoten
durch das Rootannouncement. Dieses wird per Broadcast im Meshnetz verteilt. Abbildung 2.5
Abbildung 2.5: Path Request nach Senden des Rootannouncments
zeigt die Ausbreitung des Rootannouncements. Durch die Verteilung bildet sich auf Pfadebene ein
Baum, mit dem Rootknoten als Wurzel. Nach Empfang des Rootannouncements baut ein Knoten
durch senden eines PREQ-Paketes den Pfad zum Rootknoten auf (Markierung 1 in Abbildung 2.5).
Geschieht der Aufbau über mehrere Hops, bauen die Knoten, die die PREQ- und PREP-Pakete
weitergeleitet haben, zu dem PREQ-Sender ebenfalls einen Pfad auf (Markierung 2). Nachdem
jeder Knoten im Netz auf das Rootannouncement reagiert hat, kennt somit jeder Knoten den Pfad
zum Rootknoten und zu den Hop-Knoten auf dem Weg zum Rootknoten, sowie den Pfad zu all
seinen Kindknoten. Pakete, die an unbekannte MAC-Adressen adressiert sind, müssen in jedem
Fall Richtung Rootknoten gesendet werden. Ist ein Knoten mit der Ziel-MAC-Adresse im Netz
vorhanden, muss spätestens der Rootknoten den Pfad zu diesem kennen. Ist dies nicht der Fall,
wird mit dem PERR-Paket (Path Error) signalisiert, dass kein Pfad zum Ziel vorhanden ist. PERR
wird auch benutzt, wenn ein Knoten aus dem Netz entfernt wird.
11
2.5. Überblick über die verschiedenen Kommunikationsebenen
2.4.4
Vor- und Nachteile der verschiedenen Routingvarianten
Herrscht in einem Netz eine hohe Dynamik, so ist der reaktive Modus von HPWM von Vorteil. Die
Pfade ändern sich ständig und müssen neu angepasst werden. In eher statischen Umgebungen ist
dies aber von Nachteil. Die Kommunikation wird unnötig verzögert, da vor jedem Datenaustausch
erst ein Pfad erstellt werden muss.
Der proaktive Modus ist für statische Umgebungen besser geeignet. Insbesondere dann, wenn der
Rootkonten gleichzeitig ein Portal (MPP) zum Internet darstellt. Die Pfade werden einmal aufgebaut und die Kommunikation kann direkt erfolgen.
2.5
Überblick über die verschiedenen
Kommunikationsebenen
Die nachfolgende Tabelle gibt einen Überblick über die Sendeebene, der in den vorherigen Abschnitten beschriebenen Pakettypen.
Ebene
Typ
Direkter Funkkontakt
Peer
Beacon, Peer-Request, Peer-Reply
Rootannouncement, Gateannouncement, PREQ, PREP, PREPACK, PERR, ARP-Request
ARP-Reply, Datenversand
Path
Verschlüsselungsebene:
Die Verschlüsselung von 802.11s-Meshnetzwerken erfolgt Peer-2-Peer,
wie Abschnitt 1.2 zeigt. Jede Kommmunikation auf Peer- und Pathebene ist demnach verschlüsselt.
Verschlüsselte 802.11s-Meshnetzwerke sind somit gegen Routing Attacks geschützt.
12
Kapitel 3
IEEE 802.11s-Meshnetzwerke unter
Linux
Das Linux Wireless-Projekt1 ist für den WLAN-Stack im Linuxkernel2 zuständig. Dieser wird unter
dem Namen Compat Wireless veröffentlicht. Der WLAN-Stack wird derzeit komplett neu entwickelt.
Die Entwicklung des alten Stacks um das Konfigurationsprogramm iwconfig ist eingestellt. Das
Kernelmodul CFG80211 bildet den zentralen Knoten des neuen Stacks. Es kommuniziert direkt mit
den Gerätetreibern der WLAN-Hardware.
Da in der Regel, um WLAN-Hardware günstig herstellen zu können, die MAC-Schicht nicht in
Hardware implementiert ist, muss diese durch Software emuliert werden. Hierfür ist das Kernelmodul
MAC80211 zuständig, das bei s.g. Soft-MAC-WLAN-Karten diese Emulation vornimmt. MAC80211
wird in diesem Fall zwischen CFG80211 und Treiber geschaltet.
NL80211 ist ein Kernelinterface (nl80211.h), das CFG80211 und die unterliegenden Schichten
)*$ " (
&'("
! "#$%
&"
!
%)+
Abbildung 3.1: Das Open 11s-Projekt steuert 802.11s-Erweiterungen für Linux Wireless
bei.
1
2
Homepage des Linux Wireless-Projekts: http://linuxwireless.org/
Linuxkernel-Homepage: http://kernel.org/
13
3.1. Verhältnis zwischen Mesh Points und Mesh Access Points
kapselt. Für OpenWRT existiert eine abgespeckte Variante von NL80211: libnl-tiny. Programme im
Userlayer können NL80211 nutzen, um über den neuen WLAN-Stack zu kommunizieren. Zur Zeit
tun dies die Programme hostapd, crda und WPA Supplicant, wenn NL80211 als Treiber eingestellt
wird (wpa supplicant -Dnl80211), sowie iw und Auth SAE. iw ist das CLI-Programm für den
neuen WLAN-Stack. Mit iw können alle WLAN-Netze aufgesetzt und konfiguriert werden. Anhang
A zeigt, wie per iw ein 802.11s-Meshnetzwerk eingerichtet wird.
Das Open 11s-Projekt3 erweitert iw, NL80211, CFG80211, MAC80211 und die im Linuxkernel
vorhandenen WLAN-Treiber um die 802.11s-Funktionen (siehe Abbildung 3.1). Da 802.11s noch in
der Entwicklung ist (Status: Draft), existiert auch noch keine 802.11s-fähige Hardware. Somit kann
das Routing auf MAC-Ebene nur mit Soft-MAC-WLAN-Karten umgesetzt werden. Unter Linux ist
daher der Einsatz von MAC80211 in 802.11s-Meshnetzen zwingend erforderlich.
Fortschritt der Implementierung:
Der aktuelle 11s-Entwurf (Sept. 2011) ist allerdings bei
Weitem noch nicht vollständig implementiert. Mit jeder weiteren Version von Compat Wireless
kommen weitere Funktionen des 11s-Entwurfs hinzu. Die verschiedenen Compat Wireless-Versionen
sind nicht immer zueinander kompatibel. Zum Betreiben eines Meshes sollten alle Knoten daher
dieselbe Version nutzen.
Open11s bietet zur Verschlüsselung derzeit ausschließlich Auth SAE4 an. Andere Methoden (vgl. Abschnitt 1.2) werden mit dem aktuellen Entwicklungstand nicht unterstüzt.
Auth SAE wird vom Open11s-Projekt entwickelt und greift auf NL80211 zu. Um ein verschlüsseltes
Mesh aufzusetzen, konfiguriert man es zunächst mit iw und ruft dann das Programm meshd-nl80211
auf. Dieses setzt die Auth SAE-Verschlüsselung um. Anhang A.4 zeigt hierfür ein Konfigurationsbeispiel.
Verschlüsselung:
3.1
Verhältnis zwischen Mesh Points und Mesh Access
Points
In der aktuellen Implementierung von 11s agieren Mesh Points und Mesh Access Points auf verschiedenen Ebenen. Sind MAPs und MPs im selben Netz vorhanden, dient das Mesh ausschließlich
zur Weiterleitung von Daten. Es bilden sich zwei Gruppen: Die eine besteht aus den einfachen
Mesh Points und eventuell Mesh Portalen. Die andere Gruppe bildet sich aus allen Mesh Access
Points und den Netzwerkknoten, die sich außerhalb des Meshes befinden und über eine klassische
Netzwerkverbindung (WLAN, Ethernet) mit einem MAP verbunden sind.
3
Homepage des Open-11s-Projekts: http://open80211s.org/
Auth SAE-Projekt: http://authsae.sourceforge.net/
Siehe auch: https://github.com/cozybit/open80211s/wiki/HOWTO, Abschnitt For secured mesh und Secure Mesh Setup
4
14
3.2. Meshframehandling im Linuxkernel
Alle Teilnehmer können sich gegenseitig anpingen. Datenversand kann aber nur innerhalb der
jeweiligen Gruppen erfolgen.
Ein MAP kann also alle anderen MAPs kontaktieren, sowie die externen Knoten, die sich hinter
diesem verbergen. Gleiches gilt für einen aus Sicht des Meshes externen Rechner. Er kann alle
MAPs und mit den MAPs extern verbundenen Knoten erreichen, aber keinen MP.
Die Mesh Points hingegen können nur andere MPs (oder MPPs und das dahinter verborgene
Netzwerk) erreichen, aber keinen MAP.
Um den MAPs und den Mesh-externen Knoten, die mit ihnen Verbunden sind, Zugang zu einem
fremden Netzwerk wie dem Internet zu ermöglichen, muss der entsprechende MPP in die Gruppe der
MAPs überführt werden. Dies geschieht, indem dieser gleichzeitig als MPP und MAP konfiguriert
wird.
Die Einrichtung von MAP, MPP und MP ist im Anhang B beschrieben.
3.2
Meshframehandling im Linuxkernel
Abbildung 3.2: Treiber übergibt Frame an MAC80211
Wie Abbildung 3.2 zeigt, wird die Interrupt-Service-Routine des WLAN-Treibers aufgerufen,
wenn eine Frame empfangen wurde. Dieser erstellt ein Tasklet (siehe [Love]), welches für die Verarbeitung des Frames zuständig ist und die entsprechenden Daten an die MAC80211-Schicht weiter
gibt (ieee80211 rx()). Nun wird geprüft, ob der Frame zu einem WLAN-Interface gehört. Für
jeden Interfacetyp gibt es spezielle Handler. Der Meshhandler ist für die Meshinterfaces zuständig
und überprüft zunächst, ob der Frame über die richtige Ebene versand wurde (siehe Tabelle in Abschnitt 2.5). Ist dies der Fall, wird entsprechend agiert. So wird zum Beispiel bei einem Broadcast
auf Peer-Ebene der Frame weitergeleitet. Beim Empfang eines Datenpaketes mit einer fremden
15
3.2. Meshframehandling im Linuxkernel
MAC-Adresse als Ziel wird in der Mesh-Path-Tabelle der nächste Hop ausgelesen und der Frame
über den entsprechenden Path weitergeleitet. Ist das Datenpaket für den Knoten selbst bestimmt,
wird der Payload des Frames an die IP-Schicht weitergegeben.
16
Kapitel 4
IEEE 802.11s-Meshnetzwerke unter
OpenWRT
Wie in Abschnitt 1.3 beschrieben, handelt es sich bei OpenWRT um eine für Router spezialisierte
Linuxdistribution. Es kommen die Programme zum Einsatz, die auch auf Desktopdistributionen
für den Netzwerkbereich zuständig sind. Teilweise werden auch Lightwight-Varianten dieser Programme genutzt. Das besondere an OpenWRT ist, dass alle Programme über ein einheitliches
Konfigurationstool eingerichtet werden können.
4.1
UCI - das OpenWRT-Konfigurationstool
Normalerweise erfolgt die Konfiguration der einzelnen Programme unter Linux über Konfigurationsdateien in Unterordnern des Verzeichnisses /etc. Deren Aufbau und Syntax ist allerdings alles
andere als einheitlich. Deshalb nutzt OpenWRT UCI1 (Universal Configuration Interface) als Abstraktionsschicht für die individuellen Einrichtungsdateien. Auch für das Starten und Stoppen sowie
das Aktivieren und Deaktivieren von Systemdiensten ist UCI zuständig. 802.11s-Meshnetzwerke
werden ebenfalls über UCI eingerichtet.
4.1.1
802.11s per UCI einrichten
Zu Beginn des Projektes war die Einrichtung von 802.11s-Meshnetzwerken mit UCI nur teilweise möglich. Die sogenannten Meshparameter konnten nicht eingestellt werden. Diese werden mit
dem Programm iw gesetzt. Hier können z.B. Timeout-Perioden festgelegt werden, aber auch das
Senden von Rootannouncement und Gateannouncement, welches zentrale Elemente von 802.11sMeshnetzen sind. Im Rahmen dieses Projektes wurde ein Patch erstellt, das diese fehlenden Funktionen ergänzt. Das Patch wurde dem OpenWRT-Projekt zur Verfügung gestellt2 , so dass künftig
1
2
http://wiki.openwrt.org/doc/uci
https://dev.openwrt.org/ticket/11634
17
4.2. Verschlüsselung
Meshnetzwerke vollständig über UCI eingerichtet werden können. Anhang B zeigt Konfigurationsbeispiele der verschiedenen Meshkomponenten.
4.1.2
LUCI - Webkonfigurationsinterface
Von handelsüblichen Routern ist man es gewohnt, sie über eine Weboberfläche per Browser konfigurieren zu können. Dies ist auch mit OpenWRT möglich. Hier kommt eine MVC-Webanwendung
namens LUCI zum Einsatz. LUCI ist ein Wrapper für UCI. Mit Abschluss dieses Projektes kann ein
802.11s-Meshnetzwerk komplett über LUCI eingerichtet werden. Zuvor konnte lediglich der Netzwerktyp 11s eingestellt werden. Weitere Optionen, wie z.B. das essentielle Setzen der Mesh-ID,
konnte anschließend per UCI vorgenommen werden.
4.2
Verschlüsselung
Wie in Kapitel 3 zu sehen, ist die Verschlüsselung von 802.11s-Meshnetzwerken unter Linux mit
Auth SAE umgesetzt. Auth SAE ist aber kein Teil der OpenWRT-Distribution, da das Projekt
den Entwicklungsstatus Prealpha hat. Im Rahmen dieses Projektes wurde ein Auth SAE-Paket für
OpenWRT erstellt. Die Verschlüsselung lief stabil. Der Prealpha-Status zeigte sich lediglich in einer
komplizierten Konfiguration, welche von der Dokumentation auf der Projekthomepage3 abwich.
Auth SAE-Integration in UCI und LUCI:
Um für den Enduser eine bequeme Einrichtung
von Auth SAE zu ermöglichen, wurde UCI und LUCI entsprechend erweitert. Im einfachsten Fall
muss nur ein Passphrase vom Nutzer gesetzt werden. Für alle übrigen erforderlichen Parameter
werden Standartwerte genutzt, wenn der Nutzer keine Werte per UCI gesetzt hat. Anhang B.5
enthält weitere Informationen und zeigt ein Konfigurationsbeispiel.
3
Beschreibung der Konfigurationsparameter von Auth SAE: https://github.com/cozybit/authsae/blob/master/README
18
Kapitel 5
Troubleshooting
In dem aus fünf Linksys WRT160NL-Routern bestehenden 802.11s-Meshnetzwerk erfolgte keine Datenkommunikation. Der Grund hierfür lag in einem Fehler des ATH9k-WLAN-Treibers, der Frames
filterte, die zum Aufbau der Kommunikation benötigt wurden. Ein Großteil der Projektbearbeitungszeit wurde für die Fehleranalyse und die Behebung des Fehlers aufgewandt. Dieses Kapitel
zeigt die wichtigsten Analysemethoden, die den Fehler zunächst eingekreist hatten und letztendlich
die Behebung ermöglichten.
5.1
Kein Datenaustausch im 802.11s-Meshnetzwerk
Zu Projektbeginn wurde ein einfaches Meshnetz aufgebaut. Hierbei wurden zwei Varianten getestet: der Aufbau über das CLI-Programm iw und über das OpenWRT-Konfigurationstool UCI (vgl
Abschnitt 4.1). Um die Funktionsfähigkeit zu kontrollieren, wurde erfolglos versucht die Knoten gegenseitig anzupingen. Wie Abschnitt 2.5 zeigt, gibt es im 802.11s-Meshnetzwerk mehrere Ebenen.
Der Fehler konnte der Peer-Ebene zugeordnet werden. Ein Aufruf von iw dev wlan0 station
dump zeigte, dass alle WRT160NL-Router wie erwartet zueinander Peers aufgebaut hatten. Die
Meshpath-Tabelle zeigte aber keine Einträge (Kommando: iw dev wlan0 mpath dump). Auch
die ARP-Tabelle war leer.
Abbildung 5.1: ARP-Reply kann wegen fehlenden Pfades nicht gesendet werden.
19
5.2. ARP-Verabeitung
Kein Pfadaufbau: Per Wireshark wurde Entdeckt, dass kein Pfad aufgebaut wird (siehe Abbildung 5.1). Neben dem ARP-Request sind nur die Beacons der Router zu sehen. Ein ARP-Request
wird auf Peer-Ebene verbreitet (vgl. Abschnitt 2.5). Der ARP-Reply wird aber über einen Pfad
geschickt. Auf den ARP-Frame sollte daher ein PREQ-Frame folgen (siehe Abbildung 2.4), der
in Wireshark nicht zu sehen ist. Außerdem müssten alle anderen Router den ARP-Request, welcher ein Broadcast ist, über alle Peers weiterleiten. Auch dies ist in Wireshark nicht sichtbar. Die
ARP-Pakete wurden auf den WRT160NL-Routern definitiv nicht korrekt verarbeitet.
5.1.1
Manuelles Füllen der Tabellen
Als Workaround wurden probeweise Meshpath- und ARP-Tabelle manuell per CLI gefüllt. Das
Netzwerk verhielt sich wie erwartet. Die Datenkommunikation erfolgte problemlos.
5.2
ARP-Verabeitung
Als nächstes wurde die ARP-Verarbeitung im Linuxkernel überprüft. Hierzu wurde in dem zum
Linuxkernel gehörenden Compat Wireless-Modul alle Funktionen der Datei arp.c mit printk()
makiert. Auf dem Router, der den ping-Befehl ausführte, konnte die Erstellung des ARP-Requestes
im Kernellog mitverfolgt werden. Auf allen übrigen Routern wurde aber keine Funktion von arp.c
aufgerufen. Demzufolge werden ARP-Request-Pakete nicht an die ARP-Schicht weitergeleitet, sondern vorher gefiltert.
5.2.1
ARP-Filterung per sysctl
Die zuvor erläuterten Probleme waren ein Indiz dafür, das in den sysctl-Einstellungen ARP-Filter
aktiviert waren. Eine Überprüfung widerlegte aber dieses Indiz:
root@mesh02:~# sysctl -a | grep arp | grep wlan | grep arp_ignore
net.ipv4.conf.wlan0.arp_ignore = 0
5.3
Open11s-Funktionen in der MAC80211-Schicht
Das Open11s-Projekt hat die MAC80211-Schicht um 802.11s-Funktionen erweitert. Der Aufruf
dieser Funktionen wurde genauer untersucht. Gaben Funktionen Fehlerwerte zurück, wurden diese
per printk() im Kernellog sichtbar gemacht. Eine Überwachung des Kernelogs zeigte, dass alle
Funktionen ohne Fehler arbeiteten.
5.4
Welche Frames erreichen die MAC80211-Schicht
Da scheinbar alle Frames innerhalb von MAC80211 korrekt verarbeitet werden, kommt die Frage
auf, ob die Frames mit dem ARP-Request überhaupt die MAC80211-Schicht erreichen. Wie Ab-
20
5.5. Fehlerbehebung
bildung 3.2 zeigt, bildet beim Frameeempfang die Funktion ieee80211 rx() den Eingang in die
MAC80211-Schicht. Diese wurde nun im Kernelog überwacht:
void ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb){
/* ... */
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
if(skb->data[38]==0x8 && skb->data[39]==0x6)
#define macaddstm "%X-%X-%X-%X-%X-%X"
#define mac_3 hdr->addr3[0],hdr->addr3[1],hdr->addr3[2], \
hdr->addr3[3],hdr->addr3[4],hdr->addr3[5]
printk(KERN_DEBUG "ARP received from "macaddstm"\n", mac_3);
/* ... */
}
Im Kernellog wurde die 3. MAC-Adresse des 802.11-Frames geloggt, wenn Byte 38 und 39 den Wert
0x0806 hatten. Diese Bytes bilden in LLC-Frames von Meshnetzen das Type-Feld. Der Typ 0x0806
steht für ARP-Pakete. Im Kernellog erschien keine ARP received-Meldung. Folglich wurde der ARPRequest bereits auf Treiberebene gefiltert. Das printk()-Statement wurde abgeändert, so dass alle
Frames ausgegeben wurden. Auf der Frequenz des Meshnetzes funkten noch zwei weitere Router:
Eine Fritz!Box und ein Sitecom-Router. Bei einem Vergleich zwischen einem Wiresharkdump und
dem Kernellog war zu erkennen, dass neben dem ARP-Request auch ein weiterer Frametyp vom
Treiber nicht an die MAC80211-Schicht weitergeleitet wurde.
Der Beacon aller Meshteilnehmer wurde korrekt an die MAC80211-Schicht übergeben, ebenfalls
der Beacon der netzwerkfremden Fritz!Box. Der Beacon des Sitecom-Routers kam aber ebenfalls in
der MAC80211-Schicht nicht an. Das erwartete Verhalten wäre, dass die netzwerkfremden Beacons
von ieee80211 rx() über mehrere Schritte an ieee80211 rx handlers() weitergegeben werden.
Der dem Frametyps entsprechende Handler würde erkennen, das die Beacons zu keinem auf dem
Router konfigurierten Netzwerk gehören und sie daraufhin verwerfen.
5.5
Fehlerbehebung
Die MAC80211-Schicht konfiguriert den Treiber. Neben Einstellungen wie Frequenz und Bandbreite werden auch Framefilter definiert. Diese werden bei Routern mit ATH9k-WLAN-Chips über die
Funktion ath9k configure filter() (ath9k/main.c) gesetzt. Die Überwachung mit printk()
zeigte, dass MAC80211 wie erwartet alle erforderlichen Flags setzte. Der Fehler musste also Treiberintern liegen.
Die Funktion ath calcrxfilter() in ath9k/recv.c enthält einen Hinweis, dass das
ATH9K RX FILTER PROM-Flag bei älteren Chips gesetzt werden soll:
21
5.5. Fehlerbehebung
u32 ath_calcrxfilter(struct ath_softc *sc){
/* ... */
if (sc->nvifs > 1 || (sc->rx.rxfilter & FIF_OTHER_BSS)) {
/* The following may also be needed for other older chips */
if (sc->sc_ah->hw_version.macVersion == AR_SREV_VERSION_9160)
rfilt |= ATH9K_RX_FILTER_PROM;
rfilt |= ATH9K_RX_FILTER_MCAST_BCAST_ALL;
}
return rfilt;
}
Das ATH9K RX FILTER PROM-Flag wird standardgemäß bei der Chipversion AR-9160 gesetzt.
Bei dem Linksys WRT160NL wird die Version AR-9100 genutzt. Das if-Statement wurde entsprechend erweitert:
if (sc->sc_ah->hw_version.macVersion == AR_SREV_VERSION_9160 ||
sc->sc_ah->hw_version.macVersion == AR_SREV_VERSION_9100 )
rfilt |= ATH9K_RX_FILTER_PROM;
}
Nach dieser Erweiterung funktionierte das 802.11s-Meshnetzwerk wie erwartet. Die Fehlerbehebung im ATH9k-Treiber wurde sowohl auf kernel.org, als auch auf der OpenWRT-Entwickler-Seite
publiziert1 .
1
https://bugzilla.kernel.org/show bug.cgi?id=45591, https://dev.openwrt.org/ticket/11972
22
Kapitel 6
Zusammenfassung
In diesem Masterprojekt ging es darum, ein 802.11s-Meshnetzwerk mit SoHo-Routern vom Typ
Linksys WRT160NL einzurichten. Dies ist erfolgreich gelungen. Ein Fehler im ATH9k-WLANTreiber der Router konnte behoben werden. Es wurde ein Testnetzwerk aufgebaut, das alle Komponenten eines 802.11s-Meshnetzwerkes enthielt: Mehrere Mesh Points, Mesh Access Points und
ein Mesh Portal. Aufbau und Konfiguration sind im Anhang dieses Dokumentes beschrieben.
Zu Beginn des Projektes konnte ein Mesh noch nicht komplett über das OpenWRT-eigene
Konfigurationstool UCI eingerichtet werden. Über die Weboberfläche LUCI konnte sogar nur der
Netzwerktyp ausgewählt werden. Essentielle Einstellungen, wie das Setzen der Mesh-ID waren nicht
möglich. Die fehlenden Einstellungsmöglichkeiten für UCI wurden ergänzt. LUCI wurde erweitert,
so dass nun für ein 802.11s-Meshnetzwerk Mesh-ID, Root-/Gateannouncement und Auth SAEVerschlüsselung eingestellt werden konnten.
Das Open11s-Projekt sieht zur Zeit für Linux nur eine Variante verschlüsselter Kommunikation
vor: Die Nutzung von Auth SAE. Ein Auth SAE-Paket wurde innerhalb dieses Projektes für OpenWRT erstellt. UCI wurde entsprechend erweitert, um Auth SAE einrichten zu können. Über LUCI
kann ebenfalls die Verschlüsselungsmethode Auth SAE gewählt und ein Passphrase gesetzt werden.
Somit ist es möglich, ein verschlüsseltes Mesh komplett über die Web-Schnittstelle einzurichten.
Das Projekt wurde mit Revision r32582 aus dem OpenWRT SVN-Trunk1 beendet. Alle in dem
Projekt entstandenen Veränderungen gegenüber dieser SVN Revison sind über das VS-Wiki der
Hochschule RheinMain abrufbar2 .
1
2
https://dev.openwrt.org/wiki/GetSource
https://wwwvs.cs.hs-rm.de/vs-wiki/index.php/MasterProjekte/802.11s auf SoHo-Routern
23
6.1. Ausblick
6.1
Ausblick
In diesem Abschnitt werden Aufgaben betrachtet, die in Nachfolgeprojekten dieses Masterprojekts
bearbeitet werden könnten.
6.1.1
LUCI
Mit der Webanwendung LUCI kann man mit Abschluss dieses Projektes 802.11s-Meshnetzwerke
konfigurieren. Der Netzwerkstatus wird allerdings nicht korrekt angezeigt. Eine Anpassung von LUCI
zur korrekten Anzeige des Netzwerkstatus wäre wünschenswert. Zur Zeit wird die Fehlermeldung
Wireless is disabled or not associated“ angezeigt, auch wenn das Netzwerk funktioniert. Ferner
”
wird die Mesh-ID nicht angezeigt und der Netzwerkmodus als unknown“ ausgegeben.
”
6.1.2
Auth SAE
Ein Auth SAE-Paket wurde zwar innerhalb dieses Projektes für OpenWRT erstellt, dabei zeigten sich allerdings einige Schwächen, besonders im Bereich der Konfiguration. Auth SAE lässt
sich nur per Konfigurationsdatei einrichten. Für eine bessere Integration in UCI, wäre die Einrichtung über Kommandozeilenparameter oder Umgebungsvariablen wünschenswert. Zum Auslesen der
Konfigurationsdatei wird libconfig genutzt. Ein Ersetzen der Konfigurationsdatei durch Kommandozeilenparameter oder Umgebungsvariablen würde diese Abhängigkeit auflösen und das System
insgesamt leichtgewichtiger machen.
In der Auth SAE-Konfigurationsdatei müssen WLAN-Modus, WLAN-Kanal und Bandbreite (htmod) gesetz werden. Beim Start von Auth SAE werde diese Zwangsweise neu gesetzt. Dies ist von
Nachteil, wenn man z.B. bei einem Mesh Access Point auf einer WLAN-Karte sowohl die 802.11sSchnittstelle, als auch die 802.11a/b/g/n-Schnittstelle betreibt. Auth SAE ändert die vorher eingestellten Parameter und bietet dabei nur eine geringe Auswahl an Optionen. Als WLAN-Modus
kann nur 11a, 11b oder 11g gewählt werden. Bei der Bandbreiten-Option kann htmod="40-" nicht
ausgewählt werden. In OpenWRT werden Kanal, Bandbreite und WLAN-Modus sowieso über einen
andren Weg gesetzt. Es wäre daher sinnvoll, das Setzen von Kanal, Bandbreite und WLAN-Modus
aus der Auth SAE-Software zu entfernen.
Das Auth SAE-Paket nutzt libnl. Eine zukünftige Anpassung an libnl-tiny wäre empfehlenswert. Zur Zeit müssen libnl und libnl-tiny parallel installiert werden. Auf dem Linksys
WRT160NL ist dies dank ausreichend RAM kein Problem. Auf Routern mit wenig RAM könnten
dies die Installation von Auth SAE verhindern.
24
Anhang A
802.11s-Meshnetz mit iw verwalten
A.1
Aufsetzen eines 802.11s-Meshnetzes
Das nachfolgende Konfigurationsbeispiel zeigt das Erstellen eines Interfaces mesh0 über das auf
WLAN-Kanal 1 die Verbindung zum Meshnetzwerk mit der Mesh-ID testmesh vorgenommen
wird:
iw phy phy0 interface add mesh0 type mp
ifconfig mesh0 $IP up
iw mesh0 set channel 1
iw mesh0 mesh join testmesh
A.2
Netzstatus abfragen
Über den Befehl station dump können alle Peers aufgelistet werden:
root@mesh02:~# iw dev mesh0 station dump
Station ab:cd:ef:00:00:64 (on wlan0)
inactive time: 670 ms
rx bytes:
4213
rx packets:
112
tx bytes:
280
tx packets:
4
tx retries:
0
tx failed:
0
signal:
-26 [-39, -26] dBm
signal avg:
-24 [-37, -24] dBm
tx bitrate:
1.0 MBit/s
rx bitrate:
1.0 MBit/s
25
A.3. Mesh-Parameter
mesh llid:
mesh plid:
mesh plink:
authorized:
authenticated:
preamble:
WMM/WME:
MFP:
TDLS peer:
29709
60578
ESTAB
yes
yes
long
yes
no
no
[...]
Über den Befehl mpath dump können alle Paths aufgelistet werden:
root@mesh02:~# iw
DEST ADDR
ab:cd:ef:00:00:83
ab:cd:ef:00:00:64
dev mesh0 mpath dump
NEXT HOP
IFACE
ab:cd:ef:00:00:64 wlan0
ab:cd:ef:00:00:64 wlan0
SN
1044
1
METRIC
8193
8193
QLEN
0
0
EXPTIME
300
300
Und mit dem Befehl arp kann nachgesehen werden, welche IP-Adresse zu welcher MAC-Adresse
gehört:
root@mesh02:~# arp
IP address
HW type
192.168.88.1
0x1
192.168.88.3
0x1
A.3
Flags
0x2
0x2
HW address
ab:cd:ef:00:00:82
ab:cd:ef:00:00:64
Mask
*
*
Device
wlan0
wlan0
Mesh-Parameter
Mit Hilfe der Mesh-Parameter lassen sich z.B. Timeout-Perioden einstellen. Aber auch das Senden
von Rootannouncement und Gateannouncement lässt sich über Mesh-Parameter aktivieren. Als
Beispiel wird das Aktivieren des Rootannouncements gezeigt:
root@mesh02:~# iw dev mesh0 set mesh_param mesh_hwmp_rootmode=1
Einen Überblick über alle Mesh-Parameter und deren aktuelle Werte gibt der
Befehl get mesh param:
root@mesh02:~# iw dev mesh0 get mesh_param
mesh_retry_timeout = 100 msec.
mesh_hwmp_max_preq_retries = 4
mesh_confirm_timeout = 100 msec. mesh_path_refresh_time = 1000 msec.
mesh_holding_timeout = 100 msec. mesh_min_discovery_timeout = 100 msec.
mesh_max_peer_links = 32
mesh_hwmp_preq_min_interval = 10 TUs
mesh_ttl = 31
mesh_hwmp_active_path_timeout = 5000 TUs
mesh_element_ttl = 31
mesh_hwmp_rann_interval = 5000
26
A.4. Verschlüsseltes Mesh einrichten
mesh_auto_open_plinks = 0
mesh_gate_announcements = 0
mesh_max_retries = 3
mesh_hwmp_rootmode = 0
mesh_hwmp_net_diameter_traversal_time = 50 TUs
A.4
Verschlüsseltes Mesh einrichten
Wie Kapitel 3 zeigt, ist zur Zeit Auth SAE die einzige Möglichkeit, um ein 802.11s-Meshnetzwerk zu
verschlüsseln. Auth SAE wird über eine Konfigurationsdatei1 eingerichtet. Die wichtigste Einstellung
ist das Setzen des Passwortes. Weitere Parameter zur Einstellung2 werden auf der Auth SAEProjektseite beschrieben. Das Mesh wird wie in Abschnitt A.1 beschrieben aufgesetzt. Das Setzen
des Kanals ist allerdings überflüssig, da Auth SAE dies selbst vornimmt. An Stelle des Mesh-JoinBefehls (iw mesh0 mesh join testmesh) wird Auth SAE gestartet:
meshd-nl80211 -c /etc/authsae.cfg -i mesh0
# oder
meshd-nl80211 -B -c /etc/authsae.cfg -i mesh0 # als Daemon
Anhang B.5 zeigt die Konfiguration von Auth SAE in OpenWRT mit UCI.
1
2
Konfigurationsbeispiel: https://github.com/cozybit/authsae/blob/master/config/authsae.sample.cfg
Beschreibung der Konfigurationsparameter: https://github.com/cozybit/authsae/blob/master/README
27
Anhang B
802.11s-Meshnetz unter OpenWRT
einrichten
In diesem Anhang wird die Einrichtung eines 802.11s-Meshnetzwerkes auf einem OpenWRT-Router
beschrieben. Es wird vorausgesetzt, dass OpenWRT, wie in Anhang C beschrieben, installiert und
konfiguriert worden ist.
Netzwerkinterface (Kommandozeile, UCI): Zunächst wird ein Netzwerkinterface namens
meshif angelegt. Hierzu wird die Datei /etc/config/network wie folgt erweitert:
config interface ’meshif’
option proto ’static’
option ipaddr ’192.168.88.1’
option netmask ’255.255.255.0’
Alternativ kann das Interface per UCI -Kommandos angelegt werden:
uci
uci
uci
uci
uci
uci
add network interface
rename network.@interface[-1]=meshif
set network.meshif.proto=static
set network.meshif.ipaddr=192.168.88.1
set network.meshif.netmask=255.255.255.0
commit network
Um die Änderungen nutzbar zu machen, muss das Netzwerk mit dem Befehl /etc/init.d/network
restart neu gestartet werden.
Netzwerkinterface (LUCI): Das Interface kann auch über die Webschnittstelle LUCI konfiguriert werden:
28
B.1. Mesh Point
B.1
Mesh Point
UCI: Nach dem Flashen mit OpenWRT wird die WLAN-Karte automatisch erkannt und in die
Datei /etc/config/wireless folgender Eintrag eingefügt:
config wifi-device ’radio0’
option type ’mac80211’
option macaddr ’...’
option channel ’1’
Diese Angaben reichen, um ein Mesh zu betreiben. Eventuell muss die Option Channel noch angepasst werden:
uci set wireless.radio0.channel=...
uci commit wireless
802.11s-Meshnetzwerke können auch mit 40 GHz statt mit 20 GHz betrieben werden, ähnlich wie
dies bei 802.11n-Netzwerken der Fall ist. Hierzu werden folgende Optionen hinzugefügt:
29
B.1. Mesh Point
uci set wireless.radio0.hwmode=11ng
uci set wireless.radio0.htmode=HT40+
uci commit wireless
# oder htmode=HT40-
Die Option HT40+ gibt an, dass zusätzlich 20 GHz Bandbreite oberhalb des Frequenzbereiches
des gewählten Kanals genutzt werden. Wird HT40- gewählt, werden die 20 GHz unterhalb des
Frequenzbereiches des gewählten Kanals genutzt.
Um den Router als einfachen Meshpoint zu nutzen, wird per UCI ein Wifi-Interface hinzugefügt
und entsprechend konfiguriert. OpenWRT schreibt das Setzen der SSID für Wifi-Interfaces vor,
auch wenn diese in Meshnetzwerken nicht genutzt wird. Die Namenswahl kann beliebig erfolgen.
Der Übersicht halber wird im folgenden Beispiel die SSID der Mesh-ID gleichgesetzt:
uci
uci
uci
uci
uci
uci
uci
add wireless wifi-iface
set wireless.@wifi-iface[-1].device=radio0
set wireless.@wifi-iface[-1].mode=mesh
set wireless.@wifi-iface[-1].network=meshif
set wireless.@wifi-iface[-1].ssid=testmesh
set wireless.@wifi-iface[-1].mesh_id=testmesh
commit wireless
Durch Aufruf des Kommandos wifi auf der Konsole wird das WLAN des Routers mit den per UCI
gesetzen Optionen neu gestartet. Der Meshpoint ist nun verfügbar.
LUCI:
Zunächst wird ein neues Netzwerk hinzugefügt:
Dieses wird als Mesh konfiguriert. Optional können Frequenz und Bandbreite angepasst werden.
30
B.2. Mesh Portal (MPP)
Die ESSID spielt in 802.11s-Meshnetzwerken keine Rolle. Das UCI-System erfordert dennoch das
Setzen der ESSID. Diese kann frei gewählt werden. Der Übersicht zuliebe sollte sie gleich der
Mesh-ID gesetzt werden.
B.2
Mesh Portal (MPP)
Um ein Mesh Portal einzurichten, muss die Firewall1 des Routers ensprechend konfiguriert werden.
OpenWRT ordnet die verschiedenen Netzwerk-Interfaces einer Firewall-Zone zu.
Mesh Portal in ein WAN (Internet) (UCI): Standardgemäß existiert bereits eine Zone WAN, die dem Internetport (eth1) des Routers zugewiesen ist. Folgendes Beispiel erläutert die
Erstellung einer Zone meshfw für das Interface des Meshnetzwerks meshif. Eine Forwardingregel erlaubt den Meshteilnehmern WAN-Zugriff. Die Meshteilnehmer können WAN-Adressen aufrufen. Ihre
IP ist aber nur intern sichbar und aus dem Internet nicht aufrufbar. Für den WAN-/Internetzugang
ist daher der Einsatz von NAT und Masquerading notwendig. Dies wird mit der Option masq=1
aktiviert.
# Einrichten der Zone "Meshfw"
uci add firewall zone
uci set firewall.@zone[-1].name=meshfw
uci set firewall.@zone[-1].network=meshif
uci set firewall.@zone[-1].masq=1
uci set firewall.@zone[-1].input=ACCEPT
uci set firewall.@zone[-1].output=ACCEPT
uci set firewall.@zone[-1].forward=REJECT
# Verknüpfen der Zonen "Meshfw" und "WAN"
1
Generelle
Informationen
zum
http://wiki.openwrt.org/doc/uci/firewall
Einrichten
einer
Firewall
unter
OpenWRT:
31
B.2. Mesh Portal (MPP)
uci add firewall forwarding
uci set firewall.@forwarding[-1].dest=wan
uci set firewall.@forwarding[-1].src=meshfw
uci commit
firewall
Mesh Portal in ein WAN (Internet) (LUCI):
Auf dem Reiter Network/Firewall/General
Settings wird durch Klicken des Add-Buttons eine neue Firewall-Zone erstellt. Diese wird wie folgt
konfiguriert:
Rootannouncement/Gateannouncement:
Wird das Mesh hauptsächlich als Internetzugang genutzt, ist es sinnvoll Rootannouncement und Gateannouncement zu aktivieren.
(In der aktuellen Compat Wireless-Version ist das Gateannouncement nicht implementiert, obwohl
man es in den Einstellungen schon aktivieren kann. An dessen Stelle wird ein Rootannouncement
gesendet.)
Bei der Konfiguration über LUCI wird im Wireless Network-Dialog Root Announcement und Gate
32
B.2. Mesh Portal (MPP)
Announcement auf yes gesetzt. Per UCI kann man hierfür die Optionen mesh root und mesh gate
auf 1 setzen.
uci add wireless.@wifi-iface[0].mesh_root=1
uci add wireless.@wifi-iface[0].mesh_gate=1
uci commit wireless
Mesh Portal zum Intranet: Nachfolgend wird die Verbindung von einem Meshnetz mit einem
internen Netzwerk beschrieben. Es wird davon ausgegangen, dass die Teilnehmer der beiden Netze
sich gegenseitig per IP erreichen können. Die einfachste Möglichkeit ist es, die Netzwerk-Interfaces
der beiden Netze einer Firewall zuzuordnen:
# Die Netzwerk-Interfaces "meshif" und "lan"
# werden einer Zone zugeordnet:
uci add firewall zone
uci set firewall.@zone[-1].name=meshfw
uci set firewall.@zone[-1].network=meshif lan
uci commit firewall
Alternativ können auch hier zwei Firewallzonen verknüpft werden. Im nachfolgenden Beispiel wird
davon ausgegangen, dass die Zone LAN bereits existiert. Wie die Zone WAN wird LAN in der
Regel automatisch erstellt. Da sich die Teilnehmer von LAN und dem Meshnetz direkt ansprechen,
wird masq nicht gesetzt.
# Einrichten der Zone "Meshfw"
uci add firewall zone
uci set firewall.@zone[-1].name=meshfw
uci set firewall.@zone[-1].network=meshif
uci set firewall.@zone[-1].input=ACCEPT
uci set firewall.@zone[-1].output=ACCEPT
uci set firewall.@zone[-1].forward=REJECT
uci commit firewall
# Verknüpfen der Zonen "Meshfw" und "LAN"
# Es werden zwei Forwardingregeln angelegt
# Eine für MESH->LAN und die andere für LAN->MESH
uci add firewall forwarding
uci set firewall.@forwarding[-1].dest=lan
uci set firewall.@forwarding[-1].src=meshfw
uci commit firewall
uci add firewall forwarding
uci set firewall.@forwarding[-1].dest=meshfw
uci set firewall.@forwarding[-1].src=lan
33
B.3. Mesh Access Point (MAP)
uci commit
firewall
Änderungen übernehmen:
Um die Firewalleinstellungen zu übernehmen, muss die Firewall
neu gestartet werden:
/etc/init.d/firewall restart
MPP für Mesh Access Point: Sollen die mit MAPs verbundenen Netzwerkteilnehmer das
Portal nutzen können, muss dieses gleichzeitig als MPP und MAP konfiguriert werden. Abschnitt
3.1 erläutert die technischen Hintergründe.
B.3
Mesh Access Point (MAP)
In diesem Abschnitt wird beschrieben, wie der in Abschnitt B.1 eingerichtete Mesh Point in einen
Mesh Access Point umgewandelt wird. Hierzu muss zunächst das Netzwerkinterface meshif durch
die Bridge br-meshif ersetzt werden.
UCI:
Per UCI wird der Type von meshif auf bridge gesetzt wird:
uci set network.meshif.type=bridge
uci commit network
Nach dem Neustart des Netzwerkes isi die Bridge sichtbar:
root@mesh01:~# ifconfig
br-lan
[...]
br-meshif Link encap:Ethernet HWaddr .......
inet addr:192.168.88.1 Bcast:192.168.88.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
[...]
Nun wird ein weiteres Wifi-Interface ergänzt, um den Router als Wireless Access Point (Mode: ap)
zugänglich zu machen. Dabei wird die gleiche WLAN-Karte (radio0 ) genutzt, die auch das Mesh
nuzt:
uci
uci
uci
uci
uci
uci
uci
add wireless wifi-iface
set wireless.@wifi-iface[-1].device=radio0
set wireless.@wifi-iface[-1].mode=ap
set wireless.@wifi-iface[-1].encryption=none
set wireless.@wifi-iface[-1].ssid=testmap
set wireless.@wifi-iface[-1].network=meshif
commit wireless
34
B.3. Mesh Access Point (MAP)
Durch das Teilen der WLAN-Karte müssen sich das Mesh und der Access Point die Frequenz und
Bandbreite teilen. Ist dies nicht erwünscht, wird ein Router mit zwei WLAN-Karten benötigt. Dank
der USB-Schnittstelle kann der Linksys WRT160NL mit einem WLAN-USB-Stick einfach um eine zweite WLAN-Karte erweitert werden. Nach Neustart von Netzwerk (/etc/init.d/network
restart) und WLAN (wifi) kann der MAP genutzt werden.
Hinweis: Bei einem Test mit der SVN-Trunk Version r32582 funktionierte der MAP erst nach Neustart des gesamten Betriebssystems. In der aktuellen Stable-Version genügte es hingegen Netzwerk
und WLAN neu zu starten.
LUCI:
Als erstes wird MESHIF als Bridge konfiguriert:
Anschließend wird ein weiteres WLAN-Netzwerk ergänzt ...
... und als Access Point eingerichtet:
Nutzung eines Mesh Portals:
Wie Abschnitt 3.1 erläutert, können MAPs nur mit anderen
MAPs Daten austauschen. Soll ein MAP und die mit ihm verbunden Netzwerknoten ein MPP
nutzen können, so muss dieses gleichzeitig als MPP und MAP konfiguriert werden.
35
B.4. Mesh-Parameter
B.4
Mesh-Parameter
Alle per iw einstellbaren Mesh-Parameter (siehe Anhang A.3) können auch per UCI gesetzt werden.
Hierzu wird die Listenfunktion von UCI genutzt:
uci add_list wireless.@wifi-iface[0].mesh_param=mesh_max_peer_links=32
uci add_list wireless.@wifi-iface[0].mesh_param=mesh_ttl=30
uci commit wireless
Die Listenfunktion von UCI ist leider noch nicht ausgereift. Es ist zum Beispiel nicht möglich,
einzelne Elemente einer Liste zu entfernen. Man kann nur die Liste komplett löschen. Dies bereitet
dem Webinterface LUCI Probleme. Deshalb werden die wichtigsten Mesh-Parameter, welche das
Senden von Rootannouncement und Gateannouncement steuern, nicht über die mesh param-Liste
gesetzt, sondern direkt über Parameter des Interfaces eingestellt:
uci add wireless.@wifi-iface[0].mesh_root=1
uci add wireless.@wifi-iface[0].mesh_gate=1
Rootannouncement und Gateannouncement können somit per LUCI aktiviert werden (siehe Abschnitt B.2). Die übrigen Mesh-Parameter können nur per UCI gesetzt werden.
B.5
Verschlüsselung
Mit der im Rahmen dieses Projekts entstandenen Erweiterungen für OpenWRT ist es möglich, Auth
SAE per UCI zu konfigurieren. Es müssen mindestens folgende Parameter gesetzt werden:
uci set wireless.@wifi-iface[0].encryption=authsae
uci set wireless.@wifi-iface[0].key=secret
uci commit wireless
Dies kann alternativ auch mit LUCI gesetzt werden:
36
B.5. Verschlüsselung
Optional können die Parameter2 authsae group, authsae blacklist, authsae thresh,
authsae lifetime und authsae mcastrate mit UCI gesetzt werden.
2
Beschreibung der Konfigurationsparameter: https://github.com/cozybit/authsae/blob/master/README
37
Anhang C
OpenWRT mit
802.11s-Unterstützung für Linksys
WRT160NL kompilieren
Zunächst wird ein Verzeichnis openwrt r32582 angelegt. In diesem Verzeichnis wird die Revision
32582 des SVN-Trunk von OpenWRT ausgescheckt. Der OpenWRT-Quellcode liegt danach im
Unterordner trunk:
mkdir openwrt_r32582
cd openwrt_r32582
svn co svn://svn.openwrt.org/openwrt/trunk/@32582
Nun werden die in diesem Projekt entstandenen Erweiterungen1 eingespielt, indem die Datei
Openwrt r32582 11s mesh addons.tbz im Ordner trunk entpackt wird:
cd trunk
tar xvf Openwrt_r32582_11s_mesh_addons.tbz
Das OpenWRT-Buildsystem basiert auf Menuconfig. Die Standardkonfiguration für den Linksys
WRT160NL-Router wird mit folgenden Befehlen in die Konfigurationsdatei geschrieben:
echo CONFIG_TARGET_ar71xx=y > .config
echo CONFIG_TARGET_ar71xx_generic_WRT160NL=y >> .config
make defconfig
1
Download der Erweiterungen: https://wwwvs.cs.hs-rm.de/vs-wiki/index.php/MasterProjekte/802.11s auf SoHo-Routern
38
Nun werden weitere benötigte Pakete nachgeladen:
./scripts/feeds update packages luci
./scripts/feeds install -a -p luci
./scripts/feeds install -d m libconfig
make download
Anschließend wird Menuconfig gestartet ...
make menuconfig
... und folgende Optionen ausgewählt: (Variante: <Y> includes)
LuCI -->
Collections --->
luci
Applications --->
luci-app-ddns
luci-app-ntpc
luci-app-qos
luci-mesh
Libraries --->
libiw
Network --->
authsae
(Nur wenn Mesh verschlüsselt sein soll)
ath9k-nohwcrypt (Nur wenn Auth SAE benutzt werden soll und Router ATH9k-Chip hat)
Jetzt kann die OpenWRT-Toolchain kompiliert und das Image für den Router erstellt werden:
make world
Das Image zum flashen des Routers ist unter
bin/ar71xx/openwrt-ar71xx-generic-wrt160nl-squashfs-factory.bin verfügbar. Der
OpenWRT Flash-Dialog bietet die Option an, beim Flashen die alten Einstellungen zu behalten
(Keep Settings). Diese Option sollte unbedingt abgewählt werden, da sonst der Router unbrauchbar
wird. Wenn dies dennoch geschen sollte, gibt das OpenWRT-Wiki Auskunft darüber, wie mit Hilfe
eines TTL-Pegelwandlers über eine serielle Leitung ein intaktes Firmwareimage per TFTP überspielt
werden kann2 .
Die Imagedatei openwrt-ar71xx-generic-wrt160nl-squashfs-sysupgrade.bin ist fehlerhaft
und macht den Router ebenfalls unbrauchbar.
2
http://wiki.openwrt.org/toh/linksys/wrt160nl#hardware
39
Soll die Auth SAE-Verschlüsselung genutzt werden und kommt zusätzlich eine ATH9k-WLANKarte zum Einsatz, wie dies beim Linksys WRT160NL der Fall ist, muss der ATH9k-Treiber mit der
Option nohwcrypt=1 geladen werden. Das Paket ath9k-nohwcrypt richtet den Treiber beim ersten
Start des Routers entsprechend ein. Die Änderungen werden erst nach einem weiteren Neustart
des Routers aktiviert. Ist ath9k-nohwcrypt nicht installiert worden, kann der Treiber über die
Kommandozeile entsprechend konfiguriert werden:
echo "ath9k nohwcrypt=1" >/etc/modules.d/28-ath9k
40
Literaturverzeichnis
[11s]
IEEE Standard for Information Technology.
Local and metropolitan area networks — Specific requirements
Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications
Amendment 10: Mesh Networking, DRAFT - Sep. 2011.
[AODV] IETF — The Internet Engineering Task Force — Network Working Group.
Ad
hoc
On-Demand
Distance
Vector
(AODV)
http://tools.ietf.org/html/rfc3561, Jul. 2003.
Routing.
[ARP]
IETF — The Internet Engineering Task Force — Network Working Group.
An Ethernet Address Resolution Protocol. http://tools.ietf.org/html/rfc826, Nov. 1982.
[Abid]
Riduan M. Abid, Taha Benbrahim, Saâd Biaz.
IEEE
802.11s
Wireless
Mesh
Networks
for
Last-mile
Internet
Access:
An
Open-source
Real-world
Indoor
Testbed
Implementation.
http://www.eng.auburn.edu/users/sbiaz/publications/IEEE802.11.MeshNetworksAbid.pdf.
[Conn]
W. Steven Conner (Intel Corp.), Jan Kruys (Cisco Systems), Kyeongsoo Joseph Kim
(STMicroelectronics), Juan Carlos Zuniga (InterDigital Comm. Corp.).
IEEE 802.11s Tutorial
Overview of the Amendment for Wireless Local Area Mesh Networking, Nov. 2006.
[Love]
Robert Love. Linux-Kernel-Handbuch: Leitfaden zu Design und Implementierung von
Kernel 2.6, ISBN: 3-827-32204-9, 19 Jul. 2005.
[SAE]
D. Harkins (IEEE). Simultaneous Authentication of Equals: A Secure, Password-Based
Key Exchange for Mesh Networks, Aug. 2008.
41