0

Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik

Studienarbeit

Steuerung einer Hausautomatisierungsanlage über Wireless LAN

vorgelegt von: Roman Komoll geboren am: Studiengang: Elektrotechnik und Informationstechnik Studienrichtung: Informations- und Kommunikationstechnik Verantwortlicher Professor: Prof. Dr. rer. nat. habil. Jochen Seitz Betreuender wiss. Mitarbeiter: Dipl.-Ing. Michael Heubach Ilmenau, den 12.03.2005

1

Inhaltsverzeichnis

1 Einleitung ......................................................................................................................7 2 Grundlagen ...................................................................................................................9

2.1 Anwendungsszenarien ...........................................................................................9 2.1.1 Personal Area Network ................................................................................10

2.2 Gerätetypen ..........................................................................................................10 2.3 Der Standard IEEE802.11....................................................................................11 2.4 Aufbau..................................................................................................................12 2.5 Architekturen .......................................................................................................13

2.5.1 Systemarchitekturen (Netzwerk-Topologien)..............................................13 2.5.2 Protokollarchitektur .....................................................................................15

2.6 Kanalzugriff und Rahmenstruktur........................................................................16 2.6.1 Zugriffsverfahren .........................................................................................16 2.6.2 Rahmenformate ............................................................................................18 2.6.3 Fragmentierung von langen Nachrichten .....................................................19 2.6.4 Verwaltung von Stationen............................................................................20 2.6.5 Adressierung von Stationen .........................................................................23 2.6.6 Synchronisation............................................................................................23 2.6.7 WLAN und TCP/IP......................................................................................23

2.7 Bitübertragung .....................................................................................................24 2.7.1 Einordnung...................................................................................................24 2.7.2 Direct Sequence Spread Spectrum...............................................................25

3. Das Basisgerät des LISTIG-Systems ........................................................................29 4. Auswahl des Schnittstellenadapters .........................................................................30

4.1 Vorbetrachtung.....................................................................................................30 4.2 Auswahl der WLAN-Geräte ................................................................................33

4.2.1 Kriterien .......................................................................................................34 4.2.2 Schnittstellen von LISTIG ...........................................................................35 4.2.3 Hardware ......................................................................................................36

5 Wireless LAN und Linux...........................................................................................37 5.1 Grundlegendes .....................................................................................................38

5.1.1 Chipsatz........................................................................................................38 5.1.2 Software-Voraussetzungen ..........................................................................38 5.1.3 Treiber ..........................................................................................................38

5.2 Grundkonfiguration..............................................................................................41 5.2.1 Konfiguration der Standard-Treiber.............................................................41

5.3 Treiber selbst kompilieren ...................................................................................42 6 Inbetriebnahme der WLAN-Schnittstelle................................................................43

6.1 Der Linux Kernel und Wireless LAN ..................................................................43 6.2 Konfiguration der PCMCIA Card Services .........................................................44 6.3 Einrichtung der Konfigurationssoftware..............................................................47 6.4 Konfiguration des Wireless LAN.........................................................................48

6.4.1 Basiskonfiguration .......................................................................................48 6.4.2 Automatische Netzkonfiguration während des Systemstarts.......................50 6.4.3 Verschlüsselung ...........................................................................................50 6.4.4 Automatische Konfiguration durch die PCMCIA Card Services ................51 6.4.5 Testen der Verbindung.................................................................................52

2

6.5 Probleme während der Testphase ........................................................................59 6.5.1 Der PCI-to-PCMCIA/PCCARD-Adapter unter Linux ................................59 6.5.2 Die Nokia D211 Card unter Linux...............................................................61 6.5.3 Die ARTEM ComCard (IEEE 802.11g) ......................................................63

7 Bewertung der Verbindungsqualität........................................................................66 7.1 Grundlegendes .....................................................................................................66 7.2 Messungen ...........................................................................................................67 7.3 Beobachtungen und Schlussfolgerungen .............................................................70

8 Sicherheit und Authentifizierung .............................................................................72 8.1 Sicherheitsaspekte ................................................................................................72 8.2 WEP .....................................................................................................................73 8.3 Authentifizierungsmechanismen..........................................................................77 8.4 Vertraulichkeit .....................................................................................................79 8.5 Exkurs: Der HostAP-Treiber auf dem LISTIG-System.......................................82 8.6 Fazit......................................................................................................................83

9 Störungsfreier Funkbetrieb ......................................................................................83 10 Abschlussbemerkungen .........................................................................................84 Anhang ................................................................................................................................86

Den Treiber der WLAN-Karte manuell aktualisieren......................................................86

2

Abbildungsverzeichnis

Abbildung 2.1 Gliederung der Betriebsarten im IEEE801.11.......................................... Abbildung 2.2 Architekturen der Betriebsarten im IEEE802.11.................................... Abbildung 2.3 Die Dienstzugangspunkte der MAC und PHY-Schichten im IEEE802.11........................................................................................ Abbildung 2.4 Kanalzugriff........................................................................................... Abbildung 2.5 RTS/CTS-Ablauf.................................................................................. Abbildung 2.6 PLCP bei 802.11/11b.............................................................................. Abbildung 2.7 MAC-Rahmen bei 802.11....................................................................... Abbildung 2.8 Zusammenwirken der Standards............................................................. Abbildung 2.9 Offene Authentifizierung von Stationen................................................. Abbildung 2.10 Authentifizierung von Stationen durch gemeinsame Schlüssel.............. Abbildung 2.11 Unidirektionaler TCP-Verkehr über ein WLAN mit CSMA/CA-MAC............................................................................. Abbildung 2.12 Algorithmus einer expliziten Anmeldung................................................ Abbildung 2.13 Kanalaufteilung 2,4 GHz......................................................................... Abbildung 2.14 Kanalvergabe-Beispiel............................................................................ Abbildung 2.15 DSSS für 1/2 Mbit/s................................................................................. Abbildung 2.16 QPSK-Phasendiagramm.......................................................................... Abbildung 2.17 CCK-Erzeugung..................................................................................... Abbildung 2.18 Kanalzuordung beim DSSS-Verfahren im IEEE802.11..................... Abbildung 3.1 Die Hauptplatine des Basisgerätes...................................................... Abbildung 3.2 Der Versuchsaufbau des Projekts LISTIG.......................................... Abbildung 4.1 Erfolgreiche Installation mit dieser PCI-WLAN-Karte....................... Abbildung 6.1 IP über Wireless LAN 802.11b Ad-Hoc-Modus................................ Abbildung 6.2 Netzwerkverbindungen...................................................................... Abbildung 6.3 IP-Einstellungen..................................................................................... Abbildung 6.4 Windows die Konfiguration abnehmen................................................ Abbildung 6.5 Netgears Konfigurationswerkzeug........................................................ Abbildung 6.6 Profileinstellungen der drahtlosen Verbindung..................................... Abbildung 6.7 Erfolgreiche Verbindung..................................................................... Abbildung 6.8 Notebook pingt Basisgerät.................................................................... Abbildung 6.9 Konfigurationsfenster der Client-Anwendung..................................... Abbildung 6.10 Übertragung einer Zeichenkette............................................................ Abbildung 6.11 Nokia Multimode Card......................................................................... Abbildung 7.1 Messung der Verbindungsqualität mit Network Stumbler................. Abbildung 8.1 Gefährdungen..................................................................................... Abbildung 8.2 Einordnung der verschiedenen Sicherheitstechniken......................... Abbildung 8.3 WEP-Funktionsweise......................................................................... Abbildung 8.4 WEP-Authentifizierung....................................................................... Abbildung 8.5 EAP-Anwendung bei WLANs............................................................ Abbildung 8.6 Diffie-Hellman................................................................................... Abbildung 8.7 RSA-Authentifizierung....................................................................... Abbildung 8.8 X-Window über SSH-Tunnel.................................................................

3

Tabellenverzeichnis

1.1 Vergleich der verbreiteten drahtlosen Übertragungstechniken.............................. 2.1 Semantik der MAC-Adressen................................................................................ 6.1 Kernel-abhängige Versionsnummer bei Wireless Extensions 7.1 Messwerte Netzwerk-Durchsatz, 2m..................................................................... 7.2 Messwerte Netzwerk-Durchsatz, 2m................................................................. 7.3 Messwerte Verbindungsqualität..............................................................................

4

Gebräuchliche Abkürzungen und Begriffe

Begriff Bedeutung

Access Control List (ACL) Die Liste der Hardwareadressen (MAC-Adressen) der Stationen, die sich beim jeweiligen Access Point oder Router einbuchen dürfen. Mit einigen Tricks kann eine Hardwareadresse jedoch gefälscht werden, die Access Control List sollte nicht die einzige Absicherung eines WLANs sein.

Access Point (AP) Basisstation, arbeitet wie ein Netzwerk-Switch und verteilt Daten zwischen den Stationen. Moderne Access Points haben zusätzlich eine Netzwerkschnittstelle und arbeiten als Bridge.

Bridge (BRG) Verbindet drahtlose und drahtgebundene Netze miteinander. Wireless Bridges sind heute selten, da die meisten Access Points gleichzeitig als Bridge arbeiten.

Basic Service Set (BSS) Steht für die Summe alle Stationen mit der gleichen Kennung (SSID, BSSID) in einer ..Managed Infrastructure".

Basic Service Set Identifier (BSSID) Hardwareadresse (MAC-Adresse) des Access Points. bei Ad-Hoc (BSSID) Netzwerken die Hardwareadresse einer (bevorzugten) Gegenstation.

Extended Service Set (ESS) Bezeichnet die Gesamtheit aller miteinander (über Distribution Systems) verbundener drahtloser und drahtgebundener Netze.

Extended Service Set Identifier (ESSID)

Kennung oder Name eines Gesamtnetzes (ESS). Sinnvollerweise ein Identifier (ESSID) Firmen- oder Abteilungsname.

5

Independent Basic Service Set (IBSS)

Steht für die Summe aller Stationen eines Ad-Hoc-Netzes mit gleicher (laSS) Kennung (SSID, ESSID).

Initialization Vector (IV) 3 Bytes lange, fortlaufende Paketnummer, die jedem Datenpaket hinzugefügt wird. Sie beschränkt die Länge des geheimen Schlüssels bei WEP auf 104, respektive 40 Bit, mit ihr zusammen ist der Paketschlüssel dann 128 (WEP-128), respektive 64 (WEP-64) Bit lang.

Router Steht meist für Access-Router oder Wireless-Router, solche Geräte enthalten oft Modems, ISDN-Adapter oder einen Anschluss zum DSLModem, um selbst als Zugangsknoten (Gateway) zum Internet zu fungieren. Je nach Ausstattung haben sie noch Firewalls. Mail-Server oder .... einen Netzwerk-Switch für drahtgebundene Clients eingebaut.

Service Set Identifier (SSID) Kennung oder Name eines Netzes, meist ist die ESSID gemeint.

Station (STA) Alle Wireless-Geräte, also Karten, Access Points. Router und Bridges.

Wired Equivalent Privacy (WEP) "drahtähnliche Vertraulichkeit". bezeichnet die Verschlüsselung, die (WEP) zur Absicherung von WLANs eingesetzt wird. Gebräuchlich sind WEP-64 (auch WEP-40 genannt, Schlüssellänge 40 Bit) und WEP128 (Schlüssellänge 104 Bit), beide sind allerdings mit Hausmitteln zu knacken.

Wireless Local Area Network (WLAN)

Drahtloses Netzwerk (LAN)

6

Einige Begriffe rund um WLAN-Security:

• ACL - Access-Control-List; Liste, in der die für ein Netzwerk zugelassenen MAC-Adressen gespeichert sind; jedes Firmen-Netz sollte sie verwenden, aber auch für private Router sind sie sinnvoll...

• DMZ - Demilitarized Zone • EAP - Extensible Authentication Protocol • Kerberos - ein Authentifizierungs-Verfahren • LEAP - Lightwight-EAP; proprietäre Lösung für 802.1x WLAN-Sicherheit von

Cisco; benutzt MIC (Message-Integrity-Check) um das Verfälschen von Nachrichten zu verhindern; WLAN-Client und Access-Point müssen sich gegenseitig authentifizieren, dadurch werden Man-in-the-Middle-Angriffe verhindert

• PMK - Pairwise Master Key; wird bei der WPA-Authentifizierung ausgetauscht • SSID - Service-Set-ID; Name des WLAN-Netzwerks, z.B. "any" • TKIP - Temporal Key Integrity Protocol; Protokoll zur Verbesserung der

Sicherheit in WLANs • WEP - Wired Equivalent Privacy; die auf RC4 basierende Verschlüsselung von

Karten nach dem 802.11-Standard • WPA - Wi-Fi Protected Access; die Wi-Fi Alliance plant, mit WPA den bekannt

unsicheren Standard WEP abzulösen

7

1 Einleitung

Der Bereich der Hausautomatisierung stellt derzeit einen kräftigen Wachstumsmarkt dar. Viele Hersteller bieten bereits Lösungen zur Steuerung und Visualisierung von Komponenten der Haustechnik an. Basierend auf Standard-Ethernet mit Brücken zu verschiedensten Bussystemen werden Komponenten wie Heizung, Rollo, Markisen, Garagentore, Zutritts- und Überwachungs- Systeme, Licht, Solaranlagen und Wetter-Stationen über eine zentrale Einheit bedient. Die Benutzerschnittstelle ist meist reglementiert. Das Problem besteht darin, dass kein allgemein anerkannter Standard zur Steuerung dieser Anlagen existiert, so dass jede Automatisierungseinrichtung mit einer separaten Steuerung ausgestattet ist. Es ist bis jetzt nicht möglich, über ein beliebiges Bedienungsinterface auf die zentrale Einheit zuzugreifen. Mit Hilfe des Projekts „LAN-integriertes Steuerungssystem für intelligente Gebäude-technik“ (LISTIG) soll die Integration verschiedener Automatisierungsarchitekturen über ein Basisgerät ermöglicht werden. LISTIG bietet eine Lösung zur Steuerung von Komponenten der Haustechnik. Geräte und Funktionen sollen über beliebige Endgeräte wie Handy, PDA oder Laptop mittels GPRS, IrDA, Bluetooth und WLAN gesteuert und überwacht werden. Diese Technologien bilden die Grundlage für künftige Hausautomatisierungs-Szenarien in denen das Basis-System mit Komponenten der intelligenten Haustechnik verknüpft wird. Das Basisgerät muss demnach unterschiedliche Kommunikationstechniken unterstützen. Im Heimbereich stößt man heute schnell auf eine große Menge unterschiedlicher Datenübertragungs-Standards und Netzwerk-Technologien. Deshalb will ich im Folgenden einen kurzen Überblick über einige bestehende drahtlose Übertragungs-Standards geben, welche im Zusammenhang mit Home-Networking oft genannt werden: IrDA: Die Abkürzung "IrDA" steht für Infrared Data Association" und bezeichnet einen Standard zur Datenübertragung mittels Infrarot. Seit 1995 gilt die Spezifikation 1.1 für FIR (Fast Infrared), welche Bandbreiten von maximal 4 Mbps ermöglicht. Bis zu 16 Mbps sollen zukünftig mit VFIR (Very Fast Infrared) übertragen werden können. Für den Aufbau von Netzwerken ist IrDA eher ungeeignet, so dass dieser Standard vor allem für Datentransfers zwischen einzelnen Geräten wie Notebooks, Handys, Palmtops oder für low-speed Peri-pherie-Geräte wie Maus oder Keyboard verwendet wird. Obwohl IrDA relativ preiswert ist, hat es den wesentlichen Nachteil, dass zwischen allen Geräten stets Sichtverbindung bestehen muss. Umgebungslicht hat Einfluss auf die Übertragungsqualität und Ver-schlüsselung ist nicht vorgesehen. Dadurch sind die Einsatzmöglichkeiten von IrDA im Hinblick auf Heim-Netzwerke eher begrenzt. Doch aufgrund der großen Verbreitung bei Endgeräten, brauchbarer Übertragungsraten und eines niedrigen Stromverbrauchs ist diese Form der Datenübertragung eine Variante, die bei dem Projekt „LISTIG“ berücksichtigt wird. Bluetooth: Bei Bluetooth handelt es sich um eine Nahbereichsfunk-Technologie. Auf einer Frequenz von 2.4 GHz können Daten mit bis zu 1 Mbit pro Sekunde übertragen werden. Die Reichweite von Bluetooth beträgt im allgemeinen ca. 10 m, läßt sich mittels eines zusätzlichen Funkmoduls jedoch auf mehr als 100 m ausdehnen. Dieser Standard ist vor allem im Bereich Telekommunikation nicht ohne Bedeutung, doch ebenso wie IrDA ist es für größere Netzwerke ungeeignet. Für das Projekt „LISTIG“ stellt Bluetooth eine

8

brauchbare „Punkt-zu-Punkt-Lösung“ dar, verfügt über eine größere Reichweite als IrDA und lässt Verschlüsselungstechniken zu. Die Verbreitung bei Endgeräten ist zur Zeit geringer als IrDA, aber stark zunehmend. WLAN: Wesentlich interessanter sind dagegen sogenannte "wireless local area networks" - WLANs. Der 1997 verabschiedete Standard IEEE 802.11 definiert eine Funkübertragung - ebenfalls im 2.4 GHz-Frequenz-Bereich - mit bis zu 54 Mbit/s. Immerhin 11 Mbit/s sind mit 802.11b möglich. Auch aufgrund einer Reichweite von 30-50 m in Gebäuden und ca. 300 m im Freien, sowie einigem Spielraum für Geschwindigkeitssteigerungen, sind WLANs durchaus als eine mögliche Teillösung für zukünftige Heim-Netze anzusehen. Aktuell wird an Verbesserungen des existierenden 802.11 und anderen Standards auf einer Frequenz von 5 GHz gearbeitet, welche die Bandbreiten weiter erhöhen sollen. Obwohl diese Übertragungsgeschwindigkeiten bislang nicht mit den meisten Kabellösungen konkurrieren können, bringen drahtlose Netze grundsätzlich natürlich erheblich Vorteile gegenüber einer festen Verkabelung mit sich. Der Nachteil liegt in der Beeinflussbarkeit durch elektromagnetische Störquellen. Besonders häufig sind heutzutage Laptops bereits mit integrierten WLAN-Chips ausgestattet, so dass auch dieser Übertragungsstandard eine wichtige Variante für das Projekt „LISTIG“ darstellt. In zunehmendem Maße werden auch PDAs mit WLAN-Funktionalität angeboten.

Übertragungs-Standard

Vorteile Nachteile

IrDA sehr preiswert,

bei brauchbaren Über-tragungsraten große Verbreitung geringer Stromverbrauch geringe Beeinflussbarkeit durch Funkstörquellen

geringe Reichweite (bis 2m) Sichtverbindung notwendig Beeinflussbarkeit durch Umgebungslicht keine Verschlüsselung

Bluetooth geringe Sendeleistung not-wendig akzeptable Reichweite kein Sichtkontakt notwendig Verschlüsselungstechniken

teurere Komponenten elektromagnetische Störquellen geringere Verbreitung

WLAN weltweite Standardisierung größere Reichweite (bis 50m in Gebäuden) akzeptable Übertragungs- geschwindigkeiten kein Sichtkontakt notwendig Verschlüsselungstechniken zunehmende Verbreitung

elektromagnetische Störquellen

Tabelle 1.1: Vergleich der verbreitesten Übertragungstechniken

Gerade die zunehmende Verbreitung im Heimbereich zur Datenkommunikation machen den Standard IEEE 802.11 (WLAN) auch zur Kommunikation mit dem „LISTIG“- Basisgerät interessant. Nach vorsichtigen Prognosen soll es allein in den USA bis zum Jahr

9

2007 fast 40 Millionen Laptops, Notebooks, Sub-Notebooks und Taschencomputer (PDAs) mit einem WLAN-Funkinterface geben. Als Aufgabenstellung der Studienarbeit ergibt sich somit die Erweiterung des Basisgeräts mit einer Schnittstelle für WLAN. Nach Inbetriebnahme der WLAN - Komponente soll die Kommunikation zwischen Basis- und Endgerät anhand definierter Szenarien hinsichtlich verschiedener Kriterien wie Reichweite und Störanfälligkeit untersucht werden. Abschließend sollen Konzepte zur Authentisierung und Sicherung erörtert und falls möglich, integriert werden.

2 Grundlagen

Drahtlose lokale Netze (Wireless Local Area Networks –WLAN) erfreuen sich seit mehreren Jahren einer außerordentlichen Beliebtheit, da sie den kostengünstigen und leistungsfähigen Anschluss der in zunehmendem Maße portablen Anwendungen ermöglichen. Es handelt sich standardisierte Netzwerktechnologien, die LAN- Funktionalität mit einer drahtlosen Übertragung realisieren. Ziel ist der breitbandige Anschluss von mikroelektronischen Geräten im Umkreis von einigen zehn bis hundert Metern.

Kabellose Netzwerke arbeiten heute nach dem IEEE 802.11 (Institute of Electrical and Electronics Engineers) Standard und dessen Derivaten. Derzeit lassen sich fünf Formate unterscheiden (802.11a, 802.11b, 802.11b+, 802.11g, 802.11h).

Als digitales Modulationsverfahren für die Nutzung des 2,4 GHz-ISM-Frequenzbereichs ist in Nordamerika und in Europa der Einsatz eines Frequenzspreizverfahrens (Spread Spectrum Technik) vorgeschrieben, also die Benutzung eines sehr breiten Frequenzbandes zur Signalübertragung. Die Formate sind jedoch untereinander inkompatibel, d.h. damit arbeitende Geräte können nur miteinander kommunizieren, wenn sie den selben Standard benutzen.

Sender und Empfänger einigen sich auf einen bestimmten Funkkanal in einem Frequenzspektrum und verwerfen die restlichen. Deswegen müssen sich alle Geräte auf einem Funkkanal die Bandbreite teilen. Die Folge: je mehr Nutzer sich an einem Access Point anmelden, desto geringer ist der Datendurchsatz für den einzelnen. Des Weiteren liegt die Nettodatenrate bei etwa 45 - 60 Prozent der Herstellerangaben, da der maximale Durchsatz nur zu schaffen ist, wenn Sender und Empfänger nahe beieinander liegen und die Funksignale nicht gestört, gedämpft oder reflektiert werden.

2.1 Anwendungsszenarien

10

Die drahtlose Übertragung von Informationen ersetzt das Kabel zunächst lediglich auf der Bitübertragungsschicht im ISO/OSI - Referenzmodell. Diese grundlegend Aussage hat jedoch noch zwei Aspekte: Die wesentlichen Netzwerkarchitekturen, wie sie sich während des jahrzehntelangen Einsatzes drahtgebundener Netzwerke etabliert haben, werden auch von den drahtlosen Netzen übernommen. Werden die Dienste auf den höheren Ebenen mit dem physischen Übertragungsprotokoll der untersten Ebene verbunden, dann ist ein drahtloses Netz doch mehr als nur ein Kabelersatz. Von den üblichen Netzwerkanwendungen und den sich daraus ergebenen Anwendungsszenarien wie Personal Area Networks (PAN), Local Area Networks (LAN), Small Offices and Home Offices (SoHo-LAN), Büro-LAN und Kopplung von Netzwerken, interessiert uns hinsichtlich der Aufgabenstellung vor allem das Personal Area Network (PAN).

2.1.1 Personal Area Network Unter diesem Begriff fasst man die Kommunikation von Geräten eines oder einiger weniger Nutzer im Umkreis von etwa 10m zusammen. Ausgehend davon kann man annehmen, dass sich die kommunizierenden Geräte meist im gleichen Raum oder zumindest in der unmittelbaren Nähe befinden. Dabei lassen sich die meisten Anwendungen mit moderaten Bandbreiten zufrieden stellen. Hierunter stellt wiederum die Kopplung externer Bediengeräte (einschließlich Notebook) mit der Dienstplattform das Szenario der Wahl im Sinne der Zielsetzung dar.

2.2 Gerätetypen Zur Erfüllung dieser Aufgaben müssen verschiedene Geräte zur Verfügung gestellt werden. Dazu betrachten wir für unsere Aufgabe vor allem die Gruppe der Netzwerk-Adapter, die die Verbindung der Endgeräte ermöglichen. In diese Kategorie fallen:

• PCI- Karten zum Einsatz in Desktop-Computern. Da die Anbindung von stationären Desktop- PCs weniger Marktbedeutung aufweist als die drahtlose Vernetzung von portablen Notebooks, basieren die PCI- Lösungen nicht selten auf den PC- Cards. Die Kompatibilität wird dann mit Hilfe zusätzlicher Schaltkreise hergestellt

• USB- Stationen zum flexiblen Einsatz an Desktop- und Notebook-Computern.

Allerdings muss die Unterstützung sowohl durch die PC-Hardware als auch durch das Betriebssystem gegeben sein. Insbesondere für ältere PCs ist dies nicht gegeben.

• PC- Cards zum Einsatz in Notebooks

• Integrierte WLAN- Adapter, die vom Hersteller fest in das Notebook eingebaut

werden

11

2.3 Der Standard IEEE802.11 Für drahtlose lokale Netze hat die Standardisierungsvereinigung des IEEE im Jahr 1997 mit dem 802.11 den ersten herstellerunabhängigen Standard für Übertragungsprotokolle verabschiedet. Im Umfeld des IEEE802.11-Standards haben sich weitere Gremien gebildet, die helfen sollen, den Markterfolg und die Interoperabilität der Geräte zu gewährleisten: Die Wireless LAN Association (WLANA) soll die Verbreitung des Standards durch Marketing- und Informationsaktivitäten unterstützen Die 1999 gegründete Wireless Ethernet Compatibility Alliance (WECA) zertifiziert die Interoperabilität der 802.11-kompatiblen Geräte. In diesem Zusammenhang werden die Geräte nach IEEE802.11 auch unter dem Markennamen Wi-Fi.

Einige der wichtigsten Eigenschaften des 802.11-Standards sind:

• 5 Geschwindigkeiten: 54 MBit/s, 11 MBit/s, 5 MBit/s, 2 MBit/s und bei größerer Entfernung Fallback auf 1 MBit/s (im Bereich von 2.4 GHz)

• Robustheit der Datenübertragung durch Protokoll und RTS/CTS • Multi Channel Roaming - dadurch können mehrere Zellen denselben Bereich

abdecken und das Netzwerk insgesamt bekommt eine höhere Kapazität • Power-Management für längere netzunabhängige Betriebszeiten der mobilen

Geräte (Notebook, PDA, ...) • Verschlüsselung (WEP = Wired Equivalent Privacy; basiert auf RC4).

Am 25. Juni 2004 waren 4 Normen verabschiedet: 802.11, 802.11a, 802.11b und 802.11g. Zur Verabschiedung vorgesehen noch für 2004 sind 802.11e und 802.11i.

• 802.11 ursprünglicher Standard, 1997 verabschiedet o Datentransfer: brutto 1 oder 2 MBit/s o Frequenzband 2,400 bis 2,485 GHz (lizenzfrei) o Akzeptanz: veraltet, nicht mehr breit genutzt

• 802.11a Erweiterung der physischen Schicht, 1999 o Datentransfer: brutto 54 MBit/s o Frequenzband 5 GHz (seit dem 13. Dezember 2002 in Deutschland

freigegeben) o Akzeptanz: nicht verbreitet

• 802.11b Erweiterung der physischen Schicht, 1999 o Datentransfer: brutto 11 MBit/s (netto 50 %) o Frequenzband 2,400 bis 2,485 GHz (lizenzfrei) o Akzeptanz: noch relativ weit verbreitet

• 802.11g Erweiterung der physikalischen Schicht, 2003 o Datentransfer: brutto 54 MBit/s o Frequenzband: 2,400 bis 2,485 GHz (lizenzfrei) o Akzeptanz: mittlerweile der am weitesten verbreitete Standard

12

• 802.11n Neuer Standard in der Entwicklungsphase, geplant Ende 2006 o Datentransfer: brutto 540 MBit/s o Frequenzband: geplant 5 GHz o Akzeptanz: noch keine

Zusätzliche Erweiterungen von 802.11:

• 802.11c MAC-Layer-Bridging gemäß 802.1d • 802.11d Anpassung an die regulatorischen Bestimmungen verschiedener Länder • 802.11e Unterstützung von Quality-of-Service • 802.11f Interoperabilität zwischen Basisstationen • 802.11h Reichweitenanpassung, Indoor- und Outdoor-Kanäle (im 5-GHz-Band)

TPC/DFS • 802.11i Erweiterungen bezüglich Sicherheit und Authentifizierung

Neben diesen gibt es proprietäre Erweiterungen, die andere Übertragungsraten erlauben (22 MBit/s im 2,4-GHz-Band, PBCC, auch als "802.11b+" bezeichnet; oder 108 MBit/s). Diese sind aber keine offiziellen IEEE-Standards.

Sendeleistungen: 2,4 Ghz: 100 mW

5 GHz: 60 mW, mit TPC/DFS 200 mW (indoor, ab 802.11h)

In Europa ist TPC/DFS vorgeschrieben, sodass weniger Störungen auftreten und Akku-Betriebszeiten deutlich verlängert werden.

DFS: Dynamic Frequency Selection; automatische Frequenzwahl; bevor ein Mobilgerät sich in einem WLAN einbucht, beobachtet es erst einmal das Funk-Netz.

TPC: Transmit Power Control; Sendeleistungssteuerung; die mobilen Geräte senden nur mit der tatsächlich benötigten Leistung

Kompatibilitäten: 802.11b und 802.11g sind zueinander kompatibel, jedoch fällt das 802.11g-Gerät dann in einen Kompatibilitätsmodus zurück, der die effektive Geschwindigkeit auf ca. 10-15 MBit/s reduziert. 802.11a und 802.11h sind zueinander kompatibel, keine Einschränkungen.

802.11 sieht drei Übertragungsverfahren vor: FHSS (Frequency Hopping Spread Spectrum), DSSS (Direct Sequence Spread Spectrum) und Infrarot. Wie schon erwähnt, sind die verschiedenen Verfahren sind nicht miteinander kompatibel. Vor allem bei 11 MBit/s dürfte DSSS das effizienteste System sein. Bei 802.11b wird nur noch DSSS verwendet.

2.4 Aufbau Die Familie der 802-Standards beschreibt mit der Bitübertragungsschicht (Physical Layer) und der Sicherungsschicht (Data Link Layer) die unteren zwei Schichten des ISO/OSI - Referenzmodells. Dabei wird die Verbindungsschicht noch einmal unterteilt: Die

13

Zugriffssteuerung übernimmt das Medium Access Control (MAC), die logische Steuerung der Verbindungen erfolgt durch das Logical Link Control (LLC), das für alle Standards nach IEEE802 identisch ist. Auf diese Weise können Protokolle der darüber liegenden Schichten unabhängig vom Zugriffsmechanismus und der physikalischen Realisierung auf die Kommunikationsdienste zugreifen. Insbesondere bedeutet dies, dass die drahtlosen Protokolle nach 802.11 von Protokollen wie TCP/IP (Schichten 4 und 3) in prinzipiell der gleichen Weise genutzt werden können wie herkömmliche drahtgebundene Protokolle nach 802.3. Einschränkungen im Sinne einer reduzierten Datenrate können sich dennoch durch die mehrfache Implementierung von Algorithmen zur Fehlerkorrektur oder Verkehrssteuerung ergeben, wie sie im folgenden Kapitel erläutert werden.

Zu den am weitesten verbreiteten Erweiterungen des Standards gehören die Spezifikationen IEEE802.11a und IEEE802.11b/g. Bei gleicher Zielsetzung, höhere Bandbreiten zu erreichen, beschreiten beide grundsätzlich unterschiedliche Wege. Während der 802.11a einen weiteren Frequenzbereich im 5GHz-Bereich nutzt, in dem größere Bandbreiten zur Verfügung stehen, nutzt der 802.11b (und g) weiterhin das 2,4 GHz-ISM-Band. Der 802.11b (und g) greifen auf das DSSS-Verfahren zurück. Als Modulationsverfahren zur besseren Ausnutzung des Frequenzspektrums wird im Wesentlichen auf das Quadrature Phase Shift Keying (QPSK) zurückgegriffen. Bei den Unterstandards 802.11a und 802.11g kommt das OFDM-Modulationsverfahren zum Einsatz.

Mit der Wahl des DSSS-Verfahrens als Übertragungsstandard ist eine Einbeziehung des 802.11-DSSS-PHY verbunden, so dass auch Systeme nach 802.11-1997 mit Datenraten von 1 oder 2 MBps angesprochen werden. WLAN-Systeme nach 802.11, die das FHSS-Verfahren einsetzen, können jedoch nicht eingebunden werden.

2.5 Architekturen

2.5.1 Systemarchitekturen (Netzwerk-Topologien) Der 802.11-Standard beschreibt die folgenden Betriebsarten, deren Hierarchie und Aufbau in Abbildung 2.1 und Abbildung 2.2 dargestellt sind.

Abbildung 2.1: Gliederung der Betriebsarten im IEEE802.11

14

Abbildung 2.2: Architekturen der Betriebsarten im IEEE802.11

Im Ad-Hoc-Modus können Endgeräte in einem Peer-to-Peer-Netzwerk unmittelbar miteinander kommunizieren. In diesem Independent Basic Service Set (IBSS) können schnell, einfach und kostengünstig Netzwerke über meist kurze Entfernungen und mit einer begrenzten Anzahl von Teilnehmern ohne Integration in eine größere Netzwerkstruktur aufgebaut werden. Die Rechner müssen sich nicht gegenseitig hören können. Access Points für den zentralen Datentausch gibt es nicht, der Versorgungsbereich ist daher potentiell halb so groß wie in der „Managed Infrastructure“. Werden aber nur zwei Rechner mteinander verbunden, etwa das Basisgerät von LISTIG und ein Notebook, spielt das keine Rolle: In dem Fall muss die WLAN-Antenne des Basisgeräts dort aufgestellt werden, wo sich ansonsten der Access Point befinden würde. Falls man sich entscheidet externe Wireless-USB-Adapter einzusetzen, ließen sich notfalls mit mehreren USB-Hubs hintereinander größere Distanzen überbrücken. Längere Koaxialkabel hingegen rentieren sich kaum, die Kabelverluste sind schon bei Längen von 10 m enorm. Im Infrastruktur-Modus findet die Kommunikation grundsätzlich über einen Access Point (Zugangspunkt) statt. In dieser Betriebsart können auch Stationen außerhalb der direkten Reichweite kommunizieren. Die Anbindung an ein externes Netzwerk kann mit Hilfe eines Gateways erfolgen.

In der einfachsten Version besteht ein solches Netzwerk aus einem Access Point und einer Gruppe von drahtlosen 802.11-Stationen im Funkbereich des Access Points.

Ein solches Netzwerk wird als Basic Service Set (BSS) bezeichnet.

Werden zwei oder mehrere BSS in einem gemeinsamen Netzwerk betrieben, indem die Access Points über ein dahinter liegendes Netzwerk gekoppelt werden, so spricht man von einem Extended Service Set (ESS). Das koppelnde Netzwerk bezeichnet der Standard als Verteilungssystem (Distribution System - DS). Dieses kann drahtgebunden oder auch mit Hilfe von Richtfunkstrecken implementiert werden. Im ESS-Modus muss insbesondere die Lokalisierung der Stationen in einem BSS und ein Wechsel der Stationen von einem BSS zu einem anderen unterstützt werden. Einen solchen Wechsel bezeichnet man als Roaming. Die hierzu notwendige Kommunikation der Zugangspunkte über das

15

Verteilungsnetz ist noch nicht Bestandteil des IEEE802.11-Standards (vgl. Abschnitt 4.7).

Im Infrastrukturmodus müssen sich die Stationen beim Access Point anmelden. Sie übertragen dann auf dem Kanal, der von dem Access Point verwendet und ihnen vorgegeben wird.

Die Zuordnung kann vom Systemadministrator vorgegeben werden, um Zugriffsrechte zu verwalten und Benutzergruppen physisch zusammenzufassen.

Es besteht aber auch die Möglichkeit einer Zuordnung. Insbesondere existieren

dabei verschiedene herstellerspezifische Verfahren eines Load Balancing (automa-tische Zuordnung). Auch kann im Rahmen des Roaming eine neue Zuordnung zum Beispiel durch die räumliche Veränderung der mobilen Station erfolgen, die zu einer Veränderung der Kanaleigenschaften führt.

Die Bezeichnung des Ad-hoc-Modus im Rahmen des IEEE802.11-Standards

unterscheidet sich von der Definition des Ad-hoc-Networkings, worunter einfach die Fähigkeit von Anwendungen verstanden wird, selbsttätig miteinander in Verbindung treten zu können. Denn auch im Infrastrukturmodus müssen die Access Points und die mobilen Stationen selbsttätig Informationen austauschen und den Anmeldevorgang durchführen. Also: Ad-hoc-Networking betreiben die IEEE802.11-Netze sowohl im Ad-hoc- als auch im Infrastrukturmodus.

2.5.2 Protokollarchitektur Bei der Betrachtung der Protokollarchitektur des IEEE802.11 ist neben der auch in anderen Protokollen üblichen Aufteilung einer Ebene in einen Sublayer und einen Management Layer die weitere Aufteilung der Bitübertragungsschicht (PHY-Layer) hervorzuheben. In dieser Aufteilung übernimmt das Physical-Medium-Dependent-Sublayer (PMD) die Modulation und Kodierung, während das Physical Layer Convergence Protocol (PLCP) medienunabhängig eine übliche PHY-Schnittstelle zur Verfügung stellt: Insbesondere liefert das PLCP auch das Clear-Channel-Assignment-Signal (CCA), das den aktuellen Zustand des Mediums anzeigt. Dieses CCA-Signal dient neben der Beobachtung der Signale, die von anderen Kommunikationsteilnehmern ausgesendet werden, auch der Vermeidung von Kollisionen mit Störungen durch Mikrowellenherde. Diese senden bei 50 Hz-Netzen und einer Aktivität von 50% Störsignale mit einer Dauer von 10 ms und einer Pause von 10 ms aus. Selbst wenn das Störsignal des Mikrowellenherds während der aktiven Phase sehr stark ist, stehen immer noch die 10 ms Pausenzeit für eine Übertragung des WLAN zur Verfügung. Die Dienstzugangspunkte (Service Access Points - SAP) für den Signalfluss sind in Abbildung 2.3 dargestellt.

Der MAC-SAP ist identisch mit den Dienstzugangspunkten der anderen Standards nach IEEE802.x, insbesondere auch mit dem Ethernet-Standard 802.3.

Der PHY-SAP ist unabhängig von der Realisierung der physischen Übertragung.

16

Eine weitere Besonderheit ergibt sich dadurch, dass auf beiden Ebenen die von den höheren Ebenen erhaltenen Daten mit einem zusätzlichen Rahmen verpackt werden. Auf die Rahmenformate gehe ich im nächsten Kapitel näher ein.

Abbildung 2.3: Die Dienstzugangspunkte der MAC und PHY-Schichten im IEEE802.11

2.6 Kanalzugriff und Rahmenstruktur

2.6.1 Zugriffsverfahren Das Medium "Funk" ist in gewisser Hinsicht mit dem traditionellen Ethernet vergleichbar, bei dem mehrere Stationen um den Zugriff auf ein Medium (bzw. jetzt ein Frequenzband) konkurrieren. Bei WLANs nach 802.11 werden folgende Verfahren zur Koordinierung des Medienzugriffs eingesetzt:

Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA)

Eine sendewillige Station prüft, ob das Medium (der Funkkanal) frei ist. Das vom Ethernet bekannte CSMA/CD ist nicht einsetzbar, weil eine Station während des Sendens kaum feststellen kann, ob eine weitere Station ebenfalls sendet.

Distributed Coordination Function (DCF)

Eine absolute Vermeidung von Kollisionen ist nicht gegeben. Allerdings wird die Zeitspanne, in der Kollisionen vorkommen können, durch ein geschicktes Verfahren minimiert:

1. Station wartet Pause mit einer Mindestlänge ab DCF Inter-Frame Spacing (DIFS)

2. Empfänger quittiert nach kurzer Pause Short Inter-Frame Spacing (SIFS)

3. bei "besetzt": DIFS + Zufallswert (Backoff) abwarten

"Fairness": Zufallswert wird nach eigenem Senden gesetzt, sonst heruntergezählt

17

Abbildung 2.4: Kanalzugriff

Wegen der endlichen Ausbreitungsgeschwindigkeit kann es natürlich trotzdem zu Kollisionen kommen, wenn zwei Stationen nahezu zum selben Zeitpunkt einen freien Kanal feststellen und zu senden beginnen. Durch die ausbleibende Quittung (ACK) kann die Kollision erkannt werden. Eine Zufallskomponente bei der Zeit bis zum Wiederholversuch sorgt dafür, daß die beiden Stationen beim nächsten Mal (höchstwahrscheinlich) nicht wieder kollidieren.

Der eben beschriebene Mechanismus funktioniert allerdings nur dann korrekt, wenn alle Stationen alle anderen auch empfangen können (in unserem Beispiel kann C sowohl A als auch B empfangen). Mitunter wird das nicht gegeben sein, wenn zwischen bestimmten Stationen Hindernisse vorhanden sind. Wir bezeichnen dies als das Problem der hidden nodes. Eine Station D, die A nicht empfangen kann, könnte beispielsweise mitten während der Daten-Sendung von A beginnen.

Für diesen Fall gibt es den (optionalen) Mechanismus Request to send/Clear to send (RTS/CTS). Den erreichten Effekt bezeichnet man als Virtual Carrier Sense. D erfährt aus dem CTS von B, dass der Kanal durch A für eine gewisse Zeit belegt sein wird:

Abbildung 2.5: RTS/CTS-Ablauf

18

RTS- und CTS-Rahmen enthalten eine Längenangabe für Data.

Optional ist eine Point Coordination Function (PCF), bei der die Zugriffskoordinierung durch den Access Point erfolgt. Damit lassen sich beispielsweise definierte Teilbandbreiten vergeben (Stichwort "Multimedia" ...)

2.6.2 Rahmenformate Hier sieht man die Rahmenstruktur des Physical Layer Convergence Protocol (PLCP):

Abbildung 2.6: PLCP bei 802.11/11b

192 Bits werden mit 1 Mbit/s übertragen, bei 802.11b ist eine kürzere Präambel zugelassen.

In der Payload haben wir dann folgende Rahmenstruktur:

Abbildung 2.7: MAC-Rahmen bei 802.11

19

Die bis zu vier vorhandenen MAC-Adressen haben folgende Semantik:

DS steht für "Distribution System"

toDS/fromDS Adr 1 Adr 2 Adr 3 Adr 4 00 IBSS Ziel Quelle BSSID 01 vom AP Ziel BSSID Quelle 10 zum AP BSSID Quelle Ziel 11 AP-AP-Bridge Ziel-BSSID BSSID Ziel Quelle

Tabelle 2.1: Semantik der MAC-Adressen

Als Basic Service Set Identifier (BSSID) wird die MAC-Adresse des WLAN-Interfaces des betreffenden AP verwendet.

Man fragt sich zunächst, warum hier nicht wie beim Ethernet die MAC-Adressen von Absender und Empfänger ausreichend sind. Die Erklärung liefert eine Station, die zwei APs im selben Subnetz "sieht". In diesem Fall darf nur einer der APs den Rahmen weiterleiten, diese Auswahl wird durch die MAC-Adresse des AP getroffen.

Im Falle IBSS (Betrieb ohne AP) wird als BSSID eine 48-Bit-Zufallszahl verwendet. Die Stationen eines IBSS-Netzes erfahren diesen Wert, weil er von einem (dynamisch gewählten) Mitglied des Netzes zyklisch als Bakensendung (Beacon) verbreitet wird. Es gibt weiterhin eine für Broadcasts reservierte BSSID (alles 1-Bits).

Das soll den Betrieb mehrerer IBSS-Netze mit überlappenden Versorgungsbereichen ermöglichen.

Die beschriebene MAC-Schicht kann mit unterschiedlichen physischen Schichten kombiniert werden:

Abbildung 2.8: Zusammenwirken der Standards

2.6.3 Fragmentierung von langen Nachrichten Längere Mitteilungen lassen sich in Fragmente zerlegen, um hierdurch die Wahrscheinlichkeit der fehlerfreien Übertragung jedes einzelnen Fragments zu erhöhen. Dabei werden die zu einer Nachricht gehörenden Fragmente mit Hilfe des Sequenzkontrollfelds gekennzeichnet, das im Steuerrahmen übermittelt wird. Zum einen wird eine Identifikationsnummer der Nachricht angegeben, zum anderen werden die einzelnen Rahmen durchnummeriert. Bei jedem Rahmen wird außerdem das More Frag-

20

Bit gesetzt. Lediglich beim letzten Rahmen wird diese Kennzeichnung nicht vorgenommen. Der Wert RTSthreshold, ab dem ein Paket fragmentiert werden soll, kann vom Systemadministrator eingestellt werden. Dabei muss einerseits berücksichtigt werden, dass lange Pakete mit einer höheren Wahrscheinlichkeit von Bitfehlern während der Übertragung belastet sind, wobei im Fehlerfall die Übertragung wiederholt werden muss. Andererseits erhöht sich aber durch die Fragmentierung der Protokollaufwand, so dass hier für die jeweiligen Gegebenheiten des Funknetzes ein Optimum gefunden werden muss. Dies geschieht meist experimentell.

2.6.4 Verwaltung von Stationen In diesem Abschnitt finden insbesondere zwei Aspekte Berücksichtigung:

Die Zuordnung der mobilen Stationen zur Zelle eines Zugangspunkts.

Der Aufbau von Ad-hoc-Netzwerken.

Die Verwaltung von Stationen im Sinne des Ad-hoc-Networking umfasst die folgenden drei Schritte:

Identifikation von Stationen,

Authentifizierung und

Anmeldung.

Die Verwaltung von Stationen im Sinne ihrer Adressierung und Identifizierung findet sich in Abschnitt 2.6.6.

Beacon-Rahmen

Die Beacon-Rahmen stellen Management-Rahmen dar, die in einer Zelle in periodischen Zeitintervallen per Broadcast an alle Teilnehmer einer Zelle versendet werden und grundlegende Informationen über die Zelle enthalten. Beacon-Rahmen werden in Infrastruktur-Netzwerken von den Zugangspunkten versendet. In Ad-hoc-Netzwerken kann jede Station zur nächsten TBTT (Target Beacon Trans-mission Time) einen Beacon-Rahmen versenden. Damit dies nicht mehrere Stationen gleichzeitig tun, wird wieder ein Algorithmus zur Kollisionsvermeidung eingesetzt, indem jede Station zur nächsten TBTI einen Tuner mit einer Zufallszahl lädt und den Beacon-Rahmen nur dann sendet, wenn der Tuner abgelaufen ist und bis zu diesem Zeitpunkt noch kein Beacon-Rahmen von einer anderen Station empfangen wurde. Wird ein Zugangspunkt eingeschaltet, so beginnt er mit der Versendung von Beacon-Rahmen in den festgesetzten Zeitabständen. Eine Station, die kein AP ist, kann also durch die Überwachung aller physischen Kanäle herausfinden,

21

von welchen Zellen sie Signale empfangen kann. Diesen Vorgang bezeichnet man als Passives Scanning. Dabei kann eine Station durchaus Beacon-Rahmen von mehreren Zugangspunkten erhalten, wenn sie sich im Bereich überlappender Zellen befindet. Die Station kann aufgrund der Signalstärke des Beacons entscheiden, bei welcher Zelle sie sich anmelden möchte. Ist die Station so konfiguriert, dass sie sich nur bei einer bestimmten Zelle anmelden darf, so schränkt dies natürlich die Auswahl der Funkzelle ein. Darüber hinaus kann eine Station auch so konfiguriert werden, dass sie eine neue Zelle als Ad-hoc-Netzwerk startet, nachdem sie eine bestimmte, einstellbare Zeit auf den Empfang eines Beacon-Rahmens für ein Ad-hoc-Netzwerk gewartet hat. Stationen können aber auch Aktives Scanning betreiben. Hierzu werden Management-Rahmen per Broadcast mit dem Subtype Probe Request versendet. Im Datenteil des Rahmens ist entweder lediglich angegeben, dass die Station eine beliebige Zelle sucht, oder es ist die Adresse der gesuchten Zelle hinterlegt. Empfängt ein AP einen solchen Rahmen, antwortet es mit einem Management-Rahmen - mit dem Subtype Probe Response mit den Informationen über seine Zelle. In einem Ad-hoc-Netzwerk antwortet diejenige Station, die als Letzte für die Zelle einen Beacon-Rahmen erzeugt hat. Authentifizierung Unter Authentifizierung versteht man den Identitätsnachweis einer Station gegenüber einer anderen Station. Der IEEE802.11-Standard unterscheidet zwei Arten von Authentifizierung:

Die offene Authentifizierung folgt einem sehr einfachen Algorithmus, der die Authentifizierung nur formal erfüllt. Die in Abbildung 4.22 dargestellte offene Authentifizierung ist das standardmäßig implementierte Verfahren.

Abbildung 2.9: Offene Authentifizierung von Stationen

Die Authentifizierung durch gemeinsame Schlüssel (Shared Key Authentication)

setzt auf der verschlüsselten Kommunikation mit Hilfe des WEPAlgorithmus auf. Er beruht auf der Überprüfung, ob die beiden beteiligten.Stationen denselben geheimen Schlüssel aufweisen.

22

Dies wird dadurch erreicht, dass die Authentifizierung gebende Station S2 der Authentifizierung suchenden Station SI einen Text übergibt (Challenge Text), den diese verschlüsselt zurücksendet. Nur wenn die Verschlüsselung korrekt war, erhält diese die Nachricht der erfolgreichen Authentifizierung zurück (vgl. Abbildung 2.8).

Abbildung 2.10: Authentifizierung von Stationen durch gemeinsame Schlüssel

Anmeldung Grundlegend für die Funktionsweise von Infrastrukturnetzen ist die Zuordnung der Stationen zu den jeweiligen Zellen. Dabei muss für jede Station eine eindeutige Entscheidung möglich sein, zu welcher Zelle sie gehört, um Daten in das Verteilungssystem zu schicken. Eine solche Zuordnung kann mit Hilfe der ESSID erfolgen. In vielen Fällen werden aber auch herstellerspezifische Steuerinformationen eingesetzt. Auf der anderen Seite muss einem Access Point bekannt sein, welche Stationen sich als zu seiner Zelle gehörend betrachten. Diese Zuordnung erfolgt über eine explizite Anmeldung (Association), wie sie in Abbildung 2.9 dargestellt ist. Anmeldung und Authentifizierung bilden zusammen ein zweistufiges Zuordnungssystem:

Eine Station kann sich nur anmelden, wenn sie authentifiziert ist.

Eine Station kann das Verteilungssystem nur dann nutzen, wenn sie bei einer Zelle angemeldet ist.

23

2.6.5 Adressierung von Stationen Bei der Adressierung im Rahmen von IEEE802.11-Netzwerken sind mit der Adressierung auf MAC-Ebene und der Identifizierung auf Netzwerkebene zwei Aspekte zu unterscheiden, die jedoch auch miteinander verbunden sind. Auf der MAC-Ebene verwendet IEEE802.11 Adressen, die den MAC-Adressen des IEEE802.3-Ethernet-Standards entsprechen. Auch aus diesem Grund ist die Einbindung in die bestehenden Betriebssysteme vergleichsweise einfach. Allerdings muss noch auf einen Aspekt hingewiesen werden, der von Zeit zu Zeit zu Verwirrung führt. Die Stationen in Funknetzen, die Brückenfunktionen erfüllen, weisen mindestens zwei Netzwerkanschlüsse auf. Dies gilt beispielsweise für die Zugangspunkte. Diese sind auf der einen Seite an das drahtgebundene Verteilungssystem (Distribution System) angeschlossen sind und verfügen dort über eine MAC-Adresse für das IEEE802.3-Netzwerk. Auf der anderen Seite wird auch dem Funkmodul eine MAC-Adresse zugewiesen. Auf der Netzwerkebene wird zusätzlich eine Identifikation durchgeführt. Dabei sind zwei Identifikationsebenen zu unterscheiden:

Für die Identifikation eines Basic Service Set (BSS) wird eine BSSID eindeutig zugewiesen. Bei einem drahtgebundenen BSS wird die MAC-Adresse des Zugangspunkts gewählt, der den Dienst für das BSS erbringt. Für ein unabhängiges BSS (Independent BSS - IBSS) wird die BSSID zufällig gebildet.

Auf der zweiten Ebene wird vom Systemadministrator eine Electronic System ID

(SSID oder ESSID) in allen mobilen Teilnehmern und allen Zugangspunkten eingetragen, die zu einer Domäne gehören sollen.

Diese SSID bildet auch ein Element der Zugangsbeschränkung.

2.6.6 Synchronisation Mit Hilfe der Timing Synchronisation Function (TSF) werden alle Stationen auf eine Systemzeit synchronisiert. Die Synchronisation wird durch regelmäßiges Versenden des TSF-Zeitgebers in einen so genannten Beacon zu den durch Target Beacon Transmission Time (TBTT) festgelegten Zeizten gewährleistet. In inem Infrastrukturnetz ist der Zugangspunkt für di Aussendung des Snchronisations-Beacons zustandig, während in einem Adhoc-Netz die Beacon-Erzeugung auf alle Stationen verteilt wird. Hierzu wird die Ausstrahlung des Beacons von den verschiedenen Stationen mit verschiedenen, zufällig ausgewählten Verzögerungszeiten durchgeführt.

2.6.7 WLAN und TCP/IP An dieser Stelle sollen kurz zwei Aspekte angesprochen werden, die dazu führen, dass die Übertragung von TCP/IP- basiertem Verkehr über WLAN- Technologien nicht die Leistungsfähigkeit erlaubt, die theoretisch möglich wäre. Zunächst handelt es sich bei TCP/IP um ein verbindungsorientiertes Protokoll, das den erfolgreichen Empfang von Paketen mit Empfangsbestätigungen quittiert. In dem üblichen

24

Fall, dass Informationen nur in einer Richtung übertragen werden, muss der Empfänger ein getrenntes Paket an den Sender zurückschicken, das nur die Empfangsbestätigung enthält. Wird diese Empfangsbestätigung nun über ein WLAN übertragen, das nach dem CSMA- CA- Algorithmus arbeitet, dann ergibt sich der in Abbildung 10.3 gezeigte Ablauf. Es ist offensichtlich, dass die erreichbare Nutzdatenrate in diesen Fällen deutlich reduziert wird. Der zweite Aspekt bezieht sich auf die Tatsache, dass TCP/IP für den Einsatz in drahtgebundenen Netzen entwickelt wurde, was zu einer Anpassung der Zeitkonstanten an die Gegebenheiten im drahtgebundenen Netz führte. Abbildung 2.11: Unidirektionaler TCP-Verkehr über ein WLAN mit CSMA/CA-MAC Jedes Paket wird auf der MAC- und auf der TCP-Ebene bestätigt. Dies führt zu einem erheblich höheren Verkehrsaufkommen und im Falle von fortlaufendem Verkehr vom Sender S1 zum Empfänger S2 zu einer erhöhten Kollisionswahrscheinlichkeit. Dabei wählt TCP die Geschwindigkeit bei der Sendung von Paketen in Abhängigkeit von der gemessenen Zeit vom Senden der vorangegangenen Pakete bis zum Empfangen der zugehörigen Bestätigung. Da diese Zeiten aber bei drahtlosen Netzen deutlich länger sein können als bei drahtgebundenen Netzen, ohne dass tatsächlich eine Verstopfung des Übertragungskanals vorliegt, liefert TCP unter manchen Umständen deutlich weniger Pakete, als das Netz übertragen könnte.

2.7 Bitübertragung

2.7.1 Einordnung Auf der Bitübertragungsschicht ergeben sich naturgemäß die größten Unterschiede zur drahtgebundenen Kommunikation, da ja nunmehr auf elektromagnetische Wellen als Übertragungsmedium über die Luftschnittstelle zurückgegriffen wird. Bei der Spezifikation des physischen Übertragungsprotokolls müssen die Eigenschaften der Übertragung über die Luftschnittstelle - und hierbei insbesondere Störungen – berücksichtigt werden.

25

Abbildung 2.13: Algorithmus einer expliziten Anmeldung

Zusätzlich schreibt der IEEE802.11-Standard anhand einer Klassifizierung vor, welche Rahmen in welchem der drei Zustände von den Stationen gesendet oder empfangen werden dürfen, um auf diese Weise den zweistufigen Aufbau umzusetzen. Zu beachten ist dabei, dass im nicht authentifizierten und nicht angemeldeten Zustand Datenrahmen innerhalb einer Zelle gesendet und auch empfangen werden dürfen. Während in den frühen IEEE802.11-kompatiblen Produkten vorwiegend das FHSS-Verfahren (Frequenzsprung-Verfahren) Anwendung gefunden hat, setzt sich das DSSS-Verfahren zunehmend durch. Die maßgebliche Begründung hierfür besteht darin, dass die Erweiterung IEEE802.11b/g und die damit erreichbare Datenrate nur mit dem DSSS-Verfahren erreicht wird Dabei bleiben die Systeme auf eine einfache Weise abwärtskompatibel zu den langsamen Geschwindigkeiten.

2.7.2 Direct Sequence Spread Spectrum Die Spreizspektrum-Techniken (Spread Spectrum) wurden ursprünglich für militärischen Funkverkehr entwickelt. Durch die Aufspreizung des Signals auf ein breites Frequenz-spektrum ist dieses Signal von unerwünschten Mithörern schwieriger festzustellen als ein herkömmliches schmalbandiges Funksignal.

Dies gilt allerdings strenggenommen nur, wenn der Mithörer die exakten Parameter des Signals nicht kennt.

Daneben ist dieses Signal auch durch schmalbandige Funksignale nur schwer zu stören. Selbst andere Spreizspektrum-Signale wirken nur wenig störend, wenn sich die Spreizvorschriften unterscheiden.

Da bei WLANs mittlerweile DSSS-Verfahren die Hauptrolle spielen, werden wir uns diese nachfolgend näher ansehen.

Oft werden mehrere WLANs bzw. mehrere Zellen eines WLAN mit überlappenden Funkbereichen betrieben. Hier ist es vorteilhaft, unterschiedliche Frequenzbereiche zu benutzen, um die gegenseitigen Beeinflussungen zu minimieren. Eine Separierung auf der

26

logischen Ebene ("Netzname") ist zwar auch möglich, allerdings ohne eine Vervielfachung der Bandbreite.

Die Kanalaufteilung für DSSS hat folgende Merkmale:

• Kanalbreite je 22 MHz • Kanäle sind überlappend! • Europa (ETSI): 1 - 13 • U.S., Kanada: 1 - 11 • Japan: 14

Abbildung 2.14: Kanalaufteilung 2,4 GHz

Es existieren also nur drei nichtüberlappende Kanäle. Im Idealfall wird man z.B. nur die Kanäle 1, 6 und 11 vergeben:

Abbildung 2.15: Kanalvergabe-Beispiel

Praktische Funkzellen sind natürlich (leider) nicht wabenförmig, auch halten sich die Funkwellen nicht an eine exakte Grenze. Mit nur drei nichtüberlappenden Kanälen wird man typischerweise keine Versorgung einer Fläche ohne Interferenzen erzielen. Die Nutzung von Kanälen mit Überlappung ist dann oft ein brauchbarer Kompromiss, denn der Störeinfluss nimmt durch den Kanalversatz doch etwas ab. Ein wesentlicher Zusammenhang besteht zwischen der Zellengröße und der Bandbreite pro Fläche. Letztere können wir erhöhen, wenn wir kleinere Zellen bilden. Das funktioniert aber nur, wenn wir gleichzeitig die Reichweiten, d.h. die Sendleistungen verringern!

27

Beim Übertragungsverfahren Direct Sequence Spread Spectrum nach 802.11 wird die Nutzinformation mit einem Spreizkode XOR-verknüpft:

Abbildung 2.16: DSSS für 1/2 Mbit/s

Der 11-Bit-Spreizkode ("Barker-Kode") 10110111000 ist standardisiert und einheitlich, daher

findet hier kein Kodemultiplex (CDMA - Code Division Multiple Access) statt.

Mit einem Modulationsverfahren wird nun dieses Resultat einem Träger aufmoduliert, wobei zwei oder vier Phasen verwendet werden. Das ergibt dann ein bzw. zwei kodierbare Bits pro Schritt. Mehr Zustände bedeuten eine höhere Datenrate, allerdings auch einen größeren Signal/Störabstand und damit geringere Reichweite.

• 1 Mbit/s: Differential Binary Phase Shift Keying (DBPSK)

• 2 Mbit/s: Differential Quadrature Phase Shift Keying (DQPSK)

Abbildung 2.14: QPSK-Phasendiagramm

• 11/5,5 Mbit/s (802.11b): Complementary Code Keying (CCK) + DQPSK

Um die höheren Datenraten zu erreichen, wird bei 802.11b kein konstanter Spreizkode mehr verwendet, sondern dieser als zusätzliches Kodierelement genutzt.

28

Abbildung 2.15: CCK-Erzeugung

Statt 11-Bit-Barker-Kode wird ein komplexer 8-Bit-Kode verwendet,

aus den möglichen 48 Kodeworten werden 64 mit möglichst optimaler Distanz ausgewählt. Die Symbolrate ist 1,375 Msym/s

1 aus 64 CCK: 6 + 2 => 8 bit * 1,375 Msym/s = 11 Mbit/s 1 aus 4 CCK: 2 + 2 => 4 bit * 1,375 Msym/s = 5,5 Mbit/s

Die unterschiedlichen Kanäle mehrerer 802.11-Systeme unterscheiden sich durch verschiedene Trägerfrequenzen im Sinne eines FDMA-Verfahrens. Dabei erreicht ein Kanal aufgrund der Spreizung mit einem 11 Bit langen PN-Code die Bandbreite von 22 MHz. In Nordamerika und in Europa ist auf diese Weise der Betrieb von drei überlappungsfreien Kanälen möglich. Während in Nordamerika nur die Kanäle 1, 6 und 11 mit einem Bandabstand von 3 MHz überlappungsfrei betrieben werden können, sind in Europa mit 13 Auswahlkanälen unterschiedliche Kombinationen oder größere Bandabstände möglich. So erreicht man z.B. bei der Nutzung der Kanäle 1, 7 und 13 Bandabstände von 8 MHz. Wenn man die Kanäle 1, 6 und 13 nutzt, dann beträgt der Bandabstand zwischen den Kanälen 6 und 13 immerhin 30 MHz.

Abbildung 2.16: Kanalzuordnung beim DSSS-Verfahren im IEEE802.11

Dieser Aspekt wird von den Befürwortern der anderen Frequenzspreiztechnologie, dem Frequenzsprungverfahren, gern als Kritikpunkt angeführt. Die Frequenzspreizmethode mit Barker-Code zugrunde legend leuchtet es ein, dass die Qualität von DSSS-Systemen nicht nur im Sinne ihrer Kanaleffizienz, sondern auch in Bezug auf ihre Störunempfindlichkeit mit wachsendem Spreizfaktor steigt. Entsprechend erfüllt das IEEE802.11-Verfahren nur minimale Anforderungen.

29

3. Das Basisgerät des LISTIG-Systems

Abbildung 3.1: Die Hauptplatine des Basisgerätes

Das Herzstück des LISTIG-Basisgeräts bildet der STPC Atlas Prozessor der Firma ST Microelectronics. Er ist passiv gekühlt und unterstützt alle üblichen Schnittstellen wie den PCI-Bus und Schnittstellen für Eingabegeräte und Speichermedien. Der Prozessor befindet sich auf einem 120 mm x 124 mm großen Mainboard. Dessen Spannungsversorgung wird durch ein steckerseitig modifiziertes Standard-PC-Netzteil gewährleistet. Die Grafikausgabe basiert auf integriertem Grafikchip. Für die Bildschirmausgaben stehen sowohl eine 15-polige HDSUB-Buchse für den Anschluß eines CRT-Monitors, als auch ein 18 Bit breites LVTTL-Interface für den digitalen Anschluss eines TFT-Displays in Form einer 40-poligen ODU-Minifix Stiftleiste zur Verfügung. Die Spannung ist über eine Sicherung gegen Kurzschluss geschützt. Weiterhin mit an „Board“ sind ein PS/2-Anschluss für eine Tastatur, ein COM-Anschluss mit LVTTL-Pegel und eine 4-polige Stiftleiste für das Nachaußenführen eines USB-Ports. Man erkennt, dass trotz der bescheidenen Abmessungen des Mainboards alle wichtigen Schnittstellen zur Erfüllung von grundlegenden Aufgaben eines Computersystems vorhanden sind. Zwei PCI-Steckplätze (32 Bit, 5V) bieten die Möglichkeit das System mit Erweiterungskarten aufzurüsten. Eine Maus lässt sich entweder an der seriellen Schnitt-stelle (COM) oder am USB-Port betreiben. Zum Anschluss einer Standard-ATA-Festplatte und eines CD-ROM Laufwerks steht natürlich die IDE-Schnittstelle zur Verfügung. Sie entspricht dem ATA4-Standard. In meiner Testkonfiguration verwendete ich eine 40 GB große Festplatte von Western Digital, die mit Jumpern auf den Betrieb mit maximal 32 GB herunterkonfiguriert wurde. Als Hauptspeicher wurde für das Testsystem 128 MB SDRAM verwendet. Das PC-BIOS basiert auf dem General Software Embedded BIOS 4.3 und unterstützt das Booten aus linearem Flash-Speicher. Dadurch kann später im alltäglichen Einsatz ganz auf eine Festplatte verzichtet werden. Ohne Festplatte gibt es keine bewegten mechanischen Bauelemente, was die Robustheit des Systems erhöht und außerdem den Geräuschpegel

30

reduziert. Für das Betriebssystem stehen 4MB und als Programmspeicher 8MB Flash-Speicher zur Verfügung. Als lokales Betriebsystem bieten sich für das Basisgerät DOS/Embedded DOS und Linux an. Auf dem Testsystem wird das Open-Source Betriebssystem Debian/GNU Linux genutzt. Debian verwendet den Linux-Betriebssystemkern, aber die meisten grundlegenden Systemwerkzeuge stammen vom GNU-Projekt. Hierin vereinen sich weltweit fast eintausend aktive Entwickler, die in ihrer Freizeit bisher mehr als 8700 Anwendungspakete (vorkompilierte Software, die in einem praktischen Format für eine einfache Installation auf dem Rechner zusammengestellt ist) für Debian produziert haben. Das neueste stabile Release von Debian ist 3.0 (Codename „Woody“). Die neueste Aktualisierung zu diesem Release wurde am 1. Januar 2005 vorgenommen. Zusätzliche Informationen zum Basisgerät können der mitgelieferten Kurzbeschreibung zum STPC-Board des Hörmann Funkwerks Kölleda entnommen werden.

Abbildung 3.2: Der Versuchsaufbau des Projekts LISTIG

4. Auswahl des Schnittstellenadapters

4.1 Vorbetrachtung Mobile Computer ab der PDA-Klasse verfügen über Web-Browser und TCP/IP-Protokoll-stacks. Sub-Notebooks und Notebooks sind mit den gleichen Browsern wie Schreibtisch-PCs ausgerüstet. Diese Programme sind dabei nicht nur zum Surfen per Modem-, ISDN- oder DSL-Zugang im Internet geeignet, sie lassen sich auch zur Fernsteuerung einge-betteter Systeme, im Sinne der Aufgabenstellung also von Automatisierungssystemen, per Bluetooth oder WLAN nutzen. Unter diesen Aspekten habe ich mich zur Bearbeitung meiner Aufgabe für das Kommunikationsmodell Notebook / Basisgerät entschieden. Auf der einen Seite stehen dem Anwender heute eine ganze Reihe mobiler Endgeräte zu r Verfügung, um Embedded-Systeme zu steuern. Auf der anderen Seite fehlen noch

31

genügend eingebettete Systeme, die WLAN-Module integrieren. Aber wie wird einen solche Schnittstelle mit vertretbarem Aufwand realisiert? Welche Hard- und Softwarekomponenten sind erforderlich? Ein einfaches Konzept lässt sich auf Linux-Basis realisieren. Inzwischen gibt es für WLAN zahlreiche Chipsätze am Markt. Die Technologie ist nicht mehr neu und die verfügbaren Schaltkreisfamilien inzwischen auch sehr ausgereift. Daher erscheint die Integration einer entsprechenden Funkschnittstelle auf den ersten Blick relativ einfach. Man könnte auf einen WLAN-Chipsatz, wie z.B. den PRISM 2, PRISM 2.5 oder PRISM 3 von Intersil setzen. Der Integrationsaufwand auf einem Non-Windows-System ist allerdings nicht zu unterschätzen, da sehr komplexe Protokollstacks portiert werden müssen. Für diese sind teilweise erhebliche Lizenzkosten zu entrichten und aufwendige Entwicklungswerkzeuge notwendig. Für Projekte im Embedded-Marktsegment mit kleinen bis mittleren Stückzahlen ist eine Integration des Funkmoduls meistens nicht sinnvoll. Der Hersteller kann hier auf die bereits am Markt vorhandenen preiswerten PCMCIA-Karten oder zurückgreifen, die Notebooks nachträglich mit einem WLAN-Interface ausrüsten. Im Rahmen des Listig-Projekts habe ich mich für eine PCI-Variante entschieden, was ich später näher erläutern werde. Für PCMCIA- und PCI-Karten gibt es üblicherweise auch die entsprechenden Software-Treiber. Diese sind meist sehr ressourcenhungrig und sind daher im Embedded-Sysemumfeld, indem auch das LISTIG-Projekt angesiedelt sein soll, unpraktikabel. Der Grund: Die meisten Notebooks laufen auf Windows-PC-Betriebssystemen wie Windows 98, NT, ME, 2000 oder XP. Folglich muss ich mich anderer Wege bedienen, um an die notwenigen Treiber zu gelangen: In der Regel nutzen die PCMCIA- bzw. PCI-WLAN-Karten bestens bekannte Chipsätze. Für diese stehen zahlreiche Treiber als Open Source Software im Quellcode zur Verfügung. Solche Treiber lassen sich in einer Linux-Umgebung, zusammen mit den Standard-Protokollstacks des Betriebssystems zum Leben erwecken, was mir nach anfänglichen Hürden, auf die ich später noch eingehe, schließlich gelungen ist. Soll das LISTIG-System später aus einem Flash-Speicherbaustein heraus gestartet werden, empfiehlt sich ein Embedded Linux, indem die erforderlichen PCMCIA-Treiber eingebunden werden. Innerhalb der Open-Source-Szene findet man sowohl zahlreiche Bluetooth- als auch WLAN-Treiber-Implementierungen für Linux. Im Linux-Kernel sind die Treiber für PCMCIA sowie die beiden Netzwerkschnittstellen eth0 und wlan0 eingebunden. Open-Source-Treiber haben im Vergleich zu ihren binären Windows-Vertretern im Übrigen noch einen weiteren Vorteil: Sie sind oft wesentlich ausgereifter und besitzen ein höheres Entwicklungsniveau. Die Ursache für diesen Sachverhalt liegt darin, dass der Quellcode im Internet unter GPL (General Public License) zur Verfügung steht. Die Erkenntnisse und Verbesserungen einzelner Entwickler fließen jeweils in den Quellcode zurück und führen zu einer stetigen Weiterentwicklung. Erkannte Probleme werden im Internet über Mailing-Listen offen diskutiert und durch keine Marketing- oder Rechtsabteilung unterdrückt. Bei der Entscheidung für eine bestimmte WLAN-Technologie rücken verschiedene Auswahlkriterien in den Blickpunkt der Betrachtung. Zu berücksichtigen sind vor allem folgende Punkte:

Stabilität des Standards: Ist der Standard in seiner gegebenen Version ausgereift und stabil oder sind zusätzliche Erweiterungen und Modifikationen zu erwarten, die den kompatiblen Einsatz mit aktueller Ausrüstung in Frage stellen?

32

• Als Kompromiss zwischen modernster Technologie und bewährtem und ausgereiftem technischen Standard habe ich für das LISTIG-Basisgerät eine WLAN-Schnittstellen-Karte nach dem 802.11b-Standard ausgewählt. Zum Zeitpunkt der Bearbeitung meiner Aufgabenstellung gab es in der Open-Source-Szene noch keine ausgereiften Treiber für Linux, die Chipsätze des Standards 802.11g vernünftig unterstützten, wie zeitaufwendige Recherchen ergaben. So scheiterte die Einbindung einer PCMCIA-WLAN-Karte (ARTEM Com Card CC-W54g) mit Intersil-Chipsatz nach 802.11g-Standard an Treiberproblemen.

Verbreitung des Standards: Hat der Standard eine ausreichende Akzeptanz

gefunden, um auch in Zukunft durch innovative Geräte unterstützt zu werden?

• Chipsätze nach 802.11b haben eine sehr große Verbreitung gefunden. Die entsprechenden Geräte sind inzwischen sehr preiswert erhältlich. Die Kompatibilität ist hervorragend, da die modernen 802.11g-Chipsätze zum 802.11b-Standard abwärts kompatibel sind.

Geschwindigkeit: Welche Datenrate stellt die jeweilige Technologie zur Verfü-

gung? Hierbei ist unbedingt zwischen Brutto- und Nettodatenrate zu unterscheiden

• Diese Frage muss vor dem Hintergrund der Anforderung an die Anwendung des LISTIG-Systems berücksichtigt werden. Die Anforderung nach Bandbreite bei einer Heimautomatisierungs-Anlage zur Übertragung von einigen Steuersignalen kann eine untergeordnete Rolle spielen. Zur drahtlosen Steuerung einer solchen Anlage müssen relativ wenige Daten ausgetauscht werden.

Die Erweiterung IEEE-802.11b sieht maximal 11 MBit/s vor. In der Praxis reduziert sich die Transferrate um die Hälfte. Für den vorliegenden Anwendungsfall erscheint diese Geschwindigkeit absolut ausreichend.

Reichweite: Welche Reichweite lässt der Einsatz der jeweiligen Technologie

erwarten? Dabei sind insbesondere die zulässigen Sendeleistungen bzw. Leistungsdichten zu betrachten. Der Einsatz von anisotropen Antennen zur Erreichung höherer Reichweiten ist im Wesentlichen unabhängig von der gewählten Technologie.

• Größere Distanzen zwischen den Stationen machen sich beim Funk-LAN

deutlich bemerkbar. IEEE-802.11b bietet eine ausreichende Reichweite für den Zugriff auf das Basisgerät einer Hausautomatisierungsanlage von variablen Orten innerhalb eines Gebäudes (abhängig von der Dicke und Beschaffenheit der Wände).

Quality of Service: Werden definierte Dienstgüten unterstützt? Hierbei ist allerdings die Frage nach der Durchgängigkeit dieser Unterstützung über alle Netzwerkebenen zu stellen.

• Auch diese Frage spielt in unserem Anwendungsfall eine untergeordnete

Rolle

33

Sicherheitsmechanismen: Welche Sicherheitsmechanismen sind im Standard vorgesehen? Hierbei ist zu berücksichtigen, dass nur diejenigen Mechanismen durchgängig im Betrieb Einsatz finden können, die von allen Geräten unterstützt werden. Solange homogene Netze von nur einem Hersteller betrieben werden, reicht die Unterstützung auf Produktebene vollkommen aus. Dieses Szenario gilt allerdings nur bei Punkt-zu-Punkt-Verbindungen wie Funkbrücken uneingeschränkt.

• Standardmäßig ist zumindest das weit verbreitete WEP und bei einigen

neueren und teureren Geräten WPA als Verschlüsselungstechnik integriert. Weiterführende Sicherheitstechniken können softwareseitig nachträglich nach Einrichtung eines Access Points auf dem Basisgerät implementiert werden.

Administration: Welche Protokolle sind in dem Standard vorgesehen, die eine über

alle Hersteller durchgängige Verwaltung des gesamten Netzwerks erlauben?

• Da 802.11b ein Unterstandard von 802.11 ist, besitzt es eine Protokoll-architektur, die sich durch hohe Kompatibilität zu allen denkbaren Netzwerkkomponenten auszeichnet.

Ad-hoc-Networking: In welchem Maße werden Funktionalitäten eines Adhoc-

Networking unterstützt?

• Allgemein bieten drahtlose Netzwerke die Fähigkeit, dass über den reinen Aufbau einer Netzwerkverbindung hinaus auch die Anwendungen selbsttätig miteinander in Verbindung treten können.

4.2 Auswahl der WLAN-Geräte Auf dem sehr dynamischen Gebiet WLAN wechselt das Produktspektrum recht häufig (selbst die Herstellernamen bleiben von Änderungen nicht verschont). Zwei wesentliche Produktklassen sind:

1. Client Adapter (CA)

In manchem neueren mobilen Gerät sind WLAN-Adapter fest eingebaut, hier sind ggf. die Besonderheiten nationaler Zulassungsbedingungen zu beachten (nutzbare Kanäle ...). In den meisten Fällen werden heute austauschbare Adapter eingesetzt, die es für unterschiedliche Schnittstellen und Formfaktoren gibt:

• PCMCIA/PC-Card (Cardbus) • Compact Flash (kleiner als PC-Card, für PDAs) • PCI (eher wenig gebräuchlich) • USB (die praktikabelste Variante für Desktops)

2. Access Point (AP)

34

Hier gibt es eine größere Anzahl von Unterscheidungsparametern:

• Basis-Funktionalität (L2-Bridge ...) • Anzahl der Kanäle (typisch 1 .. 2) • Festnetz-Schnittstelle (typisch 100 BASE TX) • WEP- und andere Sicherheitsparameter • Filterfunktionen • Management-Schnittstellen • zulässige Umgebungsbedingungen • Stromversorgung: z.B. Power over Ethernet (PoE)

Im Rahmen meiner Aufgabenstellung gibt es für den Einsatz eines Access Points keine zwingende Notwendigkeit, da für die Übertragung der Steuersignale vom Notebook/PDA zum Basisgerät der Ad-hoc-Modus eine ausreichende Technik darstellt. Eine Ausnahme bildet die Option, das Basisgerät hinsichtlich des Funkverkehrs mit weiteren Sicherheits-mechanismen ausstatten zu wollen. Aber selbst hierfür ließe sich ein Access Point auf Linux-Basis unter Nutzung spezieller Open-Source-Treiber softwareseitig implementieren.

4.2.1 Kriterien Ebenso wie im vorangegangenen Kapitel waren auch bei der Auswahl des konkreten Wireless Adapters einige Vorüberlegungen anzustellen:

Bauformen: Welche Bauformen werden unterstützt? Bei den mobilen PC-gestützten Stationen unterscheidet man dabei im Wesentlichen USB-, PCI- oder PC-Card-gestützte Geräte. Bei den Access Points ist die Vielfalt deutlich größer, die Fragestellung aber meist unkritischer.

Erreichbare Bandbreiten: Im Gegensatz zu drahtgebundenen Systemen sind die

erreichbaren Bandbreiten wesentlich abhängig von der Qualität der Empfänger, die nicht im Standard vorgegeben sind. Hier geben die aktuellen Testergebnisse in den einschlägigen Fachzeitschriften ausreichend Auskunft.

Erreichbare Reichweiten: Die Frage nach den Reichweiten, über die ein Funknetz

betrieben werden kann, ist eng mit der Frage nach der jeweils erreichbaren Bandbreite verknüpft.

Verfügbarkeit von Relaisstationen: Die Reichweite von Funknetzen kann unter

Umständen durch den Einsatz von Relaisstationen vergrößert werden. Diese sind im Wesentlichen einsetzbar bei Punkt-zu-Punkt-Verbindungen.

Kompatibilität zu anderen Geräten: Auch wenn die grundsätzliche Kompatibilität

der Geräte in heterogenen Umgebungen durch die Konformität zum Standard gegeben ist, stellen viele Geräte zusätzliche Funktionen zur Verfügung, die außerhalb des Standards stehen. Hierbei ist ein unterschiedlicher Grad an Gemeinsamkeiten zu beobachten.

Zusätzliche Sicherheitsmechanismen: Vor allem in den Fällen, in denen die im

Standard vorgesehenen Sicherheitsmechanismen als nicht ausreichend angesehen werden, erweitern manche Hersteller ihre Geräte durch zusätzliche Sicherheitsmechanismen. Diese sind dann unter Umständen aber nur in homogenen Netzen zu nutzen.

35

Zusätzliche Funktionalitäten: Einige Geräte - und hierbei insbesondere die Access

Points - stellen zusätzliche Netzwerkfunktionalität zur Verfügung. Als Beispiele können Routing oder Firewall genannt werden.

Administration und Werkzeuge: Welche Werkzeuge zur Verwaltung der Stationen

und des Netzwerks werden bereitgestellt? Bei Access Points ist es mittlerweile weit verbreitet, dass ein Embedded Webserver den Zugriff über einen normalen Webbrowser ermöglicht. Aber auch hier können erhebliche Unterschiede bei Übersichtlichkeit und Bedienungskomfort beobachtet werden. Bei mobilen Stationen, die ohnehin die Installation von Treibern benötigen, werden meist zusätzliche Administrationswerkzeuge eingesetzt.

Preis: Bei der Bestimmung der kommerziellen Aspekte sind die gesamten

Systemkosten zu berücksichtigen. Dies gilt sowohl für den Vergleich zwischen drahtgebundenen und drahtlosen Systemen und der Fragestellung nach Leitungs- und Installationskosten als auch für die Kosten während des gesamten Lebenszyklus. Somit schließen die Systemkosten auch den Administrationsaufwand und eventuelle Erweitungs- oder Ersatzbeschaffungen mit ein.

Chipsatz: Der eingebaute Chipsatz der zu verwendenden Karte spielte bei meiner

Entscheidung die größte Rolle, da hiervon abhing, ob stabile Open-Source-Treiber erhältlich sind, mit denen die WLAN-Karte unter Linux verwendet werden kann.

4.2.2 Schnittstellen von LISTIG Als Schnittstellen für ein WLAN-Gerät bietet das LISTIG-Basisgerät PCI-Slots und ein USB-Interface. Über einen PCMCIA-to-PCI-Adapter ließe sich das große Angebot an verfügbaren PCMCIA-Karten für Notebooks im LISTIG-System nutzen. Für die USB-Schnittstelle fällt das Angebot kleiner aus und somit ist die Unterstützung mit Treiber-modulen für Linux sowohl in der Open-Source-Szene und erst recht herstellerseitig nur gering. Außerdem fallen für USB-Geräte höhere Preise an. Ein anderer Grund, auf die USB-Variante zu verzichten, war der, dass im Rahmen des LISTIG-Projektes die Verbindungsvariante per Bluetooth den einzigen USB-Port bereits für sich beansprucht. IrDa bedient sich des seriellen Ports, während sich die GSM-Variante den einen der beiden PCI-Slots für die Netzwerkkarte reserviert. Da insgesamt 2 PCI-Slots zur Verfügung stehen, kann einer für die WLAN-Erweiterung genutzt werden. In der Praxis stellte sich jedoch heraus, dass auf dem Basisgerät nur der äußere PCI-Slot nutzbar ist, so dass auf dem Testsystem bisher entweder nur die LAN-Netzwerkkarte oder die WLAN-Karte genutzt werden kann. Im PCI-Bus gibt es nur die vier IRQ-Leitungen INT_A bis INT_D. An diesen hängen alle PCI-Geräte, also nicht nur die Steckkarten, sondern auch Onboard-Geräte wie z.B der USB-Controller. Eine Logikschaltung ordnet die vier PCI-Interruptleitungen den 15 IRQ-Eingängen des PIC zu. Bei einigen Mainboards kann man per BIOS-Setup noch weiter in die Zuordnung der PCI-Interrupts eingreifen und etwa festlegen, welcher PCI-Slot welche IRQ-Nummer bekommen soll. Das funktioniert natürlich nur im Rahmen der elektrischen Gegebenheiten, also: Wenn zwei PCI-Slots elektrisch an dieselbe Interruptleitung

36

angeschlossen sind, kann man das nicht per BIOS-Setup ändern. Der 2. PCI-Slot ist bei den meisten Boards der einzige, für den sich wirklich ein ungeteilter IRQ einstellen lässt. Im BIOS des LISTIG-Mainboards ließ sich keine Änderung der Zuordnung von PCI-Interrupts erreichen, so dass der innere PCI-Slot zusammen mit dem USB-Port, der ISA-Bridge und dem IDE-Controller fest mit dem Interrupt 11 verbunden sind, während der äußere Slot ständig den Interrupt 10 zugewiesen bekommt. Eventuell ist ein BIOS-Update des Mainboards erforderlich. Als PCI-to-PC Card-Adapter stand mir zunächst der Level-One RNC-0100 mit dem Chipsatz ti PCI1225 von Texas Instruments zur Verfügung. Alle Versuche, die PCMCIA-WLAN-Karten

• Nokia D211 • Linksys WPC11E • Cabletron Systems Roam About • Artem ComCard 54g

darin unter Linux zum Laufen zu bringen, liefen jedoch ins Leere. Der Grund kann fehlende oder mangelnde Unterstützung dieses Chipsatzes in den PCMCIA-Packages von Linux sein. Daraufhin beschloss ich, es direkt mit einer PCI-WLAN-Karte zu versuchen, in der Hoffnung auf bessere Unterstützung durch Open-Source-Treiber. Das hat schließlich zum Erfolg geführt. Genau wie bei der Datenübertragung per Bluetooth und Infrarot, erscheint mir für die direkte Übermittlung der Steuersignale, einschließlich Feedback, eine einfache Schnittstellenkarte als ausreichend für eine Heimautomatisierungsanlage, womit die Anschaffung eines teureren Access Points für Netzwerke überflüssig wäre. Ohnehin gibt es, wie bereits erwähnt, unter Linux dank der Erfolge des „HostAP“- Projektes (http://hostap.epitest.fi/) die Möglichkeit, Access Point-Funktionalität softwaremäßig für Prism-basierte Karten einzurichten, was für die Implementierung erweiterter Sicherheitsmaßnahmen von Bedeutung wäre.

4.2.3 Hardware Alle Systeme unterstützen im Wesentlichen die Betriebssysteme der Microsoft-Windows-Familie. In den kommerziellen Standardpaketen spielt die Unterstützung von Unix im Allgemeinen und Linux im Speziellen keine Rolle. Für den Einsatz unter Linux sind seit der Kernel-Version 2.2 die gängigsten Karten im Kernel integriert. Für andere Produkte ist man auf das Engagement der Linux-Gemeinde angewiesen. Unter Berücksichtigung der vorigen Kapitel genannten Fragestellungen entschied ich mich also nach ausführlichen Recherchen für die WLAN-Karte „Netgear MA311 (PCI)“, welche den Standard 802.11b unterstützt. Dieser Standard hat sich auf breiter Front, auch wegen des günstigen Preises und der Tatsache, dass das 2,4-GHz-Band in den meisten Ländern lizenzfrei genutzt werden darf, durchgesetzt. Die Produkte mit diesem Standard gelten als ausgereift und arbeiten in der Praxis auch untereinander gut zusammen. Die Sendeleistung liegt bei maximal 100 mW was eine Reichweite von 40 m ermöglicht. In Abhängigkeit des Baustoffs für Wände und Decken reduziert sich die Reichweite auf 25 bis 30 m. Im Außenbereich lassen sich Reichweiten bei Sichtkontakt bis 100 m oder mehr erreichen.

37

Netgear-Produkte sind im Allgemeinen ausgereift und günstig zu haben. Das entscheidende Auswahlkriterium war jedoch der Chipsatz. Hier kam es darauf an, das die Karte einen generischen Chipsatz besitzt, der von den meisten Linux-Distributionen unterstützt wird. Auf der Webseite des Linux-WLAN-Projekts: http://www.linux-wlan.org/docs/wlan_adapters.html.gz ließ sich sich der Chipsatz dieses Produkts als Prism2/2.5/3 identifizieren. Hierfür galt es anschließend die passenden Treibermodule aufzuspüren. Nachdem genau das bei verschiedenen mir zur Verfügung stehenden WLAN-Karten (Linksys WPC11E, Cabletron Roam About und Artem ComCard54g) gescheitert war, ließ sich die Netgear-Komponente letztendlich erfolgreich installieren.

Abbildung 4.1: Erfolgreiche Installation mit dieser PCI-WLAN-Karte

Die drahtlose Konnektivität dieser Karte liegt bei 11 MBit/s brutto mit automatischer Fallback-Geschwindigkeit für größere Entfernungen. Nach meinen Recherchen zeichnet sich die Karte durch eine sehr gute Kompatibilität und gute Empfängerqualität aus.

Leistungsmerkmale:

• Unterstützung des IEEE 802.11b-Standards • 11-MBit/s Datendurchsatz (Brutto) • 40-, 64- und 128-Bit WEP-Verschlüsselung • Reichweite im Gebäude bis zu ca. 50 m • Bus-Interface: 32-Bit PCI v2.2 Compliant • LED-Anzeigen • Externe Antenne • WiFi-Zertifizierung

Auf der Seite des Test-Clients (ein Notebook mit Windows XP) kam eine Wireless PC Card vom gleichen Hersteller zum Einsatz, um maximale Kompatibilität zu gewährleisten. Es handelt sich hierbei um die Netgear MA521 (802.11b)

5 Wireless LAN und Linux

38

Auf dem Basisgerät kommt, wie schon erwähnt, das Open-Source Betriebssystem Debian/GNU Linux zum Einsatz. Das bedingt eine genaue Recherche, bei welcher Hardware, welche Konfiguration aus Linux-Kern, Treibermodulen und zusätzlichen Paketen notwendig ist, um eine erfolgreiche Installation der WLAN-Hardware zu garantieren. Darüberhinaus müssen Konfigurationsdateien des Betriebssystems bearbeitet werden.

5.1 Grundlegendes

5.1.1 Chipsatz Die Frage nach dem Chipsatz einer WLAN Karte ist vor dem Kauf zumindest für Linux-User entscheidend, sonst kann man später böse Überraschungen erleben. Denn um WLAN unter Linux zu nutzen, braucht man natürlich einen Adapter, für den ein Treiber existiert. Dieser unterstützt im Normalfall immer einen bestimmten Chipsatz. So kann es passieren, dass WLAN Karten zweier unterschiedlicher Hersteller mit dem gleichen Treiber laufen. Genauso passiert es aber, dass Karten mit der exakt gleichen Bezeichnung eines Herstellers unterschiedliche Treiber benötigen, weil der in der Produktion der Chipsatzanbieter gewechselt wurde; und selbst der Hinweis: „Linux Support“ ist manchmal irreführend. Es ist also Vorsicht geboten, wenn man eine WLAN Karte anschafft. Wichtig ist es, vor dem Kauf die genaue Version der Karte in Erfahrung zu bringen, denn nur über die ist es möglich, den Chipsatz zu bestimmen. Kein Hersteller schreibt die Art des Chipsatzes auf die Packung. Zum Glück gibt es Suchmaschinen im Internet. So konnte ich nach Versionsnummer, Bezeichnung und dem Stichwort "Linux" zu suchen, um den Chipsatz meiner Karte zu bestimmen. Auch ist es mit einigen Treibern bisher nicht möglich Airsnort oder andere Scanprogramme zu benutzen. Beste Unterstützung erfahren bisher der Orinoco, Prism Chipsatz. Eine umfangreiche Liste geordnet nach Herstellern findet man hier: http://www.linux-wlan.org/docs/wlan_adapters.html.gz

5.1.2 Software-Voraussetzungen Benötigt werden für eine erfolgreiche Installation im Allgemeinen:

• Treiber für Kartenchipsatz, falls nicht in Kernel • Kernelquellen mit PCMCIA-Karten-Unterstützung und Wireless Extensions • eventuell externes PCMCIA-Package • Wireless-Tools

in den richtigen Versionen !

5.1.3 Treiber Zum Zeitpunkt meiner Projektarbeit gab es drei große Treiber-Sammlungen für WLAN-Geräte unter Linux: Die PCMCIA-Card-Services (pcmcia_cs) unter http://pcmcia-cs. sourceforge.net, deren Treiber inzwischen größtenteils in den Kernel aufgenommen

39

wurden, die "Next Generation"-Treiber von AbsoluteValue Systems Inc.(besser bekannt als linux-wlan-ng) von http://www.linux-wlan.org sowie die Linksammlung von Jean Tourrilhes aus dem Linux Wireless LAN Howto von http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wireless.html. Hier noch einmal eine etwas detailliertere Übersicht: 1) Orinoco Karten mit diesem Chipsatz werden bereits seit frühen Kernel Versionen unterstützt (Lucent, WaveLan, Lucent Orinoco, Symbol Spectrum 24, Apple AirPort, Prism2-Cards) 2) wlan-ng Treiber für Karten mit Prism 2/2.5/3 Chipsatz. Sie unterstützen nicht das Wireless-Tools-Paket, aber liefern ihre eigenen Konfigurationstools mit. Download unter: http://www.linux-wlan.com/linux-wlan/ 3) host-ap Treiber für Intersil Prism2/2.5/3 USB cards basierend auf dem Prism Chipsatz werden nicht unterstützt. Der Treiber besteht aus drei Komponenten hostap-driver: Treiber mit Access Point Unterstützung (IEEE 802.11) hostapd: User space daemon for extended IEEE 802.11 management IEEE 802.1X Authentifizierung RADIUS Authentication client RADIUS Accounting client hostap-utils: Utilities http://hostap.epitest.fi/ 4) prism54

Linux Kernel Treiber WLAN 802.11(1/b/g) für den Prism GT/Duette Chipsatz Voraussetzung: Kernel 2.4.23+ oder besser 2.6.0+ Weiterhin wird eine Firmware für die Karte benötigt: http://prism54.org/firmware/ Download: http://www.prism54.org 5) RTL8180

Dieser Chipsatz wird meist in preislich günstigen Karten verbaut. Teilweise steht auf den Verpackungen: Linux Support, das stimmt zunächst auch, nur handelt es sich dabei teilweise um closed source. Die vom Hersteller Realtek angebotenen vorkompilierten Treiber funktionieren leider nicht mit jeder Kernelversion. Angeboten wird: Linux kernel 2.4.18 (gcc version 2.96) Linux kernel 2.4.20 (gcc version 3.2.2). Der neue 2.6 wird bisher nicht unterstützt und auf einem 2.4.x System lassen sich die Treiber zwar kompilieren, allerdings wurde die closed source Komponente gegen einen 2.4.20 Kernel von Red Hat gebaut. Inzwischen wurde ein Projekt auf Sourceforge.net ins Leben gerufen, um eine bessere Treiberunterstützung zu gewährleisten. Download von Realtek: http://www.realtek.com.tw/downloads...px?Keyword=8180

40

Projekt auf sourceforge http://sourceforge.net/projects/rtl-ddp/ 6) Centrino

Nachdem sich Intel lange nicht um eine Linux-Unterstützung gekümmert hatte, wird inzwischen stetig an einem Linux Treiber gearbeitet: http://ipw2100.sourceforge.net/ 7) Athero Linux Treiber für 802.11a/b/g Athero Chipsatz Download: http://sourceforge.net/projects/madwifi/ FAQ: http://www.mattfoster.clara.co.uk/madwifi-faq.htm, Wiki http://madwifiwiki.thewebhost.de/wiki/ 8) Ndiswrapper Einen Sonderweg geht das Projekt Ndiswrapper. Es versucht den mit der Karte immer mitglieferten Windowstreiber zu laden und ihn somit unter Linux benutzbar zu machen. Homepage: http://ndiswrapper.sourceforge.net/ Unterstützte Chipsätze: http://ndiswrapper.sourceforge.net/...d_chipsets.html 9) Driverloader Die kommerzielle Variante von ndiswrapper ist schon etwas weiter fortgeschritten und wurde auch aufgrund der mangelnden Unterstützung von Intel für die Entwicklung von Linux Treibern für den Centrino entwickelt: Derzeit werden folgende Chipsätze unterstützt: Atheros Broadcom (AirForce) Cisco (Aironet) INPROCOMM Intel (PRO/Wireless 2100, 2100A, 2200BG - Centrino) Intersil (Prism GT/Duette/Indigo) Marvell (Libertas) Realtek (RTL8180L) Texas Instruments (ACX100, ACX111/TNETW1130) Eine 30 tägige Testversion kann man sich für alle gängigen Linuxdistributionen herunterladen oder selbst kompilieren. Voraussetzung Kernel 2.4.x http://www.linuxant.com/driverloade...l/downloads.php (Die Lizenz kostet 19.95$) 10) Atmel Treiber unter http://atmelwlandriver.sourceforge.net Übersicht über die unterstützten Geräte: http://atmelwlandriver.sourceforge.net/usbtable.html Eine Maillinglistenarchiv/Mailingliste für diesen Chipsatz, der hauptsächlich in USB Geräten verbaut wird, befindet sich hier: http://iprserv.jura.uni-leipzig.de/.../atmel-wlan-usb

41

5.2 Grundkonfiguration Die Zusammengehörigkeit der einzelnen WLAN-Geräte zu einem Netz, egal ob Ad-Hoc oder "Managed Infrastructure", wird durch die Verwendung der gleichen SSID (Service Set Identifier) festgelegt. Auch müssen alle Geräte auf dem gleichen Kanal arbeiten. Es stehen die Kanäle 1 bis 14 zur Verfügung, der Bereich ab Kanal 8 aufwärts wird allerdings auch von Bluetooth-Geräten benutzt, was beim Parallelbetrieb zu Störungen oder niedrigeren Datenraten führen kann. Immer wieder wird empfohlen, für die SSID eine kryptische, möglichst zufällige Zeichenfolge zu verwenden, um Angreifern den Zugang zum Netz zu erschweren. Da die SSID jedoch von vielen Access Points bei jedem Datenpaket in die Welt hinausposaunt wird, braucht man lediglich kurz in den abgehörten Datenstrom zu schauen, um die SSID herauszubekommen. Daher ist es sinnvoller, den Namen des Betreibers in der SSID unterzubringen: So kann ein Nachbar durch simples Lauschen feststellen, welche WLANs in seiner Umgebung stehen, zu wem sie gehören und eventuell wie weit sie entfernt sind - um sich dann einen anderen Kanal zu suchen oder bei Störungen Kontakt aufzunehmen.

5.2.1 Konfiguration der Standard-Treiber Die Treiber des Kernels, der PCMCIA-Card-Services sowie aus der Treiber-Sammlung von Jean Tourrilhes verwenden zur Konfiguration die Datei /etc/pcmcia/wireless.opts. Die Datei besteht im Wesentlichen aus Variablen-Zuweisungen für die einzelnen WLAN-Karten, wobei die verschiedenen Konfigurationen über die Hardwareadresse (Mac-Adresse) auseinander gehalten werden. Wird nur eine Karte eingesetzt, kann auf die Angabe der Hardwareadresse verzichtet werden. Die Hardwareadresse der Karte muss nicht komplett angegeben werden, die ersten drei Bytes in hexadezimaler Schreibweise reichen meist als Unterscheidungskriterium zwischen verschiedenen Herstellern aus. Die Adresse steht meist auf dem Typenschild oder auf der Rückseite der Karte, ansonsten kann sie nach Anschließen der Karte per ifconfig abgerufen werden. Bei ESSID wird die vorab besprochene SSID des WLAN-Netzes eingetragen. Die Network-ID, kurz NWID, ist eine bis zu vierstellige hexadezimale Kennung, die für ein WLAN wiederum einheitlich gesetzt sein muss. In der Praxis wird die NWID faktisch nicht benutzt. Wird das WLAN-Netzwerk im Ad-Hoc-Modus betrieben, wird entsprechend MODE = "Ad-Hoc" gesetzt. Bei einer "Managed Infrastructure" muss entsprechend MODE = "Managed" angegeben werden. Der Modus auto ist gefährlich: Wird ein WLAN entgegen der Empfehlungen mit SSID any betrieben, kann es passieren, dass sich die Karte irrtümlich in einer fremden "Managed Infrastructure" in der Nachbarschaft anmeldet, obwohl lokal im Ad-Hoc-Modus gearbeitet wird. Mit den Variablen FREQ und CHANNEL wird der Betriebskanal angegeben. Man sollte hierbei stets FREQ offen lassen und einen der 14 Kanäle mittels CHANNEL setzen - es ist schlicht leichter zu merken. Die gewünschte maximale Transferrate wird mittels RATE eingestellt. In den meisten Fällen arbeitet auto völlig ausreichend, es wird dann versucht, die höchste Transferrate zu

42

verwenden. Bei größeren Entfernungen oder hohen Reflexionen kann es sinnvoll sein, die maximale Transferrate von vornherein zu beschränken. Das erlaubt einen schnelleren Verbindungsaufbau, weil keine Zeit zum Probieren höherer Transferraten verschwendet wird. Die neben Kanaleinstellung und SSID wichtigste Variable ist KEY, dort wird der WEP-Schlüssel des Netzes eingetragen. Für die Praxis ermittelt man einen Schlüssel entweder mit einem Würfel - hierbei können durchaus die 20-seitigen Würfel verschiedener Rollenspiele gute Dienste tun - oder durch Auslesen von /dev/urandom mit folgendem Befehl: listig2:~ # dd if=/dev/urandom bs=14 count=1 2>/dev/null \ | hexdump | cut -c 9 -40 | tr “ “ – 5fc3-c39f-30ae-b6f5-1283-adlb-9c Um Missverständnissen vorzubeugen: Es wird pro WLAN ein einziger Schlüssel bestimmt, nicht für jedes WLAN-Gerät ein neuer. Oder man ermittelt gleich mehrere, die man dann in regelmäßigen Abständen bei allen WLAN-Geräten austauscht. Die Variablen SENS, RTS, FRAG, IWCONFIG, IWSPY sowie IWPRIV werden in der Praxis nicht benötigt, eine detaillierte Beschreibung findet sich in den Man-Pages iwconfig(8), iwspy(8) und iwpriv(8). Die Konfigurationsdatei /etc/pcmcia/wlan-ng.opts für die „Next Generation“-Treiber ist etwas anders aufgebaut als die der Standard-Treiber, enthält aber ebenfalls hauptsächlich Variablenzuweisungen. Für Nicht-PCMCIA-Geräte wird die Konfigurationsdatei /etc/wlan.conf benutzt. Da diese Treiber-Sammlung im Rahmen meiner Projektarbeit im Weiteren keine Rolle spielt, gehe ich auf deren Konfiguration nicht näher ein.

5.3 Treiber selbst kompilieren Mitunter fehlen die benötigten Treiber zum Betrieb des WLAN-Geräts, Standard bei allen aktuellen Distributionen ist das PCMCIA-Card-Services-Paket, welches unter Umständen aktualisiert werden muß, wie in meinem Fall. Die "Next Generation"-Treiber enthalten nur spezielle Distributionen, wie z.B die SuSE Linux 8.1, sonstige Treiber müssen allerdings von Hand übersetzt werden. Hinweise, welche Treiber wo zu beziehen sind, liefert das Linux Wireless LAN Howto von Jean Tourrilhes auf http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux. Zum Kompilieren eines PCMCIA-Treibers werden in jedem Fall die Kernel-Quellen sowie die Quellen der PCMCIA-Card-Services benötigt. Dabei kann meist auf die Quellen der Distribution zurückgegriffen werden, nur in Ausnahmefällen braucht man die Original-Quellen der PCMCIA-Card-Services von http://pcmcia-cs.sourceforge.net/ftp oder gar einen Original-Kernel. Die Kernel-Quellen müssen vor dem Kompilieren der WLAN-Treiber zumindest per make dep vorbereitet worden sein, dieser Schritt löst Abhängigkeiten innerhalb des Kernels auf. Anschließend werden die PCMCIA-Quellen mittels ./configure konfiguriert und per make install übersetzt und installiert.

43

Erst dann ist der WLAN- Treiber an der Reihe, zum Beispiel in Form des TreiberPakets linux-wlan-ng für Prism-2- und Prism-3-Chipsätze. Nach Entpacken des Quellpakets von ftp://ftp.linux-wlan.org/pub/linux-wlan-ng wird make config aufgerufen. Der Treiber wird nach der Konfiguration per make übersetzt und mit make install installiert. Dabei wird das Skript rc.wlan nach /etc/init.d kopiert, jedoch kein symbolischer Link für die automatische Einrichtung beim Systemstart angelegt.

6 Inbetriebnahme der WLAN-Schnittstelle

6.1 Der Linux Kernel und Wireless LAN

Der Linux Kernel unterstützte schon sehr früh Karten mit denen man drahtlose Netze aufbauen konnte. Dennoch gab es lange keine einheitliche API für solche Treiber. Erst mit den Wireless Extensions wurde so eine Schnittstelle zum Kernel geschaffen. Die Wireless Extensions wurden als Erweiterung der Netzwerk Schnittstellen (z.B. eth0) definiert. Über die Erweiterungen können nun die zusätzlichen Einstellungen, die für ein drahtloses Netzwerk notwendig sind vorgenommen werden. Alle zusätzlichen Einstellungen wurden aber nicht in das Programm ifconfig eingebaut, sondern in ein extra Programm ausgelagert. Dieses Tool heißt iwconfig und ist Bestandteil der Wireless-Tools.

Wireless-Tools die Befehle Nach der Installation der Wireless-Tools verfügt man über die nötigen Befehle, um die WLAN Karte konfigurieren zu können. Nähere Informationen findet sich in den man-pages zu dem jeweiligen Befehl. Die Wireless-Tools beinhalten Managementanwendungen wie: iwconfig Iwconfig ist ähnlich wie ifconfig, aber auf die Wireless Extensions abgestimmt. Es wird benützt, um spezifische Parameter auf der Netzwerkschnittstelle zu setzen. Iwconfig wird auch eingesetzt, um diese Parameter und die Interface-Statistik anzuzeigen. iwspy Iwspy wird benützt, um eine Liste von Adressen (IP- und MAC-Adressen) auf einer Wireless Netzwerkschnittstelle zu setzen und Qualitätsinformationen über dieselben zurückzulesen. iwlist Iwlist gibt Informationen von einer Wireless Netzwerkschnittstelle zurück, die von Iwconfig nicht angezeigt werden. Dies ist typischerweise eine Liste von Parametern.

iwpriv Iwpriv [interface] iwpriv interface private-command [private-parameters] iwpriv interface roam {on,off} iwpriv interface port {ad-hoc,managed,N} Iwpriv ist das Kameraden Tool zu iwconfig. Iwpriv handelt mit Parametern und Einstellungen für jeden Treiber. Ohne Argumente listet iwpriv private Kommandos auf,

44

die für jedes Interface verfügbar sind. Mit dem Linux Kernel 2.4.x sind die PCMCIA Treiber und Module fester Bestandteil des Kernel geworden. Es existiert zwar weiter das PCMCIA Card Services Paket, aber hieraus werden nur noch die User-Level Utilities benötigt. Weiterhin sollte bei PCI-to-CardBus Komponenten nur noch das yenta_socket Modul benutzt werden.

Natürlich muss der Kernel mit den Optionen für PCMCIA, Wireless LAN, Wireless Extensions und den Treiber für die ORiNOCO bzw. Prism2-Karten kompiliert werden. Folgende Optionen sind hierbei ausreichend:

# # PCMCIA/CardBus support # CONFIG_PCMCIA=m CONFIG_CARDBUS=y # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y CONFIG_NET_WIRELESS=y CONFIG_PCMCIA_HERMES=m CONFIG_AIRO_CS=m

Den Vorgang der Konfiguration beschreibe ich im nächsten Kapitel.

6.2 Konfiguration der PCMCIA Card Services

Seit dem Kernel 2.4.3 ist der Treiber orinoco_cs fester Bestandteil im Mainlinecode. Für die Ansteuerung des "Hermes" Wireless MAC Controller wird das Modul hermes benutzt. Ab dem Kernel 2.4.5 sind alle Treiber für Wireless LAN unter dem Verzeichnis wireless zusammengefasst. Ausserdem wurde der PCMCIA unabhängige Teil von orinoco_cs in das Modul orinoco verschoben und macht somit die einfache Entwicklung von PCI und USB Wireless Adaptern möglich.

Mit dem Kernel 2.4.4 wurden die Wireless Extensions von der Version 10 auf die Version 11 erneuert. Es sollte somit mindestens ein Kernel ab der Version 2.4.4 benutzt werden. Am besten ist natürlich die Version 2.4.6 oder neuer.

Nachdem ich auf der Webseite: http://www.linux-wlan.org/docs/wlan_adapters.html.gz anhand meiner Kartenbezeichnung den verwendeten Chipsatz als Prism2/2.5/3 identifizieren konnte, hatte ich nun die Wahl, entweder die wlan-ng-Treiber oder die Treiber aus der Treibersammlung von Jean Tourrilhes zu verwenden. Ich entschied mich aufgrund von Erfahrungsberichten für die zweite Variante. Auf der Internetseite des Open-Source-Entwicklers Jean Tourilhes

45

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.drivers.html fand ich anschließend unter der Rubrik „Wavelan IEEE/Orinoco, PrismII and Symbol Cards“ die gewünschten Informationen: Treiber-Name: orinoco_pci.o Version: v0.13e, v0.14alpha2 wo: Linux Kernel (ab 2.4.21; 2.5.71) PCMCIA-Package (3.1.34) Ich habe mich aufgrund von Empfehlungen aus Linux-Foren bezüglich der Kombination aus WLAN-Chipsatz, den passenden Treibern und der optimalen Kernelversion für den Linux-Kernel 2.4.23 entschieden, was unmittelbar mit der erforderlichen Version der Wireless Extensions zusammenhing. Die Voraussetzung, die PCI-WLAN-Karte Netgear MA311 zum Laufen zu bringen, war das Vorhandensein der Wireless Extensions in der Version 16 im Kernel. Ein weiterer Vorteil dieses Kernels war, dass die benötigten Komponenten des Orinoco-Treibers bereits im Kernel vorhanden sind und sich somit die Treiberinstallation auf das richtige Konfigurieren des Kernels beschränkt, um die korrekten Module zu erstellen. Kernel Treiber Verzeichnis Wireless Extensions2.4.3 0.03 drivers/net/pcmcia/ Version 10 2.4.4 0.04c drivers/net/pcmcia/ Version 11 2.4.5 0.05d drivers/net/wireless/ Version 11 2.4.6 0.06c drivers/net/wireless/ Version 11 2.4.7 0.06c drivers/net/wireless/ Version 11 2.4.8 0.06c drivers/net/wireless/ Version 11 2.4.9 0.06f drivers/net/wireless/ Version 11 2.4.10 0.07 drivers/net/wireless/ Version 11 2.4.11 0.08a drivers/net/wireless/ Version 11 2.4.12 0.08a drivers/net/wireless/ Version 11 2.4.13 0.08a drivers/net/wireless/ Version 12 2.4.14 0.08a drivers/net/wireless/ Version 12 2.4.15 0.08a drivers/net/wireless/ Version 12 2.4.16 0.08a drivers/net/wireless/ Version 12 2.4.17 0.08a drivers/net/wireless/ Version 12 2.4.18 0.09b drivers/net/wireless/ Version 12 2.4.19 0.11b drivers/net/wireless/ Version 13 2.4.20 0.11b drivers/net/wireless/ Version 14 2.4.21 0.13b drivers/net/wireless/ Version 15 2.4.22 0.13d drivers/net/wireless/ Version 15 2.4.23 0.13d drivers/net/wireless/ Version 16 Tabelle 6.1: Kernel-abhängige Versionsnummer bei Wireless Extension

Der Orinoco Treiber soll den alten wvlan_cs Treiber vollständig ersetzen. Leider wird dieses von keiner Linux Distribution beachtet und die Linux PCMCIA Packages benutzen auch noch den veralteten Treiber. In der Datei /etc/pcmcia/config sollten folgende Einträge vorhanden sein. Der Eintrag für wvlan_cs ist Standard. Die Einstellungen für orinoco_cs müssen hinzugefügt werden:

46

device "wvlan_cs" class "network" module "wvlan_cs" device "orinoco_cs" class "network" module "orinoco_cs"

In meinem Fall war es erforderlich, (trotz PCI-WLAN-Karte), das Paket PCMCIA_CS in einer neueren Version zu installieren. In der Distribution vorhanden waren die Card Services PCMCIA_CS 3.1.33. Erforderlich war die Version 3.1.34, die ich mir wiederum von der Debian-Homepage als „PCMCIA-Package 3.1.34“ besorgte. Die Installation gelingt mit: # dpkg –i pcmcia_cs_3.1.34 Exkurs: Kernelkonfiguration

Zur Installation des WLAN-Geräts war es nötig, mir auf der Grundlage des Kernels 2.4.23 einen eigenen Kernel mit angepasster Konfiguration zu bauen. Im Internet finden sich eini-ge Quellen die die Konfiguration, das Übersetzen und Einbinden eines Kernels beschrei-ben.

Für das Erstellen eines eigenen neuen Kernels benötigte ich einige zusätzliche Software, die sich auf dem Testsystem relativ problemlos (aber zeitaufwendig, weil sehr langsam) nachinstallieren ließ:

# apt-get install gcc make bzip2 libncurses-dev

gcc: GNU C Compiler, wird für den Kernel-Bau benötigt make: Ebenfalls für Kernel-Bau bzip2: Dekomprimierungs-Tool libncurses-dev: Developement-Paket für das Text-Menü Frontend "curses"; benötigt für menuconfig, mit dem ich den Kernel konfiguriere.

Die folgenden Schritte habe ich in der Textkonfiguration "make menuconfig" ausgeführt:

Under Device Drivers -> Networking support -> Wireless LAN (non-hamradio)

[*] Wireless LAN drivers (non-hamradio) & Wireless Extensions

--- Wireless 802.11b ISA/PCI cards support

<M> Hermes chipset 802.11b support (Orinoco/Prism2/Symbol)

<M> Hermes in PLX9052 based PCI adaptor support (Netgear MA301 etc.) (EXPERIMENTAL)

<M> Hermes in TMD7160 based PCI adaptor support (EXPERIMENTAL)

<M> Prism 2.5 PCI 802.11b adaptor support (EXPERIMENTAL)

47

Kernelmodul laden Nachdem der Kernel mit den entsprechenden Treibern konfiguriert und erstellt wurde, sollten jetzt folgende Module vorhanden sein:

• hermes.o • orinoco.o • orinoco_pci.o

Root-Rechte vorausgesetzt, muss man zunächst das benötigte Kernel Modul laden. Das geschieht durch: # modprobe orinoco_pci. Nach Eingabe von lsmod kann man sich das vom Vorhandensein der richtigen Module überzeugen. Darüber hinaus kann mit dem Befehl dmesg kann kontrolliert werden, ob der Ladevorgang erfolgreich verlaufen ist. Der Treiber für die MA311 sollte beim Start geladen werden, weil die PCI-Karte ja schon beim Einschalten des Rechners eingesteckt sein muss. Sollte das nicht der Fall sein, kann man es problemlos per modconf nachladen: # modconf In der Auswahl dann "kernel/drivers/net/wireless" -> "orinoco_pci" anwählen. Danach wird das Modul in "/etc/modules" eingefügt und bei jedem Systemstart mitgeladen.

6.3 Einrichtung der Konfigurationssoftware Als Konfigurationssoftware verwendete ich die "Wireless-Tools". Unter Debian kann man diese üblicherweise leicht nachinstallieren:

# apt-get install wireless-tools Die auf dem Testsystem vorinstallierte Linux-Distribution Debian 3.0 Woody enthält standardmäßig jedoch eine zu alte Version der „Wireless-Tools“, nämlich 23.2. Erforderlich zur Inbetriebnahme der Karte sind jedoch unbedingt die „Wireless-Tools Version 26“. Dieses Paket besorgte ich mir von der Debian-Homepage und installierte es nachträglich. Diese Prozedur gestaltete sich recht umständlich und langwierig, da es eine Menge Abhängigkeitskonflikte in den Paketen der Debian-Distribution nach sich zog. Um letztendlich alle Abhängigkeiten aufzulösen, war die Installation folgender Bibliotheken notwendig:

1. libc6 (>= 2.3.2.ds1-4) 2. libiw27 (>=26+27pre10)

• libdb1-compat • libnss-db (=2.2.6.2) • libdb3 (>=3.2.9-17)

Die „Wireless-Tools Version 26“ sind nicht kompatibel mit den „Wireless Extensions“ älter als Version 9, was auch ein Grund für die Wahl des Kernels 2.4.23 war. Wie ich gemerkt habe ist es anzuraten, eventuell das Paket als "unstable" zu installieren,

48

weil sonst die "Wireless Extensions" zwischen Kernel und dem "Wireless-Tools" Paket unterschiedlich sein können, was zu Problemen führen kann:

# apt-get install wireless-tools/unstable

Sollten sich bei der folgenden Konfiguration der Karte Fehler zeigen, bei denen es um "Wireless Extensions" geht, wäre es das klügste, die "Wireless-Tools" aus den Quellen zu übersetzen. Dazu besorgt man sich hier die aktuellen Sourcen und kompiliert das Paket dann nach dem bekanntem Muster "./configure" und "make". Vor dem "make install" muss allerdings das Debian-Paket aber entfernt werden:

# apt-get remove wireless-tools # cd /usr/src # tar zxf wireless_tools.26.tar.gz # cd wireless_tools # make # make install

6.4 Konfiguration des Wireless LAN

6.4.1 Basiskonfiguration

Eine Wireless LAN Karte ist für den Linux Kernel das gleiche wie eine normale Netzwerkkarte und wird somit als Ethernet Device (z.B. eth0) im Kernel angemeldet. Mit Hilfe der Programme ifconfig und route kann die Wireless LAN Karte genauso konfiguriert werden wie jeder andere Netzwerkkarte unter Linux auch. Mit DHCP kann sogar die Adresse automatisch bezogen werden.

listig2# ifconfig -a eth0 Link encap:Ethernet HWaddr 11:22:33:44:55:66 inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:3 Base address:0x100

Bevor jedoch die Karte mit einer IP-Adresse versehen wird, sollte sie mit Hilfe der Wireless Extensions eingestellt werden. Hier kommt das Programm iwconfig zum Einsatz. iwconfig funktioniert genauso wie ifconfig und zeigt beim Aufruf ohne Parameter die aktuellen Einstellungen der Wireless Extensions an.

Die wichtigsten Einstellungen für ein Wireless LAN sind ESSID, Mode, Frequency (bzw. Channel) und Encryption key.

Die manuelle Basiskonfiguration sieht wie folgt aus:

49

modprobe orinoco_pci

iwconfig eth0 mode ad-hoc nick "" essid "heimautomat" channel 6

ifconfig eth0 192.168.0.1

ifconfig eth0 up

Der Befehl iwconfig funktioniert genauso wie ifconfig und zeigt beim Aufruf ohne Parameter die aktuellen Einstellungen der Wireless Extensions an:

eth0 IEEE 802.11-DS ESSID:"heimautomat"

Mode:Ad-Hoc Frequency:2.437GHz Cell: XX:XX:XX:XX:XX:XX

Bit Rate:11Mb/s Tx-Power=15 dBm Sensitivity:1/3

Retry min limit:8 RTS thr:off Fragment thr:off

Encryption key:off

Power Management:off

Link Quality:0 Signal level:0 Noise level:0

Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0

Tx excessive retries:0 Invalid misc:0 Missed beacon:0

Seltsam ist, dass die Link-Qualität mit “0” angezeigt wird. Nichts desto trotz funktioniert die Funkverbindung. Hier die Ausgabe von ifconfig:

eth1 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX

inet addr:192.168.0.1 Bcast:192.168.2.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:78 errors:0 dropped:0

overruns:0 frame:0

TX packets:123 errors:0 dropped:0

overruns:0 carrier:0

collisions:0 txqueuelen:100

RX bytes:5376 (5.2 KiB) TX bytes:19965 (19.4 KiB)

Interrupt:5 Base address:0xc000

Memory:dddff000-dddfffff

50

Soll der Treiber “orinoco_pci” der WLAN-Karte beim Starten jeweils automatisch geladen werden, was natürlich zu empfehlen ist, so muß er in die Datei /etc/modules eingetragen werden.

Wenn man einen (oder mehrere) Access Points ohne Verschlüsselung betreibt ist es unter Linux nur notwendig den Netzwerknamen (ESSID) zusetzen und den Modus auf Managed umzustellen. Der entsprechende Access Point wird automatisch gefunden und auch benutzt. Im Beispiel wäre der Netzwerkname "HEIMAUTOMAT".

listig2# iwconfig eth0 essid HEIMAUTOMAT listig2# iwconfig eth0 mode managed

Das Setzen der Frequency (bzw. Channel) ist unter Linux im Managed Modus nicht erlaubt. Hier wird standardmäßig der Kanal 3 benutzt, was einer Frequenz von 2.422GHz entspricht.

6.4.2 Automatische Netzkonfiguration während des Systemstarts

Alternativ lässt sich die Konfiguration des WLAN Adapters auch über die Datei /etc/network/interfaces vornehmen. Alle Parameter werden dort in der Form "wireless_<function> <value>" gespeichert. Hier die Datei im Editor ("nano") mit allen Optionen für ein Ad-Hoc Netzwerk ohne Access Point und auskommentierter Ver-schlüsselung:

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8) # The loopback interface # automatically added when upgrading auto lo eth0 iface lo inet loopback iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 # network 192.168.0.0 # broadcast 192.168.10.255 # gateway 192.168.10.1 wireless_channel 6 wireless_mode Ad-hoc wireless_essid "HEIMAUTOMAT" # wireless_enc ca4e-ff42-43ae-92c2-76fe-75ef-1e restricted

Zum Schluss muss man natürlich das Netzwerk neu starten um die Änderungen zu übernehmen:

# /etc/init.d/networking restart

6.4.3 Verschlüsselung

Ein Wireless LAN sollte immer mit einer WEP128 Verschlüsselung betrieben werden und somit ist es natürlich notwendig dem Treiber den Schlüssel mitzuteilen. Standardmäßig

51

können die Wireless LAN Karten vier verschiedene Schlüssel gleichzeitig speichern, wovon eine aber nur aktive sein kann. Karten mit WEP64 und WEP128 Verschlüsselung unterstützen sowohl 40-Bit (5 Zeichen) wie auch 104-Bit (13 Zeichen) lange Schlüssel. Man kann die Schlüssel als Hex-Wert oder auch als Zeichenkette angeben. Bei der Angabe als Zeichenkette ist ein "s:" voranzustellen. Ob es sich um einen WEP64 oder WEP128 Schlüssel handelt unterscheidet das Programm iwconfig automatisch an der Länge der Eingabe. Die Position im Kartenspeicher wird ein eckigen Klammern hinter dem Schlüssel angegeben. Nur die Positionsangabe aktiviert den Schlüssel.

listig2# iwconfig eth0 key s:abcde [1] listig2# iwconfig eth0 key s:abcdefghijklm [2] listig2# iwconfig eth0 key 6162636465666768696A6B6C6D [3] listig2# iwconfig eth0 key [3]

Natürlich kann man sich auch die aktuell gespeicherten Schlüssel anzeigen lassen. Hierfür muss man das Programm iwlist benutzen. Der aktuell benutzte Schlüssel erscheint auch in der Auflistung von iwconfig.

listig2# iwlist eth0 keys eth0 2 key sizes : 40, 104bits 4 keys available : [1]: 6162-6364-65 (40 bits) [2]: 6162-6364-6566-6768-696A-6B6C-6D (104 bits) [3]: 6162-6364-6566-6768-696A-6B6C-6D (104 bits) [4]: off Current Transmit Key: [3]

Nun kann das Interface mit ifconfig und route konfiguriert werden und man kann die Arbeit im Netzwerk beginnen.

listig2# ifconfig eth0 192.168.0.100 netmask 255.255.255.0 listig2# route add default gw 192.168.0.1

6.4.4 Automatische Konfiguration durch die PCMCIA Card Services

Es ist sehr umständlich bei jedem einstecken der Karte die Wireless Extensions zu konfigurieren und dann die Netzwerk Einstellungen zu vergeben. Mit Hilfe der Card Services kann dieses aber automatisch bei jedem Einstecken der Karte erledigt und beim Entfernen der Karte wieder rückgängig gemacht werden. Als erstes wollen wir die Einstellungen für die Wireless Extensions eintragen. Dies geschieht in der Datei /etc/pcmcia/wireless.opts. Wichtig sind hier der Netzwerkname, der Modus und der WEP Schlüssel.

case "$ADDRESS" in *,*,*,*) INFO="Wireless LAN Setup"

52

ESSID="HEIMAUTOMAT" MODE="Ad-hoc" KEY="s:abcdefghijklm [1]" ;; esac

Jetzt muss noch das Netzwerk konfiguriert werden. Hierfür werden die entsprechenden Einträge in der Datei /etc/pcmcia/network.opts vorgenommen.

case "$ADDRESS" in *,*,*,*) INFO="Network Setup" IPADDR="192.168.0.1" NETMASK="255.255.255.0" BROADCAST="192.168.0.255" GATEWAY="192.168.0.0" ;; esac

Für die Card Services ist leider nicht zu erkennen ob es sich um eine Netzwerkkarte oder eine Wireless LAN Karte handelt und die Befehle für Wireless Extensions werden immer mit ausgeführt. Dies führt natürlich zu Fehlermeldungen, wenn eine normale Netzwerkkarte eingelegt wird. Um diese zu vermeiden sollten die Einstellungen in /etc/pcmcia/wireless.opts nur beachtet werden, wenn es eine Wireless LAN Karte ist. Alle Karten, die den ORiNOCO Treiber benutzen haben eine MAC Adresse aus zwei Bereichen. Zum ersten 00:60:1D:* und zum zweiten 00:02:2D:*. Manche Karten können sowohl zum ersten als auch zum zweiten Bereich gehören. Man muss also immer beide angeben.

case "$ADDRESS" in # Lucent Wavelan IEEE (+ Orinoco, RoamAbout and ELSA) *,*,*,00:60:1D:*|*,*,*,00:02:2D:*) INFO="Wireless LAN Setup" ESSID="HEIMAUTOMAT" MODE="Ad-hoc" KEY="s:abcdefghijklm [1]" ;; esac

6.4.5 Testen der Verbindung Für den einfachen Verbindungstest reichte zunächst einmal der ICMP-Befehl Ping. Das LISTIG-Basisgerät mit der gesteckten (äußerer PCI-Slot) WLAN-Karte Netgear MA311 PCI wurde mit dem Kernel 2.4.23 gebootet und der Treiber orinoco_pci geladen. Sobald der Treiber geladen ist, zeigt die Karte durch eine permanent leuchtende grüne LED ihren ordnungsgemäßen Betriebszustand an. Insoweit Wireless-Konfigurations-einstellungen durch Startskripte automatisch zugewiesen werden, wie im Kapitel 6.4.4

53

beschrieben, braucht nichts weiter eingerichtet werden. Alternativ lädt man den Treiber manuell per # modprobe orinoco_pci Blinkt die LED jedoch gleichmäßig und stetig, dann wurde der Treiber nicht richtig eingebunden oder fehlerhaft konfiguriert. Auch in diesem Fall kann man versuchen ihn mit modprobe oder insmod manuell zu laden, bzw. manuell neu zu konfigurieren. Eine kurze Überprüfung mit dem Befehl lsmod gibt Aufschluß darüber, ob alle zum Treiber gehörigen Module richtig eingebunden wurden. Es gibt drei Module, die zur Boot-Zeit geladen werden müssen, damit die WLAN-Karte erfolgreich initialisiert und konfiguriert ist:

• hermes.o • orinoco.o • orinoco_pci.o

Wenn das richtige Kernel-PCMCIA-Modul eingebunden, oder die externen PCMCIA-Card Services entsprechend installiert wurden, werden die Module automatisch geladen. Als Gegenstelle dient ein Notebook, auf dem unter Windows XP eine PCMCIA-WLAN-Karte (Netgear MA521) installiert ist. LISTIG-Basisgerät Netgear MA311 PCI Card IP-Adresse: 192.168.0.1 Subnetzmaske: 255.255.255.0 Debian Linux Kernel 2.4.23

Abbildung 6.1: IP über Wireless LAN 802.11b Ad-Hoc-Modus

Der Client, in meinem Fall das Notebook mit Windows XP, wird mit eingesteckter PMCIA-WLAN-Karte gestartet. Daraufhin erscheint unter den Netzwerkverbindungen eine „Drahtlose Netzwerkverbindung“, die mit IP-Adresse und Subnetzmaske konfiguriert werden muss:

Client-Notebook Netgear MA521 PCMCIA Card IP-Adresse: 192.168.0.2 Subnetzmaske:255.255.255.0 MS Windows XP

54

Das kann erfolgen, indem man im Kontextmenü die Eigenschaften der Drahtlosen Netzwerkverbindung aufruft und sich die Eigenschaften vom

Internetprotokoll (TCP/IP) anzeigen läßt. Die Netgear MA521-Windows-Treiber-Software liefert ein graphisches Konfigurationstool mit, auf welches man rechts unten über Systemtray zugreifen kann. Darüber erledigt man weitere Einstellungen. Hierbei bietet sich an, das Windows-Interne Tool abzuschalten, damit es nicht zu Konflikten kommt. Man erledigt das über die Registerkarte „Drahtlose Netzwerke“ in den Eigenschaften der Drahtlosen Netzwerkverbindung:

Hier entfernt man einfach das Häkchen bei: „Windows zum Konfigurieren der Einstellungen verwenden“

Man ist auf das Windows-eigene Tool nur dann angewie-sen , wenn vom Hersteller der WLAN-Hardware kein adäquates Werkzeug mitgelie-fert wird.

Abbildung 6.2: Netzwerkverbindungen

Abbildung 6.3: IP-Einstellungen

55

Abbildung 6.4: Windows die Konfiguration abnehmen

Das Konfigurationswerkzeug von Netgear lässt sich intuitiv bedienen. Man kann hier Profile erstellen, in denen man wichtige Merkmale wie Netzwerk-SSID, Netzwerkmodus, Kanal, Verschlüsselung, Übertragungsrate, Fragmentierungsschwelle und einiges mehr abspeichern kann:

Abbildung 6.5: Netgears Konfigurationswerkzeug

Nachdem ich den Netzwerkmodus „Ad-Hoc“ eingestellt, als SSID „heimautomat“ eingetragen und den Kanal 10 ausgewählt habe, kann ich die Einstellungen beispielsweise unter dem Profil „ListigSetup“ abspeichern. Wenn ich jetzt auf die Register-karte „Standortüberprüfung“ wechsle, sehe ich, dass der Scanvorgang bereits im Gange ist und die in der Umgebung vorhandenen Netze ausfindig gemacht werden. Sobald ich das Netz „heimautomat“ aufgelistet sehe, markiere ich es mit der linken Maustaste und klicke den Button „Verbinden“

Abbildung 6.6: Profileinstellungen der drahtlosen Verbindung

56

Jetzt, da ich mit der Basisstation über Funk verbunden bin, bekomme ich auf der Register-karte „Status“ Informationen zur Signalstärke und Verbindungsqualität angezeigt. Außerdem sehe ich, wie viel Daten übertragen und empfangen werden.

Abbildung 6.7: Erfolgreiche Verbindung

Das Notebook in der Rolle des Client kann jetzt versuchen das Basisgerät von LISTIG mit einem Ping zu erreichen. Ping sendet ein ICMP-Echo-Request-Paket an die Zieladresse des zu überprüfenden Hosts. Der Empfänger muss, insofern er das Protokoll unterstützt, laut Protokollspezifikation eine Antwort zurücksenden: ICMP Echo-Reply. Ist der Zielrechner nicht erreichbar, antwortet der Router: Network unreachable (Netzwerk nicht erreichbar) oder Host unreachable (Gegenstelle nicht erreichbar). Das Ping Programm wird oft zur Fehlerbehebung von Netzwerken verwendet, da sich damit gut feststellen lässt ob eine physikalische Netzwerkverbindung fehlerfrei funktioniert. Es werden Datenpakete an den Rechner 192.168.2.1 gesandt. Vom Programm wird die Zeit gemessen, bis die Antwort des Hosts eintrifft. Die Zeitangabe sagt aus, wie lange es dauert, bis ein Datenpaket zum Host und wieder zurück braucht. Man kann daran grob erkennen, ob die Gegenstelle funktioniert und mit welcher Verzögerung bei einer Verbindung zu rechnen ist: C:\ping 192.168.0.1

Abbildung 6.8: Notebook pingt Basisgerät

Der Ping vom Basisgerät zum Notebook funktioniert auf die gleiche Weise:

57

# ping 192.168.0.2 # Ping 192.168.0.2 PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=127 time=5.03 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=127 time=1.70 ms

Nachfolgend wird beschrieben, wie ich die Verbindung zwischen Notebook und Basisgerät mit einer kleinen Testapplikation prüfe. Für eine bequemere Prozedur kann den IP-Adressen von LISTIG und Notebook in der Datei /etc/hosts 127.0.0.1 localhost 192.168.0.1 listig 192.168.0.2 notebook ein passender Name zugewiesen werden, der dann zu Adressierungszwecken genutzt werden kann. Voraussetzung für das Funktionieren der Software ist ein erforderliches Debian-Paket (libstdc++2.10_2.95.2-14_i386.deb), welches von www.debian.org bezogen werden kann. Die Installation glückte mit: # dpkg -i libstdc++2.10_2.95.2-14_i386.deb Zu beachten ist, dass die Datei libstdc++[1].so.5 in das Verzeichnis /usr/lib/ kopiert und umbenannt werden muss in libstdc++.so.5 Die Testsoftware besteht aus zwei Teilen, einer Serveranwendung in C-Code und einer Client-Anwendung in Java-Code. Gestartet wird die Applikation auf dem Basisgerät aus dem Home-Verzeichnis (/home/roman) mit: # ./listig listig2 3353 nach dem Schema: # ./<program name> <host name> <port> (Die Portnummer ist frei wählbar) Danach lauscht das Programm auf eine Aktion vom Client: listig2:~# cd /home/roman listig2: /home/roman# ./listig listig2 3353 Server: opening socket on port = 0, datagrams on port = 3353 request from notebook Your request: Licht aus 10 bytes received request from notebook Your request: Licht aus 10 bytes received request from notebook Your request: Temperatur=20 14 bytes received request from notebook Your request: Temperatur=20 14 bytes received

58

Damit das Client-Modul der Testapplikation auf dem Windows XP- Notebook läuft, muss das Java 2 Runtime Environment (http://java.sun.com/j2se/1.4.2/download.html) auf diesem Rechner installiert sein. Der Aufruf des Client-Programmes geschieht durch Doppelklick auf die Datei listig.jar. In dem sich öffnendem Fenster können Konfigurationseinstellungen vorgenommen werden:

Abbildung 6.9: Konfigurationsfenster der Client-Anwendung

Das oberste Feld der Eingabemaske ist selbsterklärend. Unter „Port“ kann ein beliebiger freier Port eingetragen werden. Ebenso kann über das Feld „Send a message“ eine beliebige Nachricht (z.B. Steuerinformationen) an den LISTIG-Host geschickt werden. Diese erscheint dann bei erfolgreicher Hin- und Rückübermittlung wieder im Feld „Receive a message“ mit voran gestelltem „You have sent:“ Ein Beispiel könnte folgendermaßen aussehen:

59

Abbildung 6.10: Übertragung einer Zeichenkette

Auf dem Monitor der Basisstation lässt sich mitverfolgen, dass die Ausgabe zwei mal erfolgt. Das hängt mit dem Quittierungsverfahren zusammen, da die Daten zuerst vom Server empfangen und dann wieder zurück an den Client verschickt werden.

6.5 Probleme während der Testphase

6.5.1 Der PCI-to-PCMCIA/PCCARD-Adapter unter Linux Am Anfang standen mir als Test-Hardware nur PCMCIA-WLAN-Karten zur Verfügung, was den Einsatz eines PCI-to-PCMCIA-Adapters erforderte. Hierbei kommt es nicht nur darauf an, dass die WirelessLAN-Karte vom Betriebssystem unterstützt wird, sondern es müssen auch Treiber zur Unterstützung der PCI-Host-Bridge vorhanden sein. Bei der Bridge handelt es sich um den Typ: Level One RNC-0100 PCI-Version: v2.2 Frequenzbereich: 2,4 GHz unterstützt: PCMCIA Typ I, II oder III, PC-Card Slot: kompatibel zu PCI 2.2, Card Bus und PC-Card 2.0 Standard Datenrate: maximal 11 Mbps Der Chipsatz ließ sich als Ricoh R5C476II identifizieren. Ob er prinzipiell unter Linux arbeiten soll, darüber ließ sich keine eindeutige Antwort finden. Hier traf ich in Foren auf widersprüchliche Meinungen.

60

Nach gründlichen Recherchen habe ich die Informationen über die Komponenten zusammengetragen, die zur Installation benötigt werden: Was wird benötigt?

1. Zunächst das PCMCIA Package, welches unter http://pcmcia-cs.sourceforge.net/ zu finden ist. Versionen: pcmcia-cs-3.3.8 oder pcmcia-cs-3.0.14

2. Des weiteren muss der Linux-Kernel mit folgenden Optionen kompiliert werden: CONFIG_HOTPLUG (Support for hot-pluggable devices) = YES CONFIG_PCMCIA (PCMCIA/CardBus support) = Module CONFIG_CARDBUS (CardBus support) = YES Zu guter Letzt brauchen wir noch die Wireless-Tools, welche unter http://www.fasta.fh-dortmund.de/users/andy/wvlan/ zu finden sind.

3. Nachdem der Kernel mit den oben genannten Parametern kompiliert ist, muss das PCMCIA Package installiert werden. Hier sind keine besonderen Tips notwendig, einfach "make config", "make all", "make install".

Nun die Konfiguration des PCMCIA Packages: Im File "/etc/pcmcia/config.opts" ist nun folgender Eintrag vor zunehmen:

module "wvlan_cs" opts "channel=1"

Außerdem muss das File /etc/pcmcia/network.opts bzw. /etc/pcmcia/wireless.opts angepasst werden, wie in Kapitel 5.2.1 beschrieben. Nun sollte sich das PCMCIA-Service starten lassen. Auf dem LISTIG-System musste ich das Modul "yenta_socket" manuell laden, bevor ich das PCMCIA-Service starten konnte.

Doch der Erfolg, die WLAN-Karten in diesem Adapter zum Leben zu erwecken, blieb trotzdem aus. Ich probierte es erfolglos mit:

• Nokia D211 • Linksys WPC11b • Cabletron Systems Roam About 802.11DS High Rate

und später mit • ARTEM ComCArd CC-W54g-STD-ETS-128

Linux unterstützt solche Adapter normalerweise mit den beiden Modulen:

• i82365, • yenta_socket

Das Pcmcia_cs package verwendet aber nur das Modul i82365; das yenta_socket-Modul ist darin nicht vorhanden.

61

Im Kernel ist wiederum das Modul yenta_socket wichtiger , weil ab der Kernel-Version 2.4.18 durch das Modul i82365 keine PCI-Adapter mehr unterstützt werden.

Für 486DX –PC’s ist eigentlich i82365 das richtige Modul. Doch in den neueren Kernel-versionen, (>=1.4.18), die wir auf LISTIG brauchen, unterstützt eben dieses Modul keine PCI-Adapter mehr.

Von Händlern habe ich Aussagen gelesen, dass kaum ein Hersteller die PCI-to-PCMCIA-Adapter bisher so richtig im Griff hat.

David Hinds, der Entwickler des PCMCIA Linux-Codes äußert sich dazu sinngemäß, dass die Tatsache, dass der Kernel nicht immer in der Lage ist, die Interrupt-Vergabe für ein PCI-Gerät zu bestimmen, den Grenzen des Linux PCI-Subsystems zuzuschreiben ist. Es scheint außerdem Motherboard-spezifisch zu sein, weil es von der Information abhängt, die das BIOS liefert.

Genau hier liegt auch die Ursache für das im Kapitel 4.2.2 angesprochene Problem mit dem nicht funktionierendem inneren PCI-Slot des LISTIG-Mainboards. Es ist dringend ein BIOS-Update notwendig.

Zitat David Hinds:

"This problem, where the kernel is unable to determine the interrupt routing for a PCI device, is a limitation of the linux PCI subsystem. It tends to be motherboard specific because it depends on what information the BIOS provides. I think the problem most often crops up, these days, with boards that are designed for ACPI. They provide PCI interrupt information in ACPI tables, but do not provide a complete or correct PCI Interrupt Routing Table, which is the only way the kernel currently knows how to fish out this information."

Quelle: http://www.serc-rmit.edu.au/~paul/wireless.html

So kann man im Prinzip nur die PCI-Bridge austauschen (oder das Motherboard)

Weitere Mainboards mit den gleichen Problemen sind z.B.:

• Mainboard MSI K7T266 Pro (MS-6380) • Mainboard MSI K7T266 Pro2 • Mainboard MSI KT3-Ultra ARU (6380E)

Besonders Mainboards von MSI scheinen Probleme mit dem Linux-PCI-Subsytem zu haben.

6.5.2 Die Nokia D211 Card unter Linux Die Nokia DataCard D211 vereint Datenübertragung per WLAN, GPRS und HSCSD in einer PC-Card.

Sie verfügt über eine interne Antenne Abbildung 6.11:

und soll mit einer breiten Palette Nokia Multimode Card tragbarer Geräte kompatibel sein, die über

62

einen Steckplatz für PC-Karten vom Typ II

oder III mit ausreichender Stromversorgung

verfügen.

Keine Probleme unter Windows Für Windows- Betriebssysteme wurde der Treiber D211NIC.sys V1.00 025 auf der beiliegenden CD mitgeliefert. Die Installation unter Windows verlief komplikationslos. Die Verbindung zur Datenübertragung sowie die Konfiguration werden bedienungsfreundlich von der grafischen Benutzeroberfläche aus gesteuert. Das Nokia D211 erreicht Übertragungsgeschwindigkeiten von bis zu 11 Mbit/s mit Wireless LAN. Zudem verfügt das Nokia D211 über eine zum IEEE802.11bWiFi Standard kompatible Schnittstelle für Mobilfunknetze.

Linuxtreiber Für Linux befanden sich ebenfalls Treiber auf der CD, die jedoch 1. veraltet und 2. speziell für eine SuSe-Distribution gedacht waren. Von der Nokia-Internetseite habe ich mir aktualisierte Treiber heruntergeladen. Nach der ebenfalls von Nokias Webseite bezogenen englischen Installationsanleitung (PDF-Dokument) gestaltete sich auch die Installation unter Linux zunächst unproblema-tisch. Nicht gerade ideal ist jedoch, dass der Treiber (übrigens für die Kernelversion 2.4.22) zur Hälfte aus einem binären Modul besteht, welches das Kernel-Modulmanagement übernimmt. Hier kommt ein proprietäres Verfahren zum Einsatz, welches zur Konfiguration der WLAN-Schnittstelle die standardmäßig bewährten Wireless-Tools umgeht. Installationsanleitung nachvollziehbar Im einzelnen mussten folgende Schritte durchgeführt werden:

• Entpacken der Treibermodule • Kopieren in die richtigen Verzeichnisse • Konfiguration des Treibers • Kompilieren des Treibers • Installieren der Treibermodule und Userspace-Utilities • Konfiguration der WLAN-Verbindung

Adapter-Problem Jedoch aufgrund der im vorigen Kapitel geschilderten Probleme mit der PCI-Bridge, verlief die Installation ergebnislos. Erschwerend macht sich das Fehlen einer Betriebs-LED bemerkbar, die wenigstens Auskunft über eine physische Verbindung hätte geben können. Teilerfolg Erst nach deren Einsatz in der zweiten PCI-Host-Bridge, einem Dual Slot PCI-to-PC Card Controller (PCI1221PDV) mit dem Chipsatz ti PC1221, einer sogenannten „Swap-Box“, die in einem 3 ½ “-Schacht eingebaut ist, konnte ich mit meinem Notebook als Gegenstelle

63

ein Signal von der Nokia-Karte empfangen. Die physikalische Funktion ließ sich also realisieren. Neue Probleme Das Problem war jetzt, dass der Treiber keine Anweisungen und Steuerbefehle verarbeitete und damit die WLAN-Verbindung nicht konfigurierbar war. Versucht man das Benutzer-Interface-Programm NOKIA_CTL aufzurufen, erscheint eine nichtssagende Fehlermeldung. Als Lösung für das Projekt LISTIG stellt die Karte meiner Meinung nach nicht die erste Wahl dar, da zu proprietär im Ansatz. Außerdem kommt die Karte definitiv nicht mit der Funktion SSID-Hide zum Geheimhalten der Netzwerk-Kennung klar und hat nach den Erfahrungen zahlreicher Linux-User Probleme mit WEP. Lösung? Die Lösung der Probleme könnte eine neue Firmware sein Da ich nur schwer beurteilen kann, ob die Probleme mit der Karte rein softwaremäßig sind, oder wiederum mit dem Einschub-Adapter zusammenhängen, entschloss ich mich danach, auf eine reine PCI-WLAN-Karte umzusteigen.

6.5.3 Die ARTEM ComCard (IEEE 802.11g) Diese WirelessLan-Karte nach dem neueren 802.11g –Standard versuchte ich anfangs auf dem LISTIG-Basisgerät unter Debian-Linux zum Laufen zu bringen. Wie sich später her-ausstellte, war das ein aussichtsloses Unterfangen. Zu diesem Zeitpunkt war die Unter-stützung von Karten dieser neueren Generation mit Open Source –Treibern einfach zu lückenhaft , fehleranfällig und oft gänzlich unmöglich. Bis heute hat sich nicht viel ver-bessert. Im Gegenteil die Unterstützung ist sogar in vielen Fällen aus verschiedenen Grün-den schwieriger geworden. Die Artem ComCard CC-W54g-STD-ETS-128 unterstützt Datenraten bis zu 54 Mb/s, verfügt über automatische Datenratenanpassung, und ist abwärts kompatibel zum Standard 802.11b. Zweifelhafte Linux-Unterstützung Im Datenblatt des Herstellers befindet sich ein eindeutiger Hinweis, dass das Betriebs-system Linux nicht unterstützt wird. Im Widerspruch dazu findet man auf der Internetseite des Herstellers aber einen Treiber für seine 802.11g-Karten unter Linux. Es handelt sich leider um Treiber für eine alte SuSe-Distribution: Suse8.2. Der Treiber ist eingebettet in eine Archiv-Datei: SuSe8.2-pcmcia-3.2.3-1.tar.gz und beziehbar über den Link: http://www.artem.de/content/artem/artem000221/SuSe8.2-pcmcia-3.2.3-1.tar.gz Der Treiber soll lediglich unter den Distributionen SuSe 8.2 und RedHat 9.0 funktionieren. Nach Erfahrungsberichten aus Internetforen funktioniert er mit SuSe 9.0 schon nicht mehr. Meiner Meinung nach handelt es sich um veraltete PRISM54-Treiber des Open-Source-Projekts „Prism54“ (www.prism54.org)

64

Alternativ kann man sich nämlich hier mit dem aktuellen PRISM54-Treiber versorgen, der folgende Chipsätze

• Prism Indigo • Prism Fribee • Prism GT • Prism Duette

unterstützt, welche auf IEEE802.11g-Wireless-Karten verbaut werden. Anfang 2004 war auf dieser Webseite übrigens noch die ARTEM-Karte gelistet, mit großen Fragezeichen, weil noch keine Erfolgsmeldung bekannt war. Ab März 2004 ist die Karte ganz aus dieser Liste verschwunden, was auch damit zusammenhängen kann, dass der Hersteller vielleicht den Chipsatz ganz gewechselt hat und für den unter Linux gar keine Unterstützung zu erwarten ist. Hintergrund Die Treiber stammen meist von einer unabhängigen Entwicklergruppe. Deshalb haben sie noch die eine oder andere Eigenheit, schon die Installation gelingt oft nur unter Schwierigkeiten. Auch hinsichtlich der Konfiguration halten sich die Entwickler nicht immer an Standards, wie etwa die Wireless Extensions bei Linux, obwohl diese die Implementierung einer eigenen Konfigurationsschnittstelle ersparen und dem Anwender den Umgang mit unterschiedlichen Produkten erleichtern. Ohne ein gutes Stück Handarbeit - Erstellen und Einbinden von Konfigurationsskripten geht die Inbetriebnahme der neuen WLAN-Karten derzeit noch nicht vonstatten. Bei fast allen Treibern ist zumindest ein Teil des Codes nicht als Quelltext erhältlich. Da werden Binary-Only-Module in den Kernel geladen und verwehren dem Entwickler jegliche Einflussnahme sowie Details über den Hardwarezugriff und die integrierten Funktionen. Hier stoßen zwei Welten aufeinander: Firmen, die ihrer Konkurrenz keine Details über die Funktionsweise liefern wollen und die Open-Source-Bewegung, für die gerade die Offenlegung der Interna erwünscht, wenn nicht gar erforderlich ist. Oft scheitert das Finden des richtigen Treibers für die eigene WLAN-Karte aber schon daran, dass kaum ein Hersteller den verwendeten Chipsatz angibt. Viele Anbieter wechseln ihn zudem zwischen Produktversionen, ohne gleichzeitig die Typennummer der Karte zu ändern. Eine recht gut gepflegte Liste enthält das WLAN-Wiki der Universität Konstanz.(http://wiki.uni-konstanz.de/wiki/bin/view/Wireless/WirelessLAN). Hilft diese Liste nicht weiter, kann man oft anhand der Vendor- und Device-IDs den vorhandenen Chipsatz herausfinden. Unter Linux zeigt normalerweise ein lspci -n diese IDs an. Alternativ wirft cardctl ident Informationen zur Karte aus. Prism54-Treiber Bei den ursprünglich von Intersil entwickelten Prism-Chipsätzen, laufen viele Funktionen als Software auf dem integrierten Mikrocontroller. Anders als noch bei den Vorgängern wird die dafür nötige Firmware nun jedes Mal beim Starten des Treibers in die Karte geladen. Grundsätzlich kann man den Treiber als freie Software betrachten, da alle auf dem Host laufenden Programmteile unter der GPL im Quelltext vorliegen. Problematisch ist allerdings die Bereitstellung des Firmware-Images, dafür sind die Anwender nach wie vor auf den Hersteller angewiesen. Umständliche Installation

65

Die Installation des Prism54Treibers gestaltet sich sehr umständlich und erfordert das Lesen zahlloser Readme-Dateien. Er basiert auf einer von Intersil für Access Points entwickelten Software, die für die normale Anwendung nicht gerade freundlich scheint. Bei meinen Versuchen habe ich mich genau und sorgfältig an die mitgelieferte Installationsanleitung unter Documentation/index.html gehalten. Beispielsweise war es notwendig, den Kernel ohne aktivierten PCMCIA/CardBus-Support und mit einem mitgelieferten Kernelpatch neu zu erstellen. Erst danach kann der eigentliche Treiber kompiliert werden. Wenn bis hierhin alles geklappt hat, wird nach Konfiguration der Card Utils und Starten des Treibers die WLAN-Konfiguration über die mitgelieferten Programme setoid und getoid fällig. Diese sollen mit ihrem Handling und der Verwendung von SNMP-OID (Simple Network Management Protocol Object IDentifier) angeblich den Ursprung aus einem Access-Point-Treiber offenbaren. Details muss man sich obendrein aus der Quelldatei bloboid.h zusammensuchen. Es wird in der Anleitung zu einem 2.6’er Kernel geraten. Ohnehin sind alle notwendigen Patches oder zusätzlich zu installierenden Pakete unstable oder testing. Alle Treiber waren Snapshots (CVS) und wurden ca. jede halbe Stunde aktualisiert. Weitere Pakete, die in der Vorbereitung installiert werde mussten, waren: Hotplug, Hotplug-Utils, Pcmcia-cs und Wireless-Tools in den neuesten Versionen, was eine Menge Abhängigkeitskonflikte mit installierten Paketen und Bibliotheken einbrachte, die es aufzulösen galt. Zusätzlich musste Firmware aus dem Internet geladen und ein Firmware-Agent gescriptet werden. Alle Einzelheiten zu schildern würde den Rahmen dieser Arbeit sprengen. Versuch fehlgeschlagen Die Installation des Hotplug-Systems ist aus unbekanntem Grund fehlgeschlagen. Doch der Hauptgrund zum Abbrechen des Versuchs war, dass nach den zahlreichen erforderlichen Installationen der Befehl make menuconfig nicht mehr funktionierte, der jedoch zum Konfigurieren des gepatchten Kernels unbedingt gebraucht wurde. Hinweise deuteten auf eine kaputte glibc-Bibliothek. Dieses Problem ließ sich aber nicht in einer akzeptablen Zeitspanne lösen. Auch problematisch war, dass sich nach der Installation des Linux-Kernel 2.6.4 und der Hotplug-Umgebung, das System so langsam wurde, dass sich Tastatureingaben merklich verzögert auswirkten und sich die Bootzeit auf etwa 10 – 15 Minuten erhöhte. Fazit Wer aktuelle WLAN-Karten unter Linux zum Laufen bringen möchte, muss derzeit noch auf wenig zufriedenstellende und fehlerhafte Treiber zurückgreifen, die oft auch noch Binary-Only-Module mitbringen. Die Unterstützung der einheitlichen Konfigurationsschnittstelle Wireless Extensions unter Linux bleibt abzuwarten. Unter diesen Gesichtspunkten schien es nicht sinnvoll, weiter mit der ARTEM-Karte oder anderen Prism54-Karten zu experimentieren, da auch das LISTIG-System damit offensichtlich überfordert wäre. Es war richtig, sich danach für eine PCI-WLAN-Karte nach IEEE802.11b zu entscheiden. Auf der Webseite www.prism.org ist von dem Problem zu lesen, dass immer mehr Hersteller die neuen SoftMAC Chipsätze einkaufen, die noch nicht von Linux unterstützt

66

oder vielleicht nie unterstützt werden. Sie sollen die bisherigen FullMAC Chipsätze ersetzen, ohne dass die Hersteller wichtige Identifizierungsnummern ändern. Wenn man nicht die Möglichkeit hat die Karte vor dem Kauf unter Linux zu testen, kann man heutzutage nur empfehlen, auf Karten mit 802.11g basiertem Chipsatz zu verzichten. Auf http://prism54.org/supported_cards.php sieht man, dass momentan nur sehr wenige der Prism54-basierten Karten von Linux-Treibern profitieren. Konkret sind das:

• Netgear WG511 • 3com OfficeConnect 11g Wireless LAN PC Card • SMC2802W - EZ Connect g 2.4GHz 54 Mbps Wireless PCI Card • D-Link Air Plus Xtreme G A1

Die Erfolgsquote bei Installation dieser Karten liegt um die 90 %, doch im Betrieb treten teilweise hohe Fehler-Raten von durchschnittlich um die 40% auf.

7 Bewertung der Verbindungsqualität

7.1 Grundlegendes

Die Reichweite hängt stark von den Räumlichkeiten, den Antennen und der Sendeleistung ab. Grundsätzlich breiten sich im verwendeten Frequenzbereich von 2.4 GHz die Funkwellen quasioptisch aus, d.h. im wesentlichen so, wie man es von "normalem" Licht her kennt. Ideal ist daher eine direkte Sichtverbindung zwischen LISTIG-Basisgerät und PC-Karte im Notebook/PDA. In geschlossenen Räumen basiert der Empfang auch stark auf Reflexion der Funkwellen an Wänden oder anderen dichten, ebenen Flächen. Dabei kann es vorkommen, dass ein Signal beim Empfänger aus mehreren Richtungen gleichzeitig oder fast gleichzeitig ankommt und sich so überlagert. Im folgenden einige grobe Reichweitenangaben (bezogen auf 802.11b), abhängig von den verwendeten Antennen:

Normale Antennen (die integrierte Antenne der PCMCIA-Karte) • auf der grünen Wiese ca. 300m • in offenen Räumen oder verglasten Gebäuden ca. 100m • in Büros mit dünnen Wänden (kein Beton) ca. 40m • problematisch ist u.U. metallbedampftes Energiesparglas - je nach

Ausführung ist dahinter mit stark vermindertem bis gar keinem Empfang zu rechnen

• in Räumen mit Stahlbetonwänden ist an der Wand Schluss - oft geht allerdings noch etwas durch die Fenster raus

• Beton ist nicht gleich Beton. Filigranbeton - aus dem in Neubauten oft Geschossdecken sind - lässt Funkwellen - wenn auch stark gedämpft - durch.

67

Typische Dämpfungswerte sind folgende:

• offenes Gelände: 5 dB • geschlossene Räume: >30 dB

• jede Wand, Decke: 4 – 6 dB • Beton: 6 – 8 dB • Glas: 3 dB • Metall: sehr große Dämpfung • atmosphärische

Änderungen (Luft- feuchte, Regen, Schnee): 10 dB

7.2 Messungen Die Leistungsfähigkeit einer Netzwerkverbindung lässt sich am besten anhand der Übertragung von großen Dateien überprüfen. Folglich gilt es den Netzwerkdurchsatz zu messen. Im Internet findet dazu Tools, wie z.B. NetIO, welches auch ich für meine Messungen verwendete. Das Tool wird über Kommandozeilen in einer DOS-Box bedient. Es ist so konzipiert, dass es mindestens auf zwei Rechnern im Netzwerk eingerichtet werden muss. Auf dem LISTIG-Basisgerät wird die Datei netio116 im so genannten Servermodus gestartet und auf dem Notebook im Client-Modus. Für den eigentlichen Test schickt dann der NetIO-Client unterschiedlich große Datenpakete an den NETIO-Server. Der wiederum sendet die Daten zurück und damit wird der Datendurchsatz gemessen. Auf dem LISTIG-System wechselt man zunächst mit # cd /home/roman/netio116/bin in das richtige Verzeichnis. Das LISTIG-Gerät soll also nach folgendem Schema: # ./linux-i386 –s <Client-IP-Nummer> -p <freie Portnummer> im Servermodus gestartet werden. Dazu tippt man ein: # ./linux-i386 –s 192.168.0.2 –p 18767 Die Option –s steht für Server-Modus. Nach der Eingabebestätigung sollte anschließend im Fenster die Zeile TCP/IP server Listening zu sehen sein. Auf dem Windows-Notebook öffne ich über Start/Programme/Zubehör/Eingabe-aufforderung eine DOS-Box und wechsele in das entsprechende bin-Verzeichnis meiner entpackten Datei. Der Aufruf des Programms unter Windows unterscheidet sich etwas von der Linux-Version. Mit der Option –t teile ich NetIO mit, das mit TCP/IP getestet wird. Ich gebe also ein:

68

C:\Net\netio116\bin> win32-i386 –t 192.168.0.1 –p 18767 Auf dem anderen Rechner, auf dem der Server läuft, ist jetzt der Satz TCP/IP connection established zu lesen, gefolgt von einem ...done sobald die Verbindung steht. Schaut man sich jetzt den Client-Rechner an, sieht man in der DOS-Box, wie verschiedene Datenpakete mit unterschiedlichen KByte-Größen abgeschickt werden. Sobald vom Server die Rückmeldung kommt, wird der Datendurchsatz in KByte/s angezeigt. Es werden insgesamt sechs Datenpakete losgeschickt, deren Größe sich immer verdoppelt. Das erste Paket hat 1 KByte Größe, das letzte ist demnach 32 KByte groß. Pro Paket werden zehn Sekunden gemessen, bevor der NetIO-Server das Feedback schickt. Ein weiteres Tool, das ich zu Performance-Messungen einsetzte, ist Network Stumbler. Es läuft unter den Windows-Betriebssystemen und kann somit auf einem Client-Gerät, wie z.B. einem Notebook zu Messungen benutzt werden. Network Stumbler ist ideal zur Reichweitenmessung und veranschaulicht präzise, wie die Verbindungsqualität mit jedem Meter Entfernung leidet. Es ist frei im Internet erhältlich und wird regelmäßig aktualisiert. Die aufgenommenen Messdaten geben Auskunft über vorhandene WLAN-Netze, Netwerk-Kennung (SSID), Kanal, Geschwindigkeit, Netzwerktyp, Verschlüsselungsart, Signal-Rausch-Abstand, Empfangsfeldstärke und deren Spitzenwerte:

Abbildung 7.1: Messung der Verbindungsqualität mit Network Stumbler

69

Messwerte Den Tabelleneintragungen ging eine Auswertung von umfangreichen Messwertreihen vor-an.

1. Paketgrößenabhängiger Netzwerk-Durchsatz mit NetIO, ohne Verschlüsselung

Distanz 2 Meter:

Durchschnittliche Datenrate in KByte/s

Paketgröße in KByte

Sender Tx Empfänger Rx

1 453 557 2 490 571 4 584 581 8 591 612 16 593 601 32 616 596

Ø = 554 Ø = 586

Tabelle 7.1: Messwerte Netzwerk-Durchsatz, 2m

Distanz 4 Meter:

Durchschnittliche Datenrate in KByte/s

Paketgröße in KByte

Sender Tx Empfänger Rx

1 442 595 2 425 606 4 478 604

70

8 513 634 16 491 621 32 529 630

Ø = 480 Ø = 6151

Tabelle 7.2: Messwerte Netzwerk-Durchsatz, 4 m

2. Messwerte mit NetIO und Net Stumbler über unterschiedliche Reichweiten, mit Verschlüsselung (WEP 128 Bit)

Durchschnittliche Datenrate in KByte/s

Distanz zwischen Host und Client

Empfangsfeldstärke in dBm

SNR in dB

Sender

Empfänger

< 1 m

-70 max. -53

25

474

564

5 m -71 max. -54 28 493 556 5 m (1 Wand) -73 max. -57 23,5 462 551 8 m ( 2 Wände)

-77 24 478 557

10 m -76 max. -56 23 457 560 10 m (1 Wand) -77 max. -56 26 479 533 15 m (1 Wand) -79 19 474 530 20 m (1 Wand) -79 24 426 465 20 m (1 Wand + 1 Glaswand)

282 202

Tabelle 7.3: Messwerte Verbindungsqualität

7.3 Beobachtungen und Schlussfolgerungen Würden die 11 MBit/s, die WLAN nach IEEE 802.11b theoretisch schafft, voll und ganz nutzbar "durchkommen", dann müsste der Datendurchsatz zwischen zwei Computern rechnerisch 1.408 KByte/s entsprechen (wenn man die 11 MBit/s auf die Darstellung als KByte/s umrechnet). Da die 11 MBit/s, die ein WLAN technisch schaffen könnte, nur unter absoluten Idealvoraussetzungen erreicht werden und zudem ein Teil der Übertragungsrate für technische Abläufe und nicht für den reinen Datentransport verbraucht werden, gilt ein Datendurchsatz von 600 KByte/s als hervorragender Wert und alles über 400 KByte/s immer noch als sehr gut.

1 Der zufälligerweise höhere Datendurchsatz beim Empfang in der 4m-Distanz im Vergleich zur 2m-Distanz könnte mit dem Interferenzmuster von Empfangsmaxima und Empfangsminima der EM-Wellen zusammenhängen wie es im nächsten Kapitel erklärt wird.

71

Maxima und Minima Die Wellenlänge im 2,4 GHz-Band beträgt ca.12 cm. Jeder Metallgegenstand mit 7 cm Länge oder einem Vielfachen davon ist damit ein guter Absorber oder Reflektor – im Zweifel reicht schon ein Nagel in der Wand. Das Interferenzmuster, welches durch Reflexionen in Räumen entsteht, ist also sehr fein. Ein Empfangsoptimum kann wenige Zentimeter neben einem Empfangsminimum liegen. Daher sind starke Schwankungen in der Empfangsfeldstärke beim Verschieben der WLAN-Karte (Antenne) schon um wenige Zentimeter normal - und machen sich natürlich gerade dann bemerkbar, wenn der Empfang ohnehin schon recht schwach ist. Praxisrelevante Aussagen über die Reichweite lassen sich so kaum machen: Während im freien Feld durchaus Entfernungen von über 50 km möglich sind, kann die Verbindung in der eigenen Wohnung schon zwei Zimmer weiter zusammen-brechen.

Polarisation man sollte Antenne am besten mit einem Winkel von 90 Grad zueinander ausrichten. Das liegt daran, dass nicht nur die Energiefelddichte (Signalstärke) eine Rolle spielt, sondern auch die Polarisation. Wenn man es perfekt machen will, richtet man auch in einem Raum die Antennen senkrecht zueinander aus, so dass jeweils eine Antenne eine Polarisations-richtung abdeckt.

Datendurchsatz Der in den Standards festgelegte (und im Marketing stark beworbene) Brutto-Datendurchsatz wird in der Praxis mit realen Anwendungen nie erreicht. Die Brutto-Datenrate von 11 MBit/s bezieht alle Kontrollinformationen und Status-Meldungen ein, in der Praxis erreicht man auch unter optimalen Bedingungen höchstens 1 MByte/s, die bei einigen Metern Entfernung oder durch Wände schnell auf 100KByte/s oder noch weniger einbrechen, irgendwann versagt die Verbindung dann gänzlich. Je größer die Distanz zwischen zwei WLAN-Geräten, umso geringer ist die Übertragungsgeschwindigkeit. Da der WLAN-Protokoll-Overhead unabhängig von der Paketgröße stets konstant bleibt, verringert sich bei kleineren Paketgrößen die Netto-Datenrate entsprechend.

|---------------------- 1500 byte -----------------| [------------------ Nutzdaten ----------------][CRC] Zeitverzögerung: Systembedingt können in Funknetzen - im Vergleich zu der recht fehlerfreien Verbindung in einem kabelgebundenen Netzwerk - teilweise erheblich verlängerte Übertragungszeiten auftreten. Das äußert sich z.B. in relativ hohen Ping-Zeiten (relevant vor allem bei Voice-over-IP (VoIP)-Anwendungen, oder Maschinensteuerungen).

Der Grund dafür ist die Tatsache, dass das Funknetz im OSI-Schichtenmodell auf dem Physical Layer (der untersten Schicht) angesiedelt ist, und deshalb von den darüber liegenden Schichten (insbesondere der Transport- und Sicherungsschicht) genauso wie ein Netzwerkkabel behandelt wird. Wegen der im Funknetz nicht zu vermeidenden Störungen realisiert WLAN aber, anders als ein einfaches Kabel, schon seine eigenen Korrekturmechanismen. Diese erweiterten Sicherungsfunktionen sorgen bei Fehlern in der Übertragung selbstständig für ein erneutes Verschicken der Datenpakete, ohne dass die höheren OSI-Schichten davon etwas mitbekommen. Der Protokoll-Stack wiederum 'weiss' ja nichts von der Existenz dieser funknetzspezifischen Korrekturmechanismen, deshalb interpretiert z.B. TCP/IP die kleine Verzögerung durch die (Funknetz-)Korrektur

72

seinerseits als 'Verstopfung' der Leitung und erhöht die notwendigen Bestätigungen von Datenpaketen durch den Empfänger, um gehäufte Wiederholungen von Datenpaketen zu vermeiden. Für die gesicherte Datenübertragung hat aber eben schon das Funknetz gesorgt - aus einer ursprünglich kleinen Verzögerung wird damit schnell eine größere.

Geschwindigkeit: Für die geringe Datenmenge, die zur Steuerung einer Hausautomatisierungsanlage anfällt, ist der Standard 802.11b mit 11 MBit/Sekunde völlig ausreichend. 11 MBit/s brutto bedeuten letztendlich in der Praxis 4 bis 6 MBit/s.

Erhöhung der Sendeleistung und Reichweite In der Praxis sind Entfernungen von 25 bis über 50 Meter möglich. Wie bei allen Funkverbindungen hängt das stark von der Raumaufteilung und den verwendeten Baustoffen ab. Die Reichweite ist ein wichtiges Kriterium, dass man allerdings nur sehr grob angeben kann. In Büro-Umgebungen beträgt sie je nach System 30 bis 100 Meter. Im Freien kommt man auch bis zu einem Kilometer weit, was im Anwendungsfall von LISTIG jedoch keine Rolle spielt. Sollte die Sendeleistung oder die Reichweite des WLAN trotz Optimierung der Standortwahl über die Datendurchsatzmessungen nicht ausreichen, gibt es mehrere Möglichkeiten, diese dennoch ein wenig zu erhöhen. Die Antennen in den üblichen WLAN-Karten sind Rundstrahler. So kann man am Basisgerät stärkere Antennen mit Keulencharakteristik, also mit Richtwirkung, verwenden oder wenn die WLAN-Karte des Clients über einen entsprechenden Anschluss verfügt, kann dieser mit einer externen Antenne ausgestattet werden.

8 Sicherheit und Authentifizierung

8.1 Sicherheitsaspekte Mit welchen Problemen ist bei einer drahtlosen Steuerung zu rechnen?

Abbildung 8.1: Gefährdungen

73

Man sieht hier dieselben Gefährdungsklassen, die man schon von drahtgebundenen Netzen kennt. Wie dort ist Sicherheit auch relativ und muss immer eine angemessene Wertigkeit gegenüber den oft konkurrierenden Merkmalen wie Nutzerfreundlichkeit oder Performanz erhalten.

Eine absolute Sicherheit gibt es natürlich nicht:

"The only system which is truly secure is one which is switched off and unplugged, locked in a titanium lined safe, buried in a concrete bunker, and is surrounded by very highly paid armed guards. Even then, I wouldn't stake my life on it." (Gene Spafford)

Bei den Vorkehrungen zur WLAN-Sicherheit hat man folgende Teilaspekte zu unterschei-den:

• Authentifizierung und Autorisierung • Integrität • Vertraulichkeit

Vorkehrungen zur Sicherheit können in ganz verschiedenen Schichten angeordnet werden. Damit wird klar, dass hier keineswegs nur WLAN-spezifische Techniken eine Rolle spielen. Einige der Techniken sind alternativ, aber auch Kombinationen sind oft sinnvoll.

Abbildung 8.2: Einordnung der verschiedenen Sicherheitstechniken

8.2 WEP

74

Funknetze sind offensichtlich leichter abzuhören oder zu beeinflussen als drahtgebundene Netze oder gar Lichtwellenleiter. In Anerkennung dieser Tatsache wurde als Bestandteil von 802.11 eine Technologie unter der Bezeichnung Wired Equivalent Privacy (WEP) entwickelt. Diese soll ein Abhören der Funkübertragung verhindern oder zumindest erschweren. Ein sekundäres Ziel war die Realisierung einer Zugriffskontrolle auf das WLAN. WEP soll etwa das Sicherheitsniveau eines Kabel-Ethernet erreichen.

Die Realisierung hat mehrere Elemente:

• Verschlüsselung mit Stream Cipher RC4 • den Partnern ist ein geheimer Schlüssel bekannt

shared secret key

• Integrity Check (IC) CRC-32 zur Integritätsprüfung

linear, d.h. Modifizierer kann CRC wieder stimmend machen!

• 24 Bit Initialization Vector (IV)

soll identische verschlüsselte Daten bei identischem Klartext verhindern, wird unverschlüsselt übertragen

75

Abbildung 8.3: WEP-Funktionsweise

Im Laufe der letzten 2 Jahre sind einige signifikante (und vermeidbare) Schwachstellen von WEP gefunden worden:

• Der IV-Raum ist zu klein, hier ein Rechenbeispiel:

8 Mbit/s, 1000-Byte-Pakete d.h. 1 ms/Paket, 16777,216 s für 2^24 Pakete, ca. 4,6h

Der IV wiederholt sich also nach einigen Stunden, damit liegt dann auch der gleiche Schlüsselstrom vor.

• Wenn ein Klartext bekannt ist, dann kann der dazugehörige Schlüsselstrom durch XOR ermittelt werden. Damit sind dann alle verschlüsselten Texte, die den gleichen IV verwenden, entschlüsselbar.

• Die Kenntnis eines Klartexts zu einem verschlüsselten Text ist leichter zu erlangen, als man auf den ersten Blick glaubt. Beispielsweise kann man einen bekannten

76

Klartext von einem beliebigen Host außerhalb des WLAN an eine Mobilstation schicken.

• Die Integritätsprüfung mittels CRC-32 kann nur zufällige Fehler mit hoher Wahrscheinlichkeit erkennen. Bei absichtlichen Modifikationen kann auch ohne Kenntnis des Klartext-Inhalts der CRC-32-Wert wieder "passend" gemacht werden. Das lässt sich beispielsweise ausnutzen, um die Ziel-IP-Adresse auf einen beliebigen Host außerhalb des WLAN zu ändern. Der AP entschlüsselt dann den betreffenden Datenstrom.

• Ein Klient weist zur Authentifizierung die Kenntnis des Schlüssels nach:

Abbildung 8.4: WEP-Authentifizierung

Ein Mithörer kennt jetzt Klartext und verschlüsselten Text, er kann daraus den RC4-Strom bestimmen (für einen IV). Ein Mithörer kann nun eine andere Challenge korrekt beantworten!

• Die Verteilung der geheimen Schlüssel ist nicht trivial. Allen Nutzern (auch Gästen) muß der geheime Schlüssel bekanntgegeben werden. Ein öffentlicher Aushang ist hierzu sicher nicht optimal, etwas besser ist z.B. die Lieferung dieser Information nach Authentifizierung über einen anderen Weg (geschützte WWW-Seite ...). Eine Alternative wäre das Einsammeln der Notebooks und die Schlüsseleinstellung durch eine vertrauenswürdige zentrale Stelle. Beide Verfahrensweisen haben Nachteile. Auch die in den meisten APs gegebene Möglichkeit, eine kleine Anzahl verschiedener Schlüssel einzustellen, mildert das Problem nur wenig.

Aus den geschilderten Schwachstellen sollte man folgende Konsequenzen ziehen:

... kurze Schlüsselnutzungszeiten

Ein automatisiertes Schlüsselmanagement kann die beschriebenen Schwachstellen teilweise beheben. Einige Produkte enthalten entsprechende Zusätze, die Interoperabilität ist dann aber möglicherweise nicht gegeben.

77

... Firewalls/SSH/SSL nutzen

Beim heutigen Stand der Technik ist die Verwendung von etablierten Techniken in anderen Schichten empfehlenswert.

Folgende Standardisierungswege für WEP-Verbesserungen (IEEE 802.11i) zeichnen sich ab:

• Temporal Key Integrity Protocol (TKIP) o Kurzfristig, weitgehende Nutzung vorhandener Hardware o Message Integrity Check (MIC) "Michael" mit 64-Bit-Schlüssel (weniger

rechenaufwendig als z.B. HMAC-SHA1) o Sequenznummer gegen Replay (48 Bit) o Verschlüsseln mit "Per-Packet"-Schlüssel (aus Basisschlüssel,

Sequenznummer ...) • Counter-Mode-CBC-MAC (CCMP)

o Advanced Encryption Standard (AES) als Verschlüsselung o Cipher Block Chaining Message Authentication Code (CBC-MAC) zur

Integritätssicherung

8.3 Authentifizierungsmechanismen Eine Authentifizierung der WLAN-Nutzer braucht man aus mehreren Gründen:

• nur festgelegte Nutzer/Nutzerklassen zulassen • Ressourcenbegrenzung (Bandbreiten/Datenmengen) ? • Abrechnung (Accounting)

Zur Identifikation eines Nutzers gibt es eine ganze Reihe unterschiedlicher Ansätze. Einige sind eher für kleine, selten wechselnde Nutzermengen geeignet; für große Nutzermengen sind nicht alle Verfahren praktikabel.

• Kenntnis des Network Name, SSID, Extended Service Set IDentifier (ESSID)

Der Nutzer weist hier nur nach, dass er einen Netzidentifikator kennt. Wenn dies als "Netzpasswort" gehandhabt werden soll, ergeben sich dieselben logistischen Hürden wie bei der Verteilung geheimer WEP-Schlüssel. Ein offenes Netz akzeptiert Mobilstationen ohne Netzidentifikator. Für die Einschränkung auf Mobilstationen, die den SSID kennen, findet man mitunter die Bezeichnung "Closed Network" (das ist wohl etwas irreführend).

• MAC-Adresse - 48 Bit

Hier wird im Grunde die WLAN-Karte als "Authentifizierungstoken" verwendet, was sich ganz gut mit der mancherorts praktizierten Ausleihe von WLAN-Karten organisieren lässt. Nachteilig ist der Organisationsaufwand für "fremde" WLAN-Karten. Außerdem

78

ist eine MAC-Adresse kein Geheimnis, sie lässt sich leicht ermitteln. Weniger bekannt ist die Tatsache, daß sich in vielen Fällen auch beliebige MAC-Adressen einstellen lassen.

• WEP-Authentifizierung - shared secret key

Wie wir im letzten Abschnitt gesehen haben, ist diese Variante eher kontraproduktiv.

• VPN-Authentifizierung (PPTP, IPSec ..)

Viele VPN-Technologien enthalten Vorkehrungen zur Authentifizierung gegenüber dem anderen Tunnelende, so etwas ist natürlich nutzbar. Hier greifen die Eigenschaften (und potentiellen Schwachstellen) der verwendeten VPN-Technologie.

• Nutzername/Passwort via HTTPS

Die Nutzer müssen sich über eine Anwendung authentifizieren. Die Authentifizierungsinformationen (z.B. Nutzername und Passwort) müssen hinreichend sicher übertragen werden, was beispielsweise mit HTTP über SSL/TLS gegeben ist.

• Port-based access control - IEEE802.1x

Das ist eine neue Entwicklung zur Authentifizierung von Netzzugängen. Im Fokus befinden sich nicht nur WLAN-Zugänge, sondern z.B. auch Ethernet-Dosen mit mehr oder weniger öffentlichem Zugang. Diese Technik ist Teil der neuen IEEE-Sicherheitsarchitektur Robust Security Network (RSN). Es wird das Extensible Authentication Protocol (EAP) verwendet, hier konkret EAP over Wireless (EAPoW).

Abbildung 8.5: EAP-Anwendung bei WLANs

Da EAP ursprünglich für drahtgebundene Netze vorgesehen war, fehlten spezielle Vorkehrungen zum kryptografischen Schutz der Authentifizierungsinformationen.

79

Weiterhin hat sich der Authenticator nicht selbst ausgewiesen, so daß man mit einem "illegalen" AP/Authenticator die Authentifizierungsinformationen "einsammeln"kann. Beide Probeme löst die Entwicklung EAP/TLS, wo mit Transport Layer Security (TLS) eine bewährte Technik zur Herstellung eines sicheren Kanals verwendet wird (bekannt von https ...).

• ...

Einige der Verfahren sind kombinierbar, was Schwachstellen kaschieren kann. Problematisch ist oft die Erkennung der Kontinuität bzw. des Nutzungsendes für einen autorisierten Nutzer.

Für die Verwaltung von Authentifizierungsdaten sollte möglichst auf etablierte und für andere Zwecke oft ohnehin vorhandene Techniken zurückgegriffen werden, wie z.B.

• Remote Authentication Dial In User Service (RADIUS), RFC 2865 • Kerberos • Directory-Systeme (LDAP ...)

Ein typischer Ablauf sieht dann so aus:

1. MS2 assoziiert sich mit AP 2. MS bekommt private IP 3. MS authentifiziert sich (z.B. gegenüber VPN-Server) 4. MS bekommt NAT freigegeben oder "eigene" IP

8.4 Vertraulichkeit

Eine mögliche Vorkehrung zur Sicherung der Vertraulichkeit ist die Verwendung der WEP-Verschlüsselung. Trotz der bekannten Schwachstellen ist das sicher besser als gar keine Vorkehrungen. Andererseits wird man bei etwas höheren Anforderungen nicht um zusätzliche oder alternative Techniken herumkommen. Dieser Abschnitt soll primär Lösungen "oberhalb" von WEP kurz darstellen.

• Virtual Private Networks (VPN) o IPSec

Bei den ersten Standardentwürfen zu IPSec hatte man übrigens ähnliche Fehler gemacht wie bei WEP. Mittlerweile kann IPSec aber als einigermaßen solide gelten. Als Nachteil bleibt die meist nicht triviale und schwer auf Korrektheit zu prüfende Konfigurierung (vor allem in Endsystemen).

o Point-to-Point Tunneling Protocol (PPTP)

2 Mobile Station

80

Diese Variante ist im Windows-Umfeld recht verbreitet. Es gibt allerdings auch hier eine Reihe signifikanter und gern ausgenutzter Schwachstellen.

o Layer 2 Tunneling Protocol (L2TP)

Hinter dieser Variante stehen IETF und große Routerhersteller.

• End-zu-End-Verschlüsselung und -Authentifizierung o Secure Sockets Layer (SSL)

Transport Layer Security (TLS) o Secure Shell (SSH)

Wir können hier nicht die Abläufe und Anforderungen aller End-zu-End-Varianten behandeln, diese sind auch nicht WLAN-spezifisch. Hier sollen nur beispielhaft wesentliche Elemente des Ablaufs bei SSH 2.x gezeigt werden, da hierbei wichtige Merkmale klar werden.

Zu Beginn wird ein "gemeinsames Geheimnis" nach dem Diffie-Hellman-Verfahren gewonnen:

Abbildung 8.6: Diffie-Hellman

Anschließend weist der Server seine Identität nach (hier mittels RSA):

81

Abbildung 8.7: RSA-Authentifizierung

Jetzt können über die so gesicherte Verbindung nicht nur Textdialoge geführt werden, sondern nahezu beliebige Protokolle "getunnelt" werden, z.B. X-Window:

Abbildung 8.8: X-Window über SSH-Tunnel

82

8.5 Exkurs: Der HostAP-Treiber auf dem LISTIG-System Viele der in den vorangegangenen Kapiteln dargestellten Sicherheitstechniken (wie z.B. das von mir favorisierte EAP/TLS) lassen sich nur mit einem Access Point verwenden. Das HostAP-Projekt (http//hostapi.epitest.fi) entwickelt für Linux einen speziellen Treiber, der gewöhnliche WLAN-Karten mit Access Point- Funktionalität ausstattet. Es ist eine Patch-Datei erforderlich, die von der Homepage des HostAP Projekts runtergeladen werden kann. Da es den Patch erst für Kernelversionen ab 2.4.24 gab, war es notwendig, dass ich zu diesem Versuch zusätzlich den Kernel 2.4.24 besorgen und nach Anwendung des Patches auf dem Basisgerät installieren musste. Nach dem Entpacken der Kernelquellen wendet man den Patch folgendermaßen an: # cd /usr/src/linux-2.4.24 # patch –p1 </usr/src/hostap-driver-02.4.tar/hostap-driver-0.2.4/Kernel- patches/hostap-linux-2.4.24.patch # cp /usr/src/ hostap-driver-02.4.tar/hostap-driver- 0.2.4/driver/modules/hostap*.[ch] drivers/net/wireless Eine andere Variante wäre es, den HostAP-Treiber separat zu installieren. Den Treiber selbst gibt es in Form einer Archiv-Datei: hostap-driver-x.y.z.tar.gz Um ihn zu kompilieren, sind die Kernel-Headers erforderlich. Diese kann man sich mit Hilfe der Debian-Paketverwaltung mit: # make-kpkg kernel-headers bequem erstellen. Mit Hilfe von # make menuconfig habe ich den Treiber in das System eingebunden und anschließend den Kernel kompiliert. Nachdem das geglückt war, konnt ich mit: # modprobe hostap den HostAP-Treiber erfolgreich laden und anschließend mit lsmod überprüfen. Die Anwendung des HostAP-Treibers erfordert eine gründliche Einarbeitung in seine Funktionen, die jedoch über den zeitlichen Rahmen der Studienarbeit hinausgehen würde. Eventuell lassen sich einige Funktionen erst nach einem Firmware-Update der WLAN-Karte nutzen. Außerdem muß die Karte wahrscheinlich mit # iwconfig eth0 mode master in den Master-Modus versetzt werden.

83

8.6 Fazit Die mindeste Sicherheitsvorkehrung, die man im Wireless LAN vom LISTIG-System vornehmen sollte, ist das Setzen eines WEP-128-Bit-Keys. Trotz der in diesem Kapitel beschriebenen offensichtlichen Mängel des WEP-Standards, stellt die Verschlüsselung mit 128 Bit immerhin eine Einstiegshürde für „Gelegenheits-Schnüffler“ dar. Außerdem erhöht das mindestens wöchentliche Wechseln des WEP128-Schlüssels die WLAN-Sicherheit des LISTIG-Systems mit einem vertretbaren Aufwand. Die Vorgehensweise für das Setzen des WEP-Schlüssels ist in Kapitel 6.4.3 beschrieben. Einige Sicherheitsberater schlagen vor, die SSID-Broadcasts zu unterdrücken. Aber während dieser Schritt vielleicht „war driving“ – Angriffe (kostenloses Mitnutzen einer fremden Internetverbindung) reduziert, garantiert er nur einen temporären Vorteil, weil diese Information aufgedeckt wird, sobald sich ein neuer Benutzer mit dem Netzwerk verbindet. Ein Angreifer ist vielleicht nicht in der Lage, sich unabhängig direkt am Server einzuloggen, weil dazu ein korrekter Benutzername und ein Passwort erforderlich ist, aber wenn er clever genug ist, braucht er das gar nicht. Er kann mit einem geeigneten Tool (Kismet, AirSnort) das Wireless LAN beobachten, um einen Benutzer ausfindig zu machen, der bereits eingeloggt ist. Dann imitiert er den Datenverkehr dieses Benutzers. Wenn der Angreifer die Netzwerk-Adress- Informationen des Benutzers kopiert, ist der Server nicht in der Lage zu realisieren, dass er in Wirklichkeit mit einem illegalen Eindringling kommuniziert und gewährt ihm die selben Zugriffsrechte, wie einem legalen Benutzer. Zugangskontrolle über MAC-Adressenfilterung als weitere Maßnahme, die Sicherheit zu erhöhen, würde auf dem LISTIG-System bei Einsatz des HostAP-Treibers aus Kapitel 8.5 funktionieren. Meiner Meinung nach lohnt es sich auf jeden Fall, die Verwendung dieses Treibers auf diesem System weiter zu untersuchen. Darüber hinaus wären dann weitere Sicherheits- und Authentifizierungsmaßnahmen möglich wie z.B. EAP/TLS (Kapitel 8.3). Der Wireless LAN –Adapter im LISTIG-Basisgerät unterstützt zur Zeit noch keine Unterdrückung der SSID. In einer aktuelleren Firmware steht dieses Feature zur Verfü-gung. Aber auch die Verschlüsselungstechnik WPA, als verbesserter Nachfolger von WEP soll Ende des Jahres in einem Firmware-Update zur Verfügung stehen. Voraussetzung für die Nutzung von WPA sind dann wiederum ausgereifte Linuxtreiber, die zur Zeit jedoch noch in der Entwicklungsphase sind.

9 Störungsfreier Funkbetrieb

Beim späteren Einsatz des LISTIG-Systems muss man sowohl potentielle Störquellen, als auch solche Funkstandards beachten, die sich von WLAN-Geräten stören lassen. Im Heimbereich können beispielsweise AV-Funkstrecken vorkommen, mittels denen man Signale vom Kabel-Decoder oder Videorecorder bequem im ganzen Einfamilienhaus verteilen kann. Mit WLAN- und Bluetooth-Geräten lassen sich diese wirkungsvoll stören, denn das Videosignal wird nur analog moduliert im 2,4 GHz-Bereich übertragen. Abhilfe ist dann gewährleistet wenn sich beide Geräte manuell auf einen anderen Kanal umschalten lassen.

84

Die Mikrowelle in der Küche kann auch zur Störquelle werden, da sie mit 2,4 GHz im gleichen Frequenzbereich arbeitet wie die 802.11/g WLAN-Netze. Die teureren 802.11a/h-Varianten gehen diesem Problem aus dem Weg. Auf der anderen Seite lassen sich WLAN-Übertragungen so gut wie gar nicht von den AV-Brücken stören, da sie als Digitalfunkverfahren im Vorteil sind und Übertragungsfehler mittels spezieller Korrekturverfahren ausmerzen. Zu unerwünschten Überlappung von Funkzellen kann es dann kommen, wenn beispielsweise ein WLAN- und ein Bluetooth-Netz einander überlappen. Die Folge sind statische Interferenzen. Mit der Bluetooth-Spezifikation 1.2 soll dieses Problem jedoch mit Hilfe des Adaptive Frequency Hopping (AFH) behoben sein. Wenn 802.11b und 802.11g- Geräte räumlich benachbart sind, konkurrieren beide zum gegenseitigen Nachteil um das Funkband. Techniken zur dynamischen Kanalwahl fehlen im 2,4 GHz-Band und somit gibt es keine automatische „Verkehrsregelung“, wenn zwei oder mehr 2,4-GHz-WLANs einander überlappen. Beim überlappenden Betrieb funken 802.11b-Geräte auf dem gleichen Kanal wie die 802.11g-Gegenstücke. Damit die verschiedenen Datenpakete nicht kollidieren, senden die Funknetze nicht zur selben Zeit, sondern erst dann, wenn das Medium frei ist. Bei gleich guten Funkbedingungen brauchen 802.11b-Geräte für dieselbe Datenmenge mehr Zeit als 802.11g-Geräte. Für den gemeinsamen Betrieb von 802.11g und 802.11b stehen nur drei nichtüberlappende Kanäle zur Verfügung (z.B. 1, 7 und 13). Bei zunehmender Popularität der b- und g-Versionen steigt somit die Wahrscheinlichkeit für Kollisionen. Wirkliche Abhilfe schafft nur eine Flucht in den 5-GHZ-Bereich, indem sich wegen teurer Geräte noch sehr wenige WLAN-Nutzer tummeln.

10 Abschlussbemerkungen

Die Kombination LISTIG und WLAN erscheint als eine sehr attraktive Kommunikations-lösung zur Steuerung der Haustechnik. Reichweite und Datenrate sind schon jetzt bei dem weitverbreiteten und kostengünstigen Drahtlos-Standard 802.11b sehr zufriedenstellend. Störquellen lassen sich durch geschickte Platzierung und externe Antennen mit Richt-wirkung weitgehend ausschließen. Als Digitalfunkverfahren, mit Fehlerkorrektur-Mecha-nismen ist WLAN robust genug, um analoge Störquellen im selben Frequenzbereich, (wie z.B. AV-Brücken), ohne Einbußen zu verkraften. Die Sicherheit ist bei Wireless LAN eine wichtige Problematik. Aber die Vielfalt an Sicherheits- und Authentifizierungsmaßnahmen hat sich in jüngster Vergangenheit stark erhöht; die Techniken haben sich verbessert und werden ständig weiterentwickelt. Außer WEP128 und WAP-Firmware-Update bietet sich für das LISTIG-System, zur Erhöhung der Sicherheit, die HostAP-Software (siehe Kapitel 8.5) an, die aus Linux-Rechnern flexible und leistungsfähige WLAN-Acess-Points macht. Es würde sich meiner Meinung nach lohnen, das Projekt an dieser Stelle weiter zu verfolgen. Der Umstieg auf den schnelleren 802.11g- Standard scheint im Hinblick auf eine Steuerungs-Schnittstelle für Hausautomatisierungstechnik momentan nicht zwingend notwendig.

85

Neuere Linux-Kernel der 2.6’er Serie mit Hotplug-System bremsen das System zu stark aus und machen vernünftige Bedienung fast unmöglich. Bei meinen Versuchen haben sich die Kernel 2.4.23 und 2.4.24 (für HostAP) als optimal erwiesen.

86

Anhang

Den Treiber der WLAN-Karte manuell aktualisieren Um beispielsweise den neusten, eventuell erweiterten und verbesserten Orinoco_cs -Treiber selbst zu kompilieren, lädt man sich am besten das aktuellste tar.gz File von der Webseite http://www.hpl.hp.com/personal/Jean_Tourilhes/Linux/Orinoco.html Man benötigt weiterhin die Kernel-Sourcen, für die entsprechende Kernelversion unter dem das eigene System läuft. Soweit man sie nicht auf CD zur Verfügung hat, kann man die Kernelquellen von: http://www.kernel.org oder ftp://ftp.kernel.org beziehen. Das ist die beste Archivseite für Kernelquellen und Kernel-Code. Man lädt sich beispielsweise die 2.4.23-Kernel-Sources von: http://www.kernel.org/pub/linux/kernel/2.4/linux-2.4.21.tar.gz. Das Kompilieren des orinoco_cs - Treibers erfordert ebenfalls, dass ein symbolischer Link von /lib/modules/<version>/build auf die Kernel-Sourcen des aktuellen Kernels zeigt. Z.B soll /lib/modules/2.4.23/build ein symbolischer Link sein, der auf /usr/src/linux-2.4.23 verweist. Um diesen Link anzulegen, muss man folgende Befehlszeile eingeben: # ln -s /usr/src/linux-2.4.23 /lib/modules/2.4.23/build Um anschließend den Treiber zu erstellen, muss man das tar.gz File entpacken und anschließend in dessen Hauptverzeichnis wechseln: # tar xzvf orinoco-0.13e.tar.gz # cd orinoco-0.13e Um den Treiber zu kompilieren und zu installieren, muß abschließend noch folgendes eingegeben werden: # make # make install Falls man versucht den Treiber zu laden und dabei die Fehlermeldung „Card Services release does not match“ erhält, wurde der Treiber gegen die Kernel-PCMCIA-Treiber kompiliert, jedoch benutzt das System eigentlich die Treiber des PCMCIA-Packages. Um den Fehler zu beheben, muss man dazu das Makefile im orinoco-0.13e - Verzeichnis editieren und der PCMCIA_CS Variable den richtigen Pfad für das PCMCIA-CS-Package zuweisen. Wenn der Treiber ordnungsgemäß installiert ist, kann man eingeben # modprobe orinoco_cs um das Treiber-Modul zu laden.

87

Literaturverzeichnis

[1] Axel Sikora: Wireless LAN. Protokolle und Anwendungen. Addison-Wesley, 2001, ISBN 3-8273-1917-X, 240 S.

[2] Bruce Potter, Bob Fleck: 802.11 Security. O'Reilly, 2002, ISBN 0596002904, 208 S. "Rezeptsammlung", u.a. HostAP/Prism2

[3] Jon Edney, William A. Arbaugh: Real 802.11 Security. Addison Wesley, 2004, 2nd Printing, ISBN 0-321-13620-9

[4] Matthew S. Gast: 802.11 Wireless Networks: The Definitive Guide. O'Reilly, 2002, ISBN 0596001835, 464 S.

[5] Roger Weeks, Edd Dumbill & Brian Jepson: Linux Unwired

O'Reilly, 2004, First Edition

[6] Philippe Bertin: WLAN Standards and Evolutions Ann.Telecommun., 2003

[7] Franz Joachim Kauffels: Wireless LANs-Drahtlose Netze Mitp-Verlag, 2002

[8] Arno Kral, Heinz Kreft: WirelessLANs Networker’s Guide Markt+Technik, 2002

[9] Rob Flickenger: Wireless Hacks O'Reilly, 2003

[10] Peter H.Ganten, Wulf Alex: Debian GNU/Linux

Springer, 2.Auflage, 2004

[11] Patrick Ditchen: Shell-Skript-Programmierung Mitp-Verlag, 2002

[12] Johannes Endres: Offene Funknetze:WLAN-Konfiguration c’t 13/2004 S.98 ff.

[13] Stefan Krecher: Authentifizierungsverfahren

c’t 18/2004 S. 192 ff.

[14] Corinna Aichele: Aufbau von Linux-basierten Access Points mit HostAP Linux Magazin, Sonderheft 3/2004, S. 22 ff

88