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