Kon�guration eines IEEE 802.11s konformen Mesh

Netzwerks (Praxis)

Master-Seminar Netz- und Datensicherheit

Sommersemester 2010

Andreas Hübner

Matrikelnummer 108009111739

5. August 2010

Inhaltsverzeichnis

1 Einleitung 1

2 Grundlagen 22.1 Geräteklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Kon�guration 43.1 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 Dem Mesh beitreten / eines erstellen . . . . . . . . . . . . . . . . . . . . . . 43.3 Das Mesh verlassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Diagnose- und Kon�gurationsmöglichkeiten 54.1 Peer List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54.2 Mesh Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64.3 Erweiterte Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5 Netzwerkanalyse mit Wireshark 85.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85.2 Vorbereitungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6 Funktionstests 106.1 Mesh Point Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.2 Mesh Access Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126.3 Mesh mit Masquerading Gateway . . . . . . . . . . . . . . . . . . . . . . . . 12

7 Fazit 13

i

1 Einleitung

Spätestens seit der Einführung der Centrino-Plattform für Notebooks im Jahr 2003 erlebtenWLAN-fähige Endgeräte einen regelrechten Absatzboom. Über die Jahre hinweg folgtensogleich WLAN-fähige DSL-Router nebst passenden USB-Adaptern, welche nun auch denfestinstallierten Arbeitsplatz-PCs einen drahtlosen Netzwerkzugang ermöglichten. Seit ge-raumer Zeit gehört die Eigenschaft, WLAN-fähig zu sein, nun auch zum Standardrepertoiregehobener Mobiltelefone. Somit steigt die Zahl der möglichen Endgeräte sehr viel schnel-ler als die Zahl der zur Verfügung stehenden Access Points, was nicht zuletzt auch damitzusammenhängt, dass man am Access Point mit Hilfe von technischen Maÿnahmen Ver-traulichkeit sicherstellt und die Zahl der potentiellen Nutzer somit künstlich begrenzt1. Aufder anderen Seite gibt es jedoch Interessensgemeinschaften, welche ein möglichst groÿes,kabelloses Netzwerk bilden möchten - jedoch ist dieses Ziel allein durch die Deaktivierungder Verschlüsselung nicht zu erreichen: Es Bedarf zusätzlich einem Backbone-Netz zwischenden Access Points, welches in der Regel durch Verkabelung realisiert wird und somit zwarCampus- oder Unternehmensweit noch realisierbar ist, bei einem rein aus Privatmitteln�nanzierten Interessensverbund jedoch eine schier unüberwindbare Grenze darstellt2.

Die Lösung für dieses Problem liegt auf der Hand: Man realisiert ein möglichst groÿ-�ächiges, kabelloses Netzwerk mit einem ebenfalls kabellosen Backbone, ein sogenanntesMesh. Auf diese Weise verschwimmt die Grenze zwischen WLAN-Endgerät und WLAN-Access Point, so dass nun jedes Gerät gleichermaÿen am Aufbau und am Erhalt der Netz-werkfunktionalität beteiligt ist. Durch diesen neuen Ansatz erhält man einige sehr Inter-essante Vorteile für jeden Teilnehmer (auch Knoten genannt), die jedoch gleichzeitig auchmit einigen Nachteilen verbunden sind:

+ Ein Mesh Netzwerk ist durch redunante Pfade sehr robusst hinsichtlich dem Ausfalleiniger Knoten

+ Es ist sehr leicht, neue Teilnehmer zum Netzwerk hinzuzufügen

� Dadurch, dass jeder Knoten unter Umständen Datenpakete empfangen und weiter-senden muss, die gar nicht für ihn bestimmt sind, ergibt sich ein erhöhter Strom-verbrauch, der sich bei akkubetriebenen Geräten in einer geringeren Laufzeit nieder-schlägt

� Es sind neuartige kryptographische Verfahren notwendig, um die Sicherheit einesMesh Netzwerkes zu gewährleisten

Zur Umsetzung dieser Idee existieren eine Vielzahl von Verö�entlichungen und fastgenauso viele praktische Implementierungen, welche allesamt einen Nachteil haben: Siesind untereinander nicht kompatibel.

Genau diesem Missstand versucht die IEEE 802.11s Arbeitsgruppe entgegen zu wir-ken: Ihr Ziel ist es, einen Standard für ein einheitliches Mesh Netzwerk zu scha�en, mitdessen Hilfe unter allen Betriebsystemen und mit der Hardware aller Hersteller ein funk-tionierendes, groÿ�ächiges kabelloses Netzwerk, dass ohne kabelgebundenes Backbonenetzauskommt, aufgebaut werden kann.

1Ein moderner, WLAN-tauglicher DSL-Router besitzt standardmäÿig einen Passwortschutz, um unbe-fugten den Netzwerkzugang zu verbieten

2Tatsächlich kann auch Campus- oder Unternehmensintern hinsichtlich der Finanzierung einer kom-pletten Backboneverkabelung diese Grenze sehr schnell erreicht werden

1

Abbildung 1: Beispieltopologie eines Meshs, welches mit anderen Netzen verbunden ist, inAnlehnung an [10]

Zum Zeitpunkt der Erstellung dieser Arbeit be�ndet sich der IEEE 802.11s Standardim Status eines Drafts mit der aktuell gültigen Versionsnummer 3.03, dass heiÿt er ist nochnicht fertiggestellt. Die Finale Version wird für Ende 2010 beziehungsweise Anfang 2011erwartet.

Im Rahmen dieser Seminararbeit wird in den nachfolgenden Abschnitten erläutert,wie ein IEEE 802.11s konformes Mesh Netzwerk unter Linux erstellt wird und welchespezi�schen Einstellungsmöglichkeiten existieren. Anschlieÿend �ndet der interessierte Le-ser einige Informationen zur Datenverkehrsanalyse mit Wireshark, gefolgt von Hinweisenzur Kon�guration drei praxisrelevanter Einsatzgebiete nebst ihrer Beurteilung hinsichtlichFunktionalität zum aktuellen Stand der Implementierung.

2 Grundlagen

2.1 Geräteklassen

Für das Verständnis der nachfolgenden Abschnitte ist es zunächst notwendig, einige Grund-lagen zu erläutern. Im IEEE 802.11s gibt es, wie in Abbildung 1 dargestellt, insgesamt dreiGeräteklassen mit jeweils unterschiedlicher Spezialisierung:

Mesh Point (MP)Normaler Teilnehmer im Mesh, welche Mesh Services unterstützen, dass heiÿt siesteuern aktiv zur Funktionalität des Mesh Netzwerkes bei, in dem sie zum BeispielPakete weiterleiten (HWMP), und nutzen es gegebenfalls auch selbst. �Mesh STA

2

x�, wobei das x hier stellvertretend für die Zi�ern 1 bis 11 steht, aus Abbildung 1gehören zu dieser Klasse.

Mesh Access Point (MAP)Mesh Peers, welche gleichzeitig Access Point Funktionalität bereitstellen, dass heiÿtsie stellen einen Zugang zum Mesh über ihre AP-Funktionalität auch nicht-Mesh-tauglichen-Geräten zur Verfügung. In Abbildung 1 sind dies die Teilnehmer mit derBezeichnung �Mesh STA 10� und �Mesh STA 11�.

Mesh Point Portal (MPP)Mesh Peers, welche gleichzeitig mit weiteren IEEE 802 LAN Segmenten wie zumBeispiel Ethernet verbunden sind. Durch MPPs wird das Mesh analog zu MAPsmit weiteren, in diesem Falle kabelgebundenen Netzwerksegmenten verbunden. AlsBeispiel seien hier die mit �Mesh STA 1�, �Mesh STA 6� und �Mesh STA 7� gekenn-zeichenten Teilnehmer aus Abbildung 1 genannt.

2.2 Routing

Das Routing in einem IEEE 802.11s kompatiblen Mesh Netzwerk �ndet auf OSI-Schicht2, also im Data-Link-Layer, statt. Es ist wichtig, sich diesen Umstand zu verdeutlichen, daman im Allgemeinen mit dem Begri� Routing eher die OSI-Schicht 3, also den Network-Layer, assoziiert. Auf OSI-Schicht 3, also dem Network-Layer, geht es beispielsweise darum,von der IP-Adresse 192.168.189.121 ausgehend die IP-Adresse 172.23.17.175 zu erreichen.Auf OSI-Sicht 2, dem sogenannten Data-Link-Layer, spielen IP-Adressen überhaupt keineRolle. Hier stellt sich eher die Frage, wie man von der MAC-Adresse 00:1c:c5:2d:f0:01 mög-lichst e�zient zur MAC-Adresse 00:26:22:32:b3:dc gelangt. Konkret abstrahiert die MeshImplementierung das Mesh Routing vom IP Routing: Aus IP-Sicht stellen alle Teilnehmerdes Mesh Netzwerks direkte, also mit nur einem Hop erreichbare Nachbarn dar. Tatsächlichist jedoch unter Umständen ein Routing auf dem Data-Link-Layer, also der OSI-Schicht2, erforderlich, um alle Mesh Nodes zu erreichen und IP-Pakete zustellen zu können. DasMesh Routing verhält sich aus IP-Sicht somit wie ein Hub beziehungsweise Switch.

Das in IEEE 802.11s eingesetzte OSI-Schicht 2-Routingverfahren hat den Namen �Hy-brid Wireless Mesh Routing Protocol�, abgekürzt HWMP. Wie der Zusatz �Hybrid� imNamen bereits vermuten lässt, besitzt HWMP sowohl proaktive als auch reaktive Verfah-renszüge: Bei proaktivem Routing wird die Route zu allen Zielen vorab ermittelt. Demge-genüber steht das reaktive Routing, hierbei wird die Route zu einem bestimmten Ziel erstbei Bedarf ermittelt. Im Fall von HWMP können sogar beide Routingvarianten parallel imEinsatz sein. Für das Routing mit Hilfe von HWMP werden in IEEE 802.11s insgesamtvier Managagementnachrichtentypen de�niert:

Root Announce (RANN)Diese Nachricht wird im Fall von proaktivem Routing periodisch von der Root Mesh,welche als solche Kon�guriert wird, ausgesendet

Route Request / Path Request (RREQ / PREQ)Mit Hilfe dieser Nachricht wird die Route zu einem bestimmten Ziel angefordert.

Route Reply / Path Reply (RREP / PREP)Dieser Nachrichtentyp ist die Antwortet auf eine Routenanforderung.

3

Route Error / Path Error (RERR / PERR)Sollte es zu einem Fehler während des Routings gekommen sein, so �ndet dieserNachrichtentyp verwendung, um die Teilnehmer darüber in Kenntnis zu setzen.

3 Kon�guration

3.1 Voraussetzungen

Die Voraussetzungen für den Aufbau eines Mesh Netzwerks sind relativ gering. Es bedarflediglich des Linux Kernels 2.6.263, welcher bereits am 13. Juli 2008 verö�entlicht wur-de (vergleiche [1]). Desweiteren muss der Kernel mit Unterstützung für Mesh Netzwerkeübersetzt worden sein - konkret kommt es hier auf die Optionen CONFIG_MAC80211 undCONFIG_MAC80211_MESH an. Für die Erstellung dieser Seminararbeit kam als DistributionUbuntu 10.04 LTS zum Einsatz, welches standardmäÿig mit dem Kernel 2.6.32 ausgeliefertwird.

Zusätzlich zum Linux Kernel benötigt man noch eine Reihe weiterer Tools, welche jedeLinuxdistribution jedoch im Repertoir haben sollte. In Debian-basierten Distributionen,wie dem eingesetzten Ubuntu 10.04 LTS, sind dies die Pakete net-tools und iw, wobeiersteres in der Regel standardmäÿig installiert ist.

Neben dem Kernel bedarf es natürlich noch entsprechender WLAN-Geräte. Unterstütztwerden unter anderem Chipsätze von Atheros, Broadcom, Marvel und Ralink - die in No-tebooks weit verbreiteten Intel Chipsätze werden derzeit laut [2] jedoch noch nicht unter-stützt. Im Rahmen dieser Arbeit kamen ausschlieÿlich WLAN-Karten mit dem AtherosAR2414 Chip zum Einsatz, mit Chipsätzen der anderern Hersteller können die Ergebnissedaher unter Umständen variieren.

3.2 Dem Mesh beitreten / eines erstellen

Sobald alle Voraussetzungen erfüllt sind, gestaltet sich die Kon�guration eines Mesh Netz-werks relativ einfach und schnell. Da der NetworkManager zur Zeit noch keine Unterstüt-zung für Mesh Netzwerke nach 802.11s enthält, sollte man diesen zuerst beenden:

$ sudo killall nm-applet

$ sudo service network -manager stop

Nach diesen Vorarbeiten genügt es typischerweise, folgenden Befehl auszuführen:

$ sudo iw dev <devname > interface add <name > type mp mesh_id

↪→ <meshid >

Hinter <devname> verbirgt sich der Gerätename der WLAN-Karte, zum Beispiel wlan0. Beider Kon�guration des Mesh Netzwerkes wird eigens für das Mesh eine neue Gerätedatei an-gelegt. Der Name dieser Gerätedatei ist frei wählbar und muss im Feld <name> eingetragenwerden. Die <meshid> ist ein maximal 32 Byte langer String, welcher in den Mesh Beaconsmitgesendet wird (vergleichbar der (E)SSID eines �herkömmlichen� Infrastruktur-WLAN-Netzes, welches von einem Access Point aufgespannt wird). Dementsprechend müssen alle

3Zwar ist es ebenfalls möglich, Mesh Netzwerk mit älteren Kerneln aufzubauen, allerdings ist mehrVorarbeit notwendig. Bedingt durch die Tatsache, dass die Verö�entlichung des 2.6.26 bereits 2 Jahre zurückliegt, wird im Rahmen dieser Seminararbeit daher nicht näher auf ältere Kernelversionen eingegangen.

4

Teilnehmer ein und desselben Mesh Netzwerkes hier die gleiche Mesh ID eintragen. Imkonkreten Fall könnte dies zum Beispiel so aussiehen4:

$ sudo iw dev wlan0 interface add mesh0 type mp mesh_id

↪→ testnetz

Laut Dokumentation verwendet ein Mesh Netzwerk standardmäÿig Kanal 1 (siehe [2]),jedoch kann der Kanal mit Hilfe des Befehls

$ sudo iw dev mesh0 set channel 11

problemlos verändert werden. Gelegentlich kann es vorkommen, dass vom System da-bei die Fehlermeldung SIOCSIFFLAGS: Name not unique on network ausgegeben wird.In diesem Fall muss man erst die �normale� WLAN-Gerätedatei herunter- und die Mesh-Gerätedatei hochfahren:

$ sudo ifconfig wlan0 down

$ sudo ifconfig mesh0 up

Abschlieÿend muss man der Mesh-Gerätedatei nun nur noch eine IP-Adresse zuweisen unddas Mesh Netzwerk ist einsatzbereit:

$ sudo ifconfig mesh0 10.0.0.1

3.3 Das Mesh verlassen

Das Beenden beziehungsweise Entfernen der Mesh-Gerätedatei gestaltet sich sehr einfachund ist bereits mit einem Befehl erledigt:

$ sudo iw dev <devname > del

Anders als beim Erstellen des Mesh Netzwerkes ist hierbei ist jedoch zu beachten, dassman <devname> nun mit der entsprechenden Mesh Gerätedatei substituiert:

$ sudo iw dev mesh0 del

Anschlieÿend ist die Mesh-Gerätedatei nicht mehr verfügbar und die Verbindung zum MeshNetzwerk damit erloschen.

4 Diagnose- und Kon�gurationsmöglichkeiten

4.1 Peer List

Unter der Peer List versteht man die Liste, welche alle MPs enthält, die eine direkteNachbarschaftsbeziehung zum aktuellen Knoten besitzen. Es handelt sich hierbei also umdiejenigen MPs, die vom aktuellen Knoten aus mit nur einem Hop erreicht werden können.Die Peer List kann man sich mit folgendem Befehl anzeigen lassen:

$ sudo iw dev <devname > station dump

4Statt dem frei gewählten mesh0 hätte man auch einfach nur mesh schreiben können - das Anhängeneiner Zahl ist keinesfalls P�icht und erfolgte nur aus estätischen Gründen.

5

Abbildung 2: Ausgabe der Peer List

Dabei ist zu beachten, dass in der Liste auch Peers enthalten seien können, die nicht mehrerreichbar sind, da sie beispielsweise o�ine gegangen sind oder sich ausser Reichweitebewegt haben. Die Ausgabe des Befehls kann beispielsweise wie in Abbildung 2 dargestelltaussehen. Für eben diesen Fall gibt es die Möglichkeit, manuelle Änderungen an der PeerList durchzuführen:

$ sudo iw dev <devname > station del <mac address >

Durch Ausführung dieses Befehls wird die mit <mac address> eindeutig spezi�erte MP ausder Peer List gelöscht. Dies ergibt jedoch nur dann Sinn, wenn die MP tatsächlich o�ineoder ausser Reichweite ist, da andernfalls automatisch ein Peer Link Establishment mitder MP durchgeführt wird und sich die MP umgehend wieder in der Peer List be�ndet.

Eine weitere Möglichkeit, die Peer List zu manipulieren, besteht darin, eine spezi�zierteMP zu blockieren oder ein Peer Link Establishment mit selbiger anzustoÿen:

$ sudo iw dev <devname > station <mac address > set

↪→ plink_action [open | block]

Je nachdem, ob der Befehl mit block oder mit open eingegeben wird, wird die durch<mac address> spezi�zierte MP blockiert oder ein Peer Link Establishment mit selbigerangestoÿen.5

4.2 Mesh Routing

Die vom in IEEE 802.11s verwendeten Routingprotokoll �HWMP� aktuell verwendete Rou-tingtabelle kann mit Hilfe des Befehls

5Hierbei handelt es sich jedoch nur um den Versuch eines Verbindungsaufbaus. Dieser Versuch kannnatürlich auch scheitern.

6

Abbildung 3: Ausgabe der Mesh Routing Tabelle

$ sudo iw dev <devname > mpath dump

eingesehen werden. Wie Bereits in Abschnitt 2.2 erläutert wurde, handelt es sich dabeium die Routingtabelle, welche auf OSI-Schicht 2, dem sogenannten Data-Link-Layer, An-wendung �ndet. Aus diesem Grund sind der Ausgabe des Befehls, wie in Abbildung 3ersichtlich ist, auch MAC-Adressen statt IP-Adressen enthalten.

Natürlich kann die von der IEEE 802.11s Implementierung des Linuxkernels aktuellverwendete Routingtabelle auch manuell modi�ziert werden. Zum einen besteht hier dieMöglichkeit, eine vorhandene Route zu einem Mesh Point mit dem Befehl

$ sudo iw dev <devname > mpath del <destination mac >

zu löschen. Hierbei muss der Parameter <destination mac> lediglich durch die MAC-Adresse des Ziels der Route ersetzt werden. Zum anderen ist natürlich auch der umgekehr-te Weg möglich, dass heiÿt man kann eine Route zu einem spezi�schen Ziel über einenselbstgewählten Nexthop erzwingen:

$ sudo iw dev <devname > mpath new <destination mac > next_hop

↪→ <nexthop mac >

Wie im obigen Beispiel sind auch hier die Parameter selbsterklärend: <destination mac>

muss durch die MAC-Adresse des Ziel-MPs und <nexthop mac> durch die MAC-Adressedes ersten Nexthop-MPs ersetzt werden.

4.3 Erweiterte Einstellungen

Neben den Möglichkeiten, welche die Manipulation der Peer List und der HWMP-Routing-tabelle bieten, kann der technisch visierte Nutzer noch einige fein granulare Einstellungenvornehmen. Hierzu existieren der Befehl

$ sudo iw dev <devname > get <parameter >

zum Auslesen der aktuell verwendeten und der Befehl

$ sudo iw dev <devname > set <parameter > <value >

zum Einfügen neuer Werte. Konkret können folgende Parameter ausgelesen und nach ei-genen Vorstellungen angepasst werden:

• mesh_retry_timeout

7

• mesh_confirm_timeout

• mesh_holding_timeout

• mesh_max_peer_links

• mesh_max_retries

• mesh_ttl

• mesh_auto_open_plinks

• mesh_hwmp_max_preq_retries

• mesh_path_refresh_time

• mesh_min_discovery_timeout

• mesh_hwmp_active_path_timeout

• mesh_hwmp_preq_min_interval

• mesh_hwmp_net_diameter_traversal_time

Die Parameter sind in der Regel mit selbstredenden Namen versehen und werden daher imRahmen dieser Arbeit nicht näher erläutert. Für eine genaue De�nition sei daher an dieserStelle auf die Originaldokumentation verwiesen, welche unter [2] bezogen werden kann.

5 Netzwerkanalyse mit Wireshark

5.1 Installation

Um eine Netzwerkanalyse mit Wireshark durchführen zu können, sind einige Vorarbeitennotwendig, da die Vanilla-Version von Wireshark von Haus aus keine Unterstützung fürdie Analyse von Mesh Netzwerken bietet. Daher ist man darauf angewiesen, den Quellcodevon Wireshark von der Projektseite, welche unter [7] erreichbar ist, herunterzuladen, zupatchen und anschlieÿend selbst zu übersetzen. Die Anwendung des Patches, welcher unter[9] bezogen werden kann, auf die zum Zeitpunkt der Erstellung dieser Arbeit aktuelleVersion 1.3.5 schlug jedoch fehl - weshalb für die weitere Vorgehensweise die Version 1.3.2von der Website [8] empfohlen wird.

Zunächst müssen die für die Übersetzung notwendigen Abhängigkeiten aufgelöst wer-den. Unter Ubuntu 10.04 LTS müssen dazu lediglich folgende Pakete über den Paketmana-ger installiert werden: build-essential, bison, flex, libglib2.0-dev, libgtk2.0-devund libpcap0.8-dev. Anschlieÿend kann man sich dem Patchen und der Übersetzung vonWireshark widmen6:

$ tar xjf wireshark -1.3.2. tar.bz2

$ cp wireshark -1.3.2 -mesh -support.patch wireshark -1.3.2/

$ cd wireshark -1.3.2/

$ patch -p0 < wireshark -1.3.2 -mesh -support.patch

6Auf einer Maschine mit Pentium 4 2,80 GHz und 512 MB Arbeitsspeicher nimmt die Übersetzungcirca 30 Minuten in Anspruch.

8

$ ./ configure

$ make

$ sudo make install

Anschlieÿend kann manWireshark, welcher nun unter /usr/local/bin installiert ist, durchEingabe des Befehls wireshark auf der Konsole aufrufen7. Sollte man stattdessen dieFehlermeldung

wireshark: error while loading shared libraries:

↪→ libwiretap.so.0: cannot open shared object file: No such

↪→ file or directory

erhalten, so ist sicher zu stellen, dass der Pfad zur libwiretap.so.0, welcher im Falledieser Seminararbeit /usr/local/lib lautet, innerhalb einer der Kon�gurationsdateienunter /etc/ld.so.conf.d eingetragen und Bibliothekscache mit Hilfe des Befehls sudo

ldconfig aktualisiert worden ist.

5.2 Vorbereitungen

Um eine Analyse mit Wireshark durchführen zu können ist es zunächst notwendig, dieWLAN-Hardware in den Monitormodus zu versetzen. Um nicht auf unvorhersagbare Kon-sequenzen zu stoÿen, bietet es sich an, für die Analyse einen separaten Rechner oder abereine zweite WLAN-Karte zu verwenden, die ausschlieÿlich zur Analyse eingesetzt wird undnicht etwa auch eine Verbindung zum Mesh-Netzwerk aufbaut. Um in den Monitormoduszu gelangen, beginnt man wie in Abschnitt 3.2 damit, den NetworkManager zu beenden:

$ sudo killall nm-applet

$ sudo service network -manager stop

Anschlieÿend kann man die WLAN-Hardware in den Monitormodus versetzen und den zuanalysierenden Kanal einstellen:

$ sudo iw dev wlan0 interface add mon0 type monitor

$ sudo iw dev mon0 set channel 11

$ sudo ifconfig mon0 up

In Wireshark wählt man nun als �Capturedevice� die soeben neu angelegte Gerätedatei mitdem Namen mon0 aus. Anschlieÿend wird von Wireshark vollautomatisch sämtlicher Daten-verkehr auf dem gewählten Kanal aufgezeichnet. Bedingt durch die Tatsache, dass sich dieWLAN-Kanäle gegenseitig überlappen, zeichnet Wireshark auch Pakete der benachbartenKanäle auf.

5.3 Analyse

Da eine sich im Monitormodus be�ndliche WLAN-Karte alle Pakete des aktuellen Kanalsund zum Teil auch der überlappenden Nachbarkanäle aufzeichnet ist es notwendig, fürdie Analyse die nicht benötigten Datenpakete auszublenden. Dies geschieht mit Hilfe dervon Wireshark zur Verfügung gestellten Filter. Als erstes bietet es sich hierbei an, die

7Durch den Aufruf von sudo make install wird kein Eintrag im Menü erstellt, dies muss manuellerfolgen.

9

periodisch ausgesendeten Beacon Frames aus der Masse der mitgeschnittenen Pakete zuentfernen. Dies geschieht mit Hilfe des Filters

wlan.fc.type_subtype != 8

Desweiteren bietet es sich an, sich nur diejenigen Pakete anzeigen zu lassen, die von denbeteiligten Geräten ausgesendet oder empfangen wurden. Hierzu ist es zunächst notwendig,die MAC-Adressen aller am Mesh beteiligter Geräte zu notieren und anschlieÿend folgendenFilter, welcher auf der Absender- und auf der Zieladresse operiert, zu aktivieren:8

wlan.addr == <mac >

Um nun alle störenden Beaconframes zu entfernen und sich gleichzeitig nur noch diejenigenPakete anzeigen zu lassen, die von den am Mesh beteiligten Geräten ausgesendet oderempfangen wurden, verknüpft man die beiden Filter einfach mit Boolschen Operatoren:

wlan.fc.type_subtype != 8 and (wlan.addr == <mac > or

↪→ wlan.addr == <mac > or ...)

Ist man an diesem Punkt angelangt, so sind alle störenden Beaconframes entfernt und derMitschnitt enthält nur noch die für die eigentliche Analyse relevanten Informationen.

Um sich nun beispielsweise nur Peer Link Establishment Nachrichten anzeigen zu lassen,kann man den Filter

wlan_mgt.fixed.category_code == 30

verwenden. Alternativ kann hier auch der Filter

wlan_mgt.tag.number == 55

genutzt werden.Ist man lediglich an HWMP-Kontrollnachrichten interessiert, so lautet der entsprechen-

de Filter wie folgt:

wlan_mgt.fixed.category_code == 32

Auch hier existiert wieder ein alternativer Filter, welcher mit Hilfe von Boolschen Opera-toren realisiert wurde:

wlan_mgt.tag.number == 49 or wlan_mgt.tag.number == 68 or

↪→ wlan_mgt.tag.number == 69 or wlan_mgt.tag.number == 70

In den Tabellen 1 und 2 sind die für die Filter möglichen Nummerncodes und ihrejeweilige Bedeutung aufgeschlüsselt.

6 Funktionstests

6.1 Mesh Point Portal

Wie bereits in Abschnitt 2.1 erläutert, handelt es sich bei einem Mesh Point Portal, kurzMPP, um eine Mesh Peer, welche gleichzeitig noch mit einem weiteren IEEE 802 LAN

8Um nur nach der Absenderadresse zu �ltern kann man wlan.sa verwenden, analoges gilt für dieZieladresse mit wlan.da.

10

Tabelle 1: Mögliche Werte für wlan_mgt.fixed.category_codeKategorie Code in Draft 1.07 Code in Draft 3.03Mesh Peer Link 30 16Mesh Link Metric 31 17Mesh Path Selection 32 18Mesh Interworking 33 19Mesh Resource Coordination 34 20Mesh Security Architecture 35Mesh Proxy Forwarding 21

Tabelle 2: Mögliche Werte für wlan_mgt.tag.numberTag NummerMesh Path Announcement 49Mesh Path Request 68Mesh Path Response 69Mesh Path Error 70Mesh Peer Link Management 55

Segment verbunden ist. Ziel ist hierbei, das Mesh vollkommen transparent mit dem LANSegment zu verbinden, wodurch sich natürlich die Notwendigkeit von mehreren Netzwerka-daptern ergibt.

Die Einrichtung eines MPP setzt natürlich erstmal ein funktionierendes MP voraus,dass heiÿt man muss dem Mesh Netzwerk bereits beigetreten sein. Anschlieÿend wird mitHilfe der Bridgeutils die Verbindung zum Mesh mit der Verbindung zum LAN gebrücktund der Brücke eine IP-Adresse zugewiesen:

$ sudo brctl addbr br0

$ sudo brctl addif br0 eth0

$ sudo brctl addif br0 mesh0

$ sudo ifconfig eth0 down

$ sudo ifconfig mesh0 down

$ sudo ifconfig eth0 0.0.0.0 up

$ sudo ifconfig mesh0 0.0.0.0 up

$ sudo ifconfig br0 10.0.0.1

Das somit installierte MPP funktioniert zwar, jedoch nicht wie erwartet: Zum Zeitpunktder Erstellung dieser Seminararbeit ist die im Linux Kernel enthaltene Implementierunglediglich dazu in der Lage, Pakete von einem LAN-Segment in ein anderes LAN-Segment zutransportieren, wenn beide Segmente über eine MPP durch ein Mesh Netzwerk verbundensind. In Abbildung 4 ist dies durch eine rote Verbindungslinie veranschaulicht. Wie in derGra�k ersichtlich ist, ist keine direkte Kommunikation eines im LAN Segment angeschlos-senen Hosts mit einem MP und andersherum möglich. Im Archiv der Maillingliste �ndensich unter [4] und [5] weitere Details dieser Problematik.

11

Abbildung 4: Rote Markierung: Zur Zeit einzig möglicher Pakettransport durch den Einsatzvon MPP

6.2 Mesh Access Point

Ein Mesh Access Point, kurz MAP, ähnelt vom Aufbau in gewisser Weise einem MeshPoint Portal (vergleiche Abschnitt 2.1). Natürlich ist es auch hier wieder erforderlich, dassmehrere Netzwerkadapter in dem MP verbaut sind, da es einer WLAN-Karte für die Ver-bindung zum Mesh und einer weiteren WLAN-Karte für den Access Point-Modus bedarf.Ein nicht Mesh-fähiges Endgerät kann sich somit in das durch die Access Point-Karteaufgespannte Netzwerk einbuchen und über den MAP vollständig transparant das MeshNetzwerk nutzen.

Da die Installation eines MAP analog zu der eines MPP erfolgt, folgt, dass auch derMAP einen zum Zeitpunkt der Erstellung dieser Arbeit erheblich geminderten Funktions-umfang besitzt (siehe Abschnitt 6.1). Aus diesem Grund wurde ein Mesh Access Point imRahmen dieser Arbeit nicht verwirklicht.

6.3 Mesh mit Masquerading Gateway

Nach den teils enttäuschenden Ergebnissen der letzten beiden Abschnitte stellte sich dieFrage, in wie fern die aktuelle Implementierung bereits eine praktische Nutzbarkeit auf-weist. Mit Hilfe des ebenfalls im Linux Kernel enthaltenen Net�lter Frameworks wurdeder Aufbau eines Mesh Point Portal etwas modi�ziert: Im LAN Segment und im MeshNetzwerk kommen nun unterschiedliche IP-Adressbereiche zum Einsatz, welche durch dassMPP mit Hilfe von Net�lter übersetzt werden.

Die Einrichtung eines solchen Einsatzszenarios ist weit weniger komplex, als es zunächstklingen mag. Es genügt, die folgenden Befehle auf dem als Pseudo-MPP geplanten Host

12

auszuführen:

$ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

$ sudo echo "1" > /proc/sys/net/ipv4/ip_forward

Zusätzlich muss nun noch auf jedem MP folgender Befehl ausgeführt werden:

$ sudo route add default gw <pseudo -mpp ip>

Ein auf diese Weise installiertes Pseudo-MPP funktioniert in der Tat bereits sehr gut.Fast alle im Rahmen dieser Arbeit notwendigen Recherchen wurden an einer MP, die übersolch ein Pseudo-MPP mit dem Internet verbunden war, durchgeführt, während nebenbeinoch ein Radiostream lief. Auch die Downloadmenge, die bei einer Aktualisierung einesDebian-basierten Linuxsystems mit Hilfe des Befehls apt-get bewältigt werden muss, zogkeine Aussetzer im Radiostream mit sich.

7 Fazit

Neben den in Abschnitt 6 erläuterten Beurteilungen existieren noch einige weitere Pro-bleme, die einen groÿ�ächigen Einsatz von IEEE 802.11s kompatiblen Mesh Netzwerkenderzeit unrentabel machen. Zum einen ist da die Tatsache, dass der Standard noch nichtverabschiedet ist und es so erwartungsgemäÿ Änderungen am Draft gibt, welche nichtimmer Zeitnah in der Implementierung im Linux Kernel berücksichtigt werden können.Durch diesen zeitlichen Versatz ist die im Linux Kernel enthaltene Implementierung vonIEEE 802.11s derzeit nicht kompatibel mit der Implementierung, die von FreeBSD ge-nutzt wird. Im Moment basiert die Implementierung, wie man den Codezeilen #define

PLINK_CATEGORY 30 und #define MESH_PATH_SEL_CATEGORY 32, zu �nden in den LinuxKernel Sourcen in der Datei net/mac80211/mesh.h entnehmen kann, auf dem alten Draft1.08 vom 15. Januar 2008. In der aktuellen Draft 3.03 haben sich diese Werte geändert.

Desweiteren haben die Entwickler bisher noch keine Sicherheitsfunktionalität imple-mentiert, so dass die gesamte Kommunikation, die in einem Mesh Netzwerk statt�ndet,vollkommen unverschlüsselt (!) statt �ndet (vergleiche [3]). Auch gibt es derzeit noch einungelöstes Stabilitätsproblem, wenn man die von HWMP genutzten Routen statisch er-zwingt (siehe [6]).

Dennoch be�ndet sich das Projekt auf einem erfolgversprechendem Weg, wie die sehrgute Nutzbarkeit eines Pseudo-MPP, wie es in Abschnitt 6.3 erläutert wurde, beweist.Wenn der IEEE 802.11s Standard ersteinmal fertiggestellt ist, so werden sich die aktuellvorhandenen Probleme ziemlich schnell lösen, da es dann nicht nur zu einem Anstieg derNutzerzahlen, sondern vermutlich auch der Entwickler - man denke nur einmal an all dieHardwarehersteller, die Linux auf ihren WLAN-Routern einsetzen - kommen wird.

13

Literatur

[1] http://lkml.org/lkml/2008/7/13/216

[2] http://www.open80211s.org/

[3] http://open80211s.com/pipermail/devel/2010-January/000423.html

[4] http://open80211s.com/pipermail/devel/2009-April/000219.html

[5] http://open80211s.com/pipermail/devel/2009-May/000238.html

[6] http://marc.info/?l=linux-wireless&m=125960715104027&w=2

[7] http://www.wireshark.org/

[8] http://www.wireshark.org/download/src/all-versions/wireshark-1.3.2.tar.bz2

[9] http://www.open80211s.org/patches/wireshark/wireshark-1.3.2-mesh-support.patch

[10] 802.11 Working Group of the IEEE 802 Committee: IEEE P802.11s/D3.03. IEEE,New York

14