IEEE 802.11s Mesh Network - €¦ · 2.1 Erweiterung des 802.11-Frames ... 1.1 Wireless Mesh...
-
Upload
truongxuyen -
Category
Documents
-
view
222 -
download
0
Transcript of IEEE 802.11s Mesh Network - €¦ · 2.1 Erweiterung des 802.11-Frames ... 1.1 Wireless Mesh...
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 Einfuhrung 1
1.1 Wireless Mesh Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Einsatzgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Uberblick uber IEEE 802.11s . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Komponenten eines 802.11s-Meshnetzes . . . . . . . . . . . . . . . 3
1.2.2 Einsatzgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 OpenWRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Das Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Ziel des Projektes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Anpassung des Projektzieles . . . . . . . . . . . . . . . . . . . . . 5
1.4.3 Projektabschluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 IEEE 802.11s-Meshnetzwerk im Betrieb 6
2.1 Erweiterung des 802.11-Frames . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Vermaschung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Address Resolution Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Hybrid Wireless Meshprotokoll . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Aufbau eines Pfades . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Reaktiver Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.3 Proaktiver Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.4 Vor- und Nachteile der verschiedenen Routingvarianten . . . . . . . 12
2.5 Uberblick uber die verschiedenen Kommunikationsebenen . . . . . . . . . . 12
3 IEEE 802.11s-Meshnetzwerke unter Linux 13
I
Inhaltsverzeichnis
3.1 Verhaltnis zwischen Mesh Points und Mesh Access Points . . . . . . . . . . 14
3.2 Meshframehandling im Linuxkernel . . . . . . . . . . . . . . . . . . . . . . 15
4 IEEE 802.11s-Meshnetzwerke unter OpenWRT 17
4.1 UCI - das OpenWRT-Konfigurationstool . . . . . . . . . . . . . . . . . . . 17
4.1.1 802.11s per UCI einrichten . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2 LUCI - Webkonfigurationsinterface . . . . . . . . . . . . . . . . . . 18
4.2 Verschlusselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Troubleshooting 19
5.1 Kein Datenaustausch im 802.11s-Meshnetzwerk . . . . . . . . . . . . . . . 19
5.1.1 Manuelles Fullen der Tabellen . . . . . . . . . . . . . . . . . . . . 20
5.2 ARP-Verabeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1 ARP-Filterung per sysctl . . . . . . . . . . . . . . . . . . . . . . . 20
5.3 Open11s-Funktionen in der MAC80211-Schicht . . . . . . . . . . . . . . . 20
5.4 Welche Frames erreichen die MAC80211-Schicht . . . . . . . . . . . . . . 20
5.5 Fehlerbehebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 25
A.1 Aufsetzen eines 802.11s-Meshnetzes . . . . . . . . . . . . . . . . . . . . . 25
A.2 Netzstatus abfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.3 Mesh-Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.4 Verschlusseltes Mesh einrichten . . . . . . . . . . . . . . . . . . . . . . . . 27
B 802.11s-Meshnetz unter OpenWRT einrichten 28
B.1 Mesh Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
B.2 Mesh Portal (MPP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
B.3 Mesh Access Point (MAP) . . . . . . . . . . . . . . . . . . . . . . . . . . 34
B.4 Mesh-Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
B.5 Verschlusselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
C OpenWRT mit 802.11s fur WRT160NL kompilieren 38
Literaturverzeichnis 41
II
Abbildungsverzeichnis
1.1 Wireless Mesh Network mit direktem Path und Path uber mehrere Hops . . . . 1
1.2 Netzwerk mit Mesh Point, MPP und MAP . . . . . . . . . . . . . . . . . . . . 3
2.1 Standard-802.11-Frame wird um das Mesh-Control-Field erweitert . . . . . . . 6
2.2 Sequenznummer bei Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Peerbildung nach Beacon-Empfang . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Erwartungsgemaßes Verhalten der Verarbeitung eines ARP-Request. . . . . . . 9
2.5 Path Request nach Senden des Rootannouncments . . . . . . . . . . . . . . . 11
3.1 Das Open 11s-Projekt steuert 802.11s-Erweiterungen fur Linux Wireless bei. . . 13
3.2 Treiber ubergibt 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
Kapitel 1
Einfuhrung
Dieses Kapitel vermittelt zunachst 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 aus-
kommen. Netzaufbau und Konfiguration finden automatisch statt. Knoten, die im direkten Funk-
kontakt 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 uber mehrereHops (orange).
1
1.2. Uberblick uber IEEE 802.11s
Uber diesen Datenkanal konnen benachbarte Knoten direkt miteinander kommunizieren. Nachrich-
ten an entfernte Knoten mussen 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 standig aktualisiert. Dies erlaubt eine hohe Dynamik hinsichtlich der
Topologie des Netzwerkes. Außerdem zeichnet sich ein Meshnetz durch eine gute Skalierbarkeit
aus. Die Knoten konnen sich also jederzeit in ein Mesh ein- und ausbuchen, sowie ihre Position
innerhalb des Netzwerkes verandern.
1.1.1 Einsatzgebiete
Wireless Mesh Networks sind vielseitig einsetzbar. Nachfolgend werden beispielhaft zwei Einsatz-
szenarien erlautert.
Sensornetzwerke: In einem Sensornetzwerk werden die einzelnen Sensoren haufig uber 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 verfugbar sind, werden Meshnetze genutzt,
um einzelne Haushalte per Funk an das Internet anzuschließen. Die einzelnen Hauser werden mit
Antennen ausgestattet und vernetzen sich untereinander. Zusatzlich wird mindestens ein Haus per
Richtfunk mit einem Sendemast verbunden, der dann den Zugang zum Internet fur das gesamte
Meshnetz zur Verfugung stellt.
1.2 Uberblick uber 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 fur Meshnetzwerke erweitert. Die Spezifi-
kation hat zur Zeit den Status Draft. Sie ist also noch nicht endgultig abgeschlossen. Das besondere
dabei ist, dass das Routing auf MAC-Ebene stattfindet (Layer 2 des OSI-Modells) und nicht wie
sonst ublich auf IP-Ebene (OSI-Layer 3). Dies macht das Routing sehr effizient hinsichtlich Be-
arbeitungszeit, Ressourcenbedarf und Energieverbrauch. Fur die Anwendungsebene wird das Rou-
tingverfahren transparent gehalten. Anwendungen konnen uber normale IP-Sokets kommunizieren.
Es mussen 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 ublich, konnen auch in 802.11s-Netzen standig Teilnehmer wegfallen und
neue hinzukommen. Daher wird auf die Verwendung von DHCP verzichtet. Gemaß der Spezifika-
tion ist namlich nicht gewahrleistet, das ein DHCP-Server immer verfugbar ist. Die IP-Adressen
2
1.2. Uberblick uber IEEE 802.11s
mussen von den Meshteilnehmern statisch konfiguriert werden. Kapitel 2 erlautert die wichtigsten
Vorgange 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 herkommlichen
WLAN-Netz. Alle Netzwerkteilnehmer mit derselben Mesh-ID bilden ein Meshnetz.
• Kanal/Frequenz: Es werden die im 802.11-Standard-ublichen Kanale und Frequenzen ge-
nutzt. Die Teilnehmer eines Meshnetzes mussen denselben Kanal verwenden.
• Bandbreite: Standardgemaß wird eine Bandbreite von 20 MHz genutzt. Optional kann, wie
beim IEEE 802.11n-Standard, auch eine Bandbreite von 40 MHz gewahlt werden.
Verschlusselte Kommunikation: Da laut Spezifikation ein 802.11s-Meshnetzwerk stark ska-
liert, kann es keinen zentralen Knoten als Authentifizierungsserver geben. Die Authentifizierung
muss Peer-2-Peer uber einen Preshared-Key erfolgen. Hierfur konnen die in IEEE 802.11i definier-
ten Authentifizierungsmethoden wie WPA2 eingesetzt werden.
Als Alternative definiert 802.11s mit [SAE] ein eigenes Authenfizierungs- und Verschlusselungsprot-
koll: Simultaneous Authentication of Equals (SAE, Auth SAE). Auth SAE wendet Zero-Knowledge-
Proof an. Es ist sicher gegenuber aktiven und passiven Attacken, so wie Worterbuchattacken.
1.2.1 Komponenten eines 802.11s-Meshnetzes
Abbildung 1.2: Netzwerk mit Mesh Point (MP), Mesh Portal (MPP) und Mesh AccessPoint (MAP)
Die Teilnehmer eines 802.11s-Meshnetzwerkes werden als Mesh Point (MP) bezeichnet. Ein MP
kann ein Router sein, aber auch ein 802.11s-fahiges Laptop, dass sich mit dem Mesh verbunden hat.
Die Mesh Points konnen zusatzlich zwei Sonderrollen einnehmen. Ein Mesh Access Point (MAP)
gehort zum einen zu einem Mesh wie ein gewohnlicher MP, zum anderen gibt er sich als normaler
802.11a/b/g/n-Access Point aus und macht somit das Mesh fur herkomliche WLAN-Endgerate
3
1.3. OpenWRT
nutzbar. Ein Mesh Portal (MPP) verbindet das Mesh mit einem andren Netzwerk (Gateway). Es ist
moglich, 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 hauptsachlich im Ersatz kleinerer interner Netzwerke, sowie im
Last-Mile-Internetaccess (siehe [Abid]). In kleineren Firmen konnte das Intranet durch ein 802.11s-
Meshnetzwerk realisiert werden. Das Verlegen von Kabeln und die Installation von Switches ist somit
uberflussig. Relativ teure Businesshardware kann durch gunstige SoHo-Produkte ersetzt werden. Ein
Firmengebaude kann problemlos mit WLAN abgedeckt werden, ohne dass Repeater, welche in der
Realitat oft Probleme verursachen, zum Einsatz kommen mussen.
Auch im Heimbereich kann 802.11s zum Einsatz kommen. In alteren Hausern mit stark abschir-
menden Wanden kann das Meshnetz fur flachendeckenden Netzwerkzugriff sorgen. Dieses Konzept
kann auf große Wohnalagen ausgedehnt werden. In einem Studentenwohnheim oder einem Hoch-
haus gabe es dann einen zentralen High-Speed-Internetzugang. Die einzelnen Wohnungen nutzen
diesen gemaß dem Last-Mile-Internetaccess-Konzept dann uber das Meshnetzwerk.
In San Francisco wird dieses Konzept bereits angewandt, um in sozialen Brennpunkten kosten-
losen Internetzugang anzubieten. Ein Meshnetz wird hier uber ganze Hauserblocks 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 Rou-
ter. Die Laptops vernetzen sich direkt im freien Feld miteinander. Dies ist dank der Dynamik und
Skalierbarkeit der 802.11s-Netze problemlos moglich.
Damit sind Meshnetze auch fur den Katastrophenschutz, Rettungsdienst oder die Polizei eine
denkbare Moglichkeit, eine mobile Vernetzung an großeren Einsatzorten umzusetzen. Ein Einsatz-
leitfahrzeug dient als Gateway zum Internet bzw. zum Polizei-Intranet. Weitere Einsatzwagen ver-
netzen sich mit dem Einsatzleitfahrzeug. Zudem konnen Akkubetriebene Router die Reichweite des
Netzes erweitern.
1.3 OpenWRT
OpenWRT ist eine minimale Linuxdistribution, die fur den Einsatz auf Embedded Devices, insbe-
sondere fur 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 Me-
nuconfig basierenden Toolchain uber SVN bereit. Der Einsatz von OpenWRT auf SoHo-Routern
bringt diverse Vorteile gegenuber dem Betrieb mit der originalen Firmware. OpenWRT nutzt die
1One Laptop per Child verteilt 100-Dollar-Laptops an Kinder in Entwicklungslandern.2OpenWRT-Homepage: http://www.openwrt.org/; Projektmanagement: https://dev.openwrt.org/
4
1.4. Das Projekt
technischen Moglichkeiten der Hardware nahezu komplett aus, wahrend die Herstellersoftware oft
nur einen bestimmten Bereich an Funktionen zulasst. Kapitel 3 zeigt, dass 802.11s-Meshnetze
unter Linux mit Hilfe des Kernelmoduls MAC80211 betrieben werden. MAC80211 ist fur Soft-
MAC-WLAN-Karten zustandig. Die meisten SoHo-Router setzen diese relativ gunstige Variante
von WLAN-Karten ein. OpenWRT kann somit mit sehr vielen Routern 802.11s-Meshnetze aufbau-
en, auch wenn die Konfiguration noch nicht ganz ausgereift ist, wie in Kapitel 4 zu sehen ist.
1.4 Das Projekt
1.4.1 Ziel des Projektes
Ziel des Projektes ist es ein Meshnetzwerk nach IEEE 802.11s-Standard mit SoHo-Routern auf-
zubauen. In dem Projekt kommen funf 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 Kon-
figurationsmoglichkeiten sollen durch entsprechende Erweiterungen erganzt werden. Mit diesem
Dokument werden wichtige Komponenten von 802.11s erlautert 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. Hochste Prioritat 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 erlautert die erreichten
Ziele genauer. Die im Rahmen des Projektes erstellten Erweiterungen sind uber das VS-Wiki der
Hochschule RheinMain4 verfugbar.
3Informationen zu OpenWRT auf dem WRT160NL http://wiki.openwrt.org/toh/linksys/wrt160nl4https://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. Zu-
dem kommt Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) zum Einsatz. Dieser
Mechanismus soll das gleichzeitige Senden zweier 802.11-WLAN-Gerate auf der selben Frequenz
verhindern. Bevor ein 802.11-Frame abgeschickt wird, muss der Sender uberprufen, ob auf der
Frequenz gesendet wird und gegebenenfalls die zusendende Frame solange zuruckhalten, 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 umdas 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 Datenubertragung verwendet, die um ein Mesh-Control-Field erweitert sind. Das Mesh-Control-
Field nutzt die ersten Bytes des Frame-Bodys. Die Nutzdaten folgen anschließend. WLAN-Gerate,
die nicht 11s-fahig sind, behandeln das Mesh-Control-Field daher als Teil eines normalen Frame-
Bodys. 11s-Frames konnen also mit den Standard 802.11-Mechanismen verarbeitet werden und
stellen fur nicht 11s-fahige WLAN-Gerate, die sich mit einem Meshnetzwerke die Frequenz teilen,
keinen unnotigen Ballast dar. Der 11s-Frame wird von ihnen als netzwerkfremd erkannt und ver-
worfen. Adressfeld 1 und 2 werden fur einen Hop des Datenpaketes verwendet. Adressfeld 3 und
4 werden fur 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 Nut-
zung von Adressfeld 5 und 6 bekannt gegeben werden. Diese werden als globale Absender- und
Empfangeradresse genutzt und benotigt, wenn Empfanger 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 erhalt bei einem Broadcast identische Nachrichten auf verschie-denen Wegen. Anhand der MAC-Adresse des Absenders und der Sequenznummer wird dieDublette 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 uberflussigen
Datenverkehr vermeiden, wie Abbildung 2.2 zeigt. Die Netzwerkknoten loggen, welche Nachrichten
sie von welcher MAC-Adresse mit welcher Sequenznummer erhalten haben. Sollten identische Nach-
richten uber 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 gehoren auch In-
formationen zur Verbindungsqualitat und zum Datendurchsatz. Theoretisch konnten anhand der
Eintrage der Stationtable der Pfad zu benachbarten Knoten direkt abgeleitet werden. Durch die
Trennung von Vermaschung und Routing ist dies aber nicht mehr moglich. Somit halt man sich
die Moglichkeit offen, neben dem Standard-Routingprotokoll HPWM auch zusatzliche Protokolle
optional zuzulassen.
Abbildung 2.3: Nach Empfang des Beacons (1) wird per Peer Request (2) undPeer Reply (3) der Peer (4) zwischen den Knoten etabliert.
Jeder Netzwerkknoten sendet in regelmaßigen Abstanden ein Beacon, mit dem unter anderem
auch die Mesh-ID publiziert wird. Empfangt nun ein anderer Knoten mit derselben Mesh-ID den
Beacon in ausreichendener Qualitat, 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
uber einen Peer verbunden. Der Peer ist ein logischer Datenkanal, der vom unterliegenden Rou-
tingprotokoll zum Datenaustausch genutzt wird.
2.3 Address Resolution Protokoll (ARP)
Mochte ein Knoten mit einer bestimmten IP-Adresse kommunizieren, kommt das Address Resolu-
tion Protokoll (ARP) zum Einsatz. Wie in klassischen WLAN-Netzen ublich, existiert eine ARP-
Tabelle, 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 enthalt die gesuchte IP-Adresse, sowie IP- und MAC-Adresse des Senders. Er wird
mit einen ARP-Reply quittiert. Die Quittierung erfolgt uber einen Path als Unicast. Standardgemaß
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: Erwartungsgemaßes Verhalten der Verarbeitung eines ARP-Request.
Path fur diesen Unicast besteht. Der ARP-Reply wird dann so lange zuruckgehalten, 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 fur das Routing innerhalb
von 802.11s-Meshnetzen. 802.11s erlaubt es zwar, eigene Routingprotokolle zu nutzen. Diese konnen
aber nur optional hinzugefugt werden. Bei der vollstandigen Implementierung des Standards ist das
Vorhandensein von HPWM Pflicht.
Wie der Name schon sagt, handelt es sich bei HPWM um ein hybrides Protokoll. Standard-
gemaß 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 Uberblick uber beide Routingmodi.
HPWM speichert alle aktiven Pfade in einer Meshpath-Tabelle ab. In einem Tabelleneintrag
wird einer Empfanger-Adresse eine Next-Hop-Adresse zugeordnet. Die Next-Hop-Adresse muss uber
einen Peer erreichbar sein. Wenn Sender und Empfanger uber einen Peer miteinander verbunden,
sind Next-Hop-Adresse und Empfanger-Adresse identisch. Aus HPWM-Sicht ist nicht der komplette
Pfad zu einem Empfangerknoten bekannt, sondern immer nur der nachste Hop.
2.4.1 Aufbau eines Pfades
Fur den Aufbau von Pfaden innerhalb von 802.11s-Meshnetzen wird eine Variation des Ad-hoc
On-demand Distance Vector-Routingalgorithmus (AODV) verwendet. [AODV] sieht hierfur 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 (PREP-
ACK). Fur den Aufbau eines Pfades, wird von einem Knoten zunachst 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 gewohn-
lichen Broadcast werden die Pakete uber alle vorhandenen Peers weitergeleitet. Kommen nun auf
verschiedenen Wegen identische Nachrichten bei einem Knoten an, werden die Dubletten nicht wie
sonst ublich 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 Qualitat eines Pfades. Hierfur 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 zusatzlich die Zeit interner Verzogerungen,
welche in der Regel durch den Einsatz von CSMA/CA zustande kommen. Um die Path Metric zu
bestimmen wird von der Airtime diese Verzogerungszeit abgezogen. Der Pfad mit dem geringsten
Wert erfullt nun das Best Path Metric-Kriterium.
Der Zielknoten bekommt nun uber jeden Peer genau eine Kopie des PREQ-Paketes zugestellt,
sofern der Knoten einen moglichen Pfad zum Sender des PREQ-Paktes hat. Der Zielknoten tragt
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
erfullt. Nun wird uber diesen Pfad der PREP gesendet. Alle Hop-Knoten tragen nun nach dem
selben Schema die MAC-Adresen von PREQ-Sender und Empfanger ein. Als Next-Hop fur die
Empfanger-MAC wird die PREP-Quelle eingetragen und als Next-Hop fur die Sender-MAC die
10
2.4. Hybrid Wireless Meshprotokoll
PREQ-Quelle genommen, die das Best Path Metric-Kriterium erfullt. 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 ver-
sandt werden sollen. Hierfur wird die Meshpath-Tabelle uberpruft. Ist fur die Zieladresse kein Eintrag
vorhanden, wird zunachst 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
ungultig.
2.4.3 Proaktiver Modus
Im proaktiven Modus ubernimmt 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 uber 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, mussen in jedem
Fall Richtung Rootknoten gesendet werden. Ist ein Knoten mit der Ziel-MAC-Adresse im Netz
vorhanden, muss spatestens 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. Uberblick uber 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 andern sich standig und mussen neu angepasst werden. In eher statischen Umgebungen ist
dies aber von Nachteil. Die Kommunikation wird unnotig verzogert, da vor jedem Datenaustausch
erst ein Pfad erstellt werden muss.
Der proaktive Modus ist fur statische Umgebungen besser geeignet. Insbesondere dann, wenn der
Rootkonten gleichzeitig ein Portal (MPP) zum Internet darstellt. Die Pfade werden einmal aufge-
baut und die Kommunikation kann direkt erfolgen.
2.5 Uberblick uber die verschiedenen
Kommunikationsebenen
Die nachfolgende Tabelle gibt einen Uberblick uber die Sendeebene, der in den vorherigen Abschnit-
ten beschriebenen Pakettypen.
Ebene Typ
Direkter Funkkontakt Beacon, Peer-Request, Peer-Reply
Peer Rootannouncement, Gateannouncement, PREQ, PREP, PREP-
ACK, PERR, ARP-Request
Path ARP-Reply, Datenversand
Verschlusselungsebene: Die Verschlusselung von 802.11s-Meshnetzwerken erfolgt Peer-2-Peer,
wie Abschnitt 1.2 zeigt. Jede Kommmunikation auf Peer- und Pathebene ist demnach verschlusselt.
Verschlusselte 802.11s-Meshnetzwerke sind somit gegen Routing Attacks geschutzt.
12
Kapitel 3
IEEE 802.11s-Meshnetzwerke unter
Linux
Das Linux Wireless-Projekt1 ist fur den WLAN-Stack im Linuxkernel2 zustandig. Dieser wird unter
dem Namen Compat Wireless veroffentlicht. 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 Geratetreibern der WLAN-Hardware.
Da in der Regel, um WLAN-Hardware gunstig herstellen zu konnen, die MAC-Schicht nicht in
Hardware implementiert ist, muss diese durch Software emuliert werden. Hierfur ist das Kernelmodul
MAC80211 zustandig, 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 fur Linux Wirelessbei.
1Homepage des Linux Wireless-Projekts: http://linuxwireless.org/2Linuxkernel-Homepage: http://kernel.org/
13
3.1. Verhaltnis zwischen Mesh Points und Mesh Access Points
kapselt. Fur OpenWRT existiert eine abgespeckte Variante von NL80211: libnl-tiny. Programme im
Userlayer konnen NL80211 nutzen, um uber 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 fur den
neuen WLAN-Stack. Mit iw konnen 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-fahige 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 vollstandig 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.
Verschlusselung: Open11s bietet zur Verschlusselung derzeit ausschließlich Auth SAE4 an. An-
dere Methoden (vgl. Abschnitt 1.2) werden mit dem aktuellen Entwicklungstand nicht unterstuzt.
Auth SAE wird vom Open11s-Projekt entwickelt und greift auf NL80211 zu. Um ein verschlusseltes
Mesh aufzusetzen, konfiguriert man es zunachst mit iw und ruft dann das Programmmeshd-nl80211
auf. Dieses setzt die Auth SAE-Verschlusselung um. Anhang A.4 zeigt hierfur ein Konfigurations-
beispiel.
3.1 Verhaltnis zwischen Mesh Points und Mesh Access
Points
In der aktuellen Implementierung von 11s agieren Mesh Points und Mesh Access Points auf ver-
schiedenen 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 uber eine klassische
Netzwerkverbindung (WLAN, Ethernet) mit einem MAP verbunden sind.
3Homepage des Open-11s-Projekts: http://open80211s.org/4Auth SAE-Projekt: http://authsae.sourceforge.net/
Siehe auch: https://github.com/cozybit/open80211s/wiki/HOWTO, Abschnitt For secured mesh und Se-
cure Mesh Setup
14
3.2. Meshframehandling im Linuxkernel
Alle Teilnehmer konnen 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 fur 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 konnen 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 ermoglichen, muss der entsprechende MPP in die Gruppe der
MAPs uberfuhrt 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 ubergibt 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 fur die Verar-
beitung des Frames zustandig ist und die entsprechenden Daten an die MAC80211-Schicht weiter
gibt (ieee80211 rx()). Nun wird gepruft, ob der Frame zu einem WLAN-Interface gehort. Fur
jeden Interfacetyp gibt es spezielle Handler. Der Meshhandler ist fur die Meshinterfaces zustandig
und uberpruft zunachst, ob der Frame uber die richtige Ebene versand wurde (siehe Tabelle in Ab-
schnitt 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 nachste Hop ausgelesen und der Frame
uber den entsprechenden Path weitergeleitet. Ist das Datenpaket fur 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 fur Router spezialisierte
Linuxdistribution. Es kommen die Programme zum Einsatz, die auch auf Desktopdistributionen
fur den Netzwerkbereich zustandig sind. Teilweise werden auch Lightwight-Varianten dieser Pro-
gramme genutzt. Das besondere an OpenWRT ist, dass alle Programme uber ein einheitliches
Konfigurationstool eingerichtet werden konnen.
4.1 UCI - das OpenWRT-Konfigurationstool
Normalerweise erfolgt die Konfiguration der einzelnen Programme unter Linux uber Konfigurati-
onsdateien in Unterordnern des Verzeichnisses /etc. Deren Aufbau und Syntax ist allerdings alles
andere als einheitlich. Deshalb nutzt OpenWRT UCI1 (Universal Configuration Interface) als Ab-
straktionsschicht fur die individuellen Einrichtungsdateien. Auch fur das Starten und Stoppen sowie
das Aktivieren und Deaktivieren von Systemdiensten ist UCI zustandig. 802.11s-Meshnetzwerke
werden ebenfalls uber UCI eingerichtet.
4.1.1 802.11s per UCI einrichten
Zu Beginn des Projektes war die Einrichtung von 802.11s-Meshnetzwerken mit UCI nur teilwei-
se moglich. Die sogenannten Meshparameter konnten nicht eingestellt werden. Diese werden mit
dem Programm iw gesetzt. Hier konnen z.B. Timeout-Perioden festgelegt werden, aber auch das
Senden von Rootannouncement und Gateannouncement, welches zentrale Elemente von 802.11s-
Meshnetzen sind. Im Rahmen dieses Projektes wurde ein Patch erstellt, das diese fehlenden Funk-
tionen erganzt. Das Patch wurde dem OpenWRT-Projekt zur Verfugung gestellt2, so dass kunftig
1http://wiki.openwrt.org/doc/uci2https://dev.openwrt.org/ticket/11634
17
4.2. Verschlusselung
Meshnetzwerke vollstandig uber UCI eingerichtet werden konnen. Anhang B zeigt Konfigurations-
beispiele der verschiedenen Meshkomponenten.
4.1.2 LUCI - Webkonfigurationsinterface
Von handelsublichen Routern ist man es gewohnt, sie uber eine Weboberflache per Browser konfi-
gurieren zu konnen. Dies ist auch mit OpenWRT moglich. Hier kommt eine MVC-Webanwendung
namens LUCI zum Einsatz. LUCI ist ein Wrapper fur UCI. Mit Abschluss dieses Projektes kann ein
802.11s-Meshnetzwerk komplett uber LUCI eingerichtet werden. Zuvor konnte lediglich der Netz-
werktyp 11s eingestellt werden. Weitere Optionen, wie z.B. das essentielle Setzen der Mesh-ID,
konnte anschließend per UCI vorgenommen werden.
4.2 Verschlusselung
Wie in Kapitel 3 zu sehen, ist die Verschlusselung 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 fur
OpenWRT erstellt. Die Verschlusselung 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 fur den Enduser eine bequeme Einrichtung
von Auth SAE zu ermoglichen, wurde UCI und LUCI entsprechend erweitert. Im einfachsten Fall
muss nur ein Passphrase vom Nutzer gesetzt werden. Fur alle ubrigen erforderlichen Parameter
werden Standartwerte genutzt, wenn der Nutzer keine Werte per UCI gesetzt hat. Anhang B.5
enthalt weitere Informationen und zeigt ein Konfigurationsbeispiel.
3Beschreibung der Konfigurationsparameter von Auth SAE: https://github.com/cozybit/authsae/blob/master/README
18
Kapitel 5
Troubleshooting
In dem aus funf Linksys WRT160NL-Routern bestehenden 802.11s-Meshnetzwerk erfolgte keine Da-
tenkommunikation. Der Grund hierfur lag in einem Fehler des ATH9k-WLAN-Treibers, der Frames
filterte, die zum Aufbau der Kommunikation benotigt wurden. Ein Großteil der Projektbearbei-
tungszeit wurde fur die Fehleranalyse und die Behebung des Fehlers aufgewandt. Dieses Kapitel
zeigt die wichtigsten Analysemethoden, die den Fehler zunachst eingekreist hatten und letztendlich
die Behebung ermoglichten.
5.1 Kein Datenaustausch im 802.11s-Meshnetzwerk
Zu Projektbeginn wurde ein einfaches Meshnetz aufgebaut. Hierbei wurden zwei Varianten getes-
tet: der Aufbau uber das CLI-Programm iw und uber das OpenWRT-Konfigurationstool UCI (vgl
Abschnitt 4.1). Um die Funktionsfahigkeit zu kontrollieren, wurde erfolglos versucht die Knoten ge-
genseitig 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 Eintrage (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 Abbil-
dung 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 uber 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 mussten alle anderen Router den ARP-Request, wel-
cher ein Broadcast ist, uber 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 Fullen der Tabellen
Als Workaround wurden probeweise Meshpath- und ARP-Tabelle manuell per CLI gefullt. Das
Netzwerk verhielt sich wie erwartet. Die Datenkommunikation erfolgte problemlos.
5.2 ARP-Verabeitung
Als nachstes wurde die ARP-Verarbeitung im Linuxkernel uberpruft. Hierzu wurde in dem zum
Linuxkernel gehorenden Compat Wireless-Modul alle Funktionen der Datei arp.c mit printk()
makiert. Auf dem Router, der den ping-Befehl ausfuhrte, konnte die Erstellung des ARP-Requestes
im Kernellog mitverfolgt werden. Auf allen ubrigen Routern wurde aber keine Funktion von arp.c
aufgerufen. Demzufolge werden ARP-Request-Pakete nicht an die ARP-Schicht weitergeleitet, son-
dern vorher gefiltert.
5.2.1 ARP-Filterung per sysctl
Die zuvor erlauterten Probleme waren ein Indiz dafur, das in den sysctl-Einstellungen ARP-Filter
aktiviert waren. Eine Uberprufung 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 zuruck, wurden diese
per printk() im Kernellog sichtbar gemacht. Eine Uberwachung 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 uberhaupt 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 uberwacht:
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 fur ARP-Pakete. Im Kernellog erschien keine ARP received-Meldung. Folglich wurde der ARP-
Request bereits auf Treiberebene gefiltert. Das printk()-Statement wurde abgeandert, 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 ubergeben, ebenfalls
der Beacon der netzwerkfremden Fritz!Box. Der Beacon des Sitecom-Routers kam aber ebenfalls in
der MAC80211-Schicht nicht an. Das erwartete Verhalten ware, dass die netzwerkfremden Beacons
von ieee80211 rx() uber mehrere Schritte an ieee80211 rx handlers()weitergegeben werden.
Der dem Frametyps entsprechende Handler wurde erkennen, das die Beacons zu keinem auf dem
Router konfigurierten Netzwerk gehoren und sie daraufhin verwerfen.
5.5 Fehlerbehebung
Die MAC80211-Schicht konfiguriert den Treiber. Neben Einstellungen wie Frequenz und Bandbrei-
te werden auch Framefilter definiert. Diese werden bei Routern mit ATH9k-WLAN-Chips uber die
Funktion ath9k configure filter() (ath9k/main.c) gesetzt. Die Uberwachung mit printk()
zeigte, dass MAC80211 wie erwartet alle erforderlichen Flags setzte. Der Fehler musste also Treiber-
intern liegen.
Die Funktion ath calcrxfilter() in ath9k/recv.c enthalt einen Hinweis, dass das
ATH9K RX FILTER PROM-Flag bei alteren 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 standardgemaß bei der Chipversion AR-9160 gesetzt.
Bei dem Linksys WRT160NL wird die Version AR-9100 genutzt. Das if-Statement wurde entspre-
chend 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 Fehlerbehe-
bung 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-WLAN-
Treiber der Router konnte behoben werden. Es wurde ein Testnetzwerk aufgebaut, das alle Kom-
ponenten 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 uber das OpenWRT-eigene
Konfigurationstool UCI eingerichtet werden. Uber die Weboberflache LUCI konnte sogar nur der
Netzwerktyp ausgewahlt werden. Essentielle Einstellungen, wie das Setzen der Mesh-ID waren nicht
moglich. Die fehlenden Einstellungsmoglichkeiten fur UCI wurden erganzt. LUCI wurde erweitert,
so dass nun fur ein 802.11s-Meshnetzwerk Mesh-ID, Root-/Gateannouncement und Auth SAE-
Verschlusselung eingestellt werden konnten.
Das Open11s-Projekt sieht zur Zeit fur Linux nur eine Variante verschlusselter Kommunikation
vor: Die Nutzung von Auth SAE. Ein Auth SAE-Paket wurde innerhalb dieses Projektes fur Open-
WRT erstellt. UCI wurde entsprechend erweitert, um Auth SAE einrichten zu konnen. Uber LUCI
kann ebenfalls die Verschlusselungsmethode Auth SAE gewahlt und ein Passphrase gesetzt werden.
Somit ist es moglich, ein verschlusseltes Mesh komplett uber die Web-Schnittstelle einzurichten.
Das Projekt wurde mit Revision r32582 aus dem OpenWRT SVN-Trunk1 beendet. Alle in dem
Projekt entstandenen Veranderungen gegenuber dieser SVN Revison sind uber das VS-Wiki der
Hochschule RheinMain abrufbar2.
1https://dev.openwrt.org/wiki/GetSource2 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 konnten.
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 ware wunschenswert. 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 fur OpenWRT erstellt, dabei zeig-
ten sich allerdings einige Schwachen, besonders im Bereich der Konfiguration. Auth SAE lasst
sich nur per Konfigurationsdatei einrichten. Fur eine bessere Integration in UCI, ware die Einrich-
tung uber Kommandozeilenparameter oder Umgebungsvariablen wunschenswert. Zum Auslesen der
Konfigurationsdatei wird libconfig genutzt. Ein Ersetzen der Konfigurationsdatei durch Komman-
dozeilenparameter oder Umgebungsvariablen wurde diese Abhangigkeit auflosen und das System
insgesamt leichtgewichtiger machen.
In der Auth SAE-Konfigurationsdatei mussen WLAN-Modus, WLAN-Kanal und Bandbreite (ht-
mod) 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.11s-
Schnittstelle, als auch die 802.11a/b/g/n-Schnittstelle betreibt. Auth SAE andert die vorher ein-
gestellten Parameter und bietet dabei nur eine geringe Auswahl an Optionen. Als WLAN-Modus
kann nur 11a, 11b oder 11g gewahlt werden. Bei der Bandbreiten-Option kann htmod="40-" nicht
ausgewahlt werden. In OpenWRT werden Kanal, Bandbreite und WLAN-Modus sowieso uber einen
andren Weg gesetzt. Es ware daher sinnvoll, das Setzen von Kanal, Bandbreite und WLAN-Modus
aus der Auth SAE-Software zu entfernen.
Das Auth SAE-Paket nutzt libnl. Eine zukunftige Anpassung an libnl-tiny ware empfeh-
lenswert. Zur Zeit mussen libnl und libnl-tiny parallel installiert werden. Auf dem Linksys
WRT160NL ist dies dank ausreichend RAM kein Problem. Auf Routern mit wenig RAM konnten
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 uber 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
Uber den Befehl station dump konnen 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: 29709
mesh plid: 60578
mesh plink: ESTAB
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
[...]
Uber den Befehl mpath dump konnen alle Paths aufgelistet werden:
root@mesh02:~# iw dev mesh0 mpath dump
DEST ADDR NEXT HOP IFACE SN METRIC QLEN EXPTIME
ab:cd:ef:00:00:83 ab:cd:ef:00:00:64 wlan0 1044 8193 0 300
ab:cd:ef:00:00:64 ab:cd:ef:00:00:64 wlan0 1 8193 0 300
Und mit dem Befehl arp kann nachgesehen werden, welche IP-Adresse zu welcher MAC-Adresse
gehort:
root@mesh02:~# arp
IP address HW type Flags HW address Mask Device
192.168.88.1 0x1 0x2 ab:cd:ef:00:00:82 * wlan0
192.168.88.3 0x1 0x2 ab:cd:ef:00:00:64 * wlan0
A.3 Mesh-Parameter
Mit Hilfe der Mesh-Parameter lassen sich z.B. Timeout-Perioden einstellen. Aber auch das Senden
von Rootannouncement und Gateannouncement lasst sich uber Mesh-Parameter aktivieren. Als
Beispiel wird das Aktivieren des Rootannouncements gezeigt:
root@mesh02:~# iw dev mesh0 set mesh_param mesh_hwmp_rootmode=1
Einen Uberblick uber 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. Verschlusseltes 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 Verschlusseltes Mesh einrichten
Wie Kapitel 3 zeigt, ist zur Zeit Auth SAE die einzige Moglichkeit, um ein 802.11s-Meshnetzwerk zu
verschlusseln. Auth SAE wird uber eine Konfigurationsdatei1 eingerichtet. Die wichtigste Einstellung
ist das Setzen des Passwortes. Weitere Parameter zur Einstellung2 werden auf der Auth SAE-
Projektseite beschrieben. Das Mesh wird wie in Abschnitt A.1 beschrieben aufgesetzt. Das Setzen
des Kanals ist allerdings uberflussig, da Auth SAE dies selbst vornimmt. An Stelle des Mesh-Join-
Befehls (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.
1Konfigurationsbeispiel: https://github.com/cozybit/authsae/blob/master/config/authsae.sample.cfg2Beschreibung 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): Zunachst 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 add network interface
uci rename network.@interface[-1]=meshif
uci set network.meshif.proto=static
uci set network.meshif.ipaddr=192.168.88.1
uci set network.meshif.netmask=255.255.255.0
uci commit network
Um die Anderungen nutzbar zu machen, muss das Netzwerk mit dem Befehl /etc/init.d/network
restart neu gestartet werden.
Netzwerkinterface (LUCI): Das Interface kann auch uber die Webschnittstelle LUCI konfi-
guriert 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 eingefugt:
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 an-
gepasst werden:
uci set wireless.radio0.channel=...
uci commit wireless
802.11s-Meshnetzwerke konnen auch mit 40 GHz statt mit 20 GHz betrieben werden, ahnlich wie
dies bei 802.11n-Netzwerken der Fall ist. Hierzu werden folgende Optionen hinzugefugt:
29
B.1. Mesh Point
uci set wireless.radio0.hwmode=11ng
uci set wireless.radio0.htmode=HT40+ # oder htmode=HT40-
uci commit wireless
Die Option HT40+ gibt an, dass zusatzlich 20 GHz Bandbreite oberhalb des Frequenzbereiches
des gewahlten Kanals genutzt werden. Wird HT40- gewahlt, werden die 20 GHz unterhalb des
Frequenzbereiches des gewahlten Kanals genutzt.
Um den Router als einfachen Meshpoint zu nutzen, wird per UCI ein Wifi-Interface hinzugefugt
und entsprechend konfiguriert. OpenWRT schreibt das Setzen der SSID fur Wifi-Interfaces vor,
auch wenn diese in Meshnetzwerken nicht genutzt wird. Die Namenswahl kann beliebig erfolgen.
Der Ubersicht halber wird im folgenden Beispiel die SSID der Mesh-ID gleichgesetzt:
uci add wireless wifi-iface
uci set wireless.@wifi-iface[-1].device=radio0
uci set wireless.@wifi-iface[-1].mode=mesh
uci set wireless.@wifi-iface[-1].network=meshif
uci set wireless.@wifi-iface[-1].ssid=testmesh
uci set wireless.@wifi-iface[-1].mesh_id=testmesh
uci 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 verfugbar.
LUCI: Zunachst wird ein neues Netzwerk hinzugefugt:
Dieses wird als Mesh konfiguriert. Optional konnen 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 gewahlt werden. Der Ubersicht 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): Standardgemaß existiert bereits eine Zo-
ne WAN, die dem Internetport (eth1) des Routers zugewiesen ist. Folgendes Beispiel erlautert die
Erstellung einer Zone meshfw fur das Interface des Meshnetzwerks meshif. Eine Forwardingregel er-
laubt den Meshteilnehmern WAN-Zugriff. Die Meshteilnehmer konnen WAN-Adressen aufrufen. Ihre
IP ist aber nur intern sichbar und aus dem Internet nicht aufrufbar. Fur 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
# Verknupfen der Zonen "Meshfw" und "WAN"
1Generelle Informationen zum Einrichten einer Firewall unter OpenWRT:http://wiki.openwrt.org/doc/uci/firewall
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 hauptsachlich als Internetzu-
gang 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 uber LUCI wird im Wireless Network-Dialog Root Announcement und Gate
32
B.2. Mesh Portal (MPP)
Announcement auf yes gesetzt. Per UCI kann man hierfur 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 konnen. Die einfachste Moglichkeit 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 konnen auch hier zwei Firewallzonen verknupft 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
# Verknupfen der Zonen "Meshfw" und "LAN"
# Es werden zwei Forwardingregeln angelegt
# Eine fur MESH->LAN und die andere fur 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
Anderungen ubernehmen: Um die Firewalleinstellungen zu ubernehmen, muss die Firewall
neu gestartet werden:
/etc/init.d/firewall restart
MPP fur Mesh Access Point: Sollen die mit MAPs verbundenen Netzwerkteilnehmer das
Portal nutzen konnen, muss dieses gleichzeitig als MPP und MAP konfiguriert werden. Abschnitt
3.1 erlautert die technischen Hintergrunde.
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 zunachst 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 erganzt, um den Router als Wireless Access Point (Mode: ap)
zuganglich zu machen. Dabei wird die gleiche WLAN-Karte (radio0) genutzt, die auch das Mesh
nuzt:
uci add wireless wifi-iface
uci set wireless.@wifi-iface[-1].device=radio0
uci set wireless.@wifi-iface[-1].mode=ap
uci set wireless.@wifi-iface[-1].encryption=none
uci set wireless.@wifi-iface[-1].ssid=testmap
uci set wireless.@wifi-iface[-1].network=meshif
uci commit wireless
34
B.3. Mesh Access Point (MAP)
Durch das Teilen der WLAN-Karte mussen sich das Mesh und der Access Point die Frequenz und
Bandbreite teilen. Ist dies nicht erwunscht, wird ein Router mit zwei WLAN-Karten benotigt. Dank
der USB-Schnittstelle kann der Linksys WRT160NL mit einem WLAN-USB-Stick einfach um ei-
ne 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 Neu-
start des gesamten Betriebssystems. In der aktuellen Stable-Version genugte es hingegen Netzwerk
und WLAN neu zu starten.
LUCI: Als erstes wird MESHIF als Bridge konfiguriert:
Anschließend wird ein weiteres WLAN-Netzwerk erganzt ...
... und als Access Point eingerichtet:
Nutzung eines Mesh Portals: Wie Abschnitt 3.1 erlautert, konnen MAPs nur mit anderen
MAPs Daten austauschen. Soll ein MAP und die mit ihm verbunden Netzwerknoten ein MPP
nutzen konnen, 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) konnen 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 moglich,
einzelne Elemente einer Liste zu entfernen. Man kann nur die Liste komplett loschen. Dies bereitet
dem Webinterface LUCI Probleme. Deshalb werden die wichtigsten Mesh-Parameter, welche das
Senden von Rootannouncement und Gateannouncement steuern, nicht uber die mesh param-Liste
gesetzt, sondern direkt uber 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 konnen somit per LUCI aktiviert werden (siehe Ab-
schnitt B.2). Die ubrigen Mesh-Parameter konnen nur per UCI gesetzt werden.
B.5 Verschlusselung
Mit der im Rahmen dieses Projekts entstandenen Erweiterungen fur OpenWRT ist es moglich, Auth
SAE per UCI zu konfigurieren. Es mussen 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. Verschlusselung
Optional konnen die Parameter2 authsae group, authsae blacklist, authsae thresh,
authsae lifetime und authsae mcastrate mit UCI gesetzt werden.
2Beschreibung der Konfigurationsparameter: https://github.com/cozybit/authsae/blob/master/README
37
Anhang C
OpenWRT mit
802.11s-Unterstutzung fur Linksys
WRT160NL kompilieren
Zunachst 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 fur 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
1Download der Erweiterungen: https://wwwvs.cs.hs-rm.de/vs-wiki/index.php/MasterProjekte/802.11s auf SoHo-Routern
38
Nun werden weitere benotigte 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 ausgewahlt: (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 verschlusselt 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 fur den Router erstellt werden:
make world
Das Image zum flashen des Routers ist unter
bin/ar71xx/openwrt-ar71xx-generic-wrt160nl-squashfs-factory.bin verfugbar. Der
OpenWRT Flash-Dialog bietet die Option an, beim Flashen die alten Einstellungen zu behalten
(Keep Settings). Diese Option sollte unbedingt abgewahlt werden, da sonst der Router unbrauchbar
wird. Wenn dies dennoch geschen sollte, gibt das OpenWRT-Wiki Auskunft daruber, wie mit Hilfe
eines TTL-Pegelwandlers uber eine serielle Leitung ein intaktes Firmwareimage per TFTP uberspielt
werden kann2.
Die Imagedatei openwrt-ar71xx-generic-wrt160nl-squashfs-sysupgrade.bin ist fehlerhaft
und macht den Router ebenfalls unbrauchbar.
2http://wiki.openwrt.org/toh/linksys/wrt160nl#hardware
39
Soll die Auth SAE-Verschlusselung genutzt werden und kommt zusatzlich eine ATH9k-WLAN-
Karte 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 Anderungen werden erst nach einem weiteren Neustart
des Routers aktiviert. Ist ath9k-nohwcrypt nicht installiert worden, kann der Treiber uber 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) speci-
fications
Amendment 10: Mesh Networking, DRAFT - Sep. 2011.
[AODV] IETF — The Internet Engineering Task Force — Network Working Group.
Ad hoc On-Demand Distance Vector (AODV) Routing.
http://tools.ietf.org/html/rfc3561, Jul. 2003.
[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, Saad Biaz.
IEEE 802.11s Wireless Mesh Networks for Last-mile Internet Ac-
cess: 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