Aichele: Mesh

Corinna Elektra Aichele

Mesh
Drahtlose Ad-hoc-Netze
Alle in diesem Buch enthaltenen Programme, Darstellungen und Inform ationen wurden nach bestem
Wissen erstellt. Dennoch sind Fehler nicht ganz auszuschlieen. Aus diesem Grunde sind die in dem
vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art
verbunden. Autor(en), Herausgeber, bersetzer und Verlag bernehm en infolgedessen keine Verantwor
tung und werden keine daraus folgende Haftung bernehm en, die auf irgendeine Art aus der Benutzung
dieser Inform ationen - oder Teilen davon - entsteht, auch nicht fr die Verletzung von Patentrechten,
die daraus resultieren knnen. Ebenso wenig bernehm en Autor(en) und Verlag die Gewhr dafr, dass
die beschriebenen Verfahren usw. frei von Schutzrechten Dritter sind.
Die in diesem Werk wiedergegebenen Gebrauchsnam en, Handelsnam en, W arenbezeichnungen usw.
werden ohne Gewhrleistung der freien Verwendbarkeit benutzt und knnen auch ohne besondere
Kennzeichnung eingetragene Marken oder W arenzeichen sein und als solche den gesetzlichen Bestim
mungen unterliegen.
Dieses Werk ist urheberrechtlich geschtzt. Alle Rechte, auch die der bersetzung, des Nachdrucks und
der Vervielfltigung des Buches - oder Teilen daraus - Vorbehalten. Kein Teil des Werkes darf ohne
schriftliche Genehmigung des Verlags in irgendeiner Form (Druck, Fotokopie, Mikrofilm oder einem an
deren Verfahren), auch nicht fr Zwecke der Unterrichtsgestaltung, reproduziert oder unter Verwendung
elektronischer Systeme verarbeitet, vervielfltigt oder verbreitet werden.

Bibliografische Information Der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;

detaillierte bibliografische Daten sind im Internet ber http://dnb.d-nb.de abrufbar.

2007 Open Source Press, M nchen

Gesamtlektorat: Ulrich Wolf
Satz: Open Source Press (BT^X)
Umschlaggestaltung: www.fritzdesign.de
G esamtherstellung: Ksel, Krugzell

ISBN 978-3-937514-39-0 http://www.opensourcepress.de

 Inhaltsverzeichnis

Vorwort 11

1 Einleitung 13

2 Meshrouting 19
2.1 Ad-Hoc vs. Infrastruktur...................................................................... 20
2.1.1 Bandbreitenproblematik bei Multihop-Links mit nur
einem Interface ........................................................................22
2.1.2 Problemfall T C P ........................................................................ 24
2.1.3 Exposed Nodes - Hidden Nodes............................................ 26
2.2 Routingprotokolle fr drahtloseN etzw erke................................... 27
2.2.1 P rotokolltypen........................................................................... 29
2.2.2 Praktische Relevanz der Routingprotokolle...................... 31

3 OptimizedLink State Routing 35

3.1 Entwicklungsgeschichte.......................................................................36
3.2 Die OLSR-lmplementierungvon01sr.org und F reifu n k ...............37
3.2.1 Hysteresealgorithmus...............................................................37
3.2.2 Multipoint-Relais ..................................................................... 38
3.2.3 01sr.org - Aus den Fehlern lern en ......................................... 39
3.2.4 Funktionsweise des OLSR-Daemon...................................... 39
3.2.5 Topologieinformationen und Dijkstra-Algorithmus . . . 40
3.3 Praxis mit O lsrd ....................................................................................... 44
3.3.1 Installation unter Linux, Mac OS X und *BSD ....................44
3.3.2 Installation unter Windows ...................................................46
3.3.3 Konfigurationsdatei des O lsrd ................................................48

5
Inhaltsverzeichnis

3.3.4 Erster Start des D a e m o n ........................................................57

3.4 Wichtige Plugins fr O l s r d .................................................................61
3.4.1 DotDraw...................................................................................... 62
3.4.2 H ttpinfo...................................................................................... 63
3.4.3 Nameservice ............................................................................. 65
3.5 Typische Probleme mit OLSR............................................................. 67
3.5.1 Gateway-Switching ................................................................. 67
3.5.2 Typische Probleme beim ersten E in s a tz ........................... 69
3.5.3 Probleme mit W iFi.................................................................... 69

4 B.A.T.MAN. - Better Approach To Mobile Ad-Hoc Networking 71

4.1 Funktionsweise des B.A.T.M.A.N.-A lg orith m u s...........................73
4.1.1 Die Originatornachricht ........................................................73
4.1.2 Bidirectional Link Check - Linkprfung auf Bidirektio-
n a li t t .......................................................................................... 74
4.1.3 Eine Originatornachricht reist durch das M esh .............. 76
4.2 Praxis mit B.A.T.M.A.N...........................................................................79
4.2.1 Erster Start des D aem ons........................................................80
4.2.2 Den Netzwerkstatus im Debugging-Modus beobachten 81
4.2.3 Routingklassen und Gatew ayklassen................................. 83
4.2.4 Visualisierungsserver..............................................................85
4.2.5 Firewalleinstellungen a n p a sse n ...........................................86
4.2.6 Webinterface fr B.A.T.M.A.N................................................. 86

5 WLAN-Technik 87
5.1 Die WiFi-Standards 802.11 von a bisDraft-n .................................88
5.1.1 IEEE 802.1 lb / g .......................................................................... 88
5.1.2 IEEE 8 0 2 .1 1 a ............................................................................. 90
5.1.3 IEEE 802.1 l n ............................................................................. 92
5.1.4 Bruttodatenrate und N ettodatenrate................................. 92
5.2 Gerte fr den Aufbau eines M esh n etzw erk s...............................93
5.2.1 SoHO-Router oder P C ? .......................................................... 93
5.2.2 WLAN-Karten fr PCs und Routerboards ........................94
5.2.3 SoHO-WLAN-Router ..............................................................95
5.2.4 Professionelle WLAN-Router.................................................96

6
 Inhaltsverzeichnis

5.2.5 WLAN-Router im S e lb s tb a u .................................................96

5.2.6 HF-Steckverbinder................................................................... 97
5.2.7 Koaxialkabel .............................................................................98
5.2.8 G e h u se ...................................................................................... 99
5.2.9 Typische Hardware-Problemeim Ad-Hoc-Modus . . . . 101
5.3 Chipstze ................................................................................................ 104
5.3.1 Prism fr 802.11b ................................................................... 104
5.3.2 Lucent-Orinoco ...................................................................... 105
5.3.3 Prism54 Hard- und Soft-M A C ............................................. 106
5.3.4 Atheros ......................................................................................106
5.3.5 A tm el............................................................................................ 108
5.3.6 B ro a d co m ................................................................................... 108
5.3.7 C is c o ............................................................................................ 109
5.3.8 Intel .............................................................................................109
5.3.9 Ralink ......................................................................................... 110
5.3.10 R ealtek......................................................................................... 111
5.3.11 Texas In stru m en ts................................................................... 111
5.3.12 Z ydas............................................................................................ 111
5.4 Typische Hardware-Problemeim Ad-Hoc-Modus .......................112
5.4.1 C ell-S p littin g.............................................................................112
5.4.2 Der IBSSID-H ack.......................................................................115
5.5 Power over E th e r n e t............................................................................ 116
5.5.1 Einfaches PoE im S e lb s tb a u .................................................116
5.5.2 Einfache PoE-Lsungen selbstentwickeln und berech
nen 118
5.5.3 Spannungsverluste auf der Leitung b erech n en ...............122

6 Mesh-Betrieb auf SoHO-Routern 125

6.1 Freifunk-kompatible R o u t e r ..............................................................126
6.1.1 Linksys WRT54GL und WRT54G...........................................128
6.1.2 Buffalo WHR-G54S....................................................................129
6.1.3 Asus WL500G P rem ium .......................................................... 130
6.2 Installation der Freifunk-Firm w are..................................................130
6.2.1 Firmware-Installation auf Linksys W R T54G L.................... 131

7
Inhaltsverzeichnis

6.2.2 Firmware-Installation p e rT F T P ........................................... 134

6.3 Konfiguration per W eb in terface....................................................... 135
6.3.1 Sicher anmelden ber S S H .....................................................136
6.3.2 Konfigurationsschritte ...........................................................137
6.3.3 Kennwort und K ontaktinfos..................................................137
6.3.4 S y stem ..........................................................................................138
6.3.5 O L SR .............................................................................................139
6.3.6 D rah tlo s....................................................................................... 143
6.3.7 LAN................................................................................................ 148
6.3.8 W A N .............................................................................................150
6.3.9 Publizieren .................................................................................151
6.3.10 Software 1 ....................................................................................151
6.3.11 S o ftw are2....................................................................................152
6.3.12 Firmware ....................................................................................152
6.3.13 N eu start.......................................................................................152
6.4 Gateway-Konfiguration....................................................................... 153
6.4.1 Internet-Gateway ber D S L ..................................................153
6.4.2 Internet-Gateway ber ein bereits existierendes LAN . . 153
6.4.3 Fortgeschrittene Konfiguration - das Freifunk-Gateway-
Plugin ...........................................................................................154
6.5 Konfiguration auf der Kommandozeile........................................... 156
6.5.1 Softwareinstallation auf der Kom m andozeile.................. 156
6.5.2 Zugang vom Mesh ins LAN.....................................................157
6.6 O penW R T ................................................................................................159
6.7 Wenn etwas schiefgeht - Probleme mitderRouter-Firmware . 161
6.7.1 Router verkonfiguriert" oder Passwortvergessen . . . . 161
6.7.2 Reparatur gebrickter WRTs ...............................................163

7 Elektromagnetische Wellen und Antennen 169

7.1 Bel und D ezibel.......................................................................................170
7.2 Das Phnomen der elektromagnetischen W e lle n ..........................171
7.3 Das Prinzip von A n te n n e n .................................................................173
7.3.1 Polarisation von A n ten n en .....................................................175
7.3.2 Freifelddmpfung und Absorptionsverluste..................... 176

8
 Inhaltsverzeichnis |

7.4 A ntennengew inn ....................................................................................... 177

7.5 A n ten n en typ en .......................................................................................... 178
7.5.1 O m n i-A n ten n en ..........................................................................178
7.5.2 Sektorantennen ..........................................................................179
7.5.3 R ich ta n te n n e n .............................................................................180
7.6 Wireless Long Shots - Funkstrecken ber groe Entfernungen . 180
7.6.1 Link Budget - wie weit kann man funken?.......................... 180
7.6.2 Signal-Rauschabstand................................................................ 183
7.6.3 Fresnel-Zone, Multi-Path-Propagation und Phasenrau
schen ............................................................................................... 184
7.6.4 E rdkrm m un g............................................................................. 186
7.6.5 Timing-Probleme bei Langstreckenverbindungen . . . . 187
7.6.6 Planung von Wireless Long S h o ts .......................................... 188
7.7 Sind elektromagnetische Wellen von WiFi-Gerten gefhrlich? 188

8 Die Community 191

9
 Vorwort

Dieses Buch ist, obwohl in manch einsamen Stunden geschrieben, letzt

lich das Produkt einer weltweiten Community, deren Motto lauten knnte:
Freie Kommunikation fr alle! Dabei ist frei im Sinne von Freiheit ge
meint. Aktivisten aus mehr als 30 Nationen treffen sich einmal im Jahr zum
Wireless Summit for Free Information Infrastructures1 - im vergangenen
Jahr in Indien, 2007 in Ghana.
Letztlich habe ich nur aufgeschrieben und dokumentiert, was viele Men
schen mit Leidenschaft und Idealismus gemeinsam geschaffen haben. Da
zu wurde und wird stetig experimentiert, programmiert, diskutiert und ge
forscht. Ohne das Internet wre das Entstandene undenkbar, und es wird
Zeit, dass auch die Menschen in weniger entwickelten Regionen dieses klei
nen Planeten die Mglichkeit haben, sich durch Wikis, Blogs, Newsserver,
Mailinglisten, Chat, IRC, Webserver, VoIP, FTP etc. gegenseitig auszutau
schen, zu koordinieren und die Frchte ihrer Arbeit der ganzen Welt zur
Verfgung zu stellen. Das Prinzip von Open Source erffnete den Horizont
fr Creative Commons und seit einigen lahren auch fr Open Communica-
tion mit drahtloser Netzwerktechnologie.
Das grte Potential der globalen Kommunikation via Internet besteht dar
in, dass sich viele Kpfe zu einem global denkenden Organismus vernet
zen knnen, um Probleme zu lsen und sich weiter zu entwickeln. Heute
kommuniziere ich gleichzeitig und praktisch kostenlos mit Menschen aus
Nepal, Indien, Bangladesh, den USA, Japan, Lettland - um nur einige zu
nennen - und natrlich auch mit den Freifunkern aus Deutschland, der
Schweiz und sterreich. Vor einigen Jahren war das noch undenkbar, un
bezahlbar und htte ohnehin eine Ewigkeit gedauert.
Die Diskriminierung durch Armut ist eine der grten Geieln der Mensch
heit. Wer sich die gesellschaftliche Teilnahme nicht leisten kann ist von ihr
ausgeschlossen. Kommunikation kann nur dann frei sein, wenn sie auch
bezahlbar ist oder im besten Fall nichts kostet. Mein Dank geht darum an
alle Menschen, die daran arbeiten.

1 http://wsfii.org

11
 Besonders danken mchte ich ebenfalls dem ber alle Maen tapferen und
geduldigen Lektor Ulrich Wolf von Open Source Press, dem meine zahlrei
chen Versuche, den vorgesehenen Umfang des Buches zu sprengen, und
die vielen fehlenden Kommas das eine oder andere graue Haar beschert
haben drften.
Ich mchte auerdem all jenen danken, die unermdlich an den Routing
protokollen gebastelt haben. Das sind ganz besonders Bruno Randolf, Tho
mas Lopatic, Axel Neumann und Marek Lindner - und all die anderen Ent
wickler von OLSR und B.A.T.M.A.N. Vielen Dank auch an Ludger Schmudde
fr das Webinterface zu B.A.T.M.A.N. und den Mut, immer wieder neue Ver
sionen unserer unausgegorenen Routingsoftware im hrtesten Real-Life-
Production-Deployment einzusetzen, das ich kenne (auf einem Kirchturm
mitten in Berlin-Kreuzberg mit acht Ecken, ebenso vielen Routern und dop
pelt so vielen Netzwerkinterfaces). Und natrlich an Felix Fietkau, den ich
lange wegen der Fehler im Ad-Hoc-Modus des Madwifi-Treibers genervt
habe. Vielen Dank auch an die anderen Entwickler von OpenWRT fr ihre
groartige Arbeit. Dank geht an Sven-Ola Tcke fr die Antworten auf viele
Fragen und die tolle Firmware und Patches - ohne die Freifunk-Firmware
wren wir lange noch nicht da, wo wir heute sind. Vielen Dank an die Teil
nehmer, Organisatoren und Sponsoren von WSFII. Dem Chaos Computer
Club sei gedankt fr die Gelegenheit, Prsentationen ber das Thema zu
halten, und weil Euer Chaos-Camp der Schauplatz des ersten Meshversuchs
mit mehr als zwei Knoten war. Und nicht zuletzt geht ein besonders war
mes Dankeschn an Sven Wagner und alle Crewmitglieder der C-Base in
Berlin, weil Eure Raumstation ein so angenehmer und kreativer Space ist,
in dem sich die Berliner Freifunker jeden Mittwoch zum Wavelten tref
fen knnen. Dem MIT-Roofnet fr ETX, den Freifunkern in Nah und Fern,
den Community-Netzwerkern berall auf der Welt, dem Verlag Open Source
Press und und und ...
Eine solche Liste ist entweder endlos oder unvollstndig. Seid mir darum
nicht bse, wenn Ihr nicht persnlich genannt seid - Ihr und andere wissen,
welchen Beitrag Ihr geleistet habt! Vielen Dank fr den Tee, das Bier und
den ganzen Rest!

Corinna Elektra Aichele, im Juli 2007

12
 Einleitung

Innerhalb kurzer Zeit nach der Markteinfhrung der ersten Gerte fr Wire-
less Local Area Networks (WLAN) nach dem IEEE-Standard 802.11 entstan
den in verschiedenen Metropolen - zuerst in London, Amsterdam und Ber
lin - die ersten Brgernetze auf der Grundlage der neuen Technologie.
Mittlerweile erleben Community-Netzwerke einen globalen Boom. Zwar ist
fr einen Groteil der Bevlkerung heute ein breitbandiger Internetzugang
ebenso selbstverstndlich wie Wasser- und Stromanschluss, doch selbst in
Industrienationen wie der Bundesrepublik gibt es riesige Lcken in der
breitbandigen Internetpenetration, die selbst groe Stadtteile in der Haupt
stadt Berlin unversorgt lassen.
Schuld an diesem Problem ist u. a. die Optische Anschlussleitung (OPAL).
Die Glasfaser kam vor allem beim Auf- und Ausbau des Telefonsystems in
Ostdeutschland in den 1990er Jahren zum Einsatz und wurde zum Hemm
schuh, als die DSL-Technik eingefhrt wurde, die auf Kupferleitungen ba
siert. Fr die Betroffenen tut sich also selbst im Land der Exportweltmeis
ter der vom ehemaligen UN-Generalsekretr Kofi Annan konstatierte Di-
gital Divide, die Digitale Kluft, auf: Wer keinen Anschluss hat, verliert
den Anschluss an die globale Gesellschaft, an Bildung, Kommunikation und
Entwicklung. Lnder wie Estland wirken dem mit groer Weitsicht entge
gen und nehmen eine Vorreiterrolle ein, indem der kostenlose Zugang zum
Internet als Grundrecht in der Verfassung verankert ist.
Doch das erklrte Ziel der Freifunker - wie sich viele Aktivisten der Com
munity-Netzwerke selbst bezeichnen - ist nicht unbedingt nur das draht
lose Verteilen und Teilen von Internetzugangspunkten. Lokale Inhalte und
lokale Dienste sollen an Bedeutung gewinnen.
Bei vielen kommunalen Verwaltungen rennen die freien Netzwerker inzwi
schen offene Tren ein. Kirchen gestatten den Brgernetzen Installatio
nen auf Kirchtrmen und lehnen andererseits die Montage von Basissta
tionen von Mobiltelefonanbietern ab. Mit dazu beigetragen haben Vorbil
der wie der Brgermeister von San Francisco, der in Zusammenarbeit mit
Google seine Stadt mit kostenlosem drahtlosen Internetzugang per Mesh-
Technologie ausstatten lsst. Eine dazu passende Notiz am Rande ist, dass
Google die Firma Meraki Networks aufgekauft hat, die in ihren Wireless
Routern das OLSR-Protokoll fr Meshnetzwerke einsetzt, welches durch die
Berliner Freifunker weiterentwickelt wurde.

Freies Funken und rechtliche Grenzen

Dabei war die Entwicklung von Community-Netzen ein Weg mit Hindernis
sen. Eine wichtige Voraussetzung war, dass der 2,4-GHz-Frequenzbereich
fr die lizenzfreie Nutzung durch Privatpersonen zum Aufbau schneller
drahtloser Datennetze verfgbar wurde. Bis dahin konnten nur Funkama
teure und CB-Funker privat Datenfunkstrecken mit Packet Radio aufbau
en. Die Nutzbarkeit von Packet Radio ist jedoch sehr beschrnkt. Es ist sehr
langsam - vergleichbar mit Modems aus den 1980er Jahren -, und Daten
drfen im Amateurfunk nur zum Zwecke des Hobbys und nur unverschls
selt bertragen werden.
Die lizenzfreie Datenbertragung mit WLAN war in der BRD zuerst nur
innerhalb privater Grundstcke - nicht jedoch ber Grundstcksgrenzen
hinweg - gestattet. Der Sinn derartiger Beschrnkungen ist natrlich zwei
felhaft, da elektromagnetische Wellen kaum an Grundstcksgrenzen Halt
machen. Die ersten Funkstrecken der deutschen Community-Netzwerker
der Initiative Freifunk bewegten sich deshalb in einer rechtlichen Grauzo
ne, um es vorsichtig auszudrcken.
Nach und nach wurden die gesetzlichen Bestimmungen gelockert. In ei
nem nchsten Schritt wurden grundstcksbergreifende Datenverbindun
gen gestattet, blieben aber meldepflichtig. Dann wurde auch die Melde
pflicht aufgehoben. Seit einigen Jahren kann man die Frage, ob ein Com-
munity-Netzwerk in Deutschland legal ist, eindeutig bejahen.
Meshrouting vergrert die Reichweite

Mit verantwortlich fr den Boom der Community-Netzwerke ist neben dem

drastischen Preisverfall bei WLAN-Gerten das dynamische Meshrouting,
das aktiv von der Brgernetzinitiative Freifunk weiterentwickelt wurde,
denn die Reichweite der in Brgernetzen verwendeten WiFi-Gerte ist an
sich gering.
Um ber grere Entfernungen miteinander kommunizieren zu knnen,
mssen Daten so lange von Netzwerkknoten zu Netzwerkknoten weiterge
reicht werden, bis sie am Ziel ankommen. Die Netzwerkteilnehmer mssen
dazu ein Maschennetz bilden (engl.: Mesh), bei dem jeder Knoten mindes
tens einen Nachbarn hat, der fr ihn das Weiterreichen von Daten ber
nehmen kann. Voraussetzung fr den Betrieb eines Meshnetzwerks ist Soft
ware, die automatisch den gnstigsten Weg fr das Weiterleiten der Infor
mationen zum Ziel anpasst, wenn neue Netzwerkknoten hinzukommen,
sich bewegen oder ausfallen.
Bei einem Community-Netzwerk verluft der Aufbau blicherweise anders
als in kommerziellen Netzwerken, wo eine Firma in eine zentralisierte In
frastruktur investiert, mit der sich die Endgerte der Kunden verbinden. In
einem Community Netzwerk, das auf Mesh-Technologie setzt, bilden die
Gerte der Netzwerkbenutzer selbst einen Teil der Infrastruktur: Das Netz
basiert darauf, dass sich die Teilnehmer gegenseitig beim Datentransport
helfen. Die Hierarchie Anbieter-Konsument oder Infrastruktur-Endgert ist
in dynamisch vermaschten Meshnetzwerken beseitigt.

Aus dem Forschungslabor aufs Hausdach

Die Forschung an der drahtlosen Mesh-Technologie wird seit Beginn der

1970er Jahre im akademischen und militrischen Rahmen betrieben. Funk
tionierende, frei verfgbare technische Lsungen fr Meshnetzwerke gibt
es aber erst, seit die Brgernetzaktivisten die Mglichkeiten der Mesh-Tech
nologie fr sich entdeckt haben. Als sie begannen, damit zu experimentie
ren, erwies sie sich als praktisch kaum entwickelt und in der Praxis un
brauchbar. Doch sie waren von der Idee fasziniert und begannen die rmel
hochzukrempeln.
Die Community hatte gegenber der akademischen Forschung den ent
scheidenden Vorteil, ber eine immer weiter wachsende reale Testumge
bung zu verfgen, in der man im echten Leben die Ideen und Vernde
rungen ausprobieren konnte. Die Community hat so das Meshing aus dem
Dornrschenschlaf erweckt und gezeigt, dass groe dezentrale drahtlose
Netzwerke aus vielen einzelnen kleinen Funkzellen mglich sind, die auto
matisch von intelligenter Software vernetzt werden knnen.
Eine entscheidende Einschrnkung von WLAN-Hardware ist deren kurze
Reichweite. Die Sendeleistung ist in Europa auf 0,1 Watt bei 802.11b und
802.11g beschrnkt. Die meisten Hersteller geben fr ihre SoHO-Gerte ei
ne Reichweite von wenigen hundert Metern im Freien oder weniger als
hundert Meter innerhalb von Gebuden an. Anders als im Amateurfunk, wo
es um die direkte berbrckung mglichst groer Distanzen bei geringer
Informationsmenge geht, ist ein Community-Netz auf das Verknpfen re
lativ kurzer, breitbandiger Verbindungsstrecken angewiesen. Mit etwas Ba
siswissen ber die Physik der elektromagnetischen Wellen und zustzlichen
Antennen lsst sich die Reichweite jedoch auf mehrere Kilometer steigern,
ohne dass die bertragungsgeschwindigkeit drastisch leidet - auch ohne
dabei legale Grenzwerte zu berschreiten.

Fallende Hardwarepreise senken Einstiegshrde

Eine gute Abdeckung mit dem freien Funknetz bentigt eine groe Anzahl
von Netzwerkknoten, also ein eng verknpftes Maschennetz. Durch den
Preisverfall bei WiFi-Gerten1 und den Fortschritt in der drahtlosen Rou
tingtechnologie ist die Zugangsschwelle fr Menschen gesunken, die an
einem Brgernetz teilnehmen wollen. Der von Moore beobachtete Effekt,
dass sich die Leistungsfhigkeit von Informationstechnologie bei gleichzei
tigem Preisverfall bestndig steigert, hat erwartungsgem auch im Bereich
drahtloser Router und Netzwerkkarten keine Ausnahme gemacht.
Im Jahr 2000 kostete ein einfacher Accesspoint von Lucent umgerechnet
rund 400 Euro und eine WLAN-Karte fr Notebooks vom selben Herstel
ler 160 Euro. Heute kostet ein WLAN-Router wie der beliebte WRT54GL
von Linksys mit eingebautem Ethernetswitch etwa 60 Euro, und preiswerte
WLAN-Karten fr Notebooks oder Desktop-Rechner sind fr weniger als 20
Euro zu haben.
Einige WiFi-Router sind nicht nur gnstig, sondern auch sehr flexibel, denn
es existieren fr diese Gerte aus dem sogenannten SoHO-Bereich (Small
or Home Office) hochentwickelte alternative Betriebssysteme auf der Basis
von freier Software, die von Open-Source-Entwicklern und Brgernetzakti
visten entwickelt werden. WiFi-Router dieser Art werden fr kleinere Bros
entwickelt, oder um das drahtlose Surfen zu Hause auf dem Sofa oder im
Garten zu ermglichen.
Durch freie Software lsst sich das Einsatzspektrum enorm erweitern. Da
mit werden diese gnstigen Gerte zunehmend zur Konkurrenz von Pro
dukten, die fr Wireless Internet Service Provider zugeschnitten sind. Der
Streckenrekord ber eine Distanz von 382 Kilometern wurde mit zwei SoHO-

1 Die Begriffe WiFi (W ireless Fidelity) und W ireless 1.AN sind au stau sch b ar, auch wenn
WiFi streng genom m en nur ein e Form ein es d rah tlo sen LANs ist. ln diesem Buch wer
den beide Begriffe synonym verw endet.
Routern fr 60 US-Dollar erreicht, die mit der freien Linux-Firmware Open-
WRT ausgestattet waren.

Chancen fr Entwicklungslnder

In den Entwicklungs- und Schwellenlndern verfolgt man die Evolution der

Meshtechnologie mit WLAN mit groem Interesse. Die Autorin dieses Bu
ches hat auf der Basis dieser Technologie am Aufbau von Kommunikati
onsinfrastruktur in Bangladesh und Indien mitgewirkt. In diesen Lndern
existieren, abgesehen von GSM, oft keine Kommunikationssysteme, die der
Bevlkerung zur Verfgung stehen.
Da in Bangladesh die Bevlkerung berwiegend aus Analphabeten besteht,
ist zuerst der Aufbau von Telefonsystemen mit Voice over IP vordringlich.
ber eine Funkstrecke mit 6 Megabit Kapazitt lassen sich bereits viele
Telefongesprche gleichzeitig abwickeln. Antennen, Kabel und Elektronik
fr diesen Zweck kosten pro Standort nicht mehr als 500 US-Dollar. Unter
gnstigen Bedingungen knnen damit leicht 30 km berbrckt werden.

ber dieses Buch

Dieses Buch ist praxisorientiert. Es beschreibt die Hardware und Software,

die fr die Teilnahme an einem Mesh ntig ist. Softwareseitig liegt der
Schwerpunkt auf den Routing-Daemons Olrsd und Batmand sowie der Frei
funk-Firmware und OpenWRT, die deren bequeme Installation und Konfi
guration in SoHO-Routern ermglichen.
Um die Software einsetzen zu knnen, braucht es ein Verstndnis von Mesh
routing im Allgemeinen und der eingesetzen Routing-Protokolle, die am
Anfang des Buches beschrieben werden.
Daneben kommt auch die Hardware nicht zu kurz, denn wenn man seinen
Router stabil und mit gutem Datendurchsatz betreiben will, gilt es vieles
zu beachten - von der Stromversorgung bis zur Funkreichweite. Das Buch
liefert hier zahlreiche Praxistipps und eignet sich deshalb auch als guter
Einstieg fr alle, die mehr aus ihrer Router-Hardware herausholen wollen.
 Meshrouting

Wireless LAN nach IEEE 802.11 verfgt ber zwei verschiedene Betriebs
arten: Den Ad-Hoc-Modus - unter Microsoft Windows als Peer-to-Peer-
Modus bezeichnet - und den Infrastrukturmodus. Die meisten Anwender
benutzen WLAN im Infrastrukturmodus, wenn sie sich mit einem Access-
point in einem Hotspot verbinden. Die gesamte WLAN-Kommunikation
zwischen den Endgerten luft in einem Hotspot ber den Accesspoint ab,
der blicherweise als Internetzugangspunkt dient.
Technisch bezeichnet man eine solche sternfrmige Netzwerkstruktur als
Point-to-M ultipoint- oder One-to-M any-Topologie. Die WLAN-Basisstation
verhlt sich in einem Hotspot wie der Funkmast eines Mobiltelefonanbie
ters. Wenn zwei Mobiltelefone miteinander kommunizieren, die sich bei
derselben Basisstation eingebucht haben, werden alle zur Abwicklung des
Gesprchs notwendigen Daten ber den Mobilfunkmast als Relaisstation
bertragen.
Befindet man sich in einer abgeschiedenen Gegend ohne funktionierende
Infrastruktur, ist das Mobiltelefon nutzlos. Anders als bei einem klassischen
2 Meshrouting

Funkgert kann man andere Gesprchspartner auch dann nicht anrufen,

wenn sich ihre Telefone innerhalb der Funkreichweite befinden.

Abbildung 2.1:
WLAN im
Infrastrukturmodus

Im Ad-Hoc-Modus hingegen knnen WLAN-Karten wie Funkgerte direkt

miteinander kommunizieren, ohne auf einen Accesspoint angewiesen zu
sein. Jedes Gert kann gleichzeitig mit mehreren anderen Gerten Verbin
dungen direkt aufbauen, sofern sie in Funkreichweite sind. Entsprechend
wird diese Netzwerktopologie als Multipoint-to-Multipoint oder Many-to-
Many bezeichnet.

Abbildung 2.2:
WLAN im
Ad-Hoc-Modus

Haben alle Teilnehmer in einer Ad-Hoc-Funkzelle untereinander direkten

Funkkontakt, wird die Netzwerktopologie als Full Mesh (Vollmesh) bezeich
net. Befinden sich zum Beispiel mehrere Notebooks mit WLAN in einem Sit
zungssaal, ist die Reichweite der WLAN-Karten blicherweise ausreichend
fr ein Vollmesh. Sind die Gerte ber einen greren Bereich verteilt (z. B.
Universittscampus), knnen Ad-Hoc-Stationen jeweils nur mit den Netz
werkknoten kommunizieren, die sich gerade innerhalb der Funkreichweite
befinden.

2.1 Ad-Hoc vs. Infrastruktur

Der Ad-Hoc-Modus hat Vorteile gegenber dem Infrastrukturmodus - und

natrlich auch Nachteile. Ein direkter Vorteil liegt auf der Hand: Da Ad-
Hoc-Netze nicht auf eine Basisstation angewiesen sind, fallen beim Betrieb
die Kosten fr den Accesspoint weg, sofern keine Relaisstation an einem
exponierten Standort zur Reichweitenverbesserung erforderlich ist.
Dezentrale Ad-Hoc-Netze sind prinzipiell robuster als zentralisierte Netz
werke im Infrastrukturbetrieb. Fllt die Basisstation in einem Infrastruk
turnetz aus, bricht die Kommunikation unter ihren Clients zusammen, in
 2.1 Ad-Hoc vs. Infrastruktur I

einem Ad-Hoc-Netz ist der Ausfall eines einzelnen Netzwerkknotens nicht

unbedingt strend.
Der direkte Datentransfer zwischen Ad-Hoc-Stationen ist auerdem erheb
lich schneller als unter Clients im Infrastrukturmodus. Der Transport von
Daten zwischen zwei Endgerten in einem Hotspot setzt mindestens zwei
bertragungsvorgnge voraus (von Gert A zum Accesspoint, vom Access-
point zu Gert B). Zwei Netzwerkknoten (Nodes) knnen bei der Verwen
dung von 802.11g im Ad-Hoc-Modus Daten mit einer Geschwindigkeit von
maximal 3,2 Megabyte pro Sekunde direkt bertragen. Benutzen beide Ge
rte den Infrastrukturmodus, reduziert sich die bertragungsgeschwindig
keit im gnstigsten Fall auf 1,6 Megabyte pro Sekunde.
Diese Geschwindigkeit wird im Infrastrukturmodus nur erreicht, wenn bei
de Notebooks eine hervorragende bertragungsqualitt hin zum Access
point haben und keine anderen Gerte diesen gerade benutzen. Verwen
den mehrere Endgerte den Accesspoint gleichzeitig, teilt sich die nutzbare
Bandbreite unter allen Teilnehmern auf. Noch drastischer ist der Geschwin
digkeitseinbruch, wenn beide Endgerte zwar nahe zusammen stehen, aber
vom Accesspoint entfernt sind, so dass die bertragung zum Accesspoint
ohnehin mit stark reduzierter Datenrate luft. In diesem Fall schnurrt die
nutzbare Bandbreite weiter zusammen.
Natrlich bietet ein fest installierter Accesspoint auch Vorteile. Zweckm
igerweise wird man einen mglichst hohen und freien Standort whlen
und ihn mit einer Antenne ausstatten, welche die Reichweite steigert. Da
mit vergrert sich die Reichweite gegenber Netzwerkknoten, die sich in
Bodennhe zwischen Objekten wie Mbeln, Trennwnden und Menschen
befinden, welche die Funkbertragung erheblich behindern. Befindet sich
Notebook A auerhalb der bertragungsreichweite von Notebook B, ist im
Ad-Hoc-Modus kein Datentransfer zwischen beiden mobilen Netzwerkkno
tenpunkten mglich, solange kein weiterer Netzwerkknoten als Vermittler
zwischen den beiden Gerten agiert. Im Infrastrukturmodus bernimmt
der Accesspoint von seinem exponierten Standort aus diese Mittlerrolle
und vergrert die Reichweite und Qualitt der Abdeckung.
Die Tatsache, dass ein Accesspoint stets als Funkbrcke arbeitet und des
halb potentiell zur Reichweitenvergrerung beitrgt, ist aber kein ent
scheidender Grund gegen den Einsatz des Ad-Hoc-Modus. Auch ein Netz
werkknoten im Ad-Hoc-Modus kann an einem exponierten Standort als Re
laisstation betrieben werden. Das Weiterleiten von Daten fr andere Netz
werkknoten ist zwar keine Standardfunktion des Ad-Hoc-Modus laut Proto
koll IEEE 802.11 a/b/g, diese fehlende Funktion aber kann durch den Ein
satz einer Routingsoftware hinzugefgt werden. Dann wird jeder Netzwerk
knoten zum Router.
Ein solcher Meshrouter verhlt sich dabei weitaus intelligenter als ein her
kmmlicher Accesspoint. Dieser wiederholt einfach blind jedes drahtlos

21
2 Meshrouting

zwischen den Clients bertragene Datenpaket, welches nicht per Kabel ins
Internet oder lokale LAN weitergeleitet wird. Mit einem Routingprotokoll
ausgestattet, kann jeder einzelne Netzwerkknoten entscheiden, ob das ziel
gerichtete Weiterreichen von Daten gerade erforderlich ist. Damit steigt die
Qualitt der Abdeckung, da jedes Gert im Netzwerk bei Bedarf als Re
laisstation arbeitet. Durch den zielgerichteten Transfer verbessert sich die
Skalierbarkeit und der mgliche Datendurchsatz der Funkzelle. Auerdem
werden drahtlose Datenverbindungen ber mehrere Zwischenstationen -
sogenannte Multihop-Links - mglich. Durch den Einsatz eines Routing
protokolls wird aus einer simplen Ad-Hoc-Funkzelle ein Meshnetzwerk, das
beim Hinzukommen von neuen Netzwerkstationen dynamisch wchst. Je
der neue Teilnehmer verbessert die Funkversorgung und wird dynamisch
vom Routingprotokoll in das Netz eingegliedert.

2.1.1 Bandbreitenproblematik bei Multihop-Links mit nur

einem Interface

Die meisten Meshknoten in einem Community-Meshnetzwerk arbeiten aus

Kostengrnden mit nur einer WLAN-Karte. Das reduziert bei einer Rou
te ber mehrere Zwischenstationen mit jeweils nur einem drahtlosen In
terface die verfgbare Bandbreite bei jedem Weiterreichen der Datenpake
te. WLAN-Karten nach 802.1 la/b/g arbeiten im sogenannten Halbduplex-
Modus. Sie haben einen Empfnger und einen Sender, die auf dem gleichen
Kanal arbeiten. WLAN-Karten knnen also abwechselnd entweder senden
oder empfangen - aber nicht beides gleichzeitig. Man kann schlielich
nicht zuhren, solange man sich selbst ins Ohr brllt. Als weiteres Han
dicap kommt hinzu, dass ein Meshrouter, der gerade Daten an einen ande
ren bertrgt, den Funkkanal fr andere Knoten in der unmittelbaren Nhe
blockiert.
bertrgt Router A Daten an B, kann C nicht gleichzeitig an D senden, da
die Sendung von C den Empfang von B durch Interferenz stren wrde.

-^ r

Reicht B im nchsten Schritt die Daten an C weiter, kann A nicht an B

senden, da B gerade selbst sendet. D kann ebenfalls nicht senden, weil er
damit den Empfang der Daten von B bei C blockieren wrde.

^ r @

Die Datenrate hat sich bei der Ankunft der Daten bei C bereits halbiert. Bei
der anschlieenden bertragung von C an D hrt B unfreiwillig mit. A kann

22
 2.1 Ad-Hoc vs. Infrastruktur

nicht an B senden, da sich im Empfnger von B die Signale von C und A

gegenseitig stren wrden.

Wenn die Daten schlielich bei D eintreffen, ist die Bandbreite auf dem
Pfad A-B-C-D auf rund ein Drittel gesunken.

Auf den ersten Hops einer Multihop-Route reduziert sich also die Band
breite schnell. Sie sinkt jedoch mit weiter ansteigender Sprunganzahl (Hop
count) langsamer und fllt nicht ins Bodenlose (zumindest in der Theorie).
Nach fnf Hops stabilisiert sie sich auf niedrigem Niveau.
Diese Aussage trifft jedoch nur unter idealen Bedingungen zu. Die Voraus
setzung dafr ist, dass das Mesh sich in einer funktechnisch ruhigen Umge
bung befindet und die bertragungen nicht von anderer Seite gestrt wer
den. In dicht bevlkerten Gebieten ist das im 2,4-GHz-Bereich mit seinen
zahlreichen konkurrierenden Anwendungen jedoch kaum der Fall.
Es ist eine typische Eigenschaft der Luftschnittstelle, dass sich die Bedin
gungen sprunghaft ndern knnen. In einer Grostadt fhrt das dazu, dass
auf einer Multihop-Route mit vielen Hops hufig mindestens eine bertra
gungsstrecke gerade stark gestrt ist und praktisch kaum Bandbreite zur
Verfgung stellt. Eine Kette ist nur so stark wie ihr schwchstes Glied -
da jede Funkstrecke individuell durch Interferenzen gestrt werden kann,
steigt mit dem Hopcount die Wahrscheinlichkeit, dass eine Route augen
blicklich nicht funktioniert.
Mit steigendem Hopcount sinkt daher nicht nur die Bandbreite - gleich
zeitig steigen auch die Paketverluste und die Wahrscheinlichkeit, dass eine
Route gerade nicht passierbar ist, bevor das Routingprotokoll eine Alterna
tivroute zur Verfgung stellen kann (sofern sich eine Alternativroute auf
bauen lsst).
Paketverluste haben die unangenehme Eigenschaft sich zu multiplizieren.
Die Erfolgsrate bei der bertragung ist in der Grafik als Faktor angegeben.
Ein Faktor von 1 entspricht einer Erfolgsrate von 100 Prozent. Durch die
Multiplikation der einzelnen Erfolgsraten ergibt sich der Gesamtwirkungs
grad der Multihop-Route.

23
2 Meshrouting

Multipliziert man den Gesamtwirkungsgrad der Route mit der theoreti

schen Bandbreite, kommt man zu einer einigermaen realistischen Ein
schtzung des tatschlichen Durchsatzes (Throughput). Eine Route A-B-C-
D mit einer theoretischen Bandbreite von 3,66 Megabit und einem Gesamt
paketverlust von 50 Prozent wird einen Durchsatz von etwa 1,8 Megabit bei
der Verwendung des verbindungslosen UDP-Protokolls erzielen.
Diese Betrachtung ist allerdings stark vereinfacht. In diesem Beispiel wurde
nur der Weg in eine Richtung bercksichtigt und bei allen Verbindungsstre
cken die gleiche Bruttodatenrate angenommen. Auerdem hat das jeweils
verwendete Protokoll (TCP, UDP) einen nicht unerheblichen Einfluss auf
die erzielbare Bandbreite.

2.1.2 Problemfall TCP

Im Gegensatz zum verbindungslosen Protokoll UDP ist TCP (Transfer Con

trol Protocol) ein verbindungsorientiertes Protokoll, welches berprft, ob
die Datenbertragung zwischen zwei Netzwerkknoten erfolgreich stattge
funden hat. Der Sender wartet nach dem Verschicken eines Datensegments
auf eine Empfangsbesttigung (Acknowledgement) des Empfngers, in der
dieser mitteilt, ob er die Daten fehlerfrei empfangen hat. Trifft innerhalb
der Wartezeit (Timeout) das Acknowledgement fr das bertragene Daten
segment nicht ein, wird das Datenpaket als verloren betrachtet und erneut
bertragen. Die Performance von TCP ist in einem Mesh sehr schlecht, da
das Protokoll ausschlielich fr die Anforderungen kabelgebundener Netz
werke entwickelt wurde, bei denen Paketverluste nur selten Vorkommen.
In Kabelnetzen tritt Paketverlust nicht wie beim Funk im bertragungsme
dium auf, sondern durch Datenstaus am bergang zwischen unterschied
lichen Netzwerksegmenten. Eine primre Zielsetzung von TCP ist es, die
Steuerung der Datenrate in einem Netzwerk so zu koordinieren, dass es
nicht an Engstellen zu Datenstaus kommt. Wrde TCP trotz Datenstau die
bertragung vermeintlich verlorengegangener Pakete in schneller Folge
wiederholen, wre das verheerend - wie ein Stau auf der Autobahn, in den
immer mehr Autos hineinfahren.
Wird TCP in einem Funknetzwerk eingesetzt, interpretiert es die Paketver
luste durch bertragungsfehler im Funkmedium flschlicherweise als Da
tenstaus und reagiert darauf durch eine Reduzierung der Datenrate. Paket
verlusten begegnet es zwar mit erneuten bertragungsversuchen, es ver
doppelt aber bei jeder Retransmission die Wartezeit vor dem erneuten Sen
den (Exponential Backoff) bis zu 64 Sekunden.
 2.1 Ad-Hoc vs. Infrastruktur I

Nach 13 gescheiterten Versuchen oder 9 Minuten gibt TCP auf und erzeugt
eine Fehlermeldung. Durch den Exponential Backoff wird die Datenber
tragung ber TCP auf schlechten Funkstrecken qulend langsam.
Retransmissions von TCP sollten so gut wie es geht vermieden werden. Ei
ne naheliegende Mglichkeit, die Probleme mit TCP abzuschwchen, ist es,
die bertragung unterhalb der TCP/IP-Protokollschichten auf dem Trans-
portlayer der WLAN-Karten so robust wie mglich zu machen.
Wireless LAN nach 802.11 beherrscht die Option Fragmentation, die gre
re Datenpakete bei der bertragung zwischen zwei WLAN-Karten in klei
nere Fragmente unterteilt. Ein groes Datenpaket bentigt in der Luft
schnittstelle eine lnger dauernde, ungestrte bertragungszeit als ein
kleineres Paket und hat damit eine geringere Wahrscheinlichkeit, erfolg
reich bertragen zu werden.
Wie bei TCP erwartet die sendende WLAN-Karte nach jedem Datenfrag
ment ein Acknowledgement des Empfngers. Bleibt dieses aus, wird die
bertragung jedes einzelnen Datenfragments wiederholt - blicherweise
bis zu sieben Mal. Diese Funktion sollte in einem Mesh immer verwen
det werden. Auf diese Weise lsst sich eine gewisse bertragungssicherheit
erreichen, um zu vermeiden, dass TCP Manahmen gegen vermeintliche
Datenstaus ergreift. Die beste Erfahrung hat die Autorin mit sehr kleinen
Werten fr die Fragmentierung gemacht. Die Mindestgre ist 256 Byte.

Maximale IP-Paketgre - Maximum Transfer Unit

In drahtgebundenen Netzwerken wird bei der Konfiguration der Netzwerk

schnittstelle der grtmgliche Wert fr die Gre der IP-Pakete eingestellt,
um einen mglichst groen effektiven Datendurchsatz zu erzielen. Bei je
dem IP-Paket mssen zustzliche Informationen fr die Transportschicht
als Verpackung (Overhead) zu dem zu transportierenden Inhalt (der Pay-
load) hinzugefgt werden. Um das Verhltnis von IP-Overhead und Pay-
load gnstiger zu gestalten, wird die Paketgre daher maximiert. Sowohl
bei Ethernet als auch bei WiFi betrgt die Maximum Transfer Unit (MTU)
deshalb normalerweise 1500 Byte.
Bei Routen mit vielen Sprngen (Hops) sollte die oben beschriebene Frag
mentierung auf der MAC-Ebene bei allen Karten eingeschaltet sein. Haben
die Betreiber von Meshknoten diese Einstellung nicht vorgenommen, ist
das Verkleinern von IP-Paketen, also eine kleinere MTU, eine Notlsung,
um die negativen Effekte von TCP abzuschwchen. Der positive Effekt ist
hier jedoch bei weitem geringer als bei Verwendung der Fragmentierung
auf MAC-Ebene. Das Verkleinern der MTU kostet verglichen mit der Frag
mentierung einen greren Teil der erzielbaren Datengeschwindigkeit. Ist
aber eine Route sehr wenig belastbar, ist es sinnvoll, zustzlich zur Frag
mentierung auch die MTU zu verkleinern.
2 Meshrouting

2.1.3 Exposed Nodes - Hidden Nodes

Es wurde in den Grafiken zu den Multihop-Transfers stillschweigend da

von ausgegangen, dass sich die Knoten A-B-C-D einander nicht dauernd
chaotisch dazwischenfunken. Das ist jedoch nicht selbstverstndlich.

Hier kann A nur B sehen und C nur B. Aus der Sicht von A ist C ein ver
steckter Knoten (Hidden Node) und ebenso ist A fr C unsichtbar. B ist
der exponierte Knoten (Exposed Node) dazwischen, der alle beide Knoten
sieht. Daraus ergibt sich das Problem, dass B Schwierigkeiten hat, Pakete zu
empfangen, wenn A und C gleichzeitig senden. B muss koordinieren, wel
cher von den beiden versteckten Knoten gerade senden darf, so dass sich
die bertragungen von A und C nicht gegenseitig blockieren. Da Meshnetz-
werke auf dem Weiterreichen von Daten ber Zwischenstationen basieren,
ist das Problem mit den versteckten Knoten der Normalfall.
Ganz lassen sich Kollisionen in dieser Situation nicht vermeiden, sie lassen
sich jedoch prinzipiell stark vermindern. Bevor Knoten A anfngt, groe
Datenmengen zu senden, fragt er mit einer kurzen bertragung per Broad-
cast, ob er senden darf, dem Request-to-Send (RTS). In dem RTS-Datenpaket
ist angegeben, wie lange Knoten A das bertragungsmedium fr sich re
servieren mchte. Wenn B der Meinung ist, dass A senden darf, funkt er
Clear-to-Send (CTS). C hrt das RTS von A nicht, wohl aber, dass B einer
versteckten Station das OK zum Senden gegeben hat, und hlt sich fr die
angeforderte Zeitspanne zurck. Mchte C senden, fragt er ebenfalls vorher
per RTS-Broadcast.
Auch der RTS/CTS-Mechanismus ist eine Funktion von WLAN-Karten, die
in einem Mesh eigentlich verwendet werden sollte. Die Implementierung
von RTS/CTS in IEEE 802.1 labg wurde aber nicht fr den Einsatz in Mesh-
netzwerken entwickelt und ist dafr ungeeignet. Sie schadet viel mehr, als
sie ntzt. In einem Mesh blockieren sich die Knoten mit den RTS/CTS-
Signalen hufig irrtmlicherweise gegenseitig. Es kommt zu Situationen,
in denen gar kein Knoten sendet, weil alle Knoten flschlicherweise an
nehmen, dass das Medium fr einen nicht existierenden Knoten reserviert
wurde. Es existiert ein Lsungsvorschlag1 fr dieses Problem, der aber in

1 Saikat Ray, Jeffrey B. Carruthers and David Starobinski: R TS/CTS-Induced Con-

gestion in Ad Hoc Wireless LANs", h t t p : / / i e e e x p l o r e . i e e e . o r g / i e l 5 / 8 5 4 6 /
2 7 0 3 0 / 0 1 2 0 0 6 1 1 . pdf

26
 2.2 Routingprotokolle fr drahtlose Netzwerke

802.1 labg nicht zur Verfgung steht. Deshalb sollte bis auf weiteres auf
RTS/CTS im Mesh verzichtet werden.
Empfngt Knoten E ein RTS-Signal, welches nicht an ihn gerichtet ist, stellt
er fr die im RTS-Paket angegebene Zeitdauer jegliche Aussendungen ein,
da fr ihn das Medium mutmalich blockiert ist. Er tut dies auch dann,
wenn er in der aktuellen Situation kein Hidden Node ist und die bertra
gung berhaupt nicht stren wrde. Wird E in dem Zeitraum, in dem fr
ihn das Senden blockiert ist, von einem weiteren Knoten F mit einem RTS-
Signal nach Sendezeit gefragt, darf er nicht antworten. Da E nicht antwor
tet, vermutet F eine Kollision und stellt seinerseits fr eine Zeit (Backoff-
Time) den Sendebetrieb ein. Das RTS-Paket von F veranlasst aber weite
re Knoten, die das RTS-Signal empfangen, ebenfalls dazu, fr die im RTS-
Paket angegebene Zeitdauer ihre Aussendungen einzustellen. Diese Ant
worten dann ihrerseits auf die RTS-Anfragen anderer Netzwerkkonten nicht.
Dieser Irrtum kann sich ber das gesamte Mesh ausbreiten, so dass ber
haupt kein Knoten mehr sendet!
Im Extremfall tritt das Phnomen unter Meshknoten auf, die einen Kreis
bilden. Die RTS/CTS-Blockade pflanzt sich ringfrmig fort und kann zu ei
ner Blockade (Deadlock) fhren, die einige Zeit anhalten kann.

2.2 Routingprotokolle fr drahtlose Netzwerke

Die Entscheidung, auf welchem Weg Daten von jedem einzelnen Netzwerk
knotenpunkt zu jedem anderen Node im Netz geroutet werden, kann bei
kleinen statischen Netzwerken noch von Hand in die IP-Routingtabellen je
des Netzknoten eingegeben werden. Doch selbst in kleinen drahtgebunde
nen Netzwerken gert das schnell zu einem mhsamen und komplizierten
Unterfangen. Kommt ein neuer Router hinzu oder fllt einer aus, mssen
unter Umstnden smtliche Routingtabellen in allen Routern von Hand be
arbeitet werden. Ein derartiges Verfahren wre viel zu aufwendig und feh
lertrchtig. Deswegen arbeitet man in professionellen Netzwerken schon
lange mit Software, die Routingtabellen automatisch erzeugt und anpasst.
Fr drahtgebundene Netze entwickelte Routingprotokolle eignen sich je
doch nicht fr drahtlose Netzwerke. Diese sind permanenten Vernderun
gen unterworfen, auch wenn sie nur aus statischen Netzwerkknoten auf
Hausdchern bestehen, zwischen denen keine die Funkbertragung st
renden Objekte auftauchen und wieder verschwinden. Die verfgbare Band
breite zur Datenbertragung ist prinzipiell eher gering. Ein Routingproto
koll, welches selbst groe Datenmengen erzeugt, ist auf schnellen Daten
leitungen akzeptabel, solange es zuverlssig funktioniert. In drahtgebun
denen Netzen lsst sich die Bandbreite prinzipiell durch mehr Leitungen
erweitern, in einem drahtlosen Netzwerk hingegen teilen sich alle Netz
werkknoten mit dem Funkspektrum ein gemeinsames bertragungsmedi

27
2 Meshrouting

um, die Bandbreite ist begrenzt; Routingprobleme lassen sich nicht durch
mehr Bandbreite kompensieren.
Von einer kabelgebundenen Datenverbindung kann man weiterhin erwar
ten, dass das, was man am einen Ende hineingibt, auch auf der anderen
Seite herauskommt, solange die Hardware nicht beschdigt ist. Ist eine ka
belgebundene bertragungsstrecke defekt, fllt sie in der Regel komplett
aus. Eine Funkstrecke kann zwischen fehlerloser bertragungsqualitt bei
hoher Geschwindigkeit oder geringstem Datendurchsatz mit unregelmi
gen Aussetzern schwanken. Derartige Probleme treten in der Praxis in einer
Umgebung mit konkurrierenden Funkanwendungen hufig auf.
WiFi arbeitet in Frequenzbereichen, die auch von vielen anderen Funkan
wendungen genutzt werden. Strungen durch Interferenzen sind daher
eher die Regel als die Ausnahme. Nicht zuletzt erzeugt auch jede Daten
bertragung in einem Meshnetzwerk selbst ein Strsignal bei Netzwerkkno
ten in der Umgebung und schrnkt damit die Qualitt der anderen Funk
verbindungen ein. Die Strreichweite einer Funkbertragung ist mindes
tens dreimal so hoch wie die Nutzreichweite.
Ein groes, drahtloses Meshnetzwerk ist - vor allem in einer Grostadt -
hochgradig dynamischen Vernderungen unterworfen und chaotisch. Wenn
ein Knoten ausfllt, kann sich das Protokoll nicht darauf verlassen, dass
diese Vernderung zeitnah oder zuverlssig mitgeteilt wird. Ein Routing
protokoll fr Meshnetzwerke muss daher robust gegenber fehlenden oder
unzuverlssigen Informationen sein, schnell auf Vernderungen reagieren
und mit einem Minimum an selbsterzeugtem Datenverkehr auskommen.
Die Forschungen an Routingprotokollen fr Meshnetzwerke laufen seit dem
Beginn der 1970er Jahre. Die englischsprachige Wikipedia listet ber 70 ver
schiedene Protokollentwrfe auf2. Viele davon existieren nur auf dem Pa
pier oder werden bislang nur in Simulationen eingesetzt. Routingprotokolle
fr Meshnetzwerke werden in folgende Gruppen eingeteilt:

proaktive Protokolle

reaktive Protokolle

hybride Protokolle (proaktiv/reaktiv)

hierarchische Protokolle

geografische Protokolle

energieorientierte Protokolle

Multicast-Protokolle

geografische Multicast-Protokolle

2 http://en.wikipedia.org/List_of_ad-hoc_routing_protocols
 2.2 Routingprotokolle fr drahtlose Netzwerke

2.2.1 Protokoll typen

Proaktive P rotokolle ermitteln permanent alle Routen zwischen allen Nodes

in einem Funknetz mit einem mathematischen Algorithmus, der den kr
zesten (oder gnstigsten) Pfad zwischen einem Start- und einem Zielpunkt
berechnet. Jeder Knoten berechnet Routen zu allen anderen Knoten im
Netzwerk, unabhngig davon, ob diese gerade bentigt werden oder nicht.
Sie erzeugen deshalb prinzipbedingt schon in relativ kleinen Netzwerken
viel Rechenlast und protokollspezifischen Datenverkehr. Die meisten proak
tive Routingprotokolle verwenden den Shortest-Path-Algorithmus, der nach
seinem Erfinder Edsger W. Dijkstra Dijkstra-Algorithmus oder auch Link-
State-Algorithmus genannt wird. Dazu flutet jeder einzelne Router regelm
ig das gesamte Netzwerk mit Nachrichten, in der er seine lokalen, direkt
erreichbaren Nachbarknoten auflistet. Diese Informationen ber die loka
le Topologie jedes einzelnen Node wird von jedem anderen Teilnehmer in
einer eigenen Datenbank gesammelt und zu einem groen Graphen verar
beitet, der das ganze Netz abbildet. Link-State-Verfahren sind in der Lage,
bei ihren Routingentscheidungen auch Faktoren wie Bandbreite, Zuverls
sigkeit von Verbindungsstrecken, Delay und Auslastung der Verbindungs
strecken zu bercksichtigen.
Selten wird bei proaktiven Protokollen zur Routenberechnung das Distanz-
Vektor-Verfahren angewendet. Dazu mssen die einzelnen Knoten ihre Rou
tingtabellen (komplett oder partiell) ber das Netzwerk kommunizieren.
Dieses Verfahren erzeugt ein noch greres protokollspezifisches Daten
aufkommen als das Link-State-Verfahren und kann sich nur langsam an
Vernderungen im Netzwerk anpassen (konvergieren).
Zu den proaktiven Protokollen gehren DSDV (Destination-Sequenced Dis-
tance-Vector)3 , B.A.T.M.A.N. (Better Approach to Mobile Ad-Hoc Networ
king)4 und OLSR (Optimized Link State Routing)5.
Reaktive P rotokolle ermitteln Routen nur bei Bedarf. Mchte ein Knoten
mit einem anderen Netzteilnehmer kommunizieren, flutet er das Netz mit
einer Anfrage nach einer Route zu seinem Ziel. Reaktive Verfahren erzeugen
nur wenig Protokolldatenverkehr im Netz und verursachen wenig Rechen
last, wenn nur selten Routen gesucht werden und wenn die gefundenen
Routingpfade stabil sind. Solange jedoch nicht nach Routen im Mesh ge
sucht wird, wei ein Knoten nicht, ob berhaupt andere Knoten im Netz
werk vorhanden oder erreichbar sind.
Da Routen erst bei Bedarf gesucht werden, stehen Netzwerkverbindungen
erst nach einer Verzgerung zur Verfgung. Bekannte reaktive Protokolle

3 h t t p ://citeseer.i s t .p s u .edu/perkins94highly.html
4 http://open-mesh.net/batman
5 http://hipercom.inria.fr/olsr/

29
2 Meshrouting

sind DSR (Dynamic Source Routing)6, AODV (Adhoc On-Demand Distance

Vector)7, DYMO (Dynamic MANET On-demand)8 und SrcRR9 .
Hybride Protokolle verwenden bis zu einem bestimmten Horizont ein pro
aktives und fr weiter entfernte Knoten ein reaktives Verfahren. Dadurch
sollen die Vorteile von proaktiven Verfahren (Routen sind proaktiv in der
Routingtabelle vorhanden) und reaktiven Verfahren (weniger Protokollda
tenaufkommen und Rechenaufwand) kombiniert werden, ohne die Nach
teile zu bernehmen. Hybride Protokolle sollen fr sehr groe Meshnetz-
werke geeignet sein. Vertreter dieser Gattung sind HSLS (Hazy Sighted Link
State Routing)10 und ZRP (Zone Routing Protocol)11.
Hierarchische Protokolle versuchen, Netzwerkknoten zu hierarchisch ge
gliederten Gruppen zusammenzufassen um das Aufkommen von Protokoll
datenverkehr zu reduzieren und dadurch die Skalierbarkeit zu erhhen. Ein
Protokoll dieser Gattung ist DART (Dynamic Address Routing)12.
Geografische Protokolle treffen ihre Routingentscheidungen nach der geo
grafischen Position der Netzwerkknoten. Dieses Verfahren erfordert zustz
liche Hardware zur Positionsbestimmung oder die manuelle Eingabe des
Standorts. Nicht bercksichtigt wird dabei, dass sich zwei Knotenpunkte
zwar geografisch nahe sein knnen, die Funkverbindung aber mglicher
weise durch Hindernisse vllig getrennt ist.
Energieorientierte Protokolle spielen vor allem fr Sensornetzwerke eine
Rolle, wo die Einsparung von Sendeenergie optimiert werden soll. Datenpa
kete sollen nicht mit groer Sendeenergie ber lngere Strecken bertragen
werden, sondern ber viele Zwischenstationen, um Sendeenergie zu sparen
oder Sensoren schwerer auffindbar zu machen.
Multicast-Protokolle dienen der bertragung von Daten ber verbindungs
lose Protokolle. Interessant sind sie fr Multimedia-Inhalte, etwa Audio-
und Videostreams.
Geografische Multicast-Protokolle sollen multimediale Inhalte per Multicast
ber ein Mesh an Gerte verbreiten, die sich in einem bestimmten geografi
schen Gebiet befinden. Sie knnen unter anderem fr sogenannte Location
Based Services (Standortbezogene Dienste) eingesetzt werden.

6 David B. Johnson, Routing in Ad Hoc Networks o f M obile H osts", Proceedings of the

Workshop on M obile C om puting System s and A pplication s, pp. 158-163, IKEK Compu
ter Society, Santa Cruz, CA, D ecem b er 1994.
' http ://moment.c s .u c s b .edu/AODV/aodv .html
8 http://moment.cs.ucsb.edu/dymo
9 http://pdos .csail .mit .edu/roofnet/doku.php?id=designfcs=srcr#routing
.protocol
10 http :/ / v v v .i r .b b n .com/documents/techmemos/TM1301.pdf
11 http://tools .ietf .org/id/draft-ietf -manet-zone-zrp-04 .txt
12 http://dart.cs.ucr.edu

30
 2.2 Routingprotokolle fr drahtlose Netzwerke

2.2.2 Praktische Relevanz der Routingprotokolle

Auf dem Gebiet der Routingprotokolle fr drahtlose Netzwerke wird in

ternational viel geforscht. Es existieren viele theoretische Protokollentwr
fe. Doch die meisten Arbeiten dienen in der akademischen Forschung le
diglich als Diskussionsgrundlage und werden nie in der Praxis eingesetzt
oder getestet, da nur wenige Forschungseinrichtungen die Mglichkeiten
fr umfangreiche praktische Erprobung haben. Wenn Programmcode fr
eines der Protokolle existiert, handelt es sich oft nur um Implementierun
gen fr Netzwerksimulatoren, was hufig kritisiert wird.
Es ist nmlich sehr schwer, die komplexe Situation eines realen drahtlosen
Netzwerks durch Simulation effektiv nachzubilden. Jedes von einem Router
ausgesandte Datenpaket hat Auswirkungen auf andere Datenbertragun
gen, die gerade im Mesh stattfinden, da die Strreichweite eines ausgesand
ten Signals schwer zu berechnen ist. Um ein Mesh mit 1000 Meshroutern zu
simulieren, msste das Programm fr viele aufeinander folgende Zeitein
heiten von sehr kurzer Dauer jeweils berechnen, was gerade im gesamten
Netz passiert, und dabei alle signifikanten Wechselwirkungen bercksich
tigen. Dafr ist komplexe Software und eine leistungsfhigen Grorechen-
anlage ntig.
Eine brauchbare Simulationssoftware ist mglicherweise noch bedeutend
schwieriger zu entwickeln als ein wirklich gutes Routingprotokoll. Es liegt
daher nahe, die Ideen in einem tatschlich existierenden und genutzten
Netzwerk einem Praxistest unter realen Bedingungen zu unterziehen. So
knnen stichhaltige Ergebnisse erzielt werden.
Das MIT (Massachusetts Institute of Technology) gehrt mit dem Projekt
Roofnet zu den Ersten, die dem Problem durch praktisches Experimentie
ren in einem realen, von Anwendern genutzten Meshnetzwerk nachgegan
gen sind. Aus diesem Projekt sind das reaktive Routingprotokoll SrcRR (ei
ne DSR-Variante mit einer Metrik zur Linkbeurteilung, die den Link-State-
Algorithmus von Edsger W. Dijkstra verwendet) und die Firma Meraki her
vorgegangen13. Meraki vertreibt preiswerte Wireless Router auf der Basis
von Open-WRT mit installiertem OLSR und SrcRR. Bislang hat die Lsung
von Meraki in Europa kaum Verbreitung gefunden.
Die Entwicklung von Protokollen fr Meshnetzwerke ist nicht einmal an
satzweise abgeschlossen und bietet ein weites Feld fr Forschung und Ent
wicklung. Dabei werden unterschiedlichste Anstze verfolgt. In der akade
mischen Diskussion spielt vor allem die Skalierbarkeit eine Rolle - wie vie
le Netzwerkknoten sind mglich, bevor die vom Routingprotokoll erzeugte
Rechen- und Protokolldatenlast die Netznutzung zu sehr einschrnkt.

13 lohn Bicket et al., Architecture and Evaluation of an Unplanned 802.11b Mesh Net
work", h t t p : //pdos. c s a i l . m i t . e d u / p a p e rs/ ro o fn e t:m o b ic o m 0 5 / ro o fn et-m o -
b ic o m 0 5 .p d f
2 Meshrouting

Aus der - rein subjektiven - Sicht der Autorin ist diese Frage aber von un
tergeordneter Rolle. Denn der Datenverkehr ber eine drahtlose Multihop-
Route ist ohnehin nur bis zu einer bestimmten Anzahl von Sprngen sinn
voll und mglich. Deshalb sind berlegungen, in einem Mesh zigtausende
Router miteinander kommunizieren zu lassen, wenig praxisrelevant. Ent
scheidend ist viel eher, ob ein Routingprotokoll die gnstigsten Routen fin
det sowie schnell und richtig auf Vernderungen im Netzwerk reagiert.
Das ideale Protokoll sollte immer die bestmgliche Route zur Verfgung
stellen und bei einer Strung sofort reagieren. Trotz aller berechtigter Kritik
am greren Rechenleistungs- und Bandbreitenverbrauch sind proaktive
Protokolle in der Praxis von grerer Relevanz als reaktive Protokolle, bei
deren Entwicklung die Skalierbarkeit im Vordergrund steht. Erstere haben
den Vorteil zu funktionieren und sinnvolle Routen zu finden - whrend letz
tere zwar theoretisch skalieren, aber in der Realitt kaum etwas Sinnvolles
zu Stande bringen.
Die Resultate von reaktiven Routingprotokollen sind in der Praxis entweder
bedeutend schlechter oder sie enthalten wie das vom Roofnet-Projekt ver
wendete DSR/SrcRR proaktive Elemente, die ihre Skalierbarkeit zwar redu
zieren, sie aber gleichzeitig praxistauglich machen. Rein reaktive Protokolle
finden bestenfalls irgendeine Route, welche die krzeste Verbindung zwi
schen zwei Knoten darstellt. Soll dagegen die Qualitt der Verbindungen bei
der Routenfindung eine Rolle spielen, kommen die Protokollentwickler um
ein proaktives Messen der Verbindungsqualitt der einzelnen Linkstrecken
nicht herum.
Alle heute in der Praxis relevanten Routingprotokolle fr Meshnetze ver
wenden eine Metrik, die die Qualitt der Funkstrecken bercksichtigt. Ent
weder ist sie im Algorithmus inhrent wie bei B.A.T.M.A.N. oder sie wird ex
plizit gemessen und permanent berwacht wie bei der OLSR-Implementie-
rung von Freifunk, bei HSLS und SrcRR, der DSR-Implementierung des
MIT. Protokolle, die einfach die krzeste Verbindung zwischen zwei Punk
ten suchen, sind in der Praxis irrelevant.
Von praktischer Bedeutung fr freie Funknetze sind in Europa bislang OLSR
(Optimized Link State Routing) und B.A.T.M.A.N. (Better Approach to Mo
bile Ad-Hoc Networking) aus der Gruppe der proaktiven Protokolle. HSLS
(Hazy Sighted Link State Routing) aus der Gruppe der hybriden Protokolle
und das reaktive Srcr spielen vor allem in den USA eine Rolle. DSR, AODV,
DART, DYMO und ZRP sind dagegen (bislang) irrelevant.
HSLS ist theoretisch wegen seines hybriden Protokollaufbaus fr den Ein
satz in extrem groen Meshnetzwerken geeignet. Dieses Protokoll wird von
CuWIN (Champaign-Urbana Community Wireless Network), einer US-ame-
rikanischen Community-Netzwerk-Initiative implementiert und weiterent
wickelt, in Europa ist HSLS nicht verbreitet. Die grten HSLS-Meshes sind
mit 25 Knoten (Stand Oktober 2006 laut Chefentwickler David Young) ver

32
 2.2 Routingprotokolle fr drahtlose Netzwerke

gleichsweise klein. Bislang gibt es fr HSLS nur die Softwareimplementie

rung von CuWIN, die ausschlielich unter NetBSD arbeitet. CuWIN setzt
bei der Hardware auf PCs, die von einer Live-CD mit dem NetBSD-basierten
CuWIN-System booten. Dies drfte eine Ursache fr die geringe Verbrei
tung sein, da die in Community-Netzwerken verwendeten SoHO-Access-
points blicherweise Linux verwenden.
Fr das SrcRR-Protokoll gibt es bisher keine Implementierung in einer per-
formanten Programmiersprache wie C oder C++. Das MIT Roofnet ver
wendet die Software Click M odular Router, die einen Softwareinterpreter
fr Routinganweisungen darstellt. Routingablufe werden in der Hochspra
che des Click Modular Router als Programmmodule formuliert und diesem
beim Start zur Ausfhrung bergeben. Click ist eine hervorragende Um
gebung fr die Entwicklung von Netzwerkdesigns, da der Click Modular
Router sowohl auf Computern als auch im Netzwerksimulator NS2 lauf
fhig ist. Der fr Click geschriebene Protokollcode kann daher ohne Ver
nderungen im Simulator oder in einem realen Netzwerk getestet werden.
Diese Vorgehensweise ist fr die Entwickung von Protokollen sehr elegant,
bedingt aber auch einen erhhten Rechenaufwand beim Einsatz eines Rou
tingprotokolls, der Probleme mit der Skalierbarkeit in einem Mesh aufwirft,
wenn Consumer-Accesspoints wie der Linksys WRT54G beziehungsweise
WRT54GL eingesetzt werden. Dessen ungeachtet verkauft die Firma Meraki
kleine Meshrouter mit der Leistungsfhigkeit von SoHO-Gerten, in denen
sowohl Click als auch OLSR installiert ist.
OLSR und B.A.T.M.A.N. werden in den folgenden Kapiteln ausfhrlich vor
gestellt.

33
 Optimized Link State Routing

Optimized Link State Routing (OLSR) gehrt zu den proaktiven Routingpro

tokollen, die mit dem Ziel entwickelt wurden, den Zustand des gesamten
Netzwerks kontinuierlich zu erfassen. In jedem Meshknoten werden stn
dig Routen zu allen anderen erreichbaren Netzwerkknoten berechnet und
bereitgehalten.
Um das zu erreichen, prft jeder Knoten in regelmigen Intervallen durch
das Versenden und Empfangen von Hello-Nachrichten, ob sich Nachbarn
in direkter Funkreichweite befinden. Diese Informationen ber die lokalen
Nachbarschaftsverhltnisse - also welcher Knoten welche Nachbarn hat -
werden immer wieder ber das ganze Netzwerk verteilt. Jeder Knoten sam
melt sie in seiner eigenen Datenbank, die das gesamte Netzwerk abbildet.
Auf diese Datenbank wird beim Eintreffen jeder neuen Nachricht ber den
Zustand des Netzwerks der Shortest Path Algorithm angewendet, um die
krzeste Verbindung zwischen allen Netzwerkknoten zu berechnen.
Das Vorgehen entspricht einem klassischen Link-State-Algorithmus. Die
se erzeugen jedoch sehr hohe Rechenlast und viele Protokolldaten, die die
3 Optimized Link State Routing

Nutzbandbreite des Netzwerks reduzieren. Ziel von OLSR ist es, das klassi
sche Link-State-Routing im Hinblick auf Skalierbarkeit und Zuverlssigkeit
zu optimieren. Zu diesem Zweck setzen die OLSR-Entwickler auf die Erwei
terung des Link-State-Routings um sogenannte Multipoint-Relais, die das
Fluten des Netzwerks mit Topologieinformationen effektiver gestalten sol
len. Diese Technik wird im Abschnitt 3.2.2 nher errtert.

3.1 Entwicklungsgeschichte

OLSR wurde als Internet Draft RFC 3626 im Jahr 2003 von Mitarbeitern der
staatlichen franzsischen Forschungseinrichtung INRIA bei der IETF ein
gereicht. Es wird unter anderem von der US-Navy zur Kommunikation zwi
schen Kriegsschiffen eingesetzt. Fr OLSR nach RFC 3626 gibt es zahlreiche
unterschiedliche Implementierungen - unter anderem von der INRIA, der
US-Navy und 01sr.org.
Die OLSR-Implementierung von 01sr.org wurde von Andreas Toennesen im
Rahmen seiner Diplomarbeit an der Universitt Oslo erstellt. Sie ist Open
Source und steht unter der sehr liberalen BSD-Lizenz. Das OLSR-Projekt
von Andreas Toennesen hat sich in Zusammenarbeit mit den Freifunkern
im Laufe der Jahre weiterentwickelt. Die derzeitige OLSR-Variante hat zwar
ihre Wurzeln in RFC 3626, sie ist aber nicht mehr interoperabel zum Ent
wurf der INRIA. OLSR-Knoten, die nach RFC 3626 oder Freifunk-OLSR ar
beiten, ignorieren sich gegenseitig. Die von Olsr.org erhltliche Routing
software lsst sich aber so konfigurieren, dass sowohl ein RFC-konformes
Verhalten als auch der Betrieb in einem Freifunk-Mesh mglich ist.
Die von den Freifunkern modifizierte Variante von OLSR ist in freien Fun
knetzen mit bis zu 600 Knotenpunkten weltweit verbreitet. Genaue Studien
ber die Verbreitung gibt es nicht, es drfte jedoch die mit Abstand am
weitesten verbreitete Variante des OLSR-Routingprotokolls sein.
Im Jahr 2004 wurde die OLSR-Implementierung von Andreas Toennesen
von den Berliner Freifunkern auf der Konferenz Wizards of OS 3" in ei
nem Feldversuch mit Konferenzteilnehmern getestet und danach im Ber
liner Freifunknetz eingefhrt. Die Performance war jedoch bei den ersten
praktischen Tests keineswegs zufriedenstellend und nicht besser als die des
zuvor eingesetzten proaktiven Protokolls Mobilemesh. Die Routingtabelle
in den OLSR-Knoten baute sich nur sehr langsam auf und brach stndig
ganz oder teilweise zusammen. Die vom Protokoll gewhlten Routen wa
ren uerst instabil und hatten nur eine minimale nutzbare Bandbreite.
Es stellte sich heraus, dass die vorgeschlagenen Optimierungen bis zu die
sem Zeitpunkt nur theoretisch oder in Simultationsvcrfahren auf ihre Taug
lichkeit berprft worden waren. Innerhalb kurzer Zeit nahmen deshalb die
Freifunker umfangreiche Vernderungen an der Implementierung vor.

36
 3.2 Die OLSR-Implementierung von Olsr.org und Freifunk

3.2 Die OLSR-Implementierung von Olsr.org und

Freifunk
Klassische Link-State-Protokolle verwenden fr das Routen von Datenpa
keten stets den krzesten Pfad (Minimum Hop Count). Auch OLSR nach
RFC 3626 geht diesen Weg. Dadurch werden potentiell Routen ber schwa
che und instabile Funkstrecken bevorzugt, um die Anzahl der Sprnge ber
Zwischenstationen klein zu halten. Die Stabilitt und der Datendurchsatz
einer solchen Route ist nur in Ausnahmefllen brauchbar. Ein sinnvollerer
Algorithmus zur Bestimmung der Routen wurde bentigt, der den besten
Kompromiss aus Bandbreite und Routenlnge finden sollte. Diese Proble
matik fhrte zur Entwicklung des Linkquality-ETX-Algorithmus fr OLSR
bei Freifunk. Zwei Konzepte, die zur Optimierung des Link-State-Verfahrens
in OLSR dienen sollten, wurden ebenfalls unmittelbar nach dem misera
blen Resultat auf der Wizards of OS ber Bord geworfen: Hysterese und
Multipoint-Relais. Da man bei der Arbeit mit OLSR immer wieder auf diese
Konzepte stt, soll hier kurz darauf eingegangen werden.

3.2.1 Hysteresealgorithmus

Der Begriff Hysterese bedeutet so viel wie Beharrungsvermgen. Bei OLSR

verbirgt sich dahinter ein Mechanismus, der entscheidet, ob benachbarte
Meshknoten fr das Routen von Paketen berhaupt in Betracht gezogen
werden. Um allzu schwache Verbindungen zu vermeiden, werden benach
barte Router aus der Routing-Tabelle entfernt, wenn eine bestimmten An
zahl von erwarteten, aufeinanderfolgenden Hello-Paketen ausbleibt.
Fr die Entscheidung, ob ein benachbarter Router verwendet wird, wer
den ein unterer und ein oberer Schwellwert definiert. Empfngt ein OLSR-
Router beispielsweise von einem Nachbarn weniger als drei von zehn auf
einander folgenden Hello-Paketen, wird dieser aus der Routingtabelle ge
lscht (unterer Schwellwert der Hysterese). Erst wenn beispielsweise sie
ben von zehn aufeinander folgenden Hello-Paketen wieder eingetroffen
sind (oberer Schwell wert der Hysterese), wird der Nachbar wieder zur Rou
tingtabelle hinzugefgt. Wurde ein benachbarter Router aus der Routingta
belle gelscht und schafft dieser es nicht, mehr als sechs von zehn Hello-
Nachrichten erfolgreich zu bertragen, sorgt die Hysterese dafr, dass er
nicht mehr in die Routingtabelle aufgenommen wird.
Da Datenfunkstrecken immer wieder durch Strungen irgendwelcher Art
einige Sekunden aussetzen knnen, werden durch den Hysteresealgorith
mus benachbarte Router und die ber sie erreichbaren Nodes immer wie
der aus der Routingtabelle geworfen. Das ist verheerend fr Anwendungen
wie Webbrowser, Mailclients oder VoIP, die ber das Mesh Daten transpor
tieren wollen, da sie jedes Mal die Meldung vom Betriebssystem erhalten,

37
3 Optimized Link State Routing

dass keine Verbindung mglich ist. Die Programme geben dann selbst eine
Fehlermeldung aus und brechen die Verbindungsversuche ab, obwohl die
Verbindung nur kurz aussetzt.
OLSR verhlt sich dabei leider nicht opportunistisch - wenn es nur einen
einzigen Nachbarn gibt, um ein entferntes Ziel zu erreichen, ist es sehr
ungeschickt, diesen Router aus der Routingtabelle zu lschen. Besser ist es,
wenn das Routingprotokoll erkennt, dass es nur eine - wenn auch schlechte
- Verbindung hat, und diese so weit wie mglich nutzt. Der Hysteresealgo
rithmus tut das aber leider nicht.
Da OLSR bei der Routenfindung versucht, die Anzahl der Zwischenstatio
nen zu reduzieren, whlt es bevorzugt solche Nachbarn als Relaisstationen,
die ber instabile Verbindungen erreicht werden. Diese fallen dann stndig
wieder aus der Routingtabelle - einschlielich der anderen Meshknoten,
die nur ber diesen Nachbarn erreichbar waren. Die Folge sind in der Pra
xis Verbindungsabbrche, fortlaufende Fehlermeldungen und immer wie
der zusammenbrechende Routingtabellen. Der Hysteresealgorithmus von
OLSR wird deshalb von Freifunk nicht verwendet.

3.2.2 Multipoint-Relais

Link-State-Protokolle bertragen sehr viele Protokolldaten ins Netz, da

mit jeder Netzwerkknoten sich zeitnah ein einigermaen stimmiges Bild
ber den Zustand der Gesamttopologie machen kann. Um die Menge an
einzelnen Protokolldatentransfers zu reduzieren, haben sich die Erfinder
von OLSR mit den Multipoint-Relais eine Sparmanahme einfallen lassen:
Nicht jeder Knotenpunkt im Mesh soll Topologiedaten weiterreichen, son
dern nur jene Knotenpunkte, die fr das Fluten des Gesamtnetzes unbe
dingt notwendig sind. Dazu whlt ein OLSR-Router nur jene direkten Nach
barn (Single Hop) aus, die theoretisch notwendig sind, um alle mehr als
zwei Hops entfernte Nachbarn zu erreichen. Es wird also eine Untermenge
der direkten Nachbarn berechnet. Nur diese beauftragt ein OLSR-Knoten
damit, als Multipoint-Relais seine Topologieinformationen weiterzuleiten.
Fatalerweise wirft der OLSR-Hysteresemechanismus gerade diese Netzwerk
knoten besonders hufig aus der Routingtabelle, denn um die Untermenge
klein zu halten, werden diejenigen direkten Nachbarn bevorzugt, die relativ
weit entfernt und deshalb unzuverlssig sind.
Nun muss das OLSR-Protokoll die Topologieinformationen aber trotzdem
verbreiten, also andere Multipoint-Relais aushandeln, was Zeit kostet. Wh
renddessen bleiben Topologieinformationen aus, die Topologiedatenban
ken der Nodes werden nicht rechtzeitig synchronisiert. Hs kommt unter
den Routern zu Unstimmigkeiten ber den Pfad, auf dem die Datenpake
te weitergereicht werden sollen. Die Folge sind Kreisrouten: Datenpakete
irren herum, bis ihre Lebensdauer abgelaufen ist.

38
 3.2 Die OLSR-Implementierung von Olsr.org und Freifunk

3.2.3 Olsr.org - Aus den Fehlern lernen

Das Wechselspiel scheinbar guter Ideen sorgt in der Praxis also fr Chaos im
Netzwerk. Paradoxerweise arbeitet ein einfaches Linkstate-Protokoll ohne
Optimierungen besser als RFC 3626. Bis heute hlt die INRIA aber in ihren
weiteren IETF-Entwrfen zu OLSR an diesen Konzepten fest. Doch kaum
jemand wird heute auerhalb der wissenschaftlichen Forschung OLSR nach
RFC 3626 einsetzen, auch wenn das mit der Routingsoftware o ls r d von
01sr.org weiterhin mglich ist.
Eigentlich sollte man den modifizierten Routingdaemon nicht mehr als
OLSR bezeichnen, da er die wichtigsten Alleinstellungsmerkmale des Pro
tokolls, Hysterese und Multipoint-Relais, nicht verwendet. Trotzdem wird
sich die Bezeichnung auch weiterhin halten und unter Anwendern fr Ver
wirrung sorgen.
Der OLSR-Daemon o ls r d von 01sr.org ist lauffhig unter Linux, FreeBSD,
NetBSD, OpenBSD, Mac OS X, Windows 98 SE, Windows ME, Windows NT,
Windows 2000 und Windows XP. Nicht untersttzt werden Symbian und
Windows CE beziehungsweise Windows Mobile.
Es ist ein Dienstprogramm, das blicherweise im Hintergrund luft und
nur in der Liste der laufenden Prozesse in Erscheinung tritt. blicherwei
se wird o ls r d von der Kommandozeile gestartet. Fr Microsoft Windows
gibt es zur Bedienung und Konfiguration die grafische Benutzeroberflche
Olsr-Switch. Bei Routern mit der Freifunk-Firmware kann o ls r d von der
Weboberflche konfiguriert und beobachtet werden.

3.2.4 Funktionsweise des OLSR-Daemon

Beim Start des OLSR-Daemon beginnt dieser, ber alle zugeordneten Netz
werkkarten in einem definierten Intervall an unmittelbare Nachbarn Hello-
Nachrichten per Broadcast zu senden. Die Nachbarn schicken ihrerseits
selbst Hello-Nachrichten, die vom Olsrd empfangen werden, wenn die phy
sikalischen Bedingungen es zulassen. Dadurch lernt Olsrd, welche Nach
barn sich in unmittelbarer Funkreichweite befinden. Die Nachbarn erfah
ren ihrerseits von der Anwesenheit des neuen Nodes. In den Hello-Nach
richten teilen die Absender mit, in welchem Intervall sie Hello-Nachrichten
verschicken.
Der Freifunk-Olsrd fhrt anhand dieser Informationen eine Statistik dar
ber, wie viele Hello-Nachrichten von jedem Nachbarn innerhalb einer be
stimmten Zeit erwartet werden knnen und wie viele tatschlich eingetrof
fen sind. Olsrd fhrt diese Statistik ber eine definierte Anzahl von Paketen.
Ein Meshknoten lernt also: Ich habe drei Nachbarn A, B, C. Von Nachbar A
htte ich innerhalb der letzten 500 Sekunden 100 Helios empfangen ms
sen, aber nur 33 erhalten. Von Nachbar B bekam ich 90 Helios von 100, von

39
3 Optimized Link State Routing

Nachbar C 60 Helios von 100. Das Ergebnis seiner Statistik teilt der Olsrd
seinen Nachbarn mit, indem er diese Informationen stets aktuell in seine
Hello-Pakete schreibt. Die Nachbarn tun ihrerseits dasselbe.
Angenommen, es existiert noch ein Nachbar D, von dem gelegentlich Hello-
Pakete empfangen werden, aber dieser Nachbar D sieht unseren Olsrd nicht
- dann tauchen wir in seiner Statistik, die er dem Netz in seinen Helios
mitteilt, nicht auf. Wir wissen also, dass dieser Knoten uns nicht sieht.
Auf diese Weise erfahren alle Nachbarn nicht nur, wie gut sie andere sehen,
sondern auch, wie gut sie gesehen werden. Da der Olsrd nun wei, wie
hufig, statistisch gesehen, eine bertragung von einem Nachbarn zu ihm
klappt (Link-Qualitt, abgekrzt LQ), beziehungsweise eine bertragung
von ihm zu dem Nachbarn (Nachbar-Link-Qualitt, NLQ), kann Olsrd die
Wahrscheinlichkeit ausrechnen, mit der ein Paket, welches eine Rundreise
zum Nachbarn und wieder zurck antritt, wieder eintrifft.
Diese Wahrscheinlichkeit - wie viele Pakete mssen statistisch eine Rund
reise antreten, damit ein Paket wieder erfolgreich zurckkommt - wird in
Anlehnung an eine Studie am Massachusetts Institute of Technology (MIT)
ber eine sinnvolle Metrik zur Beurteilung von Routen fr drahtlose Netz
werke ETX (Expected Transmission Count). Die Berechnung ist einfach. Es
ist der Kehrwert der Round-Trip-Wahrscheinlichkeit:
E T X = l / ( L Q * NLQ)
Im Idealfall hat eine Funkstrecke einen ETX-Wert von 1,00. Das heit, jedes
ausgesendete IP-Paket kommt auf seiner Rundreise auch wieder zurck.
Ein ETX-Wert von 4 bedeutet, dass vier Pakete verschickt werden mssen,
damit ein Paket wieder zurckkommt. Bei einem unbrauchbaren Funklink,
der nur in einer Richtung funktioniert, ist der ETX-Wert unendlich.
Mit den ETX-Werten kann Olsrd bei Routingentscheidungen durch einfa
ches Addieren der ETX-Metriken die gnstigste Route bestimmen. Das Ver
fahren bercksichtigt, dass jede Zwischenstation auf einer Route Bandbrei
te und Geschwindigkeit kostet. Der Olsrd muss abwgen zwischen Routen
mit vielen Hops, auf der jede Funkstrecke mit gutem Durchsatz arbeitet,
und Routen ber einen krzeren Pfad, wo auf berdehnten Linkstrecken
nur wenige Datenpakete durchkommen. Der beste Pfad ist der Mittelweg
zwischen beiden Extremen, da sich bei jeder bertragung ber ein Funkre
lais die Bandbreite deutlich reduziert, wenn ein Meshrouter nur mit einer
WLAN-Karte arbeitet (siehe Abschnitt 2.1.1). Andererseits sind berdehnte
Funkstrecken nutzlos, selbst wenn noch eine Verbindung nachweisbar ist.

3.2.5 Topologieinformationen und Dijkstra-Algorithmus

Der Olsrd hat nun ber Hello-Broadcasts von der Existenz direkter Nach
barn erfahren und kennt auch die Qualitt der Funkverbindungen (LQl

40
 3.2 Die OLSR-Implementierung von Olsr.org und Freifunk

NLQ/ETX-Werte). Diese Topologieinformationen werden in einem IP-Paket

verschickt, mit dem in einem bestimmten Intervall das ganze Meshnetz ge
flutet wird. Bei Olsrd heit ein Datenpaket mit Topologieinformationen TC-
Message (Topology Control Message). Anders als die Hello-Nachrichten, die
nur lokal bertragen werden, werden Topologienachrichten von allen an
deren Knoten im Netz sofort weitergereicht. Jeder Knoten merkt sich den
Inhalt der herumschwirrenden Topologienachrichten und trgt sie zu einer
eigenen groen Datenbank - einer Landkarte des Meshnetzes - zusam
men. Auf diese Graphen wird dann der Link-State-Algorithmus von Dijk-
stra angewendet. Freifunk-Olsrd sucht anders als viele andere Link-State-
Protokolle nicht nach der geringsten Anzahl von Hops, sondern nach dem
gnstigsten (kleinsten) ETX-Gesamtwert fr jede Route.

Topologienachrichten und Protokolloverhead

Eine berschlagsrechnung zeigt, dass ein klassisches Link-State-Verfahren

fr ein drahtloses Computernetzwerk wegen der CPU-Last und der vom
Protokoll erzeugten Datenmenge mit wachsender Knotenanzahl schnell an
seine Grenzen stt. Wenn jeder Knoten alle fnf Sekunden eine neue To
pologienachricht losschickt und damit eine ganze Lawine von Datentrans
fers im gesamten Netz auslst, wird das schon bei 200 Knoten problema
tisch, da die Anzahl der Nachrichten quadratisch von der Knotenzahl ab
hngt:
TC-Nachrichten/s = Knoten2 /TC-Intervall
Statistisch wird so alle 25 Millisekunden ein anderer Netzteilnehmer eine
neue Topologienachricht auf die Reise schicken und kann damit theore
tisch eine Lawine von bis zu 199 Wiederholungen lostreten. Jede eintref
fende Topologienachricht mit neuen Informationen verursacht dabei ein
erneutes Durchrechnen des gesamten Netzwerkgraphen in jeder Maschine.
Es knnen theoretisch bei 200 Knoten im Mesh und einem TC-Intervall von
fnf Sekunden bis zu 8000 Topologienachrichtenbertragungen pro Sekun
de anfallen. Bei 400 Knoten knnten es bereits bis zu 32 000 TC-Broadcasts
pro Sekunde sein.
In der Praxis ist der Protokolloverhead (die durch OLSR produzierte Daten
menge) wesentlich kleiner als in der Theorie. Da alle Protokollnachrichten
verbindungslos als Broadcast versendet werden, werden die Daten von den
Empfngern nicht erneut angefordert, wenn sie wegen Kollisionen oder
Interferenzen auf der Funkstrecke beschdigt werden. Beschdigte Pake
te werden einfach verworfen und sind verloren. Bei jedem Hop von Node
zu Node tritt deshalb ein nicht unerheblicher Schwund auf. Nach ein paar
Hops ist die Wahrscheinlichkeit einer erfolgreichen bertragung ber eine
Kette von Broadcasts nur noch gering und trgt erheblich dazu bei, dass
der Protokolloverhead nicht unmittelbar ins Uferlose wchst.

41
3 Optimized Link State Routing

Um Bandbreite zu sparen, werden TC-Nachrichten von OLSR nicht als ein

zelne kleine Pakete verschickt, sondern mit anderen TC-Nachrichten und
weiteren Protokollinformationen zu greren IP-Paketen gebndelt, da mit
jedem Paket auch noch weitere Informationen wie IP-Header, UDP-Header,
MAC-Adresse, Broadcast-Adresse als Overhead mit bertragen werden ms
sen. Durch grere Pakete reduziert sich der IP-Overhead gegenber den zu
bertragenden Protokolldaten. Trotzdem ist die von OLSR erzeugte Daten
menge gro und verbraucht einen nicht unbetrchtlichen Teil der Band
breite, der nicht mehr fr die Nutzlast des Netzwerks zur Verfgung steht.
Kurze TC-Intervalle scheinen sich daher per se in greren Meshnetzwer-
ken zu verbieten. Andererseits ist aber ein hufiger und redundanter Ab
gleich der Datenbank in den Knoten unbedingt erforderlich, da es sonst
beim Routen zu Unstimmigkeiten ber den Verlauf des gnstigsten Pfads
kommt (Routing-Loops). In IP-Paketen befindet sich ein Zhler (Time-To-
Live, TTL), dessen Wert bei jedem weiteren Transportschritt um 1 herun
tergezhlt wird. Wird der Wert der TTL Null, wird das Paket verworfen und
eine Meldung an den Absender geschickt. Auf diese Weise wird verhindert,
dass verirrte Pakete bis in alle Ewigkeit im Netz herumsausen.
Das kann man sehr gut in einem Meshnetzwerk mit p in g beobachten, in
dem man eine entfernte Maschine anpingt. Taucht die Meldung Time to
l iv e exceeded auf, ist das Ping-Paket so lange im Kreis herumgelaufen,
bis der darin enthaltene TTL-Zhler bei Null angekommen ist.

Der Fisheye-Algorithmus

Der Multipoint-Mechanismus in RFC 3626 mildert kaum das potenzier

te Wachstum der Topologieinformationen in greren Meshnetzwerken.
Selbst wenn nur jeder zweite oder dritte Knotenpunkt an der Weiterleitung
von Topologienachrichten beteiligt ist, kann das Wachstum der TC-Pakete
bei steigender Knotenanzahl mit Multipoint-Relais kaum wirkungsvoll be
grenzt werden. Auch zu dieser Problematik ist den Freifunkern etwas einge
fallen: der Fisheye-Algorithmus. Das Prinzip ist ganz einfach: Die TTL (auch
TC-Messages enthalten eine TTL) wird bei den meisten TC-Broadcasts auf
sehr kleine Werte zwischen 1 und 3 gesetzt. Auf diese Weise wird erreicht,
dass diese TC-Nachrichten nur ein bis drei Hops weit durch das Mesh rei
sen, bis die TTL abgelaufen ist und die Nachricht verworfen wird.
Nur selten wird eine TC-Message mit einer groen TTL auf die Reise ge
schickt, die sich ber das gesamte Netzwerk ausbreiten kann - wenn sie
nicht unterwegs verloren geht. Topologienachrichten mit kleinen TTL-Wer-
ten werden sehr oft geschickt, sogar fter als Hello-Nachrichten. Dadurch
wird erreicht, dass nderungen der ETX-Werte durch gerade eintreffende
oder verlorengegangene Helios mit einer gewissen Redundanz den lokalen
Nachbarn mitgeteilt werden. Auf diese Weise knnen Routing-Loops weit
gehend verhindert werden.

42
 3.2 Die OLSR-Implementierung von Olsr.org und Freifunk

Kreisrouten treten nur zwischen Netzwerkknoten auf, die nur wenige Hops
voneinander entfernt liegen. Es ist unwahrscheinlich, dass auf einer Kreis-
route ein IP-Paket erst drei Hops nach Norden, drei Hops nach Osten, drei
Hops nach Sden und dann wieder drei Hops nach Westen reist. Meistens
sind insgesamt nur zwei oder drei Knoten an einer Kreisroute beteiligt. Ent
scheidend fr einen reibungslosen Transport der Nutzlast ist, dass benach
barte Knoten sich untereinander ber ihr Bild der Netztopologie einig sind.
Solange auf einer Route die Richtung stimmt und sich die benachbarten
Router ber den lokalen Verlauf einig sind, bewegt sich das IP-Paket auf
sein Ziel zu. Dabei nhert es sich Nodes, die umso besser ber die Netzto
pologie Bescheid wissen, je nher sie dem Zielpunkt liegen.
Wenn man ein Postpaket in ein Dorf in Indien schickt, muss man nicht wis
sen, welchen Weg der indische Paketbote mit seinem Fahrrad einschlgt,
oder welche Farbe sein Fahrrad hat. Der Paketbote vor Ort kennt den Weg
viel besser als der Absender im fernen Europa. Wir mssen nur wissen,
wo das nchstgelegene Postamt liegt, das Sendungen nach Asien annimmt.
Ebenso verhlt es sich im Meshnetz. Ein Node muss nur wissen, welchem
Nachbarn er zweckmigerweise das IP-Paket zum Weitertransport anver
traut. Die Entscheidung, was dieser Nachbarknoten mit dem IP-Paket an
stellt, trifft dieser selbststndig und unabhngig von der Sicht der anderen
Knoten.
Topologieinformationen von weit entfernten Knoten sind mglicherweise
schon sehr alt, da auf dem Weg durch das Meshnetz viele TC-Nachrichten
verlorengehen. Aktuellere Informationen, die eine falsche Sicht ber das
andere Ende des Netzwerks korrigieren knnen, kommen nur selten oder
versptet an. Das macht aber nichts, da ein Node nicht vorgeben muss, wel
chen genauen Weg ein Paket am anderen Ende des Netzwerkes zu nehmen
hat. Wegen der hohen Dynamik des Netzwerks knnte der Router das auch
gar nicht.
Es gengt also, wenn ein Knoten nur eine unscharfe Sicht von der Topo
logie des Netzes in der Entfernung hat. Er muss ber die Topologie in der
Entfernung nur wissen, wer in welcher Richtung vorhanden ist, aber nicht
wo genau. Daher kann sich OLSR das permanente Durchrechnen des kom
pletten Graphen wegen jeder einzelnen TC-Message aus der Ferne sparen.
Deshalb gengt es, wenn nur selten TC-Messages aus der Ferne auftauchen.
ber lokale Vernderungen sollte ein Meshknoten umso genauer Bescheid
wissen.
Der Fisheye-Mechanismus enthlt daher zwei Komponenten: Zum einen
werden TC-Nachrichten bei ihrer Ausbreitung durch die kleinen TTL-Werte
berwiegend auf einen lokalen Rahmen beschrnkt. Zum anderen lsen
nur TC-Nachrichten von Nodes in der Nhe eine Neuberechnung des Gra
phen aus. Im aktuellen Olsrd wird nur jede 13. TC-Message mit einer TTL
fr die weite Welt versehen. Bei einem Emissionsintervall von fnf Se
kunden wird nur alle 65 Sekunden das ganze Netz von einem Node geflu

43
3 Optimized Link State Routing

tet. Damit schrumpfen Netzwerklast und Rechenlast ganz erheblich, ohne

die Stabilitt des Netzwerks zu gefhrden. Bei einer Netzwerkgre von 500
Knoten knnen Nodes die TC-Messages alle zwei bis drei Sekunden auf die
Reise schicken.
Auch der Rechenaufwand zur Neuberechnung des Netzwerkgraphen steigt
mit der Anzahl der Knoten potenziert an. Bei 500 Knoten nimmt ein einma
liges Durchrechnen der Topologiedatenbank bei der geringen Rechenleis
tung eines SoHO-Routers bereits Sekunden in Anspruch. Das Durchrech
nen des Graphen beim Eintreffen jeder neuen TC-Message ist auf einem
kleinen Computer dann nicht mehr mglich.
Im Freifunk-Olsrd kann ein festes Intervall eingegeben werden, das an
gibt, wie oft die Gesamttopologie durchgerechnet wird. Das ist leider kei
ne saubere Verfahrensweise, da damit wieder Probleme wie Routingloops
auftreten knnen. An dieser Stelle kann nur noch ein verndertes Dijkstra-
Verfahren helfen, welches auch die Netzwerktopologie nur noch bis zu ei
ner bestimmten Anzahl Hops aus lokaler Sicht durchrechnet. Dieses Verfah
ren ist allerdings im Moment noch nicht implementiert und wartet darauf
programmiert zu werden.

3.3 Praxis mit Olsrd

Olsrd ist selbstverstndlich in der Freifunk-Firmware enthalten. Fr Open-
Wrt, Windows und Mac OS X gibt es Installationspakete. Doch die meisten
Funktionen bietet die Linux-Variante von Olsrd. Der Funktionsumfang des
Olsrd kann ber Bibliotheken, die zur Laufzeit in das Programm geladen
werden (Plugins) erweitert werden. Da Olsrd berwiegend unter Linux ent
wickelt und eingesetzt wird, funktionieren nur unter Linux alle Programm
funktionen ohne Einschrnkungen.

3.3.1 Installation unter Linux, Mac OS X und *BSD

Soll Olsrd auf einem Laptop oder Desktop-PC mit Linux oder einer Unix-
Variante wie FreeBSD installiert werden, ist es empfehlenswert, sich die ak
tuellen Programmsourcen von der Webseite olsr.org herunterzuladen und
selbst zu kompilieren. Debian GNU/Linux oder Ubuntu haben zwar Olsr-
Pakete, die ber das Paketmanagementsystem installiert werden knnen,
diese sind jedoch blicherweise veraltet.
Die Entwickler von Olsr.org haben bislang nur selten eine neue offizielle
Verffentlichung der Olsr-Software herausgegeben. Die jeweils letzte offizi
elle Programmversion enthlt mitunter lngere Zeit Fehler, die in der Ent
wicklerversion bereits behoben sind. Sollte die letzte offizielle Programm
verffentlichung schon einige Zeit zurck liegen, ist es wahrscheinlich bes-

44
 3.3 Praxis mit Olsrd

ser, eine aktuelle Entwicklerversion zu verwenden. Der aktuelle Entwick

lungsstand des Olsrd ist leider nicht als komprimiertes Dateiarchiv zum
Download erhltlich.

Installation ber die Programmsoureen unter Linux und *BSD

Die Quelltexte der Software sollten deshalb aus dem Versionsmanagement

system von 01sr.org heruntergeladen werden. Dazu muss auf dem lokalen
Rechner die passende Software fr das Versionsmanagementsystem CVS
(Concurrent Versions System) installiert sein.
Dazu wird in einem Kommandozeileninterface der folgende Befehl ausge
fhrt, um sich mit dem Server zu verbinden.

cvs - d :p s e r v e r :a n o n y m o u s o l s r d .c v s .s o u r c e f o r g e .n e t :/ c v s r o o t / o l s r d login

Wenn der Server nach einem Passwort fragt, gengt es, die Eingabetaste
zu drcken. Der nun folgende Befehl startet den Download. Genauer: Das
lokale Verzeichnis wird mit dem Inhalt des Servers synchronisiert.

c vs -z3 - d :p s e r v e r :a n o n y m o u s S o l s r d .c v s .s o u r c e f o r g e .n e t :/c v s r o o t / o l s r d \
co o l s r d - c u r r e n t

CVS legt nun in dem Verzeichnis, in dem der Befehl gestartet wurde, ein
neues Unterverzeichnis namens o l s r d -c u r r e n t an. Soll spter auf einen
neueren Stand der Software aktualisiert werden, bertrgt CVS nur noch
die Vernderungen, wenn es wieder im gleichen Verzeichnis gestartet wird
wie zuvor.
Es ist nicht garantiert, dass der aktuelle Stand der Entwicklung aus dem
CVS funktioniert. Meistens ist das jedoch der Fall. Sollte der Inhalt des CVS
einmal nicht funktionieren, kann man auf die nchste Version warten, die
innerhalb kurzer Zeit verfgbar sein drfte.
Ist auf der lokalen Maschine eine funktionsfhige Umgebung zum Kompi
lieren von C-Programmen vorhanden, ist die Installation relativ einfach, da
die Software keine besonderen Paketabhngigkeiten aufweist. Ist man auf
der Kommandozeile in das Verzeichnis mit den Olsr-Quelltexten gewech
selt, gengen die beiden Befehle make und make i n s t a l l . Fr letzteren
bentigt man Administratorrechte.
Fr Olsrd existieren einige interessante Erweiterungen (Plugins), auf die
man nicht verzichten sollte. Die Quelltexte dafr sind zwar im Paket dabei,
aber die Plugins mssen getrennt kompiliert und installiert werden. Da
zu in das Unterverzeichnis l i b im Sourceverzeichnis o ls r d - c u r r e n t mit
dem Befehl cd l i b wechseln, dann die Befehle make und make i n s t a l l
noch einmal ausfhren.
3 Optimized Link State Routing

Installation auf Ma OS X

Auf der Downloadseite von 01sr.org befindet sich ein Link zu vorkompilier
ten Olsr-Installationspaketen fr Mac OS X, die von Maximilian Thumfart
zusammengestellt werden1. Es werden sowohl Intel-Macs und PPC-Macs
untersttzt. Die Mac-Version des Olsrd ist in der Regel auf einem aktuel
len Stand. Grere Vernderungen im Routingdaemon flieen innerhalb
kurzer Zeit auch in die Mac-Version ein. Natrlich knnen ambitionierte
Mac-Anwender auch selbst kompilieren.
Die Installationspakete von Maximilian Thumfart enthalten eine zu Frei
funk kompatible Konfigurationsdatei fr den OLSR-Daemon. Nach der In
stallation kann der Olsrd in einem Terminalfenster ber den Befehl sudo
o lsrd gestartet werden.

3.3.2 Installation unter Windows

Eigentlich ist Olsrd ein reines Kommandozeilenprogramm. Jedoch existiert

mit dem Olsr-Switch exklusiv fr Windows ein grafisches Frontend, das Be
dienung und Konfiguration mit der Maus ermglicht.
Auf01sr.org befindet sich die Datei o l s r - 0 . 4 . 1 0 - s e t u p . exe unter der Ru
brik Downloads. Ein komfortables Installationsprogramm fhrt per Maus
klick die notwendigen Schritte durch und fordert anschlieend zum ein
maligen Neustart auf. Nach der Installation befinden sich die Programme
im Verzeichnis c:\Program m e\olsr.org. Leider wurde bis zur Druckle
gung des Buches diese Version des Olsrd fr Windows nicht mehr weiter
entwickelt. Das graphische Frontend Olsr-Switch gibt sich in der Men
leiste flschlicherweise als Programmversion 0.4.9 aus, der Olsr-Daemon
entspricht aber der Version 0.4.10. Auch diese Version ist leider veraltet
und enthlt schon seit lngerer Zeit bekannte Fehler. Auch der Fischaugen-
Algorithmus ist nicht vorhanden.
Die Rechenlast ist deutlich hher als bei aktuellen Versionen von Olsrd.
Da ein PC ber wesentlich mehr Rechenleistung verfgt als ein SoHO-
Router, ist das jedoch keine gravierende Einschrnkung. Auf sehr langsa
men Windows-Rechnern (Pentium II oder III) sollte jedoch auf den Kom
fort des grafischen Frontends nach der Konfiguration verzichtet werden, da
das Frontend im Betrieb des Olsrd einiges an Rechenleistung frisst. Besser
ist es, den Olsrd auf der Kommandozeile zu starten.
Die gravierendste Schwachstelle der veralteten Programmversion ist aber,
dass Olsrd abstrzt, wenn Routen mit mehr als 31 Hops im Netzwerk Vor
kommen. Dieses Problem tritt natrlich nur in sehr groen Meshnetzwer-
ken auf. Im Freifunk-Mesh in Berlin fhrt dieser Fehler zum hufigen Ab
strzen des Programms.

1 http://www.fernsehsofa.de/olsr/

46
 3.3 Praxis mit Olsrd |

Vor dem ersten Start des Olsrd muss dieser mit dem Olsr-Switch konfigu
riert werden. Dabei muss unbedingt die Checkbox Offer Internet Gateway
deaktiviert werden, wenn nicht wirklich ein Internet-Gateway ber die
sen PC angeboten werden soll. Andernfalls wird der Windows-PC fr den
Internetverkehr benachbarter Meshteilnehmer und zum Schwarzen Loch:
Es wird ein Internetzugang offeriert, in dem die Internetanfragen anderer
Netznutzer verschwinden.
Wenn der PC tatschlich als Internet-Gateway dienen soll, ist es nicht rat
sam, das mit der Windows-Version zu realisieren. Fr Olsrd unter Linux
gibt es ein dynamisches Gateway-Plugin. Dieses Plugin prft, ob der Inter
netzugang wirklich funktioniert, und stellt das Annoncieren eines Internet-
Gateways bei einer Fehlfunktion ein. Die Windows-Version berprft das
Funktionieren des Internetzugangs nicht.
Die im Screenshot 3.1 gezeigte Konfiguration kann als Ausgangsbasis ber
nommen werden. Das verwendete Interface kann von der Abbildung ab
weichen.

n i n im Abbildung 3.1:
Settings | Output | Nodes | Route | Grundkonfiguration
mit Olsr-Switch
Q IF04 104 130 300

HNA hold

TC ntetval TChoW.

TC redundancy |2 MPR covetage

Debug level r* Enabte hysteresis

j ------ Scaling |

I* Enabte ETX Ir* quality

f ' la MPR selection only

< fot MPR selection and rou

3pen | Save | Reset |

Start | ___________| E* |

Sind alle Einstellungen vorgenommen, sollte die Konfiguration ber die

Schaltflche Save gespeichert werden, bevor zum ersten Mal gestartet wird.
Die Default-Konfiguration kann man dabei getrost berschreiben. Eine ak
tive Firewall meldet beim ersten Start, dass Olsr-Switch den Port 698 ver
wenden mchte. Das muss natrlich zugelassen werden. ber die Reiter
Output, Nodes und Routes kann die Funktion beobachtet werden. Tauchen
keine Nodes und Routes auf, kann ein Blick unter dem Men Output hel
fen, wenn das Debug-Level grer oder gleich 1 gesetzt wurde. Befindet
3 Optimized Link State Routing

man sich in einem greren Mesh, kann man den Output kaum lesen, da
bei der Flut von Meldungen die Ausgabe nicht mehr stillsteht. Das Durch
rauschen der Anzeige ist ein gutes Zeichen, so lange da nicht seitenwei
se die Meldung erscheint: R eceived P a ck e t from Non-Sym-Neighbor.
Dann stimmt meistens etwas mit der WLAN-Karte nicht oder die anderen
Meshknoten empfangen das lokale Gert nicht.
Besser und ressourcenschonender kann der Status des Olsrd durch das
OLSR-Plugin Httpinfo in einem Webbrowser beobachtet werden. Dazu wird
mit einem Editor die Konfigurationsdatei um die notwendigen Eintragun
gen fr die Nutzung des Plugins erweitert. Informationen zur Einrichtung
von Httpinfo finden sich in Abschnitt 3.4.2.
Einmal eingerichtet, kann Olsrd auf der Kommandozeile aus dem Verzeich
nis gestartet werden, in dem der Daemon installiert wurde. Die zu verwen
dende Konfigurationsdatei muss ber die Option - f angegeben werden.

olsrd.exe -f Default.olsr

Da der OLSR-Daemon sich vollstndig ber die Konfigurationsdatei anpas

sen lsst, ist die Angabe weiterer Startoptionen nicht notwendig. Ledig
lich wenn etwas nicht funktioniert wie gewnscht, kann das Debuglevel
beim Programmaufruf bergeben werden. Die Konfigurationsdatei muss
stets zuerst angegeben werden, sonst bricht der Daemon den Start mit ei
ner Fehlermeldung ab.

olsrd.exe -f Default.olsr -d 1

Eben weil Olsr-Switch es Anfngern besonders einfach macht, durch einen

falschen Mausklick oder eine falsch konfigurierte Firewall das Netz emp
findlich zu stren, ist die Untersttzung fr Windows bei den Freifunkern
nicht besonders beliebt und hinkt hinterher. Das soll nicht heien, dass
o ls r d - 0 .4 .1 0 unter Windows nicht zufriedenstellend funktioniert. Tech
nisch ist es allerdings auf dem Stand von Ende 2005 und eignet sich deshalb
nur fr Meshnetze, die nicht allzu gro sind.
Klappt die Verbindung zum Mesh nicht, sollte man die WLAN-Einstellun-
gen, die Firewall, IP-Adresse, Netzwerkmaske und Broadcastadresse ber
prfen. Das richtige Interface muss im Olsr-Switch ausgewhlt werden. Oft
verursachen die Treiber oder Firmware der WLAN-Karten Probleme. Eine
solide Funktionsweise des Ad-Hoc-Modus ist bei WLAN-Karten fr PCs lei
der eher die Ausnahme. Nheres zu dieser Problemstellung ist in Abschnitt
5.4 zu lesen.

3.3.3 Konfigurationsdatei des Olsrd

Vor dem ersten Start von Olsrd muss die Konfigurationsdatei editiert wer
den. Normalerweise werden dem Daemon keine Optionen beim Start ber-
 3.3 Praxis mit Olsrd

geben. Das macht bei der Vielzahl von mglichen Optionen und Einstell-
mglichkeiten keinen Sinn. Lediglich die Angabe eines Debuglevels grer
oder gleich 1 ist zur Fehlersuche sinnvoll.
Das Laufzeitverhalten des Olsr-Routingdaemons wird unter allen Betriebs
systemen von der Konfigurationsdatei o ls r d .c o n f gesteuert, diese wird
normalerweise im Verzeichnis / e tc installiert. Unter Windows sucht Olsrd
im Windows-Systemordner nach der Datei c:\ w in d o w s\ o lsrd .con f oder
unter Windows NT c:\W IN N T\olsrd.conf. Leider wird grundstzlich im
mer noch RFC 3626 als Grundeinstellung installiert. Im Quelltextverzeich
nis des Olsrd findet man im Unterverzeichnis f i l e s die Datei o ls r d . conf .
d e f a u l t . l q - f ish ey e, die manuell nach / etc kopiert und in o ls r d . conf
umbenannt werden muss.
Alle kritischen Einstellungen, welche das Verhalten von OLSR vorgeben,
sind in dieser Konfigurationsdatei bereits vorgenommen. Die Konfigura
tionsdatei sollte in allen Routern in einem Mesh bis auf kleinere Anpassun
gen und Sonderfunktionen gleich sein. Im einfachsten Fall mssen lediglich
die Netzwerkinterfaces eingetragen werden, auf denen der Olsr-Daemon
routen soll. Durch die Verwendung einer Standardkonfiguration erschliet
sich jedoch nicht das volle Potenzial des Olsrd. So ist zum Verwenden der
Plugins etwas Handarbeit notwendig. Leider ist die o ls r d . conf alles ande
re als selbsterklrend. Wenn man sich nicht auf eine fertige Meshlsung wie
die Freifunk-Firmware verlassen will oder eigene Wnsche und Vorstellun
gen hat, muss man sich in die Untiefen der Konfigurationsdatei begeben.
Die im Folgenden vorgeteilte Konfigurationsdatei enthlt unkommentiert
alle wichtigen Konfigurationsparamenter. Die einzelnen Komponenten wer
den im anschlieend folgenden Abschnitt detailliert erklrt. Diese Datei ist
eine typische Beispielkonfiguration fr ein Meshnetzwerk aus berwiegend
stationren Knoten, wie sie von Community-Netzwerken wie Freifunk ver
wendet wird. Eine ausfhrliche, in deutscher Sprache kommentierte Konfi
gurationsdatei finden Sie im Internet2 .
Das Editieren von Konfigurationsdateien darf nur mit einem Texteditor wie
Notepad unter Windows oder nano oder v i geschehen, da Textverarbei
tungsprogramme unerwnschte Formatierungszeichen hinzufgen, welche
die Datei fr den Daemon unlesbar machen. Unter Windows mssen die
Konfigurationsdateien mit Notepad im Format UTF-8 gespeichert werden,
sonst tritt der gleiche Effekt auf.
Wie unter Unix/Linux in vielen Konfigurationsdateien blich, signalisiert
ein Rautenzeichen am Anfang der Zeile einen Kommentar.

2 h t t p ://downloads.open-mesh.net/misc/olsr/olsr.c o n f .example-german-
comments

49
| 3 Optimized Link State Routing

# olsr.org OLSR Daemon Konfigurationsdatei

DebugLevel 1
LinkQualityFishEye 1
LinkQualityDijkstraLimit 3 6.0
IpVersion 4
ClearScreen yes

Hna4
{
10.193.198.0 255.255.255.0
10.140.140.254 255.255.255.255
}

Hna6
{
# Internet Gateway:
# 0
# Weitere Eintrge:
# fecO:2200:106:: 48
}

AllowNoInt yes
TosValue 16
Willingness 4

IpcConnect
{
MaxConnections 1
}

UseHysteresis no
LinkQualityLevel 2
LinkQualityWinSize 100
Pollrate 0.05
TcRedundancy 2
MprCoverage 7

LoadPlugin "olsrd_dyn_gw.so.0.4"
{
PIParam "Interval" "40"
PIParam "Ping" "141.1.1.1"
}

Interface "ethO" "athO" "wlanO" "eth2"

{
# Ip4Broadcast 255.255.255.255
# Ip6AddrType site-local
# Ip6MulticastSite ff05::ll
# Ip6MulticastGlobal ff0e::l
Hellolnterval 2.0

50
 3.3 Praxis mit Olsrd

HelloValidityTime 200.0
Tclnterval 0.5
TcValidityTime 200.0
Midlnterval 5.0
MidValidityTime 200.0
Hnalnterval 5.0
HnaValidityTime 200.0
# LinkQualityMult 192.168.0.1 0.5
# LinkQualityMult default 0.7
# LinkQualityMult 10.143.143.143 1.0
# LinkQualityMult 10.143.143.144 1.0
}

Interface "tunO"
{
Hellolnterval 50 .0
HelloValidityTime 2 0 0 0 .0
Tclnterval 50 .0
TcValidityTime 2000.0
Midlnterval 50 .0
MidValidityTime 1 0 0 0 .0
Hnalnterval 50 .0
HnaValidityTime 1000 .0

Debug l e v e l
Dieser Wert (von 0 bis 9) gibt an, welche Informationen der Daemon
auf das Terminal ausgibt. Bei Null gibt er keine Informationen aus
und geht sofort in den Hintergrund. In einem groen Netzwerk wer
den bei Werten grer Null so viele Informationen ausgegeben, dass
die Ausgabe einfach durchrauscht. Man sollte sie dann ber eine Pipe
in eine Datei umleiten, um sie sich in Ruhe ansehen zu knnen.
Noch besser ist es, das Olsr-Plugin Httpinfo zu laden und sich die
Ausgaben von Olsrd bequem in einem Webbrowser anzeigen zu las
sen. Debugging braucht eine betrchtliche Menge Rechenleistung,
wenn das Netz einigermaen gro ist. Fr kleine Embedded-Systeme
sollte der Wert auf 0 gesetzt werden.

L in k Q u a lity F ish E y e
Soll der Fischaugenmechanismus verwendet werden? 0 = aus, 1 = an.

L in k Q u a lity D ijk s tr a L im it
Diese Einstellung verhindert, dass jede eintreffende neue Topologie
nachricht ein erneutes Durchrechnen der gesamten Netzwerkdaten
bank auslst. Das ist nicht ntig, wenn einige Sprnge weiter eine
Vernderung auftritt. Allerdings sollten Vernderungen in der Topo
logie bei benachbarten Knoten unmittelbar bercksichtigt werden.

51
3 Optimized Link State Routing

Hier mssen zwei Werte eingegeben werden. Der erste Wert - eine
Ganzzahl - gibt die Anzahl der Sprnge an. Ein Wert von 2 bedeu
tet, dass nur neue Topologieinformationen, die von direkten Nach
barn (Single-Hop) oder Nachbarn zweiter Ordnung (Two-Hop) stam
men, ein Durchrechnen der Routingtabelle auslsen. Wird der Wert
auf Null gesetzt, lst keine eintreffende Topologienachricht eine Neu
berechnung aus. Der zweite Wert, eine Zahl mit einer Kommastelle,
gibt an, in welchem Intervall die Routingtabelle neu berechnet wird,
wenn der erste Wert fr den Hopcount auf Null gesetzt ist.

IpV ersion
Version des Internetprotokolls. 4 = IPv4, 6 = IPv6.

C learScreen
Soll die Anzeige im Terminal jedes Mal neu aufgebaut werden, wenn
eine Zustandsnderung eintritt? yes/no

Hna4
HNA-IPv4-Routen (Host Network Announcement): ber eine HNA-
Nachricht kann ein OLSR-Knoten mitteilen, dass er ein Gateway zu
anderen Subnetzwerken oder Hosts ist. Auf diese Weise kann man
z. B. Gerte ohne OLSR (VoIP-Telefone, PDAs) in das Meshnetz ein
binden, ohne NAT zu verwenden. In den Gerten ohne Olsrd wird
dann dieser OLSR-Router, der den HNA ankndigt, als Gateway an
gegeben (entweder von Hand oder ber DHCP).
Dabei sollten die Administratoren der Meshknoten sich unbedingt
darber verstndigen, wer welche Subnetzwerkadressen benutzt be
ziehungsweise ankndigt. Das Olsr-Plugin Httpinfo listet alle HNA-
Ankndigungen im Mesh unter der URL h tt p :/ / lo c a l h o s t :8080/
nodes auf. Ein prfender Blick in die bereits existierenden HNAs
kann nicht schaden, um Kollisionen zu vermeiden, bevor ein neues
HNA eingerichtet wird. Ein beliebtes Problem ist, dass ein Meshrou-
ter das gleiche Subnetzwerk per HNA ankndigt, das auch von einem
anderen Olsr-Router im Mesh auf seinem Ethernetport verwendet
wird. Vor allem die bekannten Klasse-C-Netzwerke 192.168.0.0 und
192.168.1.0 sollte man unbedingt vermeiden. Das kann nicht gut ge
hen!
Stattdessen unbedingt Subnetzadressen lokal verwenden beziehungs
weise ankndigen, die nicht von den OLSR-Routern von Lieschen
Mller und Otto Normalverbraucher benutzt werden. Verwenden Lies
chen und Otto am Ethernetport ihrer OLSR-Router die Subnetzadres
se 192.168.1.0/24, kann Lieschen von ihrem PC nicht mehr auf ihren
Router zugreifen, wenn Otto eine HNA zu seinem Subnetz 192.168.
1.0/24 ankndigt - obwohl sie direkt per Kabel mit ihrem Router ver
bunden ist. Lieschens OLSR-Router trgt wegen Ottos HNA einen be
nachbarten OLSR-Router als Gateway zu Ottos kollidierendem Sub-

52
 3.3 Praxis mit Olsrd

netz ein. Jetzt kann Lieschen von ihrem PC ber LAN nicht mehr ih
ren Router erreichen, da dieser seine IP-Pakete fr Lieschens PC ber
das Mesh an Ottos Router schickt.
Fr das Ankndigen eines Internet-Gateways (0.0.0.0/0) sollte im
mer das dynamische Gateway-Plugin verwendet werden. Sonst hat
das Mesh bei einem Ausfall des Internetanschlusses immer wieder
schwarze Lcher, in dem Pakete zum Internet verschwinden. Schlgt
man diese Warnung in den Wind, stehen bald viele rgerliche Netz
teilnehmer vor der Tr und beschweren sich.
Mehrere Eintrge sind mglich, einer Netzadresse folgt immer eine
Netzmaske. Der erste Eintrag im Listing routet zu einem Klasse-C-
Netz, der zweite zu einem einzelnen Node.

Hna6
HNA-IPv6-Routen.

AllowNoInt
Soll der Olsrd auch dann weiterlaufen, wenn keine Netzwerkkarte zur
Verfgung steht? (yes oder no) Das kann fr PCMCIA/USB-Gerte
oder andere Hotplug-fhige Hardware hilfreich sein.

TosValue
TOS (Type of Service) fr den IP-Header der Protokollpakete. Der
Standardwert ist 16.

W illin g n e s s
Die fest eingestellte Bereitschaft, fr andere Knoten Pakete weiter-
zurouten (0-7). Falls nicht angegeben, wird der Wert bei Gerten
mit Stromsparmechanismen (ACPI, APM) dynamisch dem Ladezu-
stand/Stromsparmodus angepasst, wenn diese Informationen verfg
bar sind.

IpcC onnect
Diese Option erlaubt es einem Olsr-Frontend wie Olsr-Switch auf den
Daemon zuzugreifen. M axConnections gibt die Anzahl der erlaubten
Verbindungen an.

U se H y ste re sis
Soll die Hysteresefunktion verwendet werden? (yes oder no) Die Ant
wort heit: Nein. Hysterese ist nicht kompatibel zu LQ-ETX. Vorsicht:
Hysterese wird grundstzlich verwendet, wenn dieser Eintrag aus
kommentiert ist!

L in k Q u a lity L ev e l
Link Quality Extension (LQ-ETX) wird bei einem Wert von 0 nicht ver
wendet, bei 1 verwendet, um Multipoint-Relais zu bestimmen, beim
3 Optimized Link State Routing

Wert 2 bestimmt sie Multipoint-Relais und Routen. Ist diese Einstel

lung nicht gesetzt, wird LQ-ETX nicht verwendet. Das ist keine gute
Idee. Hier muss 2 stehen.

LinkQualityW inSize
Link-Qualitt-Fenstergre zur Berechnung von ETX - Anzahl der
Hello-Pakete fr die ETX/LQ-Statistik. Nicht zu klein whlen, solan
ge nicht hohe Mobilitt der Netzwerkknoten bercksichtigt werden
muss. Je grer die Fenstergre, desto ruhiger und stabiler - aber
auch trger - reagiert das Netz auf Vernderungen.

P o llr a te
Die Pollrate in Sekunden gibt an, wie oft Olsrd den Empfangspuffer
des Betriebssystems nach eingetroffenen OLSR-Nachrichten abfragt.
Ein hufigeres berprfen erzeugt eine hhere CPU-Last. Allerdings
sollte der Wert nicht zu gro eingestellt werden, da es bei einem
hohen Aufkommen von OLSR-Paketen zu Pufferberlufen im Emp
fangspuffer des Linuxkernels kommen kann. Der Kernel speichert nur
eine bestimmte Datenmenge von eingehenden UDP-Paketen.
Werden diese UDP-Pakete nicht rechtzeitig von Olsrd abgeholt, ver
wirft sie der Kernel bei einem Pufferberlauf. Die Puffergre ist im
Linuxkernel einstellbar, so dass man mit langen Pollintervallen expe
rimentieren kann, um die CPU-Last zu reduzieren. Es gibt eine Gr
undeinstellung fr die Puffergre und einen Maximalwert (rmem_
def a u lt und rmem.max). Der folgende - auerhalb dieser Konfigura
tionsdatei - auszufhrende Befehl setzt die Puffergre auf 128 Kilo
byte, dieses Kommando kann von Hand auf der Kommandozeile (in
einem Terminal) mit Administratorrechten gesetzt werden:

echo 131072 > / p r o c / s y s / n e t / c o r e / r m e m _ d e f a u l t

Gelesen werden kann die Puffergre mit dem Befehl:

cat / p r o c / s y s / n e t / c o r e / r m e m _ d e f a u l t

Hat man eine Einstellung gefunden, die bei jedem Neustart des Be
triebssystems gesetzt werden soll, kann man ein Skript anlegen, wel
ches beim Start des Betriebssystems oder beim Starten von Olsrd au
tomatisch ausgefhrt wird.

TcRedundancy
Informationen, die mit Topologienachrichten versendet werden. Hier
an der Redundanz zu sparen, wirkt sich negativ auf die Stabilitt aus.
Der Maximalwert ist 2 - alle Nachbarn mitteilen. Dieser Eintrag muss
unbedingt gesetzt werden, sonst wird bei fehlendem Eintrag Null ver
wendet, und es gibt keine Redundanz.

54
 3.3 Praxis mit Olsrd

MprCoverage
Abdeckung mit Multipoint-Relais. Gibt an, wie viele Nachbarn ein
Knoten zu Multipoint-Relais bestimmt. Hier wird ein hoher Wert ge
setzt, so dass die Funktion praktisch alle Nachbarn verwendet. Durch
einen Fehler im Code kommt es aber zu Abstrzen, wenn ein Wert
grer 7 gesetzt wird. Auch dieser Wert muss unbedingt angegeben
sein, sonst wird 1 verwendet.

LoadPlugin
Olsrd-Plugins, die geladen werden sollen. Hier muss ein absoluter
Pfad angegeben werden, wenn die Plugins nicht in / lib / oder /usr/
l i b oder in einem Verzeichnis gespeichert wurden, auf das die Va
riable LD_LIBRARY_PATHoder / e tc/ ld .so .ca ch e v erw eise n . Doku
mentationen zu den Plugins finden sich im Sourcecode-Verzeichnis
des Olsrd unter lib / P lu gin n am e. Den Plugins knnen/mssen mit
unter Plugin-Parameter als PlParam mitgegeben werden. Die Plugin-
Parameter stehen in einem von geschweiften Klammern eingegrenz
ten Konfigurationsblock zum Plugin.

PlParam " I n t e r v a l "

Das dynamische Gateway-Plugin olsrd _dyn_gw . s o . 0 .4 in der Kon
figurationsdatei prft durch Versenden von ICMP-Daten (Ping) Rich
tung Internet in einem bestimmten Intervall, ob der Zugang funktio
niert.
Hier wird innherhalb des Konfigurationsblocks das Prf-Intervall an
gegeben. Wird das Intervall nicht definiert, geschieht die berpr
fung alle 5 Sekunden.

PlParam "P in g "

Hier werden die IP-Adressen von Rechnern im Internet angegeben,
die vom dynamischen Gateway-Plugin auf ihre Erreichbarkeit geprft
werden. Hier sollte man mehrere Eintrge vornehmen, damit nicht
wegen eines Ausfalls der Gegenstelle das Gateway seine Funktion un
gewollt einstellt. Wenn mehrere IPv4-Adressen angegeben werden,
werden diese in absteigender Reihenfolge per Ping getestet. Ist der
erste Test erfolgreich, wird die zweite Adresse nicht geprft.

In te rfa c e
An dieser Stelle beginnt die Interface-Sektion. Hier werden die Inter
faces angegeben, auf denen der OLSR-Daemon aktiv wird. Die Konfi
gurationsparameter des Interfaces sind in einem Konfigurationsblock
zusammengefasst, der von geschweiften Klammern eingefasst wird.
Mehrere Interfaces knnen einem Konfigurationsblock zugeordnet
werden, wenn die Konfigurationsparameter gleich sind. Werden Op
tionen ausgelassen, verwendet OLSR die Default-Einstellungen, was
in der Regel nicht sinnvoll ist.

55
3 Optimized Link State Routing

Zunchst werden die Interfaces angegeben, die diesem Konfigurati

onsblock zugeordnet werden.

Interface "ethO" "athO" "wlanO" "eth2"

{

Ip4Broadcast
Die verwendete IPv4-Broadcast-Adresse. Ein sinnvolles Beispiel w
re 255.255.255.255 - diese schliet alle mglichen Netzadressen ein.
Dann knnen sich alle Nodes auch ber Subnetzgrenzen hinweg se
hen. Das heit: Verwendet ein Mesh die Netzwerkadresse 10.0.0.0/8,
werden auch Nodes mit einer IP-Adresse auerhalb des Subnetzes
(beispielsweise 172.29.200.0/24) ber Hostrouten geroutet. Das funk
tioniert jedoch nur unter Linux und wenn alle Knoten im Mesh die
Broadcastadresse 255.255.255.255 verwenden. Falls nicht angegeben,
wird die Broadcastadresse der Interfaces verwendet. Im Normalfall
auskommentiert lassen.

Ip6AddrType
Verwendeter IPv6-Adressbereich ( s i t e - l o c a l oder g lo b al).

Ip 6 M u ltic a s tS ite
IPv6-Multicast-Adresse, wenn der Adressbereich s i t e - l o c a l ist. De
fault ist f f 0 5 : : 15.

Ip 6M u lticastG lo b al
IPv6-Multicast-Adresse, wenn der Adressbereich g lo b a l ist. Default
ist f f 0 e : : 1.

H e llo ln te r v a l
Emissionsintervall fr Hello-Nachrichten in Sekunden (alle Sekun
denangaben sind Fliekommawerte). Werden fr OLSR-Nachrichten
keine Werte gesetzt, verwendet der Daemon die wenig sinnvollen
RFC-Werte.

H elloV alidityTim e
Gltigkeitsdauer der Hello-Nachrichten in Sekunden.

T c ln te rv a l
Topologienachrichtenintervall in Sekunden. Falls das Mesh mehr als
100 Knoten hat, sollte das Intervall fr TC-Messages vergrert wer
den. Ein TCInterval-Wert von 0.5 Sekunden kann nur verwendet wer
den, wenn das Netz sehr klein oder der Fischaugen-Mechanismus
(LinkQ ualityFishEye) aktiviert ist. Andernfalls erstickt das Netz in
einer Schwemme von Topologienachrichten.
 3.3 Praxis mit Olsrd I

T cV a lid ity T im e
Gltigkeitsdauer der Topologienachrichten in Sekunden.

M id ln te rv a l
MID-Nachrichten-Intervall in Sekunden. MID-Nachrichten geben be
kannt, ob ein Knoten mehrere Interfaces hat, auf denen Olsrd routet.

M idV alidityTim e
Gltigkeitsdauer von MID-Nachrichten in Sekunden. Es schadet in
keiner Weise, hier einen sehr hohen Wert anzugeben.

H n a ln terv a l
HNA-Nachrichten-Intervall in Sekunden.

H n aV alid ityT ime

Gltigkeitsdauer von HNA-Nachrichten in Sekunden. Darf ruhig sehr
lang sein, damit ein Gateway nicht wegen Paketverlusts aus der Rou
tingtabelle fllt.

Lin kQ u alityM u lt
Soll eine bestimmte Route manuell bevorzugt oder ignoriert werden,
knnen hier ETX-Link-Quality-Werte ber einen Multiplikator beein
flusst werden. In diesem Beispiel wrde die Route ber 192.168.0.1
schlechter erscheinen als sie ist. Durch das Multiplizieren mit dem
Faktor 0.5 wird der LinkQuality-Wert klein (schlecht) und der ETX-
Wert entsprechend hoch.
Auch der umgekehrte Weg ist mglich. Hier werden alle Linkstrecken
um den Faktor 0.7 schlechter gerechnet. Im Folgenden werden zwei
bestimmte Routen besser gestellt:

L i n k Q u a l i t y M u l t d e f a u l t 0.7
L i n k Q u a l i t y M u l t 1 0 . 1 4 3 . 1 4 3 . 1 4 3 1.0
L i n k Q u a l i t y M u l t 1 0 . 1 4 3 . 1 4 3 . 1 4 4 1.0

An dieser Stelle ist nun eine gltige Konfigurationsdatei abgeschlossen.

Falls weitere Interfaces mit abweichenden Parametern konfiguriert werden
sollen, knnen weitere Interface-Blcke hinzugefgt werden. In der Konfi
gurationsdatei folgt noch die Konfiguration eines Tunnel-Interface. Tunnel
sind beliebt zur Kopplung von isolierten kleineren OLSR-Netzen, aber auch
als Backbone innerhalb eines stadtweiten Netzes. Auf dem Tunnel-Interface
kann Olsrd sehr langsam und bandbreitenschonend konfiguriert werden.

3.3.4 Erster Start des Daemon

Ist die Konfigurationsdatei fertig editiert, gengt auf der Kommandozeile

die Ausfhrung des Befehls o ls r d mit Administratorrechten. Optional -
3 Optimized Link State Routing

zumal beim ersten Start nach umfangreichen Arbeiten an der Konfiguration

- kann der Daemon unter Angabe eines Debuglevels gestartet werden:

olsrd -d 1

Der OLSR-Daemon ist bereits bei Debuglevel 1 sehr gesprchig und liefert
eine Flut von Informationen, wenn die Routensuche funktioniert. Hhere
Debuglevel sind nur fr Softwareentwickler interessant, die tatschlich In
formationen ber die internen Ablufe des Daemon gewinnen wollen, um
Programmierfehler zu finden. Die Ausgaben des Olsrd rauschen - auer
bei sehr kleinen Meshnetzen - schon bei Debuglevel 1 im Terminalfenster
durch und erzeugen eine hohe Systemlast.
Funktioniert das Routing nicht oder ist ein Fehler in der Konfigurationsda
tei aufgetreten (Syntaxfehler in der Konfigurationsdatei, nicht vorhandenes
oder nicht konfiguriertes Netzwerkinterface), erzeugt der Daemon dagegen
bei einem schweren Fehler wenige Ausgaben, die man problemlos beob
achten kann. Schlgt dagegen lediglich das Laden eines Plugins fehl, oder
funktioniert von mehreren Interfaces eines nicht, luft die Ausgabe viel zu
schnell durch den Bildschirm, um noch lesbar zu sein. In diesem Fall kann
man die Ausgabe des Daemon in eine Datei schreiben oder sie ber eine
Pipe einem Pager wie l e s s bergeben:

olsrd -d 1 2 >Scl |cat > / t m p / o l s r d .log

oder eben

olsrd -d 1 2>&1 |less

Auer zur Fehlersuche sind die Debuglevel des Olsrd deshalb kaum geeig
net, um Auskunft ber den Zustand des Meshroutings zu erhalten. Mchte
man Informationen ber den Zustand des Mesh beobachten, ist es emp
fehlenswert, das Httpinfo-Plugin des Olsrd anzuwenden, das im Abschnitt
3.4.2 beschrieben wird.
Wurde der OLSR-Daemon mit Debuglevel 1 in einem kleinen Mesh gestar
tet, sollte die Ausgabe, wenn alles funktioniert, wie folgt aussehen (Topolo
gieliste gekrzt):

--- 21:57:54-15 ------------------------------------------------------- LINKS

IP address hyst LQ lost total NLQ ETX

104.130.30.1 0.000 0.600 40 100 0.3 1 0 5.38
104.130.30.29 0.000 0.920 8 100 0.9 1 0 1.19

--- 21:57:54.15 --------------------------------------------------- NEIGHBORS

 3.3 Praxis mit Olsrd I

IP a d d r e s s LQ NLQ SY M MPR MPRS will

104.130.30.29 0.9 2 0 0.910 YES YES NO 7
104.130.30.1 0.600 0.310 YES YES NO 3

--- 2 1 : 5 7 : 5 4 . 0 2 1 5 6 6 4 4 ---------------------------- TWO-HOP NEIGHBORS

IP a d d r (2-hop) IP a d d r (1-hop) TLQ

104 .1 3 0 . 1 . 2 4 3 104.130.30.1 0 .070
104.130.1.67 104 .130.30.1 0 .021
104.192.192.199 104 .130.30.1 0 .000
104 .1 3 0 . 3 0 . 2 9 104 .130.30.1 0 .149
104 .130.30.1 104.130.30.29 0 .675

--- 2 1 : 5 7 : 5 4 . 1 5 ---------------------------------------------------- TOPOLOGY

Sou:ree IP a d d r Dest IP ad d r LQ ILQ ETX

104 .129. 105 . 1 104 .129 . 105.2 0 .886 0 .949 1 .19
104 . 129 .105 .1 104 .129 .108.3 0 .220 0 .047 96 .76
104 .129 .105 .1 104 .129 .105 . 10 0.333 0 .929 3.23
104 .129. 105 .1 104 .129 .0.190 0 .918 0 .929 1 . 17

Die Ausgabe unter der Rubrik LINKS listet alle direkten Nachbarn auf. Der
Wert fr h y st ist immer Null, da die Hysterese ausgeschaltet ist. LQ (Link-
Quality) gibt das Verhltnis von verlorenen zu empfangenen Hello-Paketen
an, die von dem angegebenen Nachbarn gesendet werden. Der Nachbar
knoten mit der IP-Adresse 104.30.30.22 hat beispielsweise 60 von 100 Hello-
Nachrichten erfolgreich an unseren OLSR-Router verschickt. Der Wert NLQ
(Neighbor Link Quality) gibt dessen Statistik ber die von unserem Knoten
verschickten Hello-Nachrichten an.
Die Rubrik N eighbors enthlt zustzliche Informationen ber die direkten
Nachbarn, die allerdings weitgehend redundant sind. Die Angabe SYM zeigt
an, ob die Verbindung zum Nachbarn symmetrisch ist, d. h. in beide Rich
tungen funktioniert. Diese Information ist auch anhand der LQ/NLQ-Werte
ersichtlich. Solange weder der LQ- noch der NLQ-Wert Null ist, gilt ein
Nachbar als symmetrisch. Die Spalte MPR gibt an, ob es sich bei dem Nach
barn um ein Multipoint-Relais handelt. MPRS gibt an, ob sich der Nachbar
knoten unseren Router als Multipoint-Relais ausgesucht hat. W ill zeigt die
Willingness (Bereitschaft) eines Knoten an, fremde Datenpakete zu routen.
T0P0L0GY listet die LQ/NLQ-Werte von allen direkten Funklinks zwischen
allen Knoten im gesamten Mesh auf. Diese Liste wird deshalb schnell sehr
lang, wenn das Mesh mehr als nur ein paar Knoten hat.
Der Olsrd trgt nun fr smtliche Meshknoten im Netzwerk, zu denen sich
eine Route berechnen lsst, eine Hostroute in die Routingtabelle des Be
triebssystems ein. Dabei erscheint jeweils einer der direkten Nachbarn als
Gateway zu dem entfernten Knoten. Unter Linux kann die Routingtabelle
beispielsweise mit dem Befehl ro u te -n ausgegeben und berprft wer
den, der folgende, hier auszugsweise wiedergegebene Ausgabe erzeugt:
3 Optimized Link State Routing

I B M - R 5 0 :/tmp# route -n
Kernel IP routing table
D e s t i nation Gat e w a y Genmask F l a g s M e t r i e Ref Use Iface

104.19.19.18 1 0 4.130.30.29 255.255.255.255 UGH 15 0 0 athO

104.129.0.35 104.130.30.29 255.255.255.255 UGH 8 0 0 athO
104.19.19.19 1 0 4 .130.30.29 255.255.255.255 UGH 14 0 0 athO
104.131.83.2 1 0 4 .130.30.29 255.255.255.255 UGH 5 0 0 athO
104.129.1.1 104.130.30.29 255.255.255.255 UGH 6 0 0 athO
104.129.0.1 104.130.30.29 255.255.255.255 UGH 6 0 0 athO
104.130.30.1 104.130.30.29 255.255.255.255 UGH 2 0 0 athO
104.130.30.29 0.0.0.0 255.255.255.255 UH 1 0 0 athO
192.168.212.0 0.0.0.0 255.255.255.0 U 0 0 0 ethl
104.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 athO
0.0.0.0 1 0 4 .130.30.29 0.0.0.0 UG 5 0 0 athO

In der Spalte D e stin a tio n sind die erreichbaren Ziele aufgelistet. Host-
routen sind erkennbar an der Genmask (Netzmaske) 255.255.255.255 und
am Flag H fr Hostroute. Die Route mit der Destination 0.0.0.0 und der
Netzmaske 0.0.0.0 in der untersten Zeile ist eine Defaultroute. Sie wird ver
wendet fr alle Ziele, die nicht in einer weiter oben liegenden Zeile der
Routingtabelle gelistet sind. Eine Defaultroute kann - muss aber nicht - ins
Internet fhren. Von OLSR-Routern, die eine Route mit dem Ziel 0.0.0.0 an
kndigen, wird jedoch erwartet, dass sie Internetzugang bereitstellen. Der
OLSR-Daemon setzt fr jede Route eine Metrik, die der Anzahl von Hops
bis zum Ziel entspricht. Im Fall der aufgelisteten Defaultroute bedeutet das,
dass das Internet-Gateway im Mesh fnf Hops entfernt liegt.
Ob beispielsweise der Internetzugang funktioniert, kann geprft werden,
indem eine bekannte IP-Adresse eines Computers im Internet mit dem Be
fehl ping getestet wird.

I B M - R 5 0 :/tmp# ping 141.1.1.1

PING 141.1.1.1 (141.1.1.1) 56(84) b y t e s of data.
64 bytes from 141.1.1.1: i c mp_seq=l ttl= 5 1 t i m e = 1 1 6 7 ms
64 bytes from 141.1.1.1: i c mp_seq=2 ttl= 5 1 t i m e = 2 8 8 ms
64 bytes from 141.1.1.1: icmp_seq=3 ttl= 5 1 t i m e = 9 3 . 5 ms

Natrlich kann statt der IP-Nummer auch der Domainname einer bekann
ten Domain im WWW angegeben werden. Wenn eine IP-Adresse mit Ping
erreicht werden kann, aber ein Ping zu einem Domainnamen nicht gelingt,
ist entweder kein Domain-Name-Server im System konfiguriert oder dieser
ist aus dem Mesh nicht erreichbar. In einem OLSR-Mesh gibt es keine Auto
konfiguration von Meshknoten mit IP-Adresse, Netzmaske, Domain-Name-
Server-Adresse ber das DHCP-Protokoll. Diese Konfigurationsparameter
mssen manuell im Computer eingetragen werden.
Um die Eintragung des Gateways in das System muss man sich dagegen
nicht kmmern, diese Aufgabe wird vom OLSR-Daemon bernommen. Im
 3.4 Wichtige Plugins fr Olsrd I

Gegenteil: Ein Default-Gateway sollte nicht eingetragen sein, wenn man

ber das Mesh ins Internet geroutet werden mchte. Findet das Betriebs
system mehrere Gatewayeintrge zur Destination 0.0.0.0 vor, wird das Gate
way mit der kleinsten Metrik verwendet. Ein manuell eingetragenes Default-
Gateway hat normalerweise eine Metrik von Null, ein Default-Gateway von
OLSR hat eine Metrik von mindestens Eins, da OLSR mindestens einen Hop
zum Gateway bentigt. In diesem Fall wird deshalb immer das manuell ein
getragene Gateway verwendet. Ist dieses nicht erreichbar, funktioniert der
Internetzugang ber das Mesh nicht.
Der Verlauf einer Route lsst sich mit dem Befehl

t r a c e r o u t e -n Zieladresse

unter Linux oder

tracert Z i e l a d r e s s e

unter Windows berprfen. Die Option -n bewirkt, dass tr a c e r o u t e die

IP-Adressen der Zwischenstation ausgibt und nicht versucht, deren Do
mainnamen herauszufinden, was bedeutend schneller geht.

fftrace

Zur Analyse von Olsr-Routen gibt es das Programm fftrace (Freifunk-Trace-

route), das fr das berwachen und Verfolgen von OLSR-Routen entwi
ckelt wurde, fftrace zeigt ETX-Werte an und kommt besser als mtr oder
tr a c e r o u t e mit dem hufigen Umschalten von Routen zurecht5.

3.4 Wichtige Plugins fr Olsrd

Die Funktionalitt von Olsrd lsst sich durch Plugins erweitern. Das dy
namische Gateway-Plugin wurde im vorherigen Abschnitt bereits erwhnt.
Mehrere LoadPlugin-Blcke lassen sich in der Konfigurationsdatei /etc/
o ls r d .c o n f nacheinander einfgen. Sind die Plugins nicht in einem Ver
zeichnis installiert, in dem der Olsrd beim Start nach installierten Plugins
sucht, muss ein absoluter Dateipfad angegeben werden.
Unter Windows sucht Olsrd in dem Verzeichnis, aus dem der Daemon ge
startet wurde, nach den Plugins. Alternativ knnen diese Dateien (sie ha
ben die Endung . d l l ) in den Systemordner c : \Windows\system32 kopiert
werden.
Kann ein Plugin nicht geladen werden, gibt der Daemon eine Warnmeldung
aus, wenn er mit einem Debuglevel grer oder gleich 1 aufgerufen wurde.
3 h t t p ://dovnloads.open-mesh.net/fftrace

61
3 Optimized Link State Routing

3.4.1 DotDraw

Dieses Plugin gibt ber TCP-Port 2004 Topologieinformationen aus. Mit

diesen Daten lassen sich zwei- und dreidimensionale Topologiegrafiken er
zeugen. Die ausgegebenen Daten sind zu den Visualisierungsprogrammen
Graphviz und olsrs3d kompatibel.
Zum Einrichten des Plugins muss die Datei / e tc / o ls r d . conf geringfgig
erweitert werden. Das Plugin kann ohne zustzliche Parameter gestartet
werden; es gengt, einen leeren Block mit zwei geschweiften Klammern
anzuhngen. In den Grundeinstellungen kann nur lokal auf die Ausgabe
des Plugins zugegriffen werden. Wer die Ausgaben von einem entfernten
Computer abrufen will, muss den Zugriff von dessen IP-Adresse explizit
erlauben. Unter Linux:

LoadPlugin " o l s r d _ d o t _ d r a w .s o .0 .3 "

{
P I Param "accept" "192.168.100.1"
}

und unter Windows:

LoadPlugin " o l s r d _ d o t _ d r a w .d l 1"

{
}

Ob das Plugin ordnungsgem arbeitet, kann mit einem Connect per Telnet
oder ber einen Webbrowser getestet werden.

telnet IP - A d r e s s e - d e s - O l s r - R o u t e r s 2004

Telnet sollte nun lesbare Informationen in ASCII-Text ausgeben. In einem

Webbrowser kann einfach die URL der Maschine mit dem DotDraw-Plugin
zusammen mit der Portnummer geffnet werden, also beispielsweise
h t t p : / / lo c a lh o s t:2004
Meist arbeitet das DotDraw-Plugin auf einem kleinen Meshrouter, von dem
ein leistungsfhigerer Rechner ber Telnet die Daten abholt und daraus die
Topologiegrafiken generiert. Viele Freifunk-Communities bieten kontinu
ierlich aktualisierte Topologiegrafiken auf ihren Webseiten an.

Toplogievisualisierung

Es gibt ein Perlscript4, das automatisch die Informationen von DotDraw ab

holt und daraus zweidimensionale Topologiegraphen erzeugt. Dazu ms
sen die Programme Graphviz, Perl und ImageMagick (optional) installiert

4 http://meshcube.org/nylon/utils/olsr-topology-view.pl

62
 3.4 Wichtige Plugins fr Olsrd I

sein. Das Skript erzeugt Grafikdateien in unterschiedlichen Formaten wie

JPEG, PNG, Scalable Vector Graphics, PostScript usw.

perl o l s r - t o p o l o g y - v i e w . p l -- s e r v e r I P - A d r e s s e d e s O l s r - R o u t e r s - - n o s h o w

Abbildung 3.2:
Zweidimensionale
\1.00 \1.00 Topologievisualisie
rung mit
1.00 0064.32^12^ DotDraw6

vHNA ll.OOX

J 10.64.0.241 '^ ("10.64.1.33 - < ^ 1 0 6 4 . 0 . 2 1 0 / 2 55.255.25 5.255/

W / V l
0 9 / 1 .0 9 \ l.2 7 jl.27 (1.19/1.13 N 16 6 7 \i 7T77 HNA ~

Optisch ansprechender ist die rotierende dreidimensionale Visualisierung

ber das Tool olsrs3d7 von Simon Wunderlich und Marek Lindner. 01srs3d
ist eine Applikation fr den dreidimensionalen Desktop s3d auf der Basis
von OpenGL. Zur Visualisierung eines Mesh mit mehr als ein paar Dutzend
Knotenpunkten wird ein schneller Rechner mit einer leistungsfhigen Gra
fikkarte bentigt.

3.4.2 Httpinfo

Wird dieses Plugin geladen, startet Olsrd einen eigenen, minimalistischen

Webserver und zeigt detaillierte Informationen ber den Status des Dae-
mon auf mehreren HTML-Seiten an. Auf diese Weise kann die Funktion
des Routers mit einem Browser lokal und ber das Netzwerk beobachtet
werden.
Die Formatierung der generierten HTML-Seiten ist leider (noch) nicht per
fekt, die Beschriftung der einzelnen Spalten ist verschoben.
Aus Sicherheitsgrnden kann der Zugriff nur von bestimmten Rechnern
oder Netzwerken auf den Webserver erlaubt werden, da dieser potentiell
ein Einfallstor fr Angriffe gegen den Router darstellt. In der Beispielkonfi
guration ist nur der lokale Zugriff auf den Webserver erlaubt. Weitere Konfi
gurationsbeispiele fr den Zugriff von Host 80.23.53.22, Netzwerk 10.0.0.0/8
und Netzwerk 192.168.0.0/24 sind auskommentiert.

6 Ausschnitt der Grafik http://www.the-mesh.org/dotdraw/olsr_dot_draw.jpg.

7 http://s3d.berlios.de/

63
3 Optimized Link State Routing

Abbildung 3.3:

HttPinfo olsr.org OLSR daemon 4^

Einrichtung unter Linux:

L oad P l u g i n " o l s r d _ h t t p i n f o .s o .O .1"

{
# Die Portnummer, auf d e r d e r W e b s e r v e r a r b e i t e t
PlP a r a m "port" "8080"
# In der G r u n d e i n s t e l l u n g ist n u r 1 2 7 . 0 . 0 . 1
# (lokale M a s c h i n e auf d e r O l s r d luft)
# der Zugriff auf de n W e b s e r v e r e r l a u b t .
P l Param "Host" "127.0.0.1"

# Wei t e r e K n oten k n n e n h i n z u g e f g t w e r d e n .
# PlPa r a m "Host" "10. 0 . 0 . 5 "

# Der Zugriff k a n n a u c h fr g a n z e A d r e s s b e r e i c h e
# g e stattet werden. M e h r e r e E i n t r g e s i n d erlaubt.

# PlPa r a m "Net" "192.168.1.0 255.255.255.0"

Unter Windows knnen prinzipiell dieselben Plugin-Parameter verwendet

werden wie unter Linux. Es ist auch hier ein Sicherheitsrisiko, den Webser
ver fr den Zugriff von fremden Maschinen zuzulassen.

L o a d P l u g i n " o l s r d _ h t t p i n f o .d l l "
{
P lP a r a m "port" "8080"
P lP a r a m "Host" "127.0.0.1"
 3.4 Wichtige Plugins fr Olsrd

Wird die Beispielkonfiguration auf einem Arbeitsplatzrechner eingesetzt,

knnen die Statusseiten des Olsrd unter der URL h t t p : / / 1 2 7 .0 .0 .1 :8 0 8 0
aufgerufen werden.
Die von Httpinfo angezeigten Informationen sind sehr hilfreich im prakti
schen Betrieb eines Mesh. So lsst sich berprfen, ob die Verbindung zu
den direkten Nachbarn brauchbar ist, oder die gesamte Topologie betrach
ten, da OLSR diese Informationen in der lokalen Datenbank speichert. Soll
te eine normalerweise stabil funktionierende Route pltzlich nicht mehr
funktionieren, kann anhand der Topologieinformationen nachgeprft wer
den, ob alle Funkstrecken auf der Route richtig funktionieren. Auerdem
werden smliche HNA-Announcements dargestellt.

3.4.3 Nameservice

Dieses Plugin verteilt DNS-Informationen ber OLSR. OLSR-Knoten kn

nen damit ihren Namen und die Namen anderer Rechner mitteilen, zu de
nen Routen ber eigene HNA-Nachrichten annonciert werden. Also bei
spielsweise DNS-Eintrge fr Rechner am LAN-Port eines OLSR-Routers,
die statische Adressen haben und aus dem Mesh ber eigene HNA-Ankn-
digungen erreichbar sind. Auch ein echter DNS-Server, der Internetadres
sen auflst, kann anderen OLSR-Knoten mitgeteilt werden. Allerdings hat
das Plugin noch ein paar Haken und sen - ist also noch nicht so richtig
komfortabel und ausgegoren.
In jedem Linux/Unix-System gibt es die Datei / e tc / h o sts, diese enthlt
eine Tabelle, in der Hostnamen statisch zu IP-Adressen zugeordnet werden
knnen. Das Nameservice-Plugin erzeugt eine hosts-D atei und fgt DNS-
Eintrge aus dem OLSR-Mesh hinzu. Damit die vom Nameservice erzeugte
Datei vom Betriebssystem genutzt wird, muss sie unter Linux oder BSD
unter / e tc / h o s ts stehen oder mit einem symbolischen Link an diese Stelle
verlinkt werden. Im einfachsten Fall lsst man das Plugin die Datei neu
anlegen und konfiguriert es entsprechend.
Der Nachteil ist, dass bei jedem Start des Olsrd eine bereits vorhandene
Datei / e tc / h o sts von dem Plugin berschrieben wird. Wurden dort ma
nuell eigene Eintrge angelegt, gehen diese beim Einsatz des Plugins ver
loren. Die Default-Einstellung des Plugins ist daher das Anlegen einer Da
tei (Linux: / v a r/ ru n / h o sts_ o lsr, Windows: C:\WINDOWS\hosts_olsr).
Allerdings mssen die Anwender dann selbst Wege finden, diese Eintrge
dem jeweiligen System verfgbar zu machen. Linux sucht nur in der Datei
/ e tc / h o sts nach statisch zugeordneten Hostnamen. Sind keine wichtigen
Eintrge in / e tc / h o sts, darf das Plugin natrlich diese Datei einfach ber
schreiben.
Ebenso werden durch das Nameservice-Plugin die zu verwendenden DNS-
Server unter Linux/Unix in die Datei / e tc / r e s o lv .c o n f eingetragen. Hier

65
3 Optimized Link State Routing

werden die drei nchstgelegenen DNS-Server hinzugefgt, die im Mesh am

besten erreichbar sind.
Soll der Inhalt von / etc/ h o sts und / e tc / r e s o lv . co n f erhalten bleiben,
wre beispielsweise ein Shellskript eine Lsungsmglichkeit. Dieses Skript
knnte beim Start des OLSR-Daemon eine Sicherheitskopie der vorhande
nen Datei / etc/ h o sts anlegen und diese nach dem Beenden von Olsrd
wieder hersteilen.
Auf die gesammelten DNS-Informationen kann ein lokaler DNS-Server wie
beispielsweise der minimalistische dnsmasq zugreifen und sie DNS-Clients,
die keine Mesh-Clients sind, direkt zur Verfgung stellen. Wenn das Plugin
seine gewonnenen DNS-Eintrge in / v a r/ ru n / h o sts_ o lsr schreibt, kann
in dnsmasq. conf, der Konfigurationsdatei von dnsmaq, diese Zeile hinzu
gefgt werden: ad d n -h o sts= / v ar/ ru n / h osts_olsr. So kann dnsmasq die
DNS-Eintrge aus dem Nameservice-Plugin verwenden, muss dazu aber
neu gestartet werden. Einrichtung des Nameservice-Plugins unter Linux:

L o adPlugin " o l s r d _ n a m e s e r v i c e .s o .0.2"

{
# Der Name dieses O L S R - K n o t e n s , d e r d e m M e s h m i t g e t e i l t wird:
P IParam "name" " N a m e - d i e s e r - M a s c h i n e "

# Lokale Knoten, die be r H N A a n n o u n c i e r t wer d e n :

P IParam "10.134.133.56" "Sonne"
PIParam "10.134.133.57" "Mond"

# DNS-E i n t r g e we r d e n zu d i e s e r D a t e i h i n z u g e f g t .
P IParam "hosts-file" " / e t c/hosts"

# Z u stzliche Datei fr D N S - E i n t r g e s t a t t / e t c / h o s t s
# verwenden. D a d u r c h w i r d v e r h i n d e r t , dass die originale
# H o sts-Datei b e r s c h r i e b e n w i r d u n d b e r e i t s s e l b s t angelegte
# Eintrge v e r l orengehen.
# P l Param "add-hosts" "Datei mit P f a d a n g a b e "

# In diese Datei w e r d e n die drei n c h s t g e l e g e n e n D N S - S e r v e r

# eingetragen, we l c h e den b e s t e n E T X - W e r t haben.
PIParam "resolv-file" "/ e t c / r e s o l v .c o n f "

# Je d e m D N S - E i n t r a g vo n O L S R k a n n e i n S u f f i x a n g e h n g t werden.
# In der G r u n d e i n s t e l l u n g w i r d das n i c h t ge m a c h t .
# PIParam "suffix" ".olsr"

# ber diesen Ein t r a g w i r d ei n 'echter' D N S - S e r v e r annonciert.

# Wird der Eint r a g leer g e l a s s e n ("") w i r d d i e I P - A d r e s s e dieses
# OLS R - K n o t e n s verwendet.
# PIParam "dns-server" " I P - A d r e s s e des D N S - S e r v e r s "

# Das Intervall in d e m D N S - I n f o r m a t i o n e n an a n d e r e O L SR-Knoten

# v e r schickt w e r d e n (in S e k u n d e n ) . In d e r G r u n d e i n s t e l l u n g werden

66
 3.5 Typische Probleme mit OLSR I

# 120 S e k u n d e n ver w e n d e t .
# P I P a r a m " i n t erval" "Anzahl Sekun d e n "

# W i e lange sin d b e r das P l u g i n e m p f a n g e n e DNS - I n f o r m a t i o n e n

# g l t i g (in S e k u n d e n ) ? G r u n d e i n s t e l l u n g 3600 S e k u n d e n (1 Stunde)
# P I P a r a m " t i meout" "3600"
}

Unter Windows kann das Plugin dem Betriebssystem keine empfangenen

DNS-Servereintrge hinzufgen. Abgesehen davon funktioniert es wie un
ter Linux. Hosteintrge landen in den Grundeinstellungen in h o s t s . o l s r
im Windows-Systemordner C:\WIND0WS oder C:\WINNT. Mchte man die
gefundenen Hosteintrge direkt verwenden, kann das Plugin sie in die Da
tei C :\ W in dow s-System -0rdn er\system 32\ drivers\ etc\ hosts schrei
ben. Manche Ad-Blocker-Programme verwenden diese Datei jedoch, um
Zugriffe auf unerwnschte Webseiten zu blockieren, indem sie deren Adres
sen ber die Hosts-Datei umleiten. Der Einsatz des Plugins wird die Arbeits
weise dieser Programme behindern.

L o a d P l u g i n " o l s r d _ n a m e s e r v i c e .d l 1"
{
P I P a r a m "name" " N a m e - d i e s e r - M a s c h i n e "
PIParam "hosts-file" "c:\WINNT\system32\drivers\etc\hosts"
}

Die weiteren Plugin-Parameter entsprechen dem Einrichtungsbeispiel fr

Linux.

3.5 Typische Probleme mit OLSR

3.5.1 Gateway-Switching

Olsrd schaltet unter Umstnden hufig das verwendete Internet-Gateway

um, wenn es in einem OLSR-Mesh mehrere Internet-Gateways gibt. Ein
Gateway-Client kann unter OLSR nicht entscheiden, ber welches Internet-
Gateway er letzten Endes ins Internet geroutet wird, solange das Gateway
kein direkter Nachbar ist. Jeder OLSR-Router auf einem Multi-Hop-Pfad
zum Internet entscheidet unabhngig von den Wnschen des Gateway-
Clients, zu welchem Gateway er gerade die Internetpakete schickt. Dabei
wird jeweils das gnstigste Gateway gewhlt, zu dem gerade die beste Rou
te besteht. Die Qualitt von Routen verndert sich in einem Mesh jedoch
bestndig. Deshalb geschieht es in einem Mesh mit mehreren Gateways
relativ hufig, dass das Internet-Gateway von OLSR umgeschaltet wird.
Die meisten Internet-Gateways verwenden NAT (Network Address Trans
lation), d.h. sie maskieren die private IP-Adresse des Gateway-Clients und
3 Optimized Link State Routing

kommunizieren mit dem Server im Internet ber ihre ffentliche IP-Adres

se. Der Server empfngt alle Anfragen des Gateway-Clients mit der ffentli
chen IP-Adresse des Gateways und sendet seine Antworten an diese Adresse
zurck.
Immer wenn OLSR das Internet-Gateway wechselt, brechen die bestehen
den Verbindungen zusammen, da der Server im Internet nicht wei, dass
der Client nun ber eine andere ffentliche Adresse mit ihm zu kommu
nizieren versucht. Die bestehende Session ist aus Sicht des Servers unter
brochen, und der Client muss eine neue Session aufbauen. Hufiges Um
schalten des Gateways macht Anwendungen, die ein verbindungsorientier
tes Protokoll einsetzen, nahezu unbenutzbar: Downloads brechen immer
wieder ab, VoIP-Gesprche enden abrupt, SSH-Verbindungen setzen pltz
lich aus.
Sitzt man mit OLSR zwischen zwei oder mehreren annhernd gleich gut er
reichbaren Gateways, kann das Umschalten mehrmals pro Minute Vorkom
men. Da jeder OLSR-Router individuell sich fr die Weiterleitung zu einem
anderen Gateway entscheiden kann, hat man bei einer Internetverbindung
ber mehrere Zwischenhops keine Mglichkeit, das zu beeinflussen. Eine
Lsung wre, dass man den Gatewaybetreiber persnlich kennenlernt und
mit ihm zusammen manuell einen IP-Tunnel (z. B. mit OpenVPN) aufbaut.
Aber was soll man tun, wenn dieses Gateway gerade nicht funktioniert oder
nicht erreichbar ist?
Einzelne Freifunk-Communities haben das Problem gelst, indem sie den
Internettraffic von jedem Gateway im Mesh zu einem gemeinsamen Proxy/
Gateway im Internet weiterreichen, der in das Routing einbezogen wird. Al
le Internetanfragen werden ber den Proxy geroutet und nicht vorher durch
Network Address Translation maskiert. Der Proxy wei daher immer, ber
welches Gateway er zuletzt von einem OLSR-Knoten angesprochen wur-
del, und versendet die Anfragen jeweils an das Gateway, hinter dem der
OLSR-Knoten auf seine Antwort aus dem Internet wartet. Diese Lsung ist
einigermaen elegant, setzt aber einen erhhten Konfigurationsaufwand
voraus.
Nachteilig ist auerdem, dass der gesamte Datenverkehr eines stadtweiten
Netzwerks ber einen einzelnen Server abgewickelt wird - dieser muss den
gesamten anfallenden Datenverkehr entgegennehmen und weiterversen
den. Dadurch fallen zustzliche Kosten an, wenn der Traffic nicht kostenlos
ist oder pauschal abgerechnet wird. Zudem bricht der gesamte Internetver
kehr aus dem Mesh zusammen, wenn der Proxy/Gateway ausfllt. Auer
dem kann der gesamte Datenverkehr vom/zum Mesh ins Internet an einer
einzigen Stelle berwacht und abgehrt werden.
Dieses Problem haben die Entwickler bei B.A.T.M.A.N. durch das automa
tische Aushandeln von Tunnels von vornherein ausgerumt.

68
 3.5 Typische Probleme mit OLSR

3.5.2 Typische Probleme beim ersten Einsatz

Voraussetzung fr den Kontakt zum Meshnetzwerk ist eine gltige IP-Adres-

se fr jedes Interface, auf dem der Mesh-Routingdaemon arbeitet. Dazu ge
hren auch die zur Adresse des Netzwerks passende Netzmaske, die Broad-
castadresse und ein gltiger DNS-Server. Ein beliebter Fehler ist eine ungl
tige Broadcastadresse. Stimmt die Broadcastadresse nicht, ignorieren die
Meshknoten gegenseitig ihre OLSR-Pakete - diese werden ausnahmslos per
Broadcast verschickt. In einem Mesh gibt es prinzipiell keinen DHCP-Server
(Ausnahme: fr die lokalen Clients eines Meshrouters, wenn diese nicht am
Routing beteiligt sind). Das Eingabefeld Gateway muss beim Einsatz der
Protokolls unbedingt leer gelassen werden, es darf kein Default-Gateway
angegeben werden. Diese Einstellung nimmt der Routing-Daemon dyna
misch vor. Auch die WLAN-Karte(n) mssen fr die Verbindung zur Ad-
Hoc-Zelle richtig konfiguriert sein.
Bei Problemen sollte man zunchst prfen, ob eine Firewall aktiv ist. Ist das
der Fall, sollte sie testweise deaktiviert werden, um auszuschlieen, dass
die OLSR-Pakete von der Firewall blockiert werden. OLSR verwendet UDP-
Port 698, eingehende und ausgehende UDP-Verbindungen mssen deshalb
durch die Firewall erlaubt werden.

Einfaches Internet-Gateway

Mchte man fr einen Test einfach und schnell ein OLSR-Gateway mit ei
nem PC oder Notebook unter Linux einrichten, muss auf diesem Computer
im Normalfall NAT (Network Address Translation) eingerichtet werden. An
sonsten ist auch nach dem Aktivieren des Dynamischen Gateway-Plugins
keine Verbindung aus dem OLSR-Netz ins Internet mglich. Ist keine Fire
wall eingerichtet, lsst sich NAT durch das Ausfhren dieser beiden Be
fehle aktivieren. Eventuell bereits vorhandene Firewallregeln werden dazu
deaktiviert, e t h l und 1 9 2 .1 6 8 .1 .1 sind in diesem Beispiel das Netzwerk
interface und dessen IP-Adresse, ber das das Gateway mit dem Internet
verbunden ist. Diese beiden Parameter mssen der jeweiligen Situation an
gepasst werden.

i p t a b l e s -F; i p t a b l e s -t nat -F; ip t a b l e s -t m a n g l e -F

ip t a b l e s -t nat -A P O S T R O U T I N G -o ethl -j S N A T --to 192 . 1 6 8 . 1 . 1

3.5.3 Probleme mit WiFi

Allzu hufig machen WLAN-Karten beziehungsweise deren Treiber und/

oder Firmware rger. Ein alltgliches Problem ist bei Meshnetzen das so
genannte Cell-Splitting oder IBSS-ID-Splitting. Ein eindeutiges Indiz fr
Cell-Splitting ist folgendes: Obwohl alle Parameter bei der IP-Konfiguration
3 Optimized Link State Routing

stimmen und auch die Funk-Konfiguration der WLAN-Karten korrekt ist,

sehen sich die WLAN-Karten gegenseitig nicht.
Solange die Computer sich in direkter, unmittelbarer Funk-Reichweite be
finden - link-local sind -, muss es immer mglich sein, dass alle Rechner
auch ohne Routingprotokoll miteinander kommunizieren. Bei Problemen
sollte zuerst geprft werden, ob die einzelnen Computer sich gegenseitig
anpingen knnen. Klappt das nicht, sollte zunchst eine Firewall verdch
tigt werden. Auf Windows-PCs blockieren Firewalls nicht selten eingehende
ICMP-Pakete (Ping-Pakete) aus Sicherheitsgrnden.
Wenn eine Firewall als Fehlerursache ausgeschlossen ist, liegt das Problem
wahrscheinlich in einer fehlerhaften Funktion von WLAN-Karten im Ad-
Hoc-Modus, die sehr hufig auftreten. Unter Linux kann die Cell-ID durch
den Befehl

i wconfig Interface

berprft werden. Tauchen bei der Angabe der Cell-ID auf den Compu
tern unterschiedliche Angaben auf, ist eindeutig Cell-Splitting die Ursa
che, wenn alle anderen Angaben (Kanal, Modus, kein Schreibfehler in der
ESSID) stimmen. In diesem Fall liegt das Problem in der WLAN-Karten-
Firmware und/oder den Treibern. Wie man diesen Problemen aus dem Weg
gehen knnte zeigt Kapitel 5.

70
 B.A.T.M.A.N. - Better Approach To
Mobile Ad-Hoc Networking

Ausgehend von den Erfahrungen mit Freifunk-OLSR begannen die Entwick

ler aus der Freifunk-Community im Mrz 2006 in Berlin damit, ein neues
Routingprotokoll fr drahtlose Meshnetzwerke zu entwickeln.
Alle bisher bekannten Routingalgorithmen versuchen, Routen entweder zu
berechnen (proaktive Verfahren) oder sie dann zu suchen, wenn sie ge
braucht werden (reaktive Verfahren). Das neue Protokoll B.A.T.M.A.N. be
rechnet oder sucht im Gegensatz zu diesen Protokollen keine Routen - es
erfasst lediglich, ob Routen zu anderen Knoten existieren und berwacht
ihre Qualitt. Dabei interessiert es sich nicht dafr, wie eine Route verluft,
sondern ermittelt lediglich, ber welchen direkten Nachbarn ein bestimm
ter Netzwerkknoten am besten zu erreichen ist, und trgt diese Information
proaktiv in die Routingtabelle ein.
In der IP-Routingtabelle im Betriebssystem eines Computers ist grundstz
lich nur der nchstgelegene Router (oder ein Gateway) zu einem Ziel ein
4 BAT.MAN. - Better Approach To Mobile Ad-Hoc Networking

getragen. Ein Netzwerkknoten muss nur den jeweils nchsten direkt er

reichbaren Zugangspunkt kennen, der mit dem Weiterleiten von IP-Paketen
zu einem Ziel beauftragt werden kann. Kenntnisse ber Zwischenstationen
sind fr den Absender irrelevant. Dieser hat blicherweise auch keine Mg
lichkeit, den Weg seiner IP-Pakete zu beeinflussen.
Wichtig ist lediglich, dass auch der jeweils nchste Router wieder das rich
tige Gateway zum Ziel kennt. Solange diese Kette nicht unterbrochen wird
(oder das IP-Paket im Kreis herumschwirrt, bis die Time-To-Live abgelau
fen ist) erreichen die Daten ihr Ziel. Bei einem verbindungslosen Protokoll
wie UDP, welches Daten nur in eine Richtung schickt, ohne eine Best
tigung (Acknowledgement) von der Empfngerseite zu erwarten, reicht es
aus, wenn eine Route nur in einer Richtung funktionsfhig ist. Protokolle
wie TCP dagegen erwarten eine Antwort von der Gegenseite - deshalb muss
das Weiterreichen der IP-Pakete auch in der Gegenrichtung funktionieren.
Es muss also nicht nur eine Route in eine Richtung, sondern auch eine
Route in der Gegenrichtung existieren - was Anfnger oft vergessen, wenn
sie von Hand Routingtabellen editieren. blicherweise nehmen IP-Pakete
fr den Hin- und Rckweg die gleiche Route, das ist aber nicht unbedingt
notwendig.
OLSR - oder Link-State-Routing im Allgemeinen - wendet ein aufwendi
ges Verfahren an, um diese Vorgaben umzusetzen. Die einzige Entschei
dung, die ein Link-State-Router beim Versenden oder Weiterleiten von Da
ten treffen kann, betrifft ebenfalls lediglich die Auswahl des nchsten Rou
ters, der ber eine direkte Verbindung per Funk oder per Kabel mit dem
Weiterreichen des IP-Pakets beauftragt werden kann. Aber um diese einfa
che Entscheidung treffen zu knnen, treiben Link-State-Verfahren groen
Aufwand: Das gesamte Netz wird mit Topologieinformationen geflutet, al
le Routen von jedem Endpunkt des Graphen zu jedem anderen Endpunkt
werden berechnet. Am Ende fhrt gerade die Tatsache, dass sich jeder ein
zelne Knoten ein eigenes Gesamtbild des Netzwerks errechnet, zu Unstim
migkeiten und in der Folge zu Kreisrouten. Die Topologiedatenbanken in
einem drahtlosen Mesh mit einer nennenswerten Anzahl von Routern sind
praktisch nie synchron.
Link-State-Protokolle in drahtgebundenen Netzen wie das verbreitete Pro
tokoll OSPF vermeiden Kreisrouten, indem sie sicherstellen, dass die Topo
logiedatenbanken in allen Routern wirklich identisch sind. Die dazu ver
wendeten Verfahren versagen in einem drahtlosen Netzwerk. Bevor die Da
tenbanken in allen Routern tatschlich synchronisiert sind, sind sie hoff
nungslos veraltet und damit nutzlos.
Die Kenntnis ber die Zwischenstationen einer Route ist nur dann rele
vant, wenn der Absender die Route vorgibt. In IP-basierten Netzen ist das
ein Sonderfall; dieses Verfahren wird als Sourcerouting bezeichnet - die In
formationsquelle (Source) gibt die Route vor. Da die bersicht ber die
Netzwerktopologie in einem Mesh mit zunehmender Entfernung immer

72
 4.1 Funktionsweise des B.A.T.M.A.N.-Algorithmus

unscharfer wird, ist eine solche Vorgehensweise in der Praxis jedoch we

nig sinnvoll. Der Absender geht hufig von einer Route aus, die ungnstig
ist oder bereits nicht mehr funktioniert. Beliebt ist Sourcerouting in Mesh-
netzwerken deshalb, weil sich Kreisrouten leicht entdecken lassen: Wenn
in einer Sourceroutingtabelle ein Knoten mehr als einmal vorkommt, ist
offensichtlich etwas faul.

4.1 Funktionsweise des BAT.M AN.-Algorithmus

Wird der B.A.T.M.A.N.-Routingdaemon in einem Router gestartet, sendet
er in einem definierten Intervall per UDP-Broadcast sogenannte Origina-
tornachrichten {Originator-Messages). Diese sind prinzipiell dasselbe wie
Hello-Nachrichten bei Link-State-Protokollen. Der Unterschied zwischen
Helios und Originatornachrichten besteht darin, dass Hello-Nachrichten
bei Linkstate-Protokollen nur lokal versendet werden, um Nachbarn in di
rekter Reichweite zu erkennen. B.A.T.M.A.N. flutet dagegen das ganze Mesh
mit Originatornachrichten.

4.1.1 Die Originatornaehricht

Eine Originatornachricht enthlt die IP-Adresse des Urhebers (Originator),

auerdem eine Sequenznummer, mit der die einzelnen Nachrichten vom
Urheber fortlaufend nummeriert werden und eine TTL Der Inhalt der ers
ten Originatornachricht eines B.A.T.M.A.N.-Nodes mit der Adresse A lautet
sinngem: Nachricht von Knoten A, Sequenznummer 0, TTL 50. Ande
re B.A.T.M.A.N.-Knoten erzeugen und senden ebenfalls eigene Originator
nachrichten. Eine Originatornachricht von B.A.T.M.A.N. ist sehr klein, die
typische Gre ist 10 Byte. Einschlielich des Overheads, der beim Versen
den eines IP-Pakets immer mit anfllt, betrgt die gesamte effektiv bertra
gene Datenmenge blicherweise 52 Byte. Im IP-Header eines UDP-Pakets
ist immer auch die Adresse des Netzwerkknotens enthalten, welcher das
Paket gerade sendet. Diese Information ist fr den Protokollablauf wichtig.
B.A.T.M.A.N.-Router wiederholen die Originatornachrichten von anderen
Nodes unter der Beachtung bestimmter Regeln - das Netz wird mit Origina
tornachrichten geflutet. Auf ihrer Reise durch das Mesh gehen die Origina
tornachrichten dann verloren oder verbreiten sich nur langsam, wenn sie
auf ungnstige Bedingungen stoen (schlechte Funkverbindungen, ber
lastete Router, viele Interferenzen durch ausgelastete Funkverbindungen).
Auf guten, wenig belasteten Funkstrecken kommen sie schnell und mit we
niger Verlusten voran.
Empfngt ein B.A.T.M.A.N.-Router ein weitergereichtes Originatorpaket von
einem entfernten Knoten, sieht er, von welchem direkten Nachbarn er die
4 BAT.MAN. - Better Approach To Mobile Ad-Hoc Networking

Originatornachricht bekommt. Damit erfhrt er zum einen von der Exis

tenz des anderen Knotens und sieht dabei auerdem, hinter welchem Nach
barn sich die Route befindet. Da die Originatornachricht einen Weg gefun
den hat, existiert auch eine Route. Gibt es mehrere Routen zu dem ent
fernten Knoten, kommen die Originatornachrichten auf der besten Route
schneller und/oder hufiger an. Liegen die verschiedenen Routen hinter
verschiedenen Nachbarn, kann sich der Empfnger einfach fr den besten
Nachbarn als Gateway entscheiden, wenn er mit dem entfernten Knoten
kommunizieren will. Der Empfnger muss sich lediglich merken, von wel
chem Nachbarn die Originatornachrichten des Senders am schnellsten und
am zuverlssigsten eintreffen.
Zu jedem entdeckten Originator fhrt ein B.A.T.M.A.N.-Router eine Statistik
ber eine vordefinierte Anzahl der zuletzt empfangenen/erwarteten Origi
natornachrichten. Ein Node wei somit, wie viele Originatornachrichten
ber welchen direkten Nachbarn tatschlich eingetroffen sind und kann
die Qualitt der Verbindung beurteilen.

4.1.2 Bidirectional Unk Check - Linkprfung auf

Bidirektionalitt

Beim Weiterreichen von Originatornachrichten mssen die B.A.T.M.A.N.-

Knoten einige einfache Regeln beachten. Dazu gehrt, dass nur Origina
tornachrichten von Nachbarn weitergereicht werden, zu denen eine bi
direktionale Kommunikationsverbindung besteht. Eine Route, die in bei
de Richtungen - auf dem Hin- und Rckweg - funktioniert, kann nur aus
einer Kette von Funkverbindungen bestehen, die jeweils bidirektional ar
beiten. Auerdem erwartet der Absender beim Transport von Daten, die
nicht verbindungslos per Broadcast, sondern per Unicast bertragen wer
den, eine Empfangsbesttigung (Acknowledgement). Bleibt sie aus, wird die
Nachricht mehrfach verschickt. Unidirektionale Funkstrecken sind deshalb
fr den Transport von Unicast-Paketen unbrauchbar. Da alle Protokollda
ten von B.A.T.M.A.N. per Broadcast verschickt werden, muss nachgewiesen
werden, dass die Linkstrecken, ber die Originatornachrichten empfangen
werden, bidirektional sind.
Angenommen, die Knoten A und B sind in einem Mesh direkte Nachbarn,
die gegenseitig Daten empfangen knnen. Knoten B empfngt zum ersten
Mal eine Originatornachricht von A. Da die Absenderadresse im IP-Header
mit der Originatoradresse bei der empfangenen Originatornachricht iden
tisch ist, wei B, dass er das Paket direkt von seinem Originator bekommen
hat:

Nachricht von A, Sequenznummer 0 ^
TTL 50, gesendet von A ^ f g ^

74
 4.1 Funktionsweise des BAT.M.A.N.-Algorithmus

B wei nun, dass A existiert und dass A ein direkter Nachbar ist, dessen
Pakete er empfngt. B wei aber noch nicht, ob A seine Wiederholungen
auch empfangen kann. Solange ein Knoten nicht wei, ob die Verbindung
zu einem direkten Nachbarn in beide Richtungen funktioniert (also bidirek
tional ist), muss er in die Originatornachrichten, die er von diesem Nach
barn wiederholt, eine Warnung hinzufgen, dass die Originatornachricht
mglicherweise (oder erwiesenermaen, falls der Link immer oder meis
tens unidirektional ist) aus einer einseitigen Kommunikationsbeziehung
stammt. Anderenfalls knnten andere Knoten durch den Empfang dieser
Aussendung glauben, dass hier eine benutzbare Verbindung besteht, und
versuchen, Datenverkehr ber die nur in eine Richtung funktionierende
Verbindung zu routen.
Deshalb fgt B seiner Wiederholung der Originatornachricht von A ein
sogenanntes U nidirectional-Flag hinzu. B wiederholt nun die Originator
nachricht von A, nachdem er die TTL um 1 reduziert hat. Zustzlich fgt B
seinem Antwortpaket noch die Information I s - D i r e c t - L i n k als Flag hin
zu, damit A sicher sein kann, dass B auf ein Paket antwortet, dass er direkt
von A empfangen hat:

Nachricht von A, Sequenznummer 0, TTL 49

Wenn A die Wiederholung seiner eigenen Nachricht durch B empfngt,

wei er, dass es B gibt und dass B eine direkte Verbindung zu ihm hat.
Anhand des gesetzten Flags I s - D i r e c t - L i n k im Originatorpaket erkennt
A, dass B seine Originatornachricht direkt von ihm selbst empfangen hat.
A wei nun durch den Empfang seiner eigenen Originatornachricht sicher,
dass er einen direkten Nachbarn mit der Adresse B hat, der seine eigenen
Originatornachrichten auf direktem Weg empfngt und wieder auf direk
tem Weg antworten kann. Damit ist aus der Sicht von A die direkte bidirek
tionale Verbindung zu B nachgewiesen.
Htte B das Originatorpaket von A nicht empfangen, htte B es schlie
lich nicht wiederholt. Htte B die Nachricht von A ber einen Umweg ber
einen anderen B.A.T.M.A.N.-Knoten empfangen, wre das I s - D i r e c t - F l a g
nicht gesetzt. Wre die Originatornachricht auf dem Rckweg verlorenge
gangen, wsste A nichts davon, dass B seine Pakete empfngt. A trgt al
so eine Hostroute zu B in seine Routingtabelle ein. Empfngt jetzt A ber
B Originatornachrichten von entfernten Originatoren, wiederholt A diese,
solange B das beste Gateway zu dem entfernten Originator ist.
A beteiligt sich am Fluten von Nachrichten, die er ber B empfngt. Irgend
wann schickt B nun ebenfalls aufgrund des festgelegten Intervalls fr das
Erzeugen von Originatornachrichten eine eigene Originatornachricht auf
die Reise:

75
4 BAT.MAN. - Better Approach To Mobile Ad-Hoc Networking

Nachricht von B, Sequenznummer 0, TTL 50

A wei beim Empfang dieser Nachricht bereits, dass eine bidirektionale Ver
bindung zu B besteht und wiederholt diese Nachricht ohne die Unidirectio-
nal-Warnung, nachdem er die TTL um 1 reduziert hat. A setzt bei seiner
Antwort ebenfalls das Is -D ire c t-L in k -F la g :

Nachricht von B, Sequenznummer 0, TTL 49

Gesendet von A. ohne Unidirectional-Flag,

B empfngt daraufhin die Wiederholung seiner eigenen Originatornach-

richt von A. Endlich wissen A und B, dass sie direkte Nachbarn sind, die
sich gegenseitig sehen und in beide Richtungen miteinander kommunizie
ren knnen. Auch B trgt nun eine Hostroute zu A in seine Routingtabelle
ein. Empfngt B Originatornachrichten von entfernten Originatoren, die
von A weitergereicht werden, wiederholt B diese nun auch.
Angenommen, hinter Knoten B existiert noch der Knoten C. B und C haben
eine bidirektionale Verbindung und beide wissen das auch schon, da sie
den Bidirectional Link Check bereits erfolgreich durchlaufen haben. Wenn
B die Originatornachrichten von A wiederholt, hrt C die bertragungen
ebenfalls. So erfhrt C, dass sich A hinter B befindet. C trgt B als Gateway
zu A in seine Routingtabelle ein. Wiederholt B aus der anderen Richtung
die Originatornachrichten von C, erfhrt A von der Existenz von C. A trgt
B als Gateway zu C ein.
Da beide Funkverbindungen A-B und B-C daraufhin geprft wurden, dass
sie in beide Richtungen funktionieren, gibt es nun eine funktionierende
Route A-B-C und eine funktionierende Route C-B-A. ber den Verlauf der
beiden Routen wissen A und C jedoch nichts - sie wissen lediglich, dass
B fr sie das nchste Gateway ist. Wsste A, dass C seine Originatornach
richten mit einer TTL von 50 versieht, knnte A sich wegen der TTL von
49 in den Originatornachrichten, die er von B empfngt, ausrechnen, dass
C sich unmittelbar hinter B befindet. Eine Festlegung auf eine bestimmte
TTL existiert in B.A.T.M.A.N. jedoch nicht. Damit kann jeder Knoten ent
scheiden, wie weit (im Sinne von Hops) er seine Anwesenheit dem Netz
mitteilen mchte.

4.1.3 Eine Originatornaehricht reist durch das Mesh

Die folgenden Grafiken verfolgen das Fluten eines kleinen Meshnetzes mit
einer Originatornachricht der Station A. Die Qualitt der Funkstrecken ist
durch unterschiedlich krftige Pfeile angedeutet.

76
 4.1 Funktionsweise des B.A.T.M.A.N.-Algorithmus

Im ersten Schritt sendet A eine selbst erzeugte Originatornachricht, diese

wird empfangen von B und D. Diese prfen anhand der Urheberadresse
und der Sequenznummer, ob sie diese Nachricht schon einmal gesehen
haben. Wird die Nachricht zum ersten Mal empfangen, wiederholen sie die
Ausstrahlung, nachdem sie die TTL reduziert haben:

B und D sehen die Nachricht zum ersten Mal und wiederholen sie. A sieht,
dass B und D seine eigene Nachricht wiederholen. In diesem Beispiel ist
die Bidirektionalittsprfung zwischen A, B und D bereits erfolgreich abge
schlossen. Daher wiederholen B und D die Originatornachricht von A ohne
das Unidirectional-Flag. Nun sieht auch C die von B wiederholte Nachricht.
Die Funkverbindung von B zu D funktioniert schlechter als von D zu B, sie
ist gelegentlich unidirektional.
In unserem Beispiel geht das Paket auf dem Weg von B zu D verloren. Die
Wiederholung durch D wird auch von E und B gesehen. Anhand der Se
quenznummer erkennt B, dass die von D wiederholte Nachricht bereits be
kannt ist und ignoriert sie. Die bertragung von D zu G gelingt manchmal,
in diesem Augenblick ist sie jedoch nicht erfolgreich:

Nun wiederholen C und E die Nachricht. Die Verbindung von E zu F ist un

zuverlssig, diesmal geht die Originatornachricht auf dem Weg von E zu F
verloren. D sieht die Wiederholung der Nachricht von E, die bereits bekannt
ist und somit ignoriert wird. Auch B und D ignorieren die Wiederholung von
C. Sporadisch kommen Nachrichten von D bei F an, in der Beispielsituati-

77
4 BAT.M AN. - Better Approach To Mobile Ad-Hoc Networking

on ist das der Fall. Der Link funktioniert aber nur von D nach F. Da F von
D die Nachricht ber einen unidirektionalen Link bekommt, wird sie von F
ignoriert. Weitergereichte Originatornachrichten werden von B.A.T.M.A.N.
nur beachtet, wenn sie von einem Nachbarn empfangen werden, der ber
eine bidirektionale Verbindung erreicht werden kann:

\ -

Bei der nchsten bertragung kommt die Originatornachricht von A ber

G bei F an. C und D ignorieren die Wiederholung der bekannten Origina
tornachricht:

Nachrichten von A knnen ber mehrere Wege bei F ankommen. Mglich

sind unter anderem die Routen A-B-C-G-F, A-D-E-F, A -B-D -E-F. Wich
tig fr F ist nur, dass die Originatornachrichten von A entweder ber G
oder E zuerst bei ihm ankommen. Wenn Node F nun mit A kommunizie
ren mchte, muss er sich lediglich entscheiden, ob er G oder E mit dem
Weiterreichen der IP-Pakete beauftragt. Diese Entscheidung kann F treffen,
indem er eine Statistik fhrt, ber welchen direkten Nachbarn wieviele Ori
ginatornachrichten von A zuerst eingetroffen sind (Tabelle 4.1).

Tabelle 4.1: Stationen ber welchen Nachbarn gesehen?

Ranking-Tabelle
G E
A 14 7
B 16 4
C 18 8
D 14 9

78
 4.2 Praxis mit B.A.T.M.A.N.

Fortsetzung:

Stationen ber welchen Nachbarn gesehen?

E 22 19
G 59 0

In der Beispielsituation ist die Route A-B-C-G-F zuverlssiger aber lang

samer als beispielsweise A-D-E-F. Die krzere Route kann zwar schnel
ler sein, aber wenn die Mehrzahl der Pakete auf dieser Route nicht durch
kommt, werden die ber G eintreffenden Pakete hufiger das Rennen ge
winnen.

4.2 Praxis mit B.A.T.M.A.N.

Der B.A.T.M.A.N.-Daemon steht bislang fr Linux, FreeBSD und Macintosh
OS-X zur Verfgung. Die Entwicklungsarbeit konzentriert sich jedoch in
erster Linie auf Linux, weshalb es Vorkommen kann, dass erweiterte Funk
tionen unter anderen Betriebssystemen erst mit einer gewissen Verzge
rung zur Verfgung stehen.
Linux-Installationspakete des B.A.T.M.A.N.-Daemon batmand gibt es fr
Debian, OpenZaurus und OpenWRT.1 Zum Kompilieren aus dem Quelltext
gengt ein einfaches make und make i n s t a l l im Sourcecodeverzeichnis.
Als einzige Abhngigkeit wird die Bibliothek lib p th r e a d vorausgesetzt, die
auf einem Linux-System blicherweise bereits installiert sein sollte.
Um ber ein B.A.T.M.A.N.-Mesh ins Internet gehen zu knnen, muss au
erdem unter Linux das Kernelmodul tun installiert sein. Es ist im Stan
dardkernel der Linuxdistributionen enthalten und wird beim ersten Start
des B.A.T.M.A.N.-Daemons automatisch geladen. Wer einen selbstkompi
lierten Kernel einsetzt, findet es zum Beispiel in xconf ig in der Abteilung
Network D evice Support unter der Bezeichnung U n iv e rsa l TUN/TAP
d e v ic e d r iv e r support.
B.A.T.M.A.N. handelt automatisch UDP-Tunnel zu Internet-Gateways aus.
IP-Pakete, die ins Internet gesendet werden, werden in UDP-Pakete ver
packt und vom Gatewayclient an das Gateway geschickt. Auch wenn die IP-
Pakete im Tunnel ber mehrere Hops im Mesh transportiert werden, sieht
der Tunnel fr sie wie eine direkte Verbindung (Single-Hop) zum Gateway
aus. Anfangs- und Endpunkt des Tunnels sind festgelegt und unabhngig
davon, wie die Route im Mesh dazwischen gerade verluft. Solange das
Mesh in der Lage ist, eine funktionierende Hin- und Rckroute zwischen
Client und Gateway bereitzustellen, ist die Anbindung an das Internet sta
bil, auch wenn sich der Routingpfad zwischen beiden Endpunkten hufig
verndert.

1 http://d0vnl0ads.0pen-m6sh.net

79
4 B.A.T.MAN. - Better Approach To Mobile Ad-Hoc Networking

Durch die Verwendung eines Tunnels kann der Internet- oder Gateway
nutzer auf der Clientseite das Gateway aussuchen und bestimmen, dass
das Gateway nicht umgeschaltet wird. Falls ein Gateway fr Internetver
kehr zum schwarzen Loch wird oder nur noch langsam reagiert, kann der
Client selbst das Gateway abwhlen und einen neuen bestimmen. Auer
dem kann der Client entscheiden, wann, unter welchen Umstnden und
nach welchen Kriterien ein Gateway ausgesucht beziehungsweise gewech
selt wird.
Hat der B.A.T.M.A.N.-Daemon erfolgreich einen Tunnel aufgebaut, legt er
ein Tunnelinterface tunO an. Bei einer soliden Linuxdistribution sollten
beim Einsatz des Kernelmoduls tun keine Probleme auftreten. Manchmal
kommt es vor, dass der Devicenode /dev/net/tun nicht vorhanden ist
oder nicht automatisch angelegt wurde. In diesem Fall kann der Device
knoten von Hand mit Administratorrechten erzeugt werden:

mknod -m 600 / d e v / n e t / t u n c 10 200

4.2.1 Erster Start des Daemons

B.A.T.M.A.N. wird mit Administratorrechten von der Kommandozeile mit

allen erforderlichen Parametern gestartet, eine Konfigurationsdatei gibt es
nicht. Wie bei den meisten Kommandozeilenprogrammen gibt batmand -h
einen kurzen Hilfetext aus. Ausfhrlichere Informationen erhlt man mit
der Option -H
Es knnen mehrere Interfaces angegeben werden, die natrlich funktions
fhig und konfiguriert sein mssen. Im einfachsten Fall gengt dann der
Aufruf

bat m a n d Interfacel I n t e r f a c e 2 . . I n t e r f a c e N

Dabei wird das Default-Originatorintervall von einer Originatornachricht

pro Sekunde und pro Interface verwendet. Der Routing-Algorithmus lsst
sich ber die Einstellung des Originatorintervalls an unterschiedliche Ein
satzzwecke anpassen.
Wenn in einem Mesh schnelle Reaktionen auf Vernderungen der Topologie
gewnscht sind und dafr etwas mehr Protokolloverhead in Kauf genom
men werden kann, kann das Originatorintervall relativ klein gesetzt wer
den. Ein typischer Anwendungsfall sind kleinere Netze mit vielen mobilen
Knoten.
Wenn geringer Protokolloverhead im Vordergrund steht, kann der Wert ver
grert werden. Ein sehr groes Mesh mit vielen hundert Knoten wrde
unter einem zu kleinen Originatorintervall leiden, hier fordert die groe
Originatoranzahl Abstriche bei der Reaktionsgeschwindigkeit.

80
 4.2 Praxis mit B.A.T.M.A.N.

Ist ein krzeres oder lngeres Originatorintervall erforderlich, kann das mit
der Option -o angegeben werden, die Eingabe erfolgt in Millisekunden:

b a t m a n d -o 2 0 0 0 Interfacel Interface2 ... I n t e r f a c e N

4.2.2 Den Netzwerkstatus im Debugging-Modus beobachten

Der B.A.T.M.A.N.-Daemon kann auch im Debugging-Modus mit der Option

-d und einem Debuglevel von 0 bis 4 gestartet werden, um den Status des
Netzwerks zu beobachten:

b a t m a n d -d D e b u g l e v e l I n t e r f a c e

Ohne die Debugging-Option oder mit der Angabe des Debuglevels 0 geht
batmand beim Start sofort in den Hintergrund und routet auf den angege
benen Interfaces.

Abbildung 4.9:
Orginator Router (#/128): Potential Routers... Ausgabe im
105.0.0.50 105.130.30.1 (61): 105.130.30.1 (61) 105.130.30.242(2) Debuglevel 1
105.66.0.24 105.130.30.1 (31): 105.130.30.1 (31) 105.130.30.242(4)
105.130.1.154 105.130.30.1 (58): 105.130.30.1 (58) 105.130.30.242(7)
105.130.30.192 105.130.30.1 ( 7): 105.130.30.1 ( 7)
105.130.30.242 105.130.30.242 (114): 105.130.30.242 (114)
105.130.30.29 105.130.30.1 (90): 105.130.30.242 (37) 105.130.30.1 (90)
105.130.30.3 105.130.30.1 ( 3): 105.130.30.1 ( 3)
105.192.192.99 105.130.30.1 (17): 105.130.30.1 (17) 105.130.30.242 ( 2)
105.130.30.232 105.130.30.242 (117): 105.130.30.242 (117) 105.130.30.1 ( 6)
105.130.30.1 105.130.30.1 (110): 105.130.30.1 (110) 105.130.30.242 (13)
105.130.30.31 105.130.30.1 (114): 105.130.30.1 (114) 105.130.30.242 (10)
105.192.192.81 105.130.30.1 (15): 105.130.30.1 (15) 105.130.30.242 ( 1)
105.192.192.84 105.130.30.1 (18): 105.130.30.1 (18) 105.130.30.242 ( 1) I

Wird das Programm in einem Debuglevel grer als Null aufgerufen, bleibt
der Daemon im Vordergrund und gibt auf dem Terminal die somit angefor
derten Informationen aus. Fr Anwender sind nur die Debuglevel 1 und 2
interessant. Debuglevel 1 zeigt eine Liste aller erreichbaren Originatoren im
Mesh an, auerdem die Nachbarn, ber die zu den Originatoren geroutet
werden kann und die Anzahl der jeweils empfangenen Originatomachrich-
ten. Existieren Routen ber mehrere Nachbarn zu einem Originator, werden
diese in der Liste der P o t e n t i a l R o u ters angezeigt (Abbildung 4.9).

Abbildung 4.10:
Ausgabe von
Gateway Router (*/128)
105.192.99.62 105.130.30.1 ( 7), gw.class 1 0 - 6 MBit, reliability: 1 Debuglevel 2
105.131.83.5 105.130.30.1 (17), gw.class11 - >6 MBit, reliability: 0
105.192.99.192 105.130.30.1 ( 3), gw.class 10 - 6 MBit, reliability: 2
105.192.99.103 105.130.30.1 ( 5), gw.class 7 - 2 MBit, reliability: 1
=> 105.131.41.5 105.130.30.1 (10), gw.class 11 - >6 MBit, reliability: 0
I 105.192.99.61 105.130.30.1 ( 3), qw.class 7 - 2 MBit, reliability: 0

81
I 4 B.A.T.M.A.N. - Better Approach To Mobile Ad-Hoc Networking
'------------------------------ i^ i ii b.ih ,.uii .nwj.immi*-lu..I.UIP.>

Mit der Debug-Option -d 2 werden im Connect-Mode die vorhandenen

Gateways aufgelistet. Abbildung 4.10 zeigt ein Beispiel, bei dem das Gate
way mit der IP 105.131.41.5 ausgewhlt wurde. Es offeriert dem Mesh einen
Intemet-Uplink mit mehr als 6 MBit. Von den 128 Originatornachrichten,
die das Gateway auf die Reise geschickt hat, sind allerdings nur 10 auf dem
lokalen Rechner angekommen, weshalb der erzielbare Datendurchsatz ge
ring sein drfte. Der Wert R e l i a b i l i t y zeigt an, wie zuverlssig die Ver
bindung zum Gateway ist. Gateway und Gateway-Client kommunizieren
regelmig darber, ob der TYinnel aufrechterhalten werden soll. Schlgt
diese Kommunikation fehl, erhht sich der Reliability-Wert.
Der Verlauf der Route zu diesem Gateway kann unter Linux und BSD mit
dem Befehl ping -R Z i e l - I P berprft werden. Dabei wird der Hin- und
Rckweg angezeigt:

1inux:- # ping -R 105.131.41.5

PING 1 0 5 . 1 31.41.5 (105.131.41.5) 56(124) b y t e s of data.
64 bytes from 105.131.41.5: i c m p _ s e q = l t t l = 6 0 t i m e = 3 7 . 7 ms
RR: 1 0 5 . 1 30.30.0
1 0 5 . 1 30.30.1
1 0 5 . 1 3 0 . 1.67
1 0 5 . 131.83 . 3
105.131 . 41.5
1 0 5 . 1 3 1 .41 . 5
1 0 5 . 1 3 1 .41 . 3
10 5.130.1.67
1 0 5 .130.30.1

64 bytes from 105.131.41.5: i c m p _ s e q = 2 t t l = 6 0 t i m e = 1 0 . 2 ms (same route)

Die Anzeige der Ping-Ergebnisse erfolgt fortlaufend. ndert sich die Route,
ist das sofort zu erkennen. Das RR in der Ausgabe steht fr Record Route. Zu
jedem erreichbaren Knoten kann so die Route geprft werden, sofern Ping
nicht durch Firewalleinstellungen blockiert wird.

Debugging im Connect-Modus

Hat man den B.A.T.M.A.N.-Daemon bereits ohne das gewnschte Debugle-

vel gestartet oder mchte gleichzeitig oder abwechselnd die Ausgaben der
Debuglevels 1 und 2 sehen, hat man die Mglichkeit, jederzeit beliebig viele
Instanzen des B.A.T.M.A.N.-Daemon im Connect-Modus zu starten. Dazu
gibt man den Schalter -c zusammen mit dem Schalter -d 1 -4 fr das De-
buglevel an. Luft ein mit dem Routing beschftigter B.A.T.M.A.N.-Daemon
im Hintergrund, kann man sich mit

b a t m a n d -c -d 1

82
 4.2 Praxis mit B.A.T.M.A.N.

den Routingstatus der routenden Instanz des batmand ansehen. Dabei wird
die Anzeige fortlaufend aktualisiert. Soll der batmand nur einmalig eine
Ausgabe erzeugen und sich dann beenden, kann man ihn mit der Option -b
im Batch-Mode starten. Das ist interessant fr Skripte, welche die Ausgabe
des Daemons verarbeiten:

b a t m a n d -c -b -d 1

4.2.3 Routingklassen und Gatewayklassen

Der Daemon kennt unterschiedliche Gatewayklassen fr Internet-Gateways,

das heit, die Gateways geben im Mesh bekannt, wieviel Bandbreite sie
brutto zum Internet anbieten.

Gateway-Konfiguration

Ein B.A.T.M.A.N.-Gateway, das einen Internetzugang mit 2 MBit Bandbreite

(Klasse 7) anbietet, startet man wie folgt:

b a t m a n d -g 7 ethl w l a n O

Auch das Annoncieren einer Route in ein anderes Netzwerk, Subnetz oder
Hostroute analog zu den HNA-Announcements von OLSR ist mglich:

b a t m a n d -a 1 0 . 1 4 5 . 1 4 5 . 0 / 2 4 ethl w l anO

Selbstverstndlich kann man beide Optionen kombinieren und auch meh

rere Host Network Announcements gleichzeitig vornehmen:

b a t m a n d -g 7 -a 1 0 . 1 1 . 1 2 . 1 3 / 3 2 1 0 . 2 2 . 3 3 . 0 / 2 2 ethl w l anO

Gateway-Clients

Wird ein B.A.T.M.A.N.-Daemon gestartet, sucht er nicht automatisch eine

Route zum Internet. Will man auf Clientseite angeben, dass er ins Internet
routen soll, kann man mit der Option -p ein bevorzugtes Gateway angeben.
Zustzlich muss mit - r eine Routingklasse angegeben werden. Falls das be
vorzugte Gateway nicht erreichbar ist, wird sich der B.A.T.M.A.N.-Daemon
ein alternatives Gateway nach den vorgegebenen Kriterien der Routingklas
se aussuchen. Drei Routingklassen werden angeboten.
Klasse 1 ist auf maximale Bandbreite zum Internet optimiert. Um das zu
erreichen, sucht sich der B.A.T.M.A.N.-Daemon den besten Kompromiss

83
I 4 B.A.T.M.A.N. - Better Approach To Mobile Ad-Hoc Networking

aus der vom Gateway angegebenen Gatewayklasse und der Verbindungs

qualitt ber das Mesh zum Internet-Gateway. Bei Klasse 1 gibt er einem
schnelleren Gateway den Vorzug, auch wenn dann die Verbindung weniger
zuverlssig sein sollte:

b a t m a n d -r 1 athO

Klasse 2 ist auf maximale Verbindungsqualitt zum Internet-Gateway aus

gerichtet. Der Routing-Daemon wird das am besten erreichbare Gateway
whlen, auch wenn dieses nur langsamen Internetzugang anbietet. Das ist
dann interessant, wenn eine langsame, dafr jedoch zuverlssige Internet
verbindung Priorit haben soll, z. B. beim Chat, bei SSH-Verbindungen und
VOIP-Anwendungen:

b at m a n d -p 1 0 5.131.41.5 -r 2 athO

Klasse 3 whlt automatisch das jeweils nchstgelegene Internet-Gateway.

Diese Einstellung ist fr mobile Knoten interessant, die sich viel im Mesh
bewegen. Eine solche Verbindung ist schnell hergestellt, bedingt aber hu
figes Umschalten des Gateways und fhrt deshalb oft zu Verbindungsab-
brchen bei Anwendungen, die nicht verbindungslos sind. Klasse 3 ent
spricht der Gatewayfunktionalitt von OLSR mit den bekannten Proble
men (Gateway-Switching, Verbindungsabbrche) und Vorteilen (schneller
Verbindungsaufbau).
Hat der Tunnelaufbau geklappt, findet man bei einem Blick in die Routing
tabelle eine Defaultroute (Ziel: 0.0.0.0) ber ein Interface mit dem Namen
tunNummer.
Die im Mesh verfgbaren Knoten sind jeweils mit einer Hostroute einge
tragen. Hostrouten sind erkennbar an der Netzmaske 255.255.255.255. Die
IP-Routingtabelle kann entweder mit dem Befehl n e t s t a t -r n oder mit
ip r abgefragt werden. Auf Embedded-Systemen (OpenWRT) findet man
meist das modernere iproute-Paket vor, auf Arbeitsplatzrechnern steht
blicherweise n e t s t a t zur Verfgung. Der Befehl ip r funktioniert nur
auf Systemen, die das Paket ip ro u te (oder ip ro u te 2 ) installiert haben.
Die Ausgaben beider Programme sehen unterschiedlich aus, sind aber in
haltlich gleich:

linux:- # netstat -rn

Kernel IP Ro u t e n t a b e l l e
Ziel Router Genmask F l ags M S S F e n s t e r irtt Iface
105 .1 3 0 . 7 7 . 8 0 105 .130.30. 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 UG H 0 0 0 eth2
1 0 5 .1 3 0 . 1 . 67 105.130.30. 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 UG H 0 0 0 eth2
(. . .'
1 0 5 .1 3 0 .3 0 . 1 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 UH 0 0 0 eth2

84
 4.2 Praxis mit B.A.T.M.A.N.

105.192.99.192 105.130.30.1 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 UGH 0 0 0 eth2

105.192.99.0 105.130.30.1 2 5 5 . 2 5 5 . 2 5 5 . 1 9 2 UG 0 0 0 eth2
105 . 0 . 0 . 0 0. 0.0.0 255.0.0.0 u 0 0 0 eth2
0. 0. 0. 0 0. 0.0. 0 0. 0. 0. 0 u 0 0 0 tunO

l i nux:- # ip r

1 0 5 . 1 3 0 . 7 7 . 8 0 v i a 1 0 5 . 1 3 0 . 3 0 . 1 d e v eth2
1 0 5 . 1 3 0 . 1 . 6 7 v i a 1 0 5 . 1 3 0 . 3 0 . 1 d e v eth2
1 0 5 . 1 3 1 . 4 1 . 1 v i a 1 0 5 . 1 3 0 . 3 0 . 1 d e v eth2
(...)
1 0 5 . 1 3 0 . 3 0 . 1 d e v eth 2 s c o p e link
1 0 5 . 1 9 2 . 9 9 . 1 9 2 v i a 1 0 5 . 1 3 0 . 3 0 . 1 d e v eth2
1 0 5 . 1 9 2 . 9 9 . 0 / 2 6 v i a 1 0 5 . 1 3 0 . 3 0 . 1 d e v eth2
1 0 5 . 0 . 0 . 0 / 8 d e v eth 2 p r o t o ker n e l s c o p e link src 1 0 5 . 1 3 0 . 3 0 . 3 8
d e f a u l t d e v tunO s c o p e link

Eine Installation des Kernelmoduls tun ist nur dann unntig, wenn ein
B.A.T.M.A.N.-Knoten lediglich als Meshrelais arbeitet, selbst also keine Ver
bindung zu einem Internet-Gateway aufbaut und auch kein Internet-Gate
way anbietet.

4.2.4 Visualisierungsserver

Visualisierungen von Meshnetzwerken sind beliebt und in der Praxis we

gen der schnellen bersicht ntzlich. Doch bedingt durch das Konzept des
B.A.T.M.A.N.-Algorithmus kennen die einzelnen Meshknoten die Gesamt
topologie des Meshnetzwerks nicht. Deshalb haben sich die Entwickler ei
ne Lsung ausgedacht, die es ermglicht, Topologieinformationen ber die
Gesamttopologie des B.A.T.M.A.N.-Mesh zu ermitteln. Das Fluten des ge
samten Netzwerks mit Topologieinformationen zum Zwecke der Visuali
sierung und das Erstellen einer Topologiedatenbank in jedem einzelnen
Meshknoten wie bei einem Link-State-Protokoll wrde das Gesamtkonzept
von B.A.T.M.A.N. jedoch ad absurdum fhren und den proaktiven Overhead
wieder durch die Hintertr hereinbringen.
Statt die Topologieinformationen ber das Mesh zu fluten und in jedem
Knoten zu sammeln, kann ein leistungsfhiger Visualisierungsserver bei je
dem routenden Daemon (egal ob Gateway-Client oder Gateway) mit der
Option - s angegeben werden. Die einzelnen Knoten schicken ihre Informa
tionen an den Visualisierungsserver. Der Server sammelt die Topologiein
formationen und gibt sie in einem zu Graphviz kompatiblen Format aus, so
dass die fr Olsrd zur Verfgung stehenden Visualisierungslsungen auch
mit B.A.T.M.A.N. funktionieren.
Das folgende Beispiel ruft batmandals Gateway-Client von Gateway 105.131
.41.5 mit der Routingklasse 2, aus, sorgt dafr, dass die erreichbaren Ori-

85
4 BAT.M AN. - Better Approach To Mobile Ad-Hoc Networking

ginatoren und Router per Debuggingausgabe sichtbar werden und whlt

105.192.192.230 als Visualisierungsserver aus:

b a t m a n d -d 1 -p 105. 1 3 1 . 4 1 . 5 -r 2 -s 1 0 5 . 1 9 2 . 1 9 2 . 2 3 0 athO

Es muss kein Gateway angegeben werden, wenn dieses nicht explizit fest
gelegt werden soll. Die Angabe einer Routingklasse reicht aus. Umgekehrt
muss aber bei der Angabe eines bevorzugten Gateways eine Routingklasse
angegeben werden. Ist dieses Gateway nicht erreichbar, whlt der Daemon
entsprechend der Routingklasse eine Alternative.

4.2.5 Firewalleinstellungen anpassen

batmand verwendet die Ports 1966 (UDP) fr Protokollnachrichten und Port

1967 (UDP und TCP) fr den Transport der IP-Pakete im UDP-Tunnel. Die
se beiden Ports mssen fr eingehenden und ausgehenden Datenverkehr
durch die Firewall geffnet sein. Die Portnummern knnen sich nach Er
scheinen dieses Buches im Zuge der Standardisierung des B.A.T.M.A.N.-
Protokolls und der offiziellen Vergabe durch die IANA (Internet Assigned
Numbers Authority) noch ndern.
In Computern, auf denen der B.A.T.M.A.N.-Visualisierungsserver installiert
wird, muss der UDP-Port 1968 geffnet sein, um Topologie-Nachrichten
empfangen zu knnen.
Wenn ber einen B.A.T.M.A.N.-Gateway-Client lokale Computer (die bei
spielsweise am LAN-Port des Routers angeschlossen sind) ins Internet ge-
routet werden sollen, muss zum UDP-Tunnel hin NAT eingerichtet werden.
Das folgende Beispiel ist betont einfach gehalten, und lscht im ersten
Schritt mit dem Befehl ip ta b le s -F alle eventuell bereits vorhandenen
Firewall-Regeln. 105.130.30.16 ist die IP-Adresse des Tunnelinterfaces am
B.A.T.M.A.N.-Gateway-Client:

# ! /bin/sh
iptables -F; iptables -t nat -F; i p t a b l e s -t m a n g l e -F
iptables -t nat -A P O S T R O U T I N G -o tunO -j S N A T --to 1 0 5 . 1 3 0 . 3 0 . 1 6

Auf dem B.A.T.M.A.N.-Gateway muss ebenfalls zum Internet hin NAT ein
gerichtet werden, wie im Abschnitt 3.5.2 ab Seite 69 beschrieben.

4.2.6 Webinterface fr B.A.T.M.A.N.

Fr die Freifunk-Firmware gibt es ein Webinterface von Ludger Schmudde,

mit dem der batmand mittels Webbrowser komfortabel konfiguriert und
seine Funktion beobachtet werden kann. Die Installation wird im Abschnitt
6.5.1 ab Seite 156 beschrieben.

86
 WLAN-Technik

Dieses Kapitel widmet sich der fr Mesh-Netze bentigten Technik. Wer

begierig darauf sind, einen Mesh-Router sofort auszuprobieren und einzu
richten, kann es vorerst berspringen und spter lesen - gesetzt den Fall,
man entscheidet sich fr eines der im Kapitel 6 ab Seite 125 vorgestellten
SoHO1-Router-Modelle.
Lesen sollten man dieses Kapitel aber auf jeden Fall, denn hier steht vieles,
was fr einen langfristigen Betrieb eines Mesh-Routers ntig ist, von den
WiFi-Spezifikationen ber die Eigenheiten spezieller Chipstze bis hin zu
zahlreichen praktischen Tipps fr die Praxis, etwa zur Verkabelung, Strom
versorgung oder dem Langfrist-Betrieb von Routern im Freien. Das Kapitel
ist auch fr all jene wichtig, die einen PC oder Laptop als Mesh-Router be
treiben wollen.

1 Die A bkrzung steht fr Small or Home Office.

5 WLAN-Technik

5.1 Die WiFi-Standards 802.11 von a bis Draft-n

Etabliert sind WiFi-Gerte nach den Standards des Institute of Electrical
and Electronics Engineers (IEEE) 802.11b, 802.11g und 802.11a. Der IEEE-
Standard 802.1 ln MIMO (Multiple Input, Multiple Output) ist zwar noch
nicht fertiggestellt, aber es sind bereits Produkte im Handel, die sich als
802.11 Draft-n oder Pre-n bezeichnen.

5.1.1 IEEE 802.11b/g

Die zwei am weitesten verbreiteten Standards IEEE 802.11b und 802.11g

funken in Deutschland, sterreich und der Schweiz auf 13 Kanlen im so
genannten ISM-Frequenzband bei 2,4 Gigahertz. ISM steht fr Industry,
Science, Medical und bezeichnet verschiedene Bereiche des elektroma
gnetischen Frequenzspektrums, in dem unterschiedliche Anwendungen li
zenzfrei arbeiten drfen. Der ISM-Frequenzbereich wird dabei nicht nur fr
Kommunikationstechnologie genutzt, sondern auch fr Anwendungen, bei
denen beispielsweise mit sehr hohen Sendeleistungen Hitze erzeugt wird.
Unter anderem arbeiten Mikrowellenfen in Privathaushalten im gleichen
Frequenzbereich und senden mit einigen hundert Watt innerhalb des Ge
huses. Dabei tritt immer auch ein Teil der Sendeenergie nach auen. Im
Vergleich dazu ist die maximale effektive Sendeleistung von 802.1 lb/g in
Europa mit 0,1 Watt sehr gering. Die aus dem Gehuse entweichende Str
strahlung eines Mikrowellenherds kann vor allem bei lteren oder defekten
Gerten leicht ein Vielfaches der Sendeenergie eines Funknetzes betragen,
weshalb von Mikrowellenherden verursachte Strungen in WLANs hufig
sind.
Der 2,4-GHz-Frequenzbereich wird wegen der vielen sich gegenseitig st
renden Anwendungen mitunter abwertend als Schrottband bezeichnet.
In einem kleinen Abschnitt des elektromagnetischen Spektrums von nur
60 Megahertz Breite drngeln und behindern sich viele konkurrierende An
wendungen wie beispielsweise RFID-Lesegerte, Bluetooth, drahtlose Head-
sets, Funkmuse, Funktastaturen, Videosender und auch der Amateurfunk.
Besonders hufig werden WLANs von analogen Videobertragungssyste
men gestrt, die ein Dauersignal senden.

Tabelle 5.1: Kanal Frequenz verwendet in

Kanle im
01 2.412 GHz HU, Japan, USA
2,4-GHz-Bereieh
02 2.417 GHz EU, Japan, USA
03 2.422 GHz EU, Japan, USA
04 2.427 GHz EU, Japan, USA
05 2.432 GHz EIJ, Japan, USA

88
 5.1 Die WiFi-Standards 802.11 von a bis Draft-n

Fortsetzung:

Kanal Frequenz verwendet in

06 2.437 GHz EU, Japan, USA
07 2.442 GHz EU, Japan, USA
08 2.447 GHz EU, Japan, USA
09 2.452 GHz EU, Japan, USA
10 2.457 GHz EU, Japan, USA
11 2.462 GHz EU, Japan, USA
12 2.467 GHz EU, Japan
13 2.472 GHz EU, Japan
14 2.484 GHz Japan

Das Kanalraster, also der Abstand zwischen zwei Kanalmittelpunkten, be

trgt in Amerika und Europa 5 MHz, die tatschlich verwendete Band
breite bei der Datenbertragung jedoch +/- 11 MHz, insgesamt also 22
MHz. Durch die hohe Bandbreite berlappen sich viele Kanle. Benach
barte WLAN-Funkzellen auf nahe zusammenliegenden Kanlen stren sich
gegenseitig, indem sie Interferenzen verursachen, die zu Verlusten bei der
Reichweite und der erzielbaren bertragungsgeschwindigkeit fhren. Gns
tig wre es, wenn sich die verschiedenen WLANs auf die Kanle 1, 5, 9 und
13 verteilen wrden - damit wrden vier Kanle zur Verfgung stehen, die
sich kaum berlappen.
In Europa verkaufte Gerte werden nicht selten mit einer Firmware fr die
USA ausgeliefert und gestatten nur den Betrieb auf den US-Kanlen 1 -
11. Als einziges Land gestattet Japan auch die Nutzung von Kanal 14, der
wegen seines Kanalabstands von 12 Megahertz zu Kanal 13 etwas aus dem
Rahmen fllt.
Der Betrieb eines Netzwerks auf Kanal 13 ist naheliegend, da wenige Netze
auf diesem Kanal arbeiten. Die meisten Accesspoints senden auch in Eu
ropa bevorzugt auf den Kanlen 1, 6 und 11, da sich diese Kanle nicht
berlappen und keine Probleme bei der Kanalwahl mit amerikanischen
Firmwareversionen auftreten. Wer der dichten Belegung auf den unteren
11 Kanlen ausweichen will, sollte beim Kauf darauf achten, dass alle 13
Kanle funktionieren.
802.11b und 802.11g unterscheiden sich lediglich in der erreichbaren Ge
schwindigkeit und der bei der Datenbertragung verwendeten Modulati
onsarten. 802.1 lb kann - abhngig von der bertragungsqualitt (dem Ver
hltnis des Nutzsignals zum Rauschen, Signal-to-Noise-Ratio SNR) - mit
Bruttodatenraten von 11, 5,5, 2 und 1 Megabit arbeiten. 802.11g setzt auf
Bruttodatenraten von 54, 48, 36, 24, 18, 12 und 6 Megabit. 802.11g ist ab
wrtskompatibel zu 802.11b, solange der Kompatibilittsmodus nicht ab
geschaltet ist.

89
| 5 WLAN-Technik

Die hheren Geschwindigkeiten von 802.11g erfordern ein besseres Signal-

Rauschverhltnis gegenber 802.11b. Eine hhere Datenrate hat deshalb
eine geringere Reichweite zur Folge und umgekehrt. Auf Funkstrecken, die
die normale WLAN-Reichweite berschreiten, ist 802.11g nur dann schnel
ler als 802.11b, wenn das Signal-Rauschverhltnis fr die schnelleren Da
tenraten von 802.11g ausreichend ist. Tatschlich arbeiten viele WLAN-
Karten bei gleichem Signal-Rauschabstand im b-Modus noch mit 11 Me
gabit, whrend im g-Modus die Datenrate bereits auf 6 Megabit reduziert
wird. 802.11b gehrt daher bei Langstreckenverbindungen im 2.4 GHz-Band
noch nicht zum alten Eisen. Doch die Frage, welchen Standard neue Hard
ware fr das 2,4 GHz-Band untersttzen soll, stellt sich heute kaum noch,
da Gerte nach 802.11b aus dem Handel praktisch verschwunden sind.
Einige Hersteller bewerben fr ihre Produkte Bruttodatenraten, die nicht
konform zum Standard sind, wie etwa Super-G, 802.1 lb+ oder Turbo-Mode
mit 108 Megabit. Diese Verfahren sind proprietr, funktionieren nur auf
sehr kurze Entfernungen und nur mit Karten desselben Chip-Herstellers.
Fr den praktischen Betrieb in einem Mesh sind sie deshalb kaum von Be
deutung.

5.1.2 IEEE 802.11a

802.11a unterscheidet sich von 802.11b und 802.11g vor allem durch den
verwendeten Frequenzbereich zwischen 4,9 und 5,9 GHz. Dieser Bereich
des elektromagnetischen Spektrums ist im Gegensatz zu 2,4 GHz nicht von
zahllosen Anwendungen berlaufen. Die verfgbaren Kanle weichen von
Staat zu Staat voneinander ab und der Einsatz von 802.11a ist in weitaus
weniger Lndern freigegeben als bei 802.1 lb/g. In Europa werden zwei Fre
quenzbereiche von 5,150 GHz bis 5,350 GHz und von 5,470 GHz bis 5,725
GHz verwendet. Der Betrieb im Freien ist nur im oberen Frequenzband
zugelassen. Im unteren Frequenzband ist eine maximale effektive Sende
leistung von 0,2 Watt erlaubt, im oberen Frequenzband drfen es bis zu 1
Watt sein. 802.11a konkurriert im unteren Frequenzband nur mit High Per
formance Radio Local Area Network (HIPERLAN), einem weiteren, weniger
verbreiteten Standard fr drahtlose Computernetze. Strungen von ande
ren Anwendungen sind in diesem Frequenzbereich kaum zu erwarten.
Das obere Frequenzband teilt sich 802.11a mit Radarsystemen. Dabei wird
selbstverstndlich dem Radar Prioritt eingerumt. Gerte fr 802.11a ms
sen mit einer Technologie (802.11h) ausgestattet sein, die Kollisionen mit
Radar verhindert und gegebenenfalls automatisch einen Frequenzwech
sel durchfhrt. Da ein automatischer Frequenzwechsel im Ad-Hoc-Modus
technisch schwierig zu organisieren und in 802.11a auch nicht vorgesehen
ist, ist diese Betriebsart im 5-GHz-Bereich in Deutschland nicht gestattet.
Aus diesem Grund kann 802.11a nicht legal in einem Mesh fr Multipoint-
zu-Multipoint-Verbindungen eingesetzt werden. Es lassen sich aber perfor-

90
 5.1 Die WiFi-Standards 802.11 von a bis Draft-n

mante Punkt-zu-Punkt-Verbindungen aufbauen, ber die ein Mesh Traffic

routen kann. Die zur Verfgung stehenden Bruttodatenraten sind die glei
chen wie bei 802.11g. 802.11a ist bislang viel weniger verbreitet als 802.11b
und 802.11g. Bei Elektronikdiscountern findet man Gerte fr 802.11a eher
selten im Angebot. Fr lange Funkstrecken ist 802.11a interessant, da im
Outdoor-Bereich eine Sendeleistung bis zu 1 Watt erlaubt ist und Strun
gen von anderen Funknetzen wegen der geringen Verbreitung seltener auf-
treten. Die bertragungsbandbreite betrgt bei 802.11a 20 MHz, die ver
wendeten Kanle berlappen sich nicht.
Die Tabellen 5.2 und 5.3 zeigen die Kanle im 5-GHz-Bereich, nach Zulas
sungen im Gebude oder im Freien getrennt.

Kanal Frequenz verwendet in Tabelle 5.2:

Kanle im 5-GHz-
36 5,180 GHz EU, USA, Japan
Bereich (nur in
40 5,200 GHz EU, USA, Japan Gebuden)
44 5,220 GHz EU, USA, Japan
48 5,240 GHz EU, USA, Japan
52 5,260 GHz EU, USA
56 5,280 GHz EU, USA
36 5,180 GHz EU, USA
40 5,200 GHz EU, USA
44 5,220 GHz EU, USA
48 5,240 GHz EU, USA
52 5,260 GHz EU, USA
56 5,280 GHz EU, USA
60 5,300 GHz EU, USA
64 5,320 GHz EU, USA

Kanal Frequenz verwendet In Tabelle 5.3:

Kanle im 5-G Hz-
100 5,500 GHz EU
Bereich (auch im
104 5,520 GHz EU Freien)
108 5,540 GHz EU
112 5,560 GHz EU
116 5,580 GHz EU
120 5,600 GHz EU
124 5,620 GHz EU
5 WLAN-Technik

Fortsetzung:

Kanal Frequenz verwendet in

128 5,640 GHz EU
132 5,660 GHz EU
136 5,680 GHz EU
140 5,700 GHz EU
147 5,735 GHz USA
151 5,755 GHz USA
155 5,775 GHz USA
167 5,835 GHz USA

5.1.3 IEEE 802.11n

IEEE 802.1 ln, auch als MIMO (Multiple Input, Multiple Output) bezeichnet,
bildet die Grundlage fr die nchste Generation drahtloser WLAN-Gerte.
Neben hherer Datenraten bis zu 300 Mbps sollen Gerte nach diesem
Standard eine grere Reichweite bei geringerem Stromverbrauch erzie
len. Erreicht wird die grere Reichweite und Bandbreite durch mehrere
Antennen, Sender und Empfnger in einer WLAN-Karte. Der Standard ist
noch nicht offiziell verabschiedet, es existiert jedoch seit 2006 ein vorlufi
ger Entwurf. Unter der Bezeichnung 802.11 Pre-n oder Draft-n sind bereits
Gerte erhltlich, die im 2,4 GHz-Bereich arbeiten. 802.1 ln ist jedoch nicht
auf 2,4 GHz beschrnkt und soll auch im 5-GHz-Bereich eingesetzt werden.
802.1 ln im 2,4-GHz-Bereich ist abwrtskompatibel zu 802.11b und 802.11g,
kann dann aber seine Vorteile kaum unter Beweis stellen. Die frhzeitige
Investition in Gerte, die einen unfertigen Standard implementieren, ist ris
kant - ob sich in naher Zukunft die teure, dann vermutlich bereits veraltete
Hardware auf einen aktuellen und kompatiblen Stand per Firmware- oder
Treiberupdate versetzen lsst, ist unsicher. Nicht wenige Treiber oder Firm
ware fr bereits etablierte Standards erweisen sich als unfertige Baustellen,
die nie vollendet werden. Ein Test mit einer MIMO-WLAN-Karte von Site-
com (MIMO-XR WL-150 vl 001) ergab keine Verbesserung der Reichweite
gegenber einer guten WLAN-Karte nach 802.11g.

5.1.4 Bruttodatenrate und Nettodatenrate

Die fr die unterschiedlichen WiFi-Standards angegebenen bertragungs

raten weichen deutlich von der tatschlich fr den Anwender zur Verfgung
stehenden Bandbreite ab. Die maximale bertragungsgeschwindigkeit be-

92
 5.2 Gerte fr den Aufbau eines Meshnetzwerks

trgt lediglich die Hlfte der beworbenen Angaben. 802.11b erreicht maxi
mal etwa 680 kByte pro Sekunde - das sind effektiv lediglich 5,5 MBit. WiFi
mit einer Datenrate von 54 MBit erzielt bestenfalls bis zu 3,3 MByte pro
Sekunde.

5.2 Gerte fr den Aufbau eines Meshnetzwerks

Fr die Verbindung zu einem Mesh eignen sich prinzipiell alle mit WLAN-
Karten ausgestatteten Notebooks und Arbeitsplatzrechner oder dezidierte
WLAN-Router. Besonders preiswerte WLAN-Karten oder USB-Dongles fr
Notebooks oder Desktop-Rechner sind schon fr weniger als 20 Euro zu
haben, falls der PC nicht wie heute blich WLAN bereits integriert hat. Al
lerdings treten in einem Mesh mit vielen WLAN-Karten Probleme auf, die
auf unausgereifte Treiber zurckzufhren sind. Auf diese Problematik wird
im Abschnitt 5.4 ab Seite 112 nher eingegangen.

5.2.1 SoHO-Router oder PC?

Empfehlenswert fr die meisten Anwendungsflle ist die Anschaffung eines

preisgnstigen WLAN-Routers aus dem SoHO-Bereich fr Heimanwender,
der sich mit einer alternativen Firmware zu einem Mesh-Router Umrsten
lsst. Ein geeigneter WLAN-Router mit eingebautem Ethernetswitch, der
sich durch eine alternative Firmware zu einem Meshknoten Umrsten lsst,
kostet heute etwa 40 bis 80 Euro. Die Reichweite der WLAN-Karte in einem
Router mit externer Antenne ist fast immer besser als die einer eingebau
ten WLAN-Karte im PC, und man kann den Router dort aufstellen, wo der
Empfang des Netzwerks am besten ist - auf dem Dach, am Fenster oder
auf dem Balkon. Ein wetterfestes Gehuse fr einen kleinen WLAN-Router
reit keine groen Lcher in das Budget.
Eine im Router vorhandene Firewall bietet zustzlichen Schutz fr die Com
puter der Netznutzer, die sich per Ethernetkabel mit dem Mesh-Router ver
binden knnen. Der SoHO-Router bentigt nur wenig Strom und kann rund
um die Uhr selbstndig arbeiten, um die Netzabdeckung fr andere Netz
teilnehmer zu verbessern. Ein Meshnetzwerk basiert auf dem Prinzip ge
genseitiger Hilfe - die Router helfen sich gegenseitig beim Transport von
Daten. Wenn die Anwender ihre Nodes an exponierten Standorten aufstel
len und diese permanent in Betrieb lassen, nehmen sie nicht nur als Kon
sumenten am Netzwerk teil, sondern geben auch wieder etwas durch die
Bereitstellung von Infrastruktur zurck - das Prinzip der gegenseitigen Hil
fe ist Basis eines Community-Netzwerks. Mit einem Arbeitsplatz-Computer
werden das nur wenige Anwender machen wollen, da Workstations bli
cherweise eine vernehmliche Geruschkulisse haben und die Stromrech
nung in die Hhe treiben.

93
5 WLAN-Technik

Fr die Montage an einem Mast ist ein herkmmlicher PC in einem wasser

dichten Gehuse zu sperrig - auerdem lsst dieser sich nicht ohne Weite
res mit einer ungefhrlichen Kleinspannung wie ein kleiner SoHO-Router
per Power-over-Ethernet betreiben. Die Montage eines herkmmlichen PCs
unter dem Hausdach oder am Mastfu erhht die Kosten, weil dann zu
stzliche Antennenkabel und Stecker angeschafft werden mssen. Diese
reduzieren die Reichweite und schmlern den Geldbeutel. Auerdem muss
man sich in diesem Fall mit dem Wirrwarr von instabilen Treibern und un
terschiedlichen Hardwareversionen bei der Beschaffung der WLAN-Karten
beschftigen.
Natrlich hat es auch Vorteile, einen PC oder Notebook lteren Semesters
als Mesh-Router zu verwenden. Auer dem guten Gefhl, dass die aus
gediente Hardware noch ntzlich ist, sind das vor allem die Mglichkeit,
mehrere WLAN- und Ethernet-Interfaces an einem Gert zu betreiben. Das
macht sie interessant fr Gateways oder zentrale Router an exponierten
Stellen. Auerdem knnen weitere Dienste wie File- oder Webserver dar
auf laufen, ohne die Hardware in die Knie zu zwingen. Doch der Stress
mit Stromversorgung, Konfiguration und kaprizisen WLAN-Karten wiegen
diese Vorteile selten auf.

5.2.2 WLAN-Karten fr PCs und Routerboards

WLAN-Karten fr PCs sind heute als PCI-Karten, USB-Dongles oder USB-

Adapter mit Anschlusskabel erhltlich. Fr Notebooks gibt es auerdem
PC-Cards nach den Standards PCMCIA Typ II (16 Bit-Schnittstelle mit 5 Volt
oder 3,3 Volt Betriebsspannung), Cardbus (32 Bit 3,3 Volt) oder PC-Card Ex
press. In modernen Notebooks findet sich praktisch immer auch ein Mini-
PCI-Sockel mit eingebauter WLAN-Karte nach dem Mini-PCI-Standard.
Einige im Handel erhltliche PCI-Karten sind lediglich PCI-zu-MiniPCI-
Adapter mit eingesteckter Mini-PCI-Karte unter einer Abdeckung aus Me
tallblech. Solche Adapter-Karten lassen sich mit einer leistungsfhigeren
Mini-PCI-Karte aufrsten. Das ist unter anderem eine preiswerte Methode,
um zu einer WLAN-Karte fr den WLAN-Standard 802.11a zu kommen, da
Mini-PCI-Karten vergleichsweise preiswert sind.
Der Austausch ist einfach, solange die neue MiniPCI-Karte ber die glei
che Antennenbuchse verfgt: Einfach den Deckel entfernen, Antennenka
bel abziehen und Karten tauschen. Aber: Die Mini-PCI-Karte wird ber ein
kurzes Antennenkabel (Pigtail) mit dem Antennenanschluss am Slotblech
der PCI-Karte verbunden. Sind die Antennenbuchsen auf der alten und der
neuen Mini-PCI-Karte unterschiedlich, muss auch noch ein neues Pigtail
angeschafft werden. Diese Pigtails sind relativ teuer.
PCMCIA-Karten fr Notebooks mit 5 Volt und 16 Bit sind mittlerweile ver
altet. Sie sind gebraucht oder als Restposten fr wenig Geld zu bekommen.

94
 5.2 Gerte fr den Aufbau eines Meshnetzwerks

Sie passen auch in alte Notebooks mit 486er Prozessoren oder besser, die
sich damit ihr Gnadenbrot als stromsparende WLAN-Relais verdienen kn
nen. Gerade diese lteren Karten verfgen hufig noch ber einen Anten
nenanschluss, um die Reichweite zu erhhen. Beliebt sind die alten Karten
mit den Chipstzen Lucent/Orinoco oder Prism2/2.5/3 mit Antennenan
schluss fr 802.11b. Allerdings sind auch hier die passenden Antennenste
cker oder fertig konfektionierten Adapterkabel (Pigtails) relativ teuer.
USB-Adapter sind interessant wegen der Mglichkeit, sie an einer gnsti
gen Stelle plazieren zu knnen. Ein USB-Kabel darf bis zu 5 Meter lang sein,
ist preiswert und verursacht keine Verluste beim Senden und Empfangen.
Bei der Reichweite schneiden USB-Dongles am schlechtesten ab. Sie ver
wenden in der Regel stark verkleinerte Behelfsantennen, weil beim Design
eine geringe Baugre im Vordergrund steht. Wesentlich besser sind USB-
Adapter mit ausklappbarer Antenne. Einige Bastler bringen USB-Adapter
im Fokuspunkt einer umgersteten Satellitenschssel an - damit gewinnen
sie eine Antenne mit groer Reichweite und USB-Anschluss.
Fest eingebaute PCI-Karten sind fr die Verbindung zum Mesh aus der
Wohnung oder dem Bro ungnstig, da die Antenne unter dem Tisch an
der Rckseite des Computers im elektromagnetischen Strnebel des PC
sitzt. Entsprechend gering ist die Reichweite. Zustzliche Antennen, Kabel
und Stecker zur Erhhung der Reichweite treiben die Kosten in die Hhe.
Qualitativ hochwertiges Kabel und passende Stecker sind nicht gerade billig
und verursachen immer zustzliche Verluste beim Senden und Empfangen.
Das Resultat einer solchen Lsung ist wahrscheinlich wesentlich schlechter
als bei der Anschaffung eines geeigneten SoHO-Routers.

5.2.3 SoHO-W LAN-Router

Einige dieser Router sind sehr flexibel, denn es existieren fr diese Ger
te hochentwickelte alternative Linux-Betriebssysteme. Damit werden diese
billigen Gerte zunehmend zur Konkurrenz von Produkten aus dem profes
sionellen WlSP-Bereich (Wireless Internet Service Provider).
Bei den von der Freifunk-Firmware und der OpenWRT-Version White Rus-
sian untersttzten Routern mit einem WLAN-Chipsatz der Firma Broad-
com funktioniert der Ad-Hoc-Modus reibungslos. Die neuere OpenWRT-
Version Kamikaze untersttzt auch viele andere Chipstze, unter ande
rem Atheros SoC (System on a Chip) und Chipstze von Texas Instruments.
Die Broadcom-Chipstze funktionieren erwiesenermaen mit annehmba
rer Stabilitt, auch Atheros-Chips lassen sich inzwischen mit den Open-
Source-Treibem des Madwifi-Projekts ansprechen und knnen sogar gleich
zeitig als Accesspoint und als Ad-Hoc-Station arbeiten. Die Treiber fr Chips
von Texas Instruments sind bislang ungeeignet fr den Einsatz im Mesh.
Details dazu im Abschnitt 5.3 ab Seite 104.
5 WLAN-Technik

5.2.4 Professionelle WLAN-Router

Fr einige hundert Euro sind professionelle Router aus dem WISP-Bereich

erhltlich. Bekannte Hersteller sind Mikrotik, Soekris Engineering und PC-
Engines. Diese Firmen verkaufen Routerplatinen mit mehreren Steckplt
zen fr Mini-PCI-Karten und das notwendige Zubehr zum Aufbau eines
Routers fr den Innen- oder Auenbereich. Die Mainboards kosten etwa
100 bis 200 Euro, dazu kommen dann noch Kosten fr WLAN-Karten, An
tennenkabel, Antennen, Netzteil und Gehuse. Professionelle Router sind
meistens fr den Betrieb ber Power-over-Ethernet vorbereitet und haben
mehr Rechenleistung als ein kleines SoHO-Gert. Die Problematik der un
terschiedlich gut funktionierenden Chipstze und Treiber tritt hier jedoch
genauso auf wie bei Arbeitsplatzrechnern und Notebooks.
Zu den Routerplatinen werden blicherweise Karten mit Atheros-Chips an-
geboten. Kaum eine der angebotenen Lsungen hat gengend Rechenleis
tung, um die bertragungsrate von zwei Atheroskarten auszulasten. Stan
dardmig kommen angepasste Linuxdistributionen oder BSD-Versionen
wie beispielsweise OpenBSD auf diesen Gerten zum Einsatz.

5.2.5 WLAN-Router im Selbstbau

Wenn man bereit ist, Geld fr qualitativ hochwertige Antennenkabel und

Stecker auszugeben oder geeignete USB-Hardware nebst Treiber zur Verf
gung hat, kann man mit einem alten PC einen sehr leistungsfhigen Rou
ter aufbauen. Hier steht die enorme Vielfalt von Applikationen unter Li
nux oder BSD-Varianten zur Verfgung, und der Router kann mit seiner
weitaus hheren Rechenleistung Daten sehr viel schneller transportieren
als ein kleines SoHO-Gert. Mehrere Netzwerkinterfaces knnen auch dann
eingesetzt werden, wenn WLAN-Karten auf der CPU Rechenlast verursa
chen. Auch die Rechenlast durch ein proaktives Routingprotokoll in einem
groen Meshnetzwerk ist kein Problem, und es bleiben immer noch genug
Ressourcen brig, um den Computer fr andere Serverdienste zu nutzen.
Nachteilig ist natrlich die Gre der Gerte und die Stromversorgung so
wie die Unzuverlssigkeit eventuell verschlissener Hardware (vor allem ge
alterte Elektrolytkondensatoren in Netzteilen). Am ehesten wird man ein
solches Gert auf dem Dachboden direkt unter dem Dachfirst montieren
und Antennenkabel nach drauen verlegen. Als Core-Router an einem zen
tralen Knotenpunkt im Mesh eignet sich ein umgersteter PC hervorra
gend, insbesondere wenn ber mehrere Punkt-zu-Punkt-Verbindungen ein
drahtloser Backbone aufgebaut werden soll.
Kommen mehrere WLAN-Schnittstellen zum Einsatz, relativiert sich der
grere Stromverbrauch und der Anschaffungspreis fr qualitativ hochwer
tige Kabel und Stecker im Vergleich zu mehreren Embedded-Gerten recht
schnell - vier SoHO-Router einschlielich ihrer Netzteile mit zustzlichen

96
 5.2 Gerte fr den Aufbau eines Meshnetzwerks

Antennenkabeln, Antennensteckern und leistungsfhigen Antennen sind

auch nicht wesentlich sparsamer oder preiswerter als ein PC mit mehreren
WLAN-Karten. Vor allem der Einsatz von USB-WLAN-Karten ist preislich
attraktiv - ein USB-Kabel hat keine Verluste und kostet nicht viel.
PCs von der Leistungsklasse eines AMD K6 oder Pentium II oder III geh
ren fr die meisten Anwender bereits zum alten Eisen, das gerne fr einen
guten Zweck verschenkt wird. Die gemessene Leistungsaufnahme eines sol
chen Rechners betrgt etwa 25 bis 30 Watt, wenn kein allzu schlechtes oder
berdimensioniertes Netzteil verwendet wird.
Die Grafikkarte oder CD-Laufwerke und andere Komponenten kann man
getrost ausbauen und anderweitig verwenden - sie bentigen ohnehin nur
Strom, und kaum jemand wird zur Wartung einen Monitor auf den Dach
boden schleppen. Fr Wartungsarbeiten sollte man eine serielle Linuxkon-
sole einrichten und sich ber ein serielles Kabel per Terminalemulation2
mit dem Router verbinden, wenn dieser wegen einer Strung nicht mehr
ber seine Netzwerkinterfaces erreichbar ist. Fr den Anwendungszweck
als Meshrouter gibt es bereits angepasste Linuxdistributionen wie beispiels
weise Pyramid-Linux3 oder Meshlinux,4 welche die Einrichtung eines sol
chen Routers vereinfachen und mehr Treiber fr WlJ\N-Karten mitbringen
als eine Linuxdistribution fr Arbeitsplatzrechner.

5.2.6 HF-Steckverbinder

Seit der Einfhrung der ersten WiFi-Gerte sind deren Preise kontinuierlich
gefallen, die fr Antennen, Kabel und Stecker aber praktisch unverndert
geblieben. Vor allem die Preise fr geeignete WLAN-Antennenstecker und
Buchsen sind berhht. Die amerikanische Regulierungsbehrde fr Kom
munikationstechnologie (FCC) hat bei der Einfhrung der WLAN-Gerte
darauf bestanden, dass dort keine genormten, handelsblichen Hochfre
quenzverbinder zum Einsatz kommen drfen. Damit sollte der reichwei
tensteigernde Einsatz von gewinnbringenden Antennen oder Verstrkern
unterbunden oder zumindest erschwert werden.
So kamen bald - teure - HF-Stecker mit einem weiblichen Innenkontakt
und HF-Buchsen mit einem mnnlichen Innenkontakt in den Handel, mit
der Zusatzbezeichnung Reverse oder Reverse Polarity. Der Aufbau die
ser HF-Verbinder (Reverse-SMA, Reverse-TNC) entspricht ansonsten den
blichen HF-Steckern und -buchsen (SMA, TNC). Ein hochwertiger Reverse-
HF-Verbinder kostet etwa dreimal soviel wie ein Standardverbinder. Beson
ders teuer sind Miniaturstecker zum Anschluss an PC-Cards und Mini-PCI-
Karten, falls sie berhaupt erhltlich sind (Hirose, MMCX, Lucent).

2 ht t p ://tldp.org/HOWTO/Text-Terminal-H0WT0-4.html
3 http://pyramid.metrix.net
4 http://open-mesh.net/meshlinux
5 WLAN-Technik

Reverse-Verbinder sind nur zum Anschluss an die WLAN-Gerte erforder

lich, ansonsten knnen qualitativ hochwertige Normstecker und -buchsen
verwendet werden. Verbinder nach der N-Norm sind besonders robust, ver
lustarm und zuverlssig. Die meisten Antennen werden ber eine N-Buchse
angeschlossen.
Vorsicht beim Kauf allzu gnstiger Steckverbinder oder Einbaubuchsen zum
Selbstbau von Antennen: WLAN arbeitet mit hohen Frequenzen und stellt
entsprechend hohe Ansprche an Kabel und Steckverbinder. Hochwertige
Steckverbinder verwenden als Isolatoren Teflon, welches sehr gute Hoch
frequenzeigenschaften hat und beim Lten temperaturbestndig ist. Bil
ligramsch wird leider auch in diesem Produktbereich hergestellt und hat
auch im Neuzustand nicht einmal den Schrottwert, wenn neben dem r
ger auch die verschwendete Arbeitszeit mit einkalkuliert wird. Wenn beim
Lten das weie Isolationsmaterial schon weggeschmolzen ist, bevor das
Ltzinn fliet, hat man Mll eingekauft.
Auch wenn hier nicht am falschen Ende gespart wird, sind Verluste unver
meidlich. Deshalb ist es zweckmig, WLAN-Systeme nach Mglichkeit so
zu konzipieren, dass sie ohne zustzliche HF-Komponenten auskommen.

5.2.7 Koaxialkabel

Zur bertragung von elektromagnetischen Wellen in WLAN-Systemen die

nen abgeschirmte Koaxialkabel. Diese unterscheiden sich lediglich in ih
rer Impedanz und Qualitt von den abgeschirmten Koaxialkabeln, die z. B.
beim TV-Empfang eingesetzt werden.
Koaxiale Leitungen bestehen aus einem Innenleiter und einer Abschirmung,
zwischen denen sich eine Isolationsschicht befindet, das Dielektrikum. Die
Wellenbertragung findet nicht im Metall des Innenleiters statt, sondern
im Dielektrikum zwischen den Oberflchen des Innen- und Auenleiters.
Wichtige Vergleichswerte fr WLAN-Kabel sind die Impedanz oder der Wel
lenwiderstand des Kabels in Ohm (fr WLAN immer 50 Ohm) und die Ver
luste in Dezibel (siehe auch Abschnitt 7.1 ab Seite 170), die in der Leitung
fr die angegebenen Frequenzen entstehen. Da die Frequenzen von WLAN
sehr hoch sind, sind auch die Ansprche an die Leitungen hoch. Die Ver
luste entstehen vor allem im Dielektrikum und steigen mit der Frequenz.
Als Materialien fr das Dielektrikum werden vor allem Polyethylen und Luft
eingesetzt. Luft ist ein verlustarmes Dielektrikum, Polyethylen hat dagegen
wesentlich schlechtere Eigenschaften.
Koaxialkabel lterer Bauart haben ein massives Dielektrikum aus Polyethy
len und weisen relativ groe Verluste auf. Diese Kabel sind preiswert und
mechanisch ziemlich robust. Ebenso wie bei Stromleitungen haben dnne
re Koaxkabel wesentlich hhere Verluste als dicke.

98
 5.2 Gerte fr den Aufbau eines Meshnetzwerks

Moderne Koaxialkabel ersetzen das massive Dielektrikum durch eines mit

mglichst hohem Anteil von Luft - anstatt massivem Kunststoff werden bei
spielsweise Kunststoffschume oder Luftzellen eingesetzt, die durch Kunst
stoffstege abgetrennt sind. Diese modernen Kabel sind sehr teuer und ms
sen sachgerecht behandelt werden. Auf keinen Fall drfen sie scharf ge
knickt oder in irgendeiner Weise gequetscht werden. Wenn der Innenleiter
an einer Stelle der Koaxialleitung nicht mehr zentrisch innerhalb des Quer
schnitts sitzt, kann man das Leitungsstck verschrotten. Zu den Koaxialka
beln gibt es Datenbltter - man sollte unbedingt bei der Handhabung und
beim Verlegen den angegebenen minimalen Biegeradius bercksichtigen.
Die schnste Installation ist nach kurzer Zeit unbrauchbar, wenn Wasser
in Koaxialleitungen und Steckverbinder eindringt und sich durch die Kapil
larwirkung innen ausbreitet. Die Schwachstellen fr eindringende Feuch
tigkeit sind beschdigte uere Isolationsschichten und die bergnge zu
Steckverbindern. Gecrimpte Stecker sind unbrauchbar, wenn der Aufstel
lungsort den Witterungseinflssen ausgesetzt ist, da sie niemals wirklich
dicht genug sind, um die Kapillarwirkung auszuschlieen. Deshalb sollten
im Auenbereich unbedingt solide geschraubte Stecker verwendet werden,
die innen eine Dichtung haben.
Zustzlich sollte man die Verbindungen mit selbstvulkanisierendem Spezi
alklebeband aus dem Elektronik-Fachhandel umwickeln. Wenn es um die
zu schtzenden Stellen gewickelt wird, muss es unbedingt um einen vor
gegebenen Betrag gestreckt werden, der in der Gebrauchsanleitung nach
zulesen ist. Diese Bandage wird zu einem enganliegenden Gummischlauch
hnlich einem Schrumpfschlauch.
Das selbstvulkanisierende Klebeband sollte mit PVC-Klebeband umwickelt
werden. Manche Vgel oder andere Tiere knabbern gerne an dieser Gum
mimischung und knnen so im Laufe der Zeit den Ausfall eines Systems
herbeifhren. Auf diese Weise haben Krhen in Bangladesh den Ausfall ei
nes VSAT-Systems verursacht, durch den sehr hohe Kosten entstanden sind.

5.2.8 Gehuse

Oft verwenden Bastler die bekannten Tupperwaredosen als wasserfeste Be

hlter fr die Auenmontage eines SoHO-Routers. Das erweist sich beson
ders an heien Sommertagen als schlechte Idee, da sich durch den trans
parenten Kunstoff die Luft in der Dose stark aufheizt. Ein deutliches An
zeichen dafr, dass es zu hei hergeht, ist die sichtbare Verformung des
Routergehuses.
Selbst wenn der Router am ersten wirklich heien Sommertag durch ber
hitzung noch nicht in die ewigen Jagdgrnde eingegangen ist, verschlei
en die elektronischen Komponenten recht schnell. Vor allem die Elektro
lytkondensatoren in der internen Spannungsstabilisierung haben nur eine
5 WLAN-Technik

begrenzte Lebensdauer, wenn sie hohen Umgebungstemperaturen ausge

setzt sind. In den Halbleiterchips tritt auerdem bei so hohen Tempera
turen verstrkt ein als Elektromigration bezeichneter Effekt auf: Bei hohen
Temperaturen tragen die flieenden Strme Material von den chipinternen
Leiterbahnen ab, die auf diese Weise immer dnner werden. Die Chips al
tern unter hohen Temperaturen auf diese Weise recht schnell und erzeu
gen willkrliche und schwer nachvollziehbare Fehlfunktionen. Auch mit
der UV-Bestndigkeit einer Tupperbox ist es nicht weit her. Der Kunststoff
wird wahrscheinlich nach kurzer Zeit einreien, wenn er mechanisch be
lastet wird, oder einfach auseinanderfallen.
Empfehlenswert sind hingegen helle Gehuse aus Aluminium, verzinntem
Stahlblech oder UV-bestndigem hellen Kunststoff, die sich unter direkter
Sonneneinstrahung wenig aufheizen. Metallgehuse sollten unbedingt mit
einer hellen, deckenden Farbe lackiert sein. Auch wenn man es anders ver
muten wrde, heizen sich blanke oder mit Klarlack berzogenen Metallge
huse in der Sonne stark auf. Wetterfeste weie oder hellgraue Kunststoff
gehuse - zum Beispiel elektrische Anschlussdosen fr den Auenbereich
mit hoher Schutzklasse nach IP-Norm IP64 oder hher - eignen sich besser
als eine Dose fr das Gefrierfach. Die Tupperdose sollte man nur fr hit
zebestndige und einfach zu ersetzende Komponenten verwenden, z. B. fr
selbstgebaute Quadantennen.
Zustzlich ist es empfehlenswert, bei Gehusen im Auenbereich einen
Sonnenschutz vorzusehen, um die Innentemperatur bei direkter Sonnen
einstrahlung zu senken.
Gehuse sollten im Auenbereich niemals hermetisch dicht sein, sondern
am Boden an der tiefsten Stelle zumindest eine Entlftungsbohrung ha
ben. Auf wasserdichte Kabeldurchfhrungen kann man daher verzichten,
wenn sie an der Unterseite des Gehuses montiert sind. Versucht man ein
Gehuse mglichst dicht zu bekommen, sammelt sich darin nach lnge
rem Betrieb unter Garantie eine grere Menge Wasser an. Ein Gehuse -
zumal eines mit mehreren Durchbrchen fr Netzwerkkabel, Stromversor
gung, Antennen oder Antennenkabel - ist nie absolut dicht.
Wenn es nicht entlftet ist, lsst sich durch Temperaturschwankungen fol
gender Effekt beobachten: Tagsber erwrmt sich das Gehuse stark, im
Gehuse entsteht durch die Ausdehnung der erwrmten Luft ein ber
druck, der irgendwie entweicht. Nachts entsteht durch die Abkhlung ein
Unterdrck, kalte Luft wird nach innen gesaugt und bringt Feuchtigkeit mit.
Dieser Prozess wiederholt sich, dabei entweicht tagsber die nachts einge
saugte Feuchtigkeit nicht oder nur zu einem Teil. Durch diesen sich wie
derholenden Prozess fllt sich das Gehuse nach und nach teilweise mit
Wasser, welches frher oder spter die Installation durch Korrosion oder
Kurzschlsse in der Elektronik beschdigt.

100
 5.2 Gerte fr den Aufbau eines Meshnetzwerks

5.2.9 Typische Hardware-Probleme im Ad-Hoe-Modus

Theoretisch sollte jedes Gert, welches auf seiner Packung das Logo WiFi-
kompatibel" trgt, ohne Schwierigkeiten mit Gerten aller anderen Herstel
ler sowohl im Infrastruktur- als auch im Ad-Hoc-Modus Zusammenarbei
ten. In der Praxis funktioniert kaum eine WLAN-Karte korrekt im Ad-Hoc-
Modus.
Da die meisten Anwender WLAN bislang fast ausschlielich im Infrastruk
turmodus mit einem Accesspoint betreiben, vernachlssigen die Hersteller
die korrekte Funktion der Ad-Hoc-Betriebsart. Dazu kommt, dass der Ad-
Hoc-Modus von 802.11 einigermaen komplex ist. Verglichen damit ist der
Infrastruktur-Client-Modus weitaus einfacher zu implementieren. In Kom
bination mit der von vielen Firmen angewandten Bananen-Taktik (das Pro
dukt reift beim Kunden) darf sich der Anwender bei der Verwendung der
Ad-Hoc-Betriebsart in einem Meshnetzwerk auf einigen rger gefasst ma
chen - und das nicht nur bei kleineren Firmen, sondern auch bei groen
Herstellern wie Intel, von denen man solidere Entwicklungsarbeit erwarten
wrde.
Unabhngig von der verwendeten Bauform oder dem Hersteller der WLAN-
Karte ist bei der Wahl der Hardware deshalb neben der Qualitt vor allem
der in der Karte verwendete Chipsatz kaufentscheidend. Fr den Einsatz in
Meshnetzwerken ist die Auswahl sehr begrenzt, da kaum ein Chipsatz auf
dem Markt richtig im Ad-Hoc-Modus funktioniert. Die Probleme liegen in
den Hardwaretreibern und/oder der zum Chipsatz zugehrigen Firmware.
Deshalb ist es oft gleichgltig, unter welchem Betriebssystem eine WLAN-
Karte eingesetzt wird.
Auch unter Open-Source-Betriebssystemen liegt die Firmware nur als Bi
nrdatei vor und ist urheberrechtlich geschtzt. Wenn sie manipuliert wer
den knnte, wre bei vielen WLAN-Karten der Betrieb auf nicht zugelasse
nen Frequenzen oder mit berhhter Sendeleistung mglich. Daher wer
den die Quelltexte und Details der Firmware von der Herstellern unter Ver
schluss gehalten und knnen nicht legal verndert werden. Man ist also bei
Firmwareproblemen von der Bereitschaft der Hersteller abhngig, Fehler
zu beheben.
Bis heute arbeitet beispielsweise die Firmware fr die WLAN-Karten von
Intel mit dem Chipsatz IPW2200 im Ad-Hoc-Modus fehlerhaft. Da dieser
Chipsatz mittlerweile schon wieder Schnee von gestern ist, steht zu be
frchten, dass eine funktionierende Firmware nie verfgbar sein wird.
Es ist bei der Mehrheit der PC-Notebooks reine Glcksache, ob sich eine
brauchbare Verbindung zu einem Meshnetzwerk herstellen lsst. Die An
wender vermuten hufig schlechten Empfang als Ursache bei nicht funk
tionierenden Verbindungen - dabei sind allzu oft Fehler in den Treibern
oder in der Firmware verantwortlich. Deutlich wird das, wenn mehrere Ge-
I 5 WLAN-Technik

rte auf dem gleichen Tisch stehen und partout nicht miteinander reden"
wollen. Welcher Besitzer eines Autos wrde es akzeptieren, wenn die Werk
statt den defekten Rckwrtsgang in einem Neuwagen mit einem Schulter
zucken quittiert und den Mangel als Selbstverstndlichkeit betrachtet, mit
der man sich abzufinden hat? Na, bitte! Vorwrts fhrt er doch!
Ein mglicher Weg zur Abhilfe bestnde darin, dass mehr und mehr Kun
den konsequent auf ihre Rechte als Verbraucher bestehen. Schlielich ist
ein Auto, das einen defekten Rckwrtsgang hat, ebenso wie eine WLAN-
Karte, die nicht im Ad-Hoc-Modus arbeitet, ein defektes Produkt, auf des
sen Reparatur man bestehen kann. Ist der Hersteller nicht in der Lage, ein
funktionierendes Produkt anzubieten, ist man selbstverstndlich berech
tigt, vom Kaufvertrag zurckzutreten.

Die Situation bei Linux-Treibern

In der Linuxwelt sieht die Treibersituation im Augenblick eher schlecht au

auss. In der Vergangenheit haben die Entwickler von WLAN-Treibern die
Funktionalitt von 802.11 fr die meisten Chipstze auf eigene Faust imple
mentiert und damit das Rad immer wieder neu erfunden. Vielfach mangelt
es den Entwicklern dabei am grundstzlichen Verstndnis von IEEE 802.11
- der Standard umfasst einige hundert Seiten und gengend Diagramme,
um eine Wohnung zu tapezieren.
Inzwischen kann man auf eine Verbesserung der Situation hoffen, da es
einen neuen Ansatz im Linuxkernel gibt. Statt jedem Programmierer die Im
plementierung von 802.11 selbst zu berlassen, gibt es mittlerweile einen
soliden 802.11-Stack (d80211, inzwischen umbenannt in mac80211), den
die Firma Devicescape unter GPL gestellt hat und der ab Kernelversion
2.6.22 oder 2.6.23 Bestandteil des Linuxkernel werden soll. Inzwischen ar
beiten einige WLAN-Treiber-Projekte daran, ihre Software fr den neuen
802.11-Stack anzupassen.
Unter Linux muss ein Treiber nicht fr eine spezifische Karte eines be
stimmten Herstellers installiert werden, wie man es von der Windows-Welt
gewohnt ist. Es ist also nicht so, dass ein Treiber fr die Karte der Mar
ke XY sich weigert, mit der Karte der Marke WZ zu funktionieren, obwohl
beide vom gleichen OEM-Hersteller stammen. Entscheidend ist, ob es fr
den in der Karte verwendeten Chipsatz einen funktionierenden Treiber gibt
und ob Linux den von der Karte ausgegebenen Typcode einem bestimmten
Chipsatz zuordnen kann.
Einige Chiphersteller wie Zydas, Realtek und Ralink bieten selbst Linux-
Treiber als Sourcecode an, doch dieser kompiliert oft nicht gegen den ak
tuellen Linuxkernel. Da jener sich fortlaufend weiterentwickelt, mssten
auch die Treibersourcen an neuere Versionen des Kernels angepasst und
gewartet werden. Eine Arbeit, die die Hersteller meist nicht tun und fr die

102
 5.2 Gerte fr den Aufbau eines Meshnetzwerks

sich manchmal auch kein freier Entwickler findet. Doch immerhin stoen
die Hersteller damit aktiv die Entwicklung von Treibern fr Linux an. Gu
te Hardware hat auch einige Zeit, nachdem sie vom Markt verschwunden
ist, noch ihre Fans - so kommen die Anwender oft zu einer Stabilitt und
Funktionsvielfalt, die proprietre Treiber nur bei wenigen, wirklich serisen
Firmen erreichen.

Ndiswrapper - Windows-Treiber unter Linux als Behelfslsung

Sofern der Hersteller einen gut funktionierenden Treiber mit brauchbarer

Firmware fr Windows bereitstellt, kann bei fehlendem Linux-Treiber als
Notlsung das Programm Ndiswrapper weiterhelfen. NDIS (Network Device
Interface Specification) ist eine von Windows vorgegebene Schnittstellen
spezifikation fr Netzwerkkarten. Ndiswrapper (to wrap bedeutet auf Eng
lisch einw ickeln) arbeitet als Kompatibilittsschicht, die als Vermittler zwi
schen dem Linuxkernel und dem Windowstreiber fungiert. Damit lassen
sich die Funktionen der Netzwerkkarte durch den Windowstreiber unter
Linux nutzen. Dazu bentigt man den Treiber fr Windows XP, die Firm
ware (falls bei der Initialisierung der Karte ein Firmwareupload in die Karte
erforderlich ist) und die dazugehrende Installationsdatei mit der Endung
.INF. Ndiswrapper besteht aus dem Dienstprogramm ndisw rapper und
einem gleichnamigen Kernelmodul.
Auf der Webseite des Ndiswrapper-Projekts ist die Hardware aufgelistet, die
mit Ndiswrapper erfolgreich getestet wurde. Auch die passenden Treiber
und Firmwaredateien sind dort zu finden. Sollte die betreffende Karte dort
noch nicht aufgelistet sein, lohnt sich ein Versuch mit den Windowstrei
bern von der CD des Anbieters. Die erforderlichen Dateien sind norma
lerweise in einem Cab-Archiv oder einem selbstextrahierenden Zip-Archiv
verpackt. Cab-Dateien lassen sich mit dem Befehl c a b e x tr a c t unter Li
nux auspacken, selbstextrahierende Zip-Archive (Dateiendung . exe) kn
nen mit dem Befehl unzip geffnet werden. Gelingt das nicht, fhrt man
die Installation auf einem Windowssystem durch. Anschlieend verrt der
Windows-Gertemanager, welchen Treiber die Hardware verwendet.
Die bentigten Dateien aus dem Windows-System kopiert man unter Linux
zunchst in ein beliebiges Verzeichnis. Den Befehl

n d i s w r a p p e r -i I n f - D a t e i - d e s - W i n d o w s t r e i b e r s .inf

fhrt man mit Administratorrechten in dem Verzeichnis aus, das die Trei
berdateien enthlt. Er installiert den Windowstreiber in Ndiswrapper. Das
Kommando

n d i s w r a p p e r -1

103
5 WLAN-Technik