Konzipierung und Implementierung von automatisiertem WLAN

Transcription

Fachbereich Informatik
Bachelorarbeit
Konzipierung und Implementierung von automatisiertem
WLAN–Verbindungsaufbau im KFZ
Dirk Andres
Matrikelnummer: 646066
Darmstadt, 17. Oktober 2005
Betreuende Professoren:
Prof. Dr. Joachim Wietzke
Prof. Dr. Klaus Kasper
Inhaltsverzeichnis
1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1 Motivation der Bachelorarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1
Konventionelle WLAN–Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.2
Neue Möglichkeiten und Einsatzgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2 Aufbau der Bachelorarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3 Inhalt der beigefügten CD–ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2. Einführung in die WLAN–Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1 WLAN–Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2 Einordnung der WLAN–Technologie im ISO OSI Schichtenmodell . . . . . . . . . . . . . . .
6
2.3 Infrastrukturmodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.1
Infrastruktur–Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.2
Ad–hoc–Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.4 SSID und BSSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.5 Sicherheit im WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3. Anforderungen an WLAN–Lösungen im KFZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1 Wahl und Integration geeigneter Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2 Übersichtliche grafische Anwendungsrealisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.3 Spezifizierung der WLAN–Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.4 Konfliktfreier Wechsel der Betriebsmodi und zustandsabhängige Benutzerinteraktion
12
3.4.1
Automatisierte IP–Adressvergabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.4.2
Zustandsabhängige Verbindungsvisualisierung . . . . . . . . . . . . . . . . . . . . . . .
13
3.5 Dynamischer Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4. Verifizierung vorhandener Connection Manager Lösungen . . . . . . . . . . . . . . . . . . . . .
15
4.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.2 Der Pocket PC 2003 Connection Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.2.1
Aufwandsbetrachtung im Infrastrukturszenario . . . . . . . . . . . . . . . . . . . . . . .
16
4.2.2
Aufwandsbetrachtung im Ad–hoc–Szenario . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.3 Zusammenfassende Bewertung für den Einsatz im KZF . . . . . . . . . . . . . . . . . . . . . . .
18
ii
5. Vorbetrachtungen im allgemeinen WLAN–Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
5.1 Notwendigkeit einer individuellen Softwarelösung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
5.2 Programmiersprache und Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
5.3 Anmerkungen zur Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
5.4 Grundlegende Konzipierungsüberlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.5 Die Wireless Zero Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
5.6 802.11–Netzwerktreiber–Architektur und NDIS USER MODE I/O PROTOCOL . . . . .
24
5.6.1
802.11–Netzwerktreiber–Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.6.2
Implementierungsaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5.6.3
Wireless Research API (WRAPI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
6. WLAN–Verbindungsaufbau im Ad–Hoc–Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
6.1 IP–Adressen–Problematik und Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
6.1.1
Bewertung konventioneller Verfahren zur IP–Adressvergabe . . . . . . . . . . . .
29
6.1.2
Abwandlung von APIPA durch Registrierungsmanipulation . . . . . . . . . . . . . .
30
6.1.3
IP–Adresszuweisung mittels IPHelper Funktionen . . . . . . . . . . . . . . . . . . . . .
34
6.2 Adapterkonfiguration über das NDISUIO–Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . .
36
6.2.1
Setzen des Infrastrukturmodus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
6.2.2
Setzen des Authentifizierungsmodus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.2.3
Setzen der SSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.3 Netzwerkscan und dynamischer Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . .
42
6.4 Integration einer 3rd Party VOIP–Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
6.4.1
Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
6.4.2
Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
6.4.3
Testdurchführung und Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
7. WLAN–Verbindungsaufbau im Infrastruktur–Szenario . . . . . . . . . . . . . . . . . . . . . . . .
48
7.1 Adapterkonfiguration über das NDISUIO–Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . .
48
7.2 Dynamischer Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
7.3 Integration einer Informationsanwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
8. Anmerkungen zur Entwicklung unter Windows XP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
8.1 NDISUIO–Schnittstellendefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
8.2 Enumeration der WLAN–Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
8.3 Assoziation des Adapters mit dem NDISUIO Handle . . . . . . . . . . . . . . . . . . . . . . . . .
57
iii
9. Prioritätsgesteuerter WLAN–Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
9.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
9.2 802.11–Netzwerkscan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
9.3 Implementierung eines BSSID List Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
9.4 Verwertung der gesammelten Geräteinformationen . . . . . . . . . . . . . . . . . . . . . . . . . .
64
10. WLAN–Integration eines Embedded Automotive Frameworks unter QNX . . . . . . . . .
67
10.1 Systembedingte Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
10.2 Realisierung mittels WLAN–Karte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
10.2.1 Verbindungsaufbau mittels Systembefehlen . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
10.2.2 Integration der Systemkommandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
10.2.3 Verbindungsaufbau mittels DeviceControl–Zugriffen . . . . . . . . . . . . . . . . . . . . .
73
10.3 Realisierung mittels Ethernet–WLAN–Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
10.3.1 Beschaffenheit der Netzwerkgeräte und Integration in das bestehende
Kabelnetzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
10.3.2 Interface–Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
10.3.3 Konfiguration des Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
10.3.4 Konfiguration der Ethernet–WLAN–Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
10.3.5 Dynamische IP–Adresszuweisung für Endgeräte . . . . . . . . . . . . . . . . . . . . . . .
77
10.4 Verbindungsgesteuerte Client–Server–Kommunikation . . . . . . . . . . . . . . . . . . . . . . . .
78
11. Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
11.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
11.2 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
11.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
A
Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
B
Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
C
Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
D
Quellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
E
Eigenständigkeitserklärung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
iv
1. Einleitung
1.1
Motivation der Bachelorarbeit
Die WLAN-Technologie erstreckt sich heutzutage auf viele Bereiche unseres Alltages. Dabei
werden längst nicht alle Möglichkeiten dieser Technologie genutzt. Ziel der vorliegenden
Arbeit ist es, denkbare WLAN–basierte Szenarien und Lösungen von praktischer und
softwaretechnischer Seite zu beleuchten.
1.1.1
Konventionelle WLAN–Szenarien
Das Hautpeinsatzgebiet von WLAN–Lösungen beschränkt sich bisher weitgehend auf privat
installierte Access Points, zu denen ausschließlich mit dem eigenen Laptop oder PC
verbunden wird. Die Konfiguration der Geräte erfolgt im Idealfall einmal, was den Anwender
in vielen Fällen schon einiges an Zeit und Geduld kosten kann.
Der Vorteil der WLAN–Technologie wird hierbei in der kabellosen Installation gesehen.
Lästiges Kabelgewirr oder Wanddurchbrüche gehören der Vergangenheit an. Auch die
Internetanbindung des Laptops aus dem heimischen Garten kann begeistern.
Die Einsatzgebiete dieser sich immer weiter etablierenden Technologie sind dabei jedoch
bei weitem nicht ausgenutzt. Tausende von Tank– und Raststättenbetreiber haben diesen
Gedanken bereits aufgegriffen und WLAN Basisstationen installiert. Gegen Bezahlung steht
es dem Kunden frei mit eigenen Systemen ins Internet zu gehen. Die Einrichtungsarbeit
bleibt dem Anwender selber überlassen. Innovative Nutzungsmöglichkeiten wurden bisher
jedoch nicht umgesetzt.
1.1.2
Neue Möglichkeiten und Einsatzgebiete
Die bereits eingerichteten Netzwerkschnittstellen könnten einen zentralen Einstiegspunkt in
ein weiteres, viel versprechendes Anwendungsgebiet ermöglichen: Der Einsatz von WLAN–
Anwendungen im KFZ.
Viele Leute besitzen bereits heute das nötige Equipment: Ein WLAN–fähiger Laptop, ein
handelsüblicher PDA oder ein Handy, welches mit Festplatte und Wireless–LAN–Adapter
ausgerüstet ist.
Der Einsatz eines Softwaremoduls, welches über die Möglichkeit verfügt, spezifische
WLAN–Profile zu verwalten und je nach Bedarf Netzwerkanbindungen anzustreben,
erschließt eine Vielzahl von realisierbaren Szenarien. Ein Beispiel wäre das Angebot eines
digitalen Bonusprogrammes. Beim Anfahren einer Tankstelle wird automatisiert eine
-1-
Einleitung
Verbindung zu einem Tankstellenserver hergestellt, welcher den Besuch registriert und den
treuen Kunden mit digitalen Prämien, wie mp3s oder Spielen, beschenkt. Werbespots oder
Angebotsinformationen weisen den Kunden auf Sonderaktionen im Tankstellenshop hin.
Selbst das Bezahlen über digitale Zertifikate könnte realisiert werden. Hierbei verbindet sich
das Programm eigenständig mit der benutzen Zapfsäule, welche die getankte Benzinmenge
in Rechnung stellt und von dem entsprechenden Konto abbucht.
Befindet sich das Kraftfahrzeug wieder auf der Straße ist es mit einer Anwendung möglich
mit anderen Fahrern per WLAN–Telefonie zu kommunizieren. Über die vollständige
Automatisierung ist ein Voice over IP Telefonat ohne Aufmerksamkeitsdefizit möglich.
Die Anwendung ließe sich weiterhin auf In Car Systeme ausweiten. Beim Besuch einer
Werkstatt werden gespeicherte Daten genutzt um Wartungsarbeiten einzuplanen und
Angebote einzuholen. Softwareupdates werden bei Bedarf drahtlos und ohne Wartezeit
installiert.
1.2
Aufbau der Bachelorarbeit
Nach einer kurzen technischen Einführung in die WLAN–Technologie werden grundlegende
Anforderungen an den Verbindungsaufbau im KFZ erarbeitet.
Danach folgt die Betrachtung einer systemeigenen Software unter PocketPC 2003 zur
Verbindungsverwaltung nach erstellten Kriterien. Eine abschließende Bewertung weist auf
Schwachstellen des Programms im Bezug auf den Einsatz in einem Kraftfahrzeug hin und
motiviert für den Einsatz einer individuell erstellten Software.
Der Kernteil der Arbeit beleuchtet den automatisierten WLAN–Verbindungsaufbau im KFZ
aus verschiedenen Perspektiven.
Auf einem Handheld unter PocketPC 2003 wurde eine Software entwickelt, welche versucht
den gestellten Anforderungen gerecht zu werden. Gesammelte Erfahrungen bei der
Auseinandersetzung
mit
der
WLAN–Technologie
boten
Eckpfeiler
der
Konzipierungsüberlegungen.
Die WLAN–Treiber–Architektur und das NDISUI–Protokoll dienen als Grundlage für die
Implementierung des Verbindungsaufbaues in verschiedenen Betriebsmodi.
Automatisierte IP–Adresszuweisung im Ad–hoc–Netzwerk und die Suche nach verbundenen
Geräten bilden eine weitere Komponente einer erfolgreichen Netzwerkkommunikation und
werden ausführlich an Hand von Quelltextauszügen vorgestellt.
Danach
werden
ausgesuchte
Anwendungsszenarien
und
ihre
Softwareumsetzung
fokussiert.
Nach grundlegenden Anmerkungen zur Implementierung unter Windows XP und variabler
Hardware geht die Arbeit auf Aspekte des prioritätsgesteuerten WLAN–Verbindungsaufbaus
ein. Hierbei werden Informationen verfügbarer drahtloser Netzwerke ausgelesen und
verwertet.
-2-
Einleitung
Die Anwendung wählt selbsttätig zwischen vorhandenen Alternativen in Abhängigkeit von
Signalstärke, Infrastrukturmodus oder Netzwerkkennung.
Vorliegende Arbeit wendet sich nun einer Plattform zu, welche ausschließlich für den Einsatz
in einem Kraftfahrzeug konzipiert wurde. Es handelt sich hierbei um ein Embedded
Automotive Framework unter dem echtzeitfähigen Betriebssystem QNX 6.3.
Dieses zeichnet sich durch einige systembedingte Besonderheiten aus. Da WLAN–Treiber
und systemeigene Verwaltungsmöglichkeiten kaum vorhanden sind, nimmt sich die
Abhandlung im Weiteren den aufgetretenen Problemen und Lösungsansätzen im Bezug auf
die drahtlose Netzwerkanbindung an. Die Integration von WLAN–Karten wird ebenso
berücksichtigt wie die Anbindung externer Ethernet–WLAN–Brücken.
Softwaregesteuerte Konfiguration und Verbindungserkennung steht bei der Betrachtung im
Vordergrund.
Ebenso wird ein Anwendungsszenario entworfen, welches auf einer automatisierten Client–
Server–Kommunikation basiert.
Die Arbeit bemüht sich die vorgestellten Sachverhalte verständlich von allgemeinen
Grundlagen bis hin bis zu sehr speziellen Aspekten, die für die Implementierung relevant
sind, zu beleuchten.
Da das Thema einen sehr starken Praxisbezug aufweist und vorgestellte Ideen bereits im
Vorfeld
realisiert
Anmerkungen
zur
wurden,
kann
das
vorliegende
Implementierungstechnik
und
Manuskript
den
durch
beigefügten,
umfangreiche
kommentierten
Quelltextauszügen als Einführung und Leitfaden in die Implementierung softwaregesteuerter
WLAN–Adapterkonfigurationen, speziell unter Windows, Verwendung finden.
1.3
Inhalt der beigefügten CD–ROM
Auf der beigefügten, selbstständig startenden, CD–ROM befindet sich eine HTML Version
der vorliegenden Arbeit. Querverweise sind mit Hyperlinks zu den betreffenden Stellen
versehen. Ebenso werden Verweise auf Software und Quelltexte, welche in den Kapiteln
Erwähnung finden, eingebunden.
Diese Softwaresektion enthält frei verfügbare Programme für den Einsatz auf PocketPC
2003, Windows XP und QNX. Einige Programme liegen zusätzlich in Form von Quelltexten
vor. Weiterhin sind der vollständige Quelltext und eine kompilierte Version der eigens
entwickelten Software gespeichert. Dies beinhaltet ein Programm zur automatisierten WLAN
Verbindungsherstellung unter PocketPC 2003, welches für den HP iPAQ 5500 entwickelt
wurde,
weiterhin
eine
Software,
welche
sich
mit
dem
hardwareunabhängigen,
prioritätsgesteuerten Verbindungsaufbau unter Windows XP beschäftigt und eine Client–
Server–Anwendung mit WLAN–Verbindungsdedektion unter QNX.
Die Softwareauswahl gliedert sich nach Kapiteln, Betriebssystem und Plattform. Die
Programme und Quelltexte können über den Browser auf der lokalen Festplatte gespeichert
-3-
Einleitung
und ausgeführt werden. Informationen zur Installation werden innerhalb der HTML–
Dokumentation angeboten, so wie in beigelegten readme.txt Dateien.
Eine
Linksammlung
liefert
Hintergrundinformationen
zu
implementierungsrelevanten
Aspekten.
Abrundend wird ein recht populistischer Artikel vorgestellt, welcher für die Veröffentlichung in
einem Computermagazin geschrieben wurde.
-4-
2. Eine Einführung in die WLAN–Technologie
Der Begriff WLAN steht als Akronym für "Wireless Local Area Network".
Man versteht hierunter ein "drahtloses" lokales Funknetzwerk, welches sich durch räumliche
Flexibilität,
innerhalb
eines
vorgegebenen
Empfangsbereiches,
auszeichnet.
Verkabelungsprobleme und Kabelgewirr können elegant umgangen werden. Der Einsatz
einer kabellosen Netzwerktechnik für tragbare Geräte, wie Notebooks oder Handhelds,
bringt erhebliche Vorteile mit sich, allerdings auch einige Nachteile.
Im Folgenden möchte ich auf einige Grundlagen und Begrifflichkeiten, sowie auf einige
technische Details der Wireless–LAN–Architektur eingehen.
Sicherlich erhebt diese kurze Einführung in Technologie drahtloser Netzwerke keinen
Anspruch auf Vollständigkeit. Es wird hierbei lediglich auf Aspekte eingegangen, welche für
den automatisierten Verbindungsaufbau von Bedeutung sind und das Verständnis, der im
Weiteren beschriebenen Verfahren, fördert.
2.1
WLAN–Standards
Die Bezeichnung WLAN bezieht sich im Grunde genommen auf drahtlose Netzwerke im
Allgemeinen und umfasst Standardisierungen wie HiperLan/2, Bluetooth, DECT, HomeRF
und IrDA.
Technisch korrekt beschäftigt sich diese Arbeit ausschließlich mit dem IEEE 802.11
Standard. Das Institute of Electrical and Electronics Engineers (IEEE) verabschiedete seit
1997 zahlreiche standardisierte Spezifikationen. Diese wurden in Abhängigkeit von der
zeitlichen Reihenfolge alphabetisch, von 802.11a bis hin zu 802.11i (2005), gekennzeichnet.
Es handelt sich hierbei größtenteils um regional unterschiedliche Anpassungen sowie
technische Erweiterungen.
Die in Deutschland am häufigsten vorzufindenden Varianten sind der 802.11b und der
802.11g Standard. Beide Ableger der 802.11–Technologie stellen 13 Kanäle in Deutschland
zur Verfügung und senden im 2.4 - 2.4835 GHz Band [MLMMS04]. Ein gravierender
Unterschied zeigt sich jedoch in den Datenraten und der daraus resultierenden
Übertragungsgeschwindigkeit. Während der b–Standard lediglich maximal 11 Mbit/s
Datendurchsatz bietet, kann der abwärtskompatible g–Standard mit bis zu 54 Mbit/s
aufwarten. Allerdings sind diese Werte rein theoretischer Natur. In der Praxis muss
berücksichtigt werden, dass sich alle Geräte im Netzwerk diese Bandbreite teilen. Zudem
wird diese durch einschränkende Faktoren wie z.B. Stahlwände oder störende Funksignale
auf einen reellen Nettowert reduziert.
-5-
Eine Einführung in die WLAN–Technologie
2.2
Einordnung des 802.11–Technologie im ISO OSI Schichtenmodell
Betrachtet man das OSI–Referenzmodell, welches 7 Schichten zum Aufbau einer
Netzkommunikation, unabhängig von der Art der eingesetzten Protokolle, kennt, so siedelt
man die WLAN–Technik in den Schichten 1 und 2 an. Bei Schicht 1 handelt es sich um die
Bitübertragungsschicht.
Diese
stellt
die
physikalischen
Grundlagen
für
eine
Netzwerkkommunikation zur Verfügung. Elektrische Signale, optische Signale sowie in
unserem Fall, elektromagnetische Wellen, werden zur Kodierung eines Bitstromes
verwendet. Die Sicherungsschicht, als zweite Ebene des Referenzmodelles, gewährleistet
die weitgehend fehlerfreie Übertragung der zu sendenden Informationen. Hierzu werden die
Bitströme fragmentiert, also in Pakete aufgeteilt, und mit Folgenummern und Prüfsummen
versehen. Der Empfänger wertet diese Informationen bei dem Erhalt der Pakete aus und
kann bei erkannten fehlerhaften Zustellungen die wiederholte Übertragung des Paketes
anfordern. Die Bedeutung dieser OSI Schichten für den automatisierten Verbindungsaufbau
von WLAN Geräten wird schnell ersichtlich. Neben der Steuerung der zwei untersten
Schichten ist für eine erfolgreiche Netzkommunikation ebenso der Einsatz der abstrakteren
Schichten obligatorisch. Da alle Ebenen des Referenzmodelles völlig unabhängig
voneinander arbeiten, benötigt die Manipulation der höheren Schichten eine eigenständige
Realisierung.
Konkret handelt es sich hierbei um das Anbinden eines Netzwerkprotokolles, ohne das keine
verwertbaren Informationen gesendet werden können [WIOSI05].
OSI 7
Application
Application
layer
HTTP
OSI 6
Presentation
OSI 5
Session layer
OSI 4
OSI 4
Transport layer
Transport layer
OSI 3
OSI 3
Network layer
Network layer
OSI 2
LLC Layer
LLC Layer
Data Link
MAC Layer
Ethernet 802.3
CSMA/CA
OSI 1
OSI 1
10 BASE-2,
DSSS, FHSS,
Physical layer
Physical layer
10 BASE-T
Infrared
TCP
IP
Pair cable,
coax cable
OSI
OSI angepasst
LAN
Abbildung 2.1 : Einordnung von IEEE 802.11 im ISO OSI Kommunikationsmodell
-6-
Air
IEEE 802.11
2.3
Infrastrukturmodi
Ein WLAN–Adapter kann in zwei verschiedenen Infrastrukturmodi betrieben werden. Zum
einen im Infrastrukturmodus und zum anderen im Ad–Hoc–Modus.
2.3.1
Infrastruktur–Modus
Bei dem Betrieb im Infrastruktur–Modus dient ein Access Point (AP) als vermittelnde
Komponente zwischen Funknetzwerk und Festnetz. Der Zusammenschluss mehrer
Funkstationen ist als Basic Service Set (BSS) bekannt. Sind, wie in Abbildung 2.2
dargestellt, zwei oder mehrere Funkzellen über das Kabelnetzwerk miteinander verbunden,
spricht man von einem Extended Service Set (EES) [MLMMS04].
Abbildung 2.2 : Infrastruktur Szenario
Aufgabe des Access Points ist die zentrale Verwaltung und Konfiguration von WLAN–
Verbindungen, sowie das Routing in angebundene Netzwerke. Alle relevanten Einstellungen
werden direkt auf diesem Gerät vorgenommen. Des Weiteren bietet ein solcher Access
Point in der Regel eine Reihe höherer Dienste zur Netzwerkverwaltung an. So können die
Geräte, welche sich auf den niedrigeren OSI–Schichten Zugang verschafft haben, optional
über einen integrierten DHCP–Server mit einer netzkompartiblen IP–Adresse versehen
werden. Doppelte oder fehlerhafte IP–Adressvergabe kann somit profilaktisch unterbunden
werden.
-7-
2.3.2
Ad–Hoc–Modus
Will man zwei oder mehrere Endgeräte ohne den Einsatz eines zentralen Routers
miteinander verbinden, so geschieht dies über das Ad–Hoc–Protokoll.
Abbildung 2.3 : Ad–hoc–Szenario
Es erfolgt ein loser, unbeständiger Zusammenschluss dieser Geräte innerhalb begrenzter
Reichweite. Der Ad–Hoc Einsatz eignet sich somit für den schnellen, ungeplanten Einsatz.
Alle Stationen agieren hierbei gleichberechtigt und unterliegen keinerlei zentraler Steuerung
und Verwaltung. Es lassen sich hierbei lediglich Peer–to–Peer oder Ende–zu–Ende
Verbindungen einrichten, was heißt, dass ein Gerät ausschließlich mit Stationen
kommunizieren kann, welche sich in direkter Signalreichweite befinden. Eine Gruppe von
Stationen, welche auf einer einheitlichen Funkfrequenz miteinander kommunizieren, nennt
man Independent Basic Service Set (IBSS) [MLMMS04].
Der Einsatz von Routingmechanismen in solchen Peer–to–Peer–Netzwerken existiert zurzeit
nur im Experimentalstadium. Ein solcher Zusammenschluss, bei dem jeder Teilnehmer als
Router fungieren muss, nennt man Mesh–Netz. Ziel dieser mobilen Mesh–Netze ist es,
Kommunikation zwischen Geräten zu ermöglichen, welche sich nicht in direkter
Signalreichweite befinden, sondern einen Verbindungspfad über dazwischen liegende
Stationen aufbauen [WIMAH05].
-8-
2.4
SSID und BSSID
Ein Wireless LAN, unabhängig ob im Ad–hoc– oder im Infrastrukturmodus, identifiziert sich
in erster Linie über eine bis zu 32 Zeichen lange Netzwerkkennung, genannt SSID (Service
Set ID) oder ESSID (Extended Service Set ID). Grundlage für einen Netzwerkverbund auf
der Grundlage des 802.11 Standards ist die Kenntnis der SSID, welche in einem
Zusammenschluss unter Verwendung einer übergeordneten Infrastruktur sowohl auf dem
Client als auch auf dem Access Point eindeutig sein muss. Die Verwendung des
Betriebsmodus „Any“ erlaubt Geräten mit beliebiger SSID den Zugriff auf das Funknetzwerk.
Ein Zugangspunkt ist in der Regel so eingestellt, dass die SSID eines Funknetzwerkes aktiv
als Broadcast in den „Äther“ geschickt wird um das Auffinden und Einrichten der Verbindung
zu vereinfachen.
Ähnlich der SSID identifiziert sich ein Access Point über eine weitere Kennung, der BSSID
(Basic Service Set Identifier). Diese entspricht immer der 48 Bit umfassenden MAC–Adresse
des WLAN–Adapters und ist unmanipuliert in jedem Falle weltweit eindeutig. Alle Clients
müssen sich auf diese BSSID einigen um eine Kommunikation auf unterster OSI–Ebene zu
ermöglichen. Wenn mehrere Verbindungspunkte eine gleiche SSID vorweisen, kann über
das gezielte Einstellen dieser Kennung selektiv verbunden werden. Im Falle eines
infrastrukturellen Verbundes nehmen alle Teilnehmer die BSSID des Access Points an, in
einem Peer–to–Peer–Netz wird die BSSID dynamisch generiert, muss jedoch auf allen
Geräten identisch sein [MSDN05].
2.5
Sicherheit im WLAN
Im Weiteren möchte ich auf standardisierte Sicherheitsmechanismen eingehen, welche
Vertraulichkeit, Integrität und Authentizität in Funknetzwerken sichern sollen.
Als eine recht schwache Sicherheitsmassnahme, welche die sichere Zuordnung des
Senders gewährleisten soll, kann das Rundsenden der SSID auf einigen Access Points
unterbunden werden. Nur Netzwerkadapter, bei welchen eine kompatible Konfiguration
vorgenommen wurde, erlangen Zugriff. Dieses Verfahren ist jedoch nicht standardkonform.
Weiterhin wird die Netzwerkkennung in allen gesendeten Paketen unverschlüsselt mit
übertragen, so dass es möglich ist, diese mit Hilfe eines Paketfilters auszulesen.
Eine Access Control List (ACL) kann den Netzwerkzugang zusätzlich auf spezifizierte MAC–
Adressen beschränken. Geräte mit fremder Kennung werden vom Access Point
grundsätzlich abgewiesen. Diese Liste wird manuell auf dem Access Point verwaltet. Es
kann jedoch nicht sichergestellt werden, dass eine solche Kennung eindeutige Rückschlüsse
auf die Authentizität der Station ziehen lässt, da die MAC–Adresse eines Netzwerkadapters
systemintern manipuliert werden kann.
-9-
Das Wired Equivalent Privacy (WEP)–Protokoll dient sowohl der Sicherung von
Vertraulichkeit und Integrität als auch der Authentifizierung. Passive Angriffsmethoden wie
das Abhören des Datenverkehrs sollen durch Verschlüsselung der Daten unterbunden
werden.
Über
den
RC4–Algorithmus,
welcher
einen
Schlüssel
und
einen
Initialisierungsvektor als Eingabe benötigt, wird die paketweise Verschlüsselung des
Datenstromes durchgeführt. Der Schlüssel, der optional eine Länge von 40 oder 104 Bit
aufweisen muss, ist für alle Komponenten des Funk–LANs zwingend. Seine Vergabe findet
direkt auf dem Access Points statt. Der Initialisierungsvektor wird systemintern für jedes
Datenpaket generiert und der eigentlichen Nachricht bei der Übertragung vorangestellt.
Dieses Verfahren gilt jedoch als mathematisch unsicher.
Bei der Authentisierung wird der gleiche Schlüssel wie bei der Integritätssicherung genutzt.
Wird der Authentisierungsmodus mit „Shared Key“ gewählt, so erfolgt der Zugriff nach dem
Challenge–Response–Verfahren. Alternativ erfolgt im „Open“–Modus keine Kontrolle.
Im IEEE 802.11 Standard wird als Nachfolger des WEP–Protokolls Wi–Fi Protected Access
(WPA) und WPA2 eingeführt [MLMMS04.
- 10 -
3. Anforderungen an WLAN–Lösungen im KFZ
Bei der Aufarbeitung der Problemstellung hinsichtlich des in der Einleitung dargestellten
Szenarios, sowie im Laufe der Implementierung und der anschließenden Testphasen,
kristallisierten sich elementare Anforderungen an Software und Peripherie heraus. Die
erarbeiteten Punkte stellen im Weiteren eine wichtige Orientierungshilfe bei der Bewertung
vorhandener Softwarelösungen dar und sind dem Verständnis von Konzipierungsgrundlagen
bezüglich der geleisteten Implementierungsarbeit von enormem Nutzen.
3.1
Wahl und Integration geeigneter Hardware
Wahl und Integration geeigneter Hardware meint hierbei äußere Faktoren, welche für den
Betrieb von WLAN–Lösungen in einem Kraftfahrzeug von grundlegender praktischer
Bedeutung sind und die Thematik dieser Arbeit lediglich streifen. Aus Gründen der
Vollständigkeit wird im Folgenden kurz auf Anforderungen eingegangen, welche in der
Praxis Berücksichtigung finden sollten. Generell kann die Realisierung einer WLAN–Lösung
auf internen Komponenten, also dauerhaft in das Fahrzeug integrierter Hardware, oder auf
externen mobilen Geräten, wie Handhelds, PocketPCs oder Laptops, durchgeführt werden.
Allgemein ist zu sagen, dass vor allem die Positionierung und Bemessung der
Bedienelemente im Cockpit besondere Aufmerksamkeit erfahren sollte. Der Anwender
benötigt direkten Zugang zu den Elementen, welche so übersichtlich wie möglich skaliert
sind um den Konzentrationsaufwand für die Bedienung minimal zu halten. Handelt es sich
um ein mobiles Gerät, in welchem alle Peripherie in einem kompakten Gehäuse integriert ist
und die Bedienung über einen Touch–Screen erfolgt, so bietet sich eine Montage über eine
Docking–Lösung mit integrierter Stromzufuhr an. Vom Betrieb über den geräteeigenen
Akkumulator sollte abgesehen werden, da der WLAN–Adapter einen enormen Energiebedarf
aufweist. Das systemeigene Powermanagement, welches bei einigen Betriebssystemen
sinnvollerweise regulierend eingreift, drosselt die gerätespezifische Energiespeisung und
führt zu unerwünschten Leistungseinbußen. Der Einsatz spezieller WLAN–Antennen, welche
die Übertragungsreichweite deutlich erhöhen, ist empfehlenswert
3.2
Übersichtliche grafische Anwendungsrealisierung
Das grundlegende Augenmerk liegt auch hier wieder auf dem Bedienkomfort und der
Aufwandsminimierung.
Grafische
Elemente
wie
Softbuttons,
Textfelder
und
Zustandsindikatoren müssen überlegt und funktionell gestaltet angeordnet sein. Eine
Zusammenfassung von Bedienelementen nach Funktionsgruppen ist in jedem Falle von
Vorteil und erhöht die intuitive Bedienbarkeit.
- 11 -
Es werden lediglich Kernfunktionen
Anforderungen an WLAN–Lösungen im KFZ
angeboten. Detaillierte Dialoge verwirren und verleiten zu konzentrationsintensiver Suche.
Eine geeignete, aussagekräftige Farbgebung der Elemente erleichtert die Bedienung
zusätzlich. Eine Ein–Dialog–Benutzeroberfläche enthält alle wesentlichen Elemente, welche
für die Auswahl des gewünschten drahtlosen Netzwerkes und der Verbindungsüberwachung
notwendig sind.
3.3
Spezifizierung der WLAN–Konfiguration
Sinn der automatisierten WLAN–Verbindungsherstellung im KFZ ist es, Zugriff auf
Netzwerke zu erlangen, welche den Bedürfnissen der Anwendung entsprechen. Greift man
das
einleitende
Tankstellenszenario
erneut
auf,
so
wird
ersichtlich,
dass
der
Tankstellenbetreiber Software zur Verfügung stellt, welche ausschließlich Zugang zu seinen
eindeutig konfigurierten Zugangsstationen und den von ihm zur Verfügung gestellten
Diensten gewährt. Soll über das an der Tankstelle erhaltene Programm im Peer–to–Peer
Modus verbunden werden, so ist dies auch nur zu den Geräten mit identischer Konfiguration
möglich. Ähnlich verhält es sich in Firmennetzwerken oder zu Hause. Ein automatisierter
Verbindungsaufbau zu fremden Geräten ist weder erwünscht noch programmatisch
realisierbar. Die Informationen, welche für die Einrichtung des WLAN–Zugangs benötigt
werden, müssen dabei nicht weitergegeben und veröffentlicht werden. Die Konfiguration des
WLAN–Adapters bleibt im Quellcode verborgen, was eventuell sogar vor Missbrauch der
Verbindungsdaten schützen kann.
Dabei werden die drahtlosen 802.11 Netzwerke über fest vorgegebene Parameter
spezifiziert, welche ein Wireless Local Area Network eindeutig definieren. Elementare
Parameter
sind
hierbei
der
Infrastrukturmodus,
die
SSID
oder
BSSID,
der
Authentifizierungsmodus und eventuelle Sicherheitsmerkmale wie die 64– oder 128–Bit
WEP–Verschlüsselung.
3.4
Konfliktfreier Wechsel der Betriebsmodi und zustandsabhängige
Benutzerinteraktion
Eine Anwendung, welche Zugriff auf WLAN–Ressourcen benötigt, kann diesen im
Infrastrukturmodus, sowie im Ad–hoc–Modus erfordern. Ein direkter Wechsel der
Infrastrukturmodi wird entweder automatisiert über die Software erfolgen oder durch
Interaktion des Anwenders. In beiden Fällen muss diese Anforderung sofort bedient werden.
Ein Verbindungswechsel zwischen zwei oder mehreren Access Points ist auf Grund der
ähnlichen verbindungsspezifischen Voraussetzungen ohne weiteres zu bewerkstelligen.
Anders verhält es sich bei dem angesprochenen Wechsel von Netzwerken mit
verschiedenartiger Infrastruktur.
- 12 -
3.4.1
Automatisierte IP–Adressvergabe
Fand die IP–Adresszuweisung bei der Verbindung zu einem Access Point problemlos über
einen DHCP–Server statt, so steht dieser bei einem Independent Basic Service Set, sprich
Ad–Hoc–Netzwerk, nicht mehr zur Verfügung. Es müssen eventuell zeitkritische
Protokolloperationen durchgeführt werden, um dieses Problem zu lösen.
3.4.2
Zustandsabhängige Verbindungsvisualisierung
Ist die Anwendung darauf ausgelegt, dass der Anwender in Abhängigkeit des aktuellen
Verbindungszustandes mit der grafischen Benutzeroberfläche interagiert, so muss über
aussagekräftige grafische Elemente darauf Aufmerksam gemacht werden, wann welche
Aktion ausgeführt werden kann. So kann eine rot eingefärbte Schaltfläche die
Verbindungsbereitschaft anzeigen falls bisher noch kein Verbindungsaufbau zu Stande
kommen konnte. Eine grün eingefärbte Schaltfläche signalisiert eine erfolgreiche
Netzwerkanbindung.
Der Anwender ist somit in der Lage allein durch visuelle Überprüfung zu Erkennen, wann
netzwerkabhängige Aktionen ausgeführt werden können oder wann eine
erfolgreich
durch
die
Software
bewältigt
wurde.
Weiterhin
können
Aufgabe
Softbuttons
programmatisch deaktiviert werden falls die über dieses Element auszuführende Funktion
auf Grund fehlender Netzwerkgegenstellen keinen Sinn machen würde. Dieses Verfahren
schützt den Anwender vor nutzlosen Eingabevorgängen am Gerät und Leichtfertigkeit auf
der Straße.
3.5
Dynamischer Verbindungsaufbau
Eine Grundvoraussetzung für den erfolgreichen Einsatz von WLAN–Lösungen im KFZ ist die
periodische und flexible Erkennung von in Reichweite befindlichen Netzwerkpartnern und die
daraus resultierende Verbindungsherstellung, bzw. Unterbrechung.
Auch diese Anforderungen lassen sich recht anschaulich am Tankstellenszenario
nachvollziehen. Fährt der Anwender eine Tankstelle an mit der Absicht einen
Verbindungsaufbau zur Basisstation herzustellen wird er auf Grund der eingeschränkten
Signalreichweite zunächst noch nicht in der Lage sein eine sofortige praktikable Verbindung
aufzubauen. Er versetzt sein WLAN–Gerät zunächst in Bereitschaft im Infrastruktur–Modus
zu verbinden. Erst wenn die physikalischen Voraussetzungen erfüllt sind, signalisiert ein
grafischer Indikator die bestehende Netzanbindung, verweist auf mögliche Interaktion oder
nimmt diese selbstständig in Angriff.
Durch den schnellen Ortswechsel der potentiellen WLAN–Partner und die ständig
variierende Signalstärke muss die Software, welche für die Herstellung und Erhaltung von
- 13 -
Verbindungen verantwortlich ist, automatisiert nachprüfen ob eine Verbindung neu erkannt
wurde, ob eine bereits eingerichtete Verbindung beständig bleibt oder ob diese dauerhaft
unterbrochen wurde. Auf Grund der Ergebnisse werden programmatisch entsprechende
Reaktionen eingeleitet.
Die Anforderungen an die Dynamik werden auch im mobilen Ad–hoc–Einsatz deutlich.
Angenommen zwei Fahrzeuge fahren in angemessenem Abstand hintereinander her. Das
hintere Fahrzeug verringert aus nicht näher bekannten Gründen seine Geschwindigkeit und
gerät für eine kurze Zeit außer Reichweite. Obwohl die Software einen Verbindungsverlust
erkennt, wirkt sich dieser erst nach einer bestimmten Verzögerungszeit auf den Zustand des
Programms aus, indem der grafische Indikator eine Trennung meldet und erneut auf die
Suche nach einem Netzwerkpartner geht.
- 14 -
4. Verifizierung vorhandener Connection Manager
Lösungen
4.1
Übersicht
WLAN–Lösungen existieren in unterschiedlichen Formen. Die meisten herkömmlichen PC–
Systeme lassen sich mit PCI–WLAN–Karten oder USB–WLAN–Adaptern ausrüsten.
Notebooks oder Tablet–PCs werden durch PCMCIA–Steckkarten WLAN–fähig. Viele Pocket
PCs und Handhelds sind bereits ab Werk mit integrierten WLAN–Adaptern ausgerüstet.
Die physikalische Beschaffenheit dieser unterschiedlichen Geräte ist für die folgenden
Betrachtungen von geringer Bedeutung, da sich alle Adapter festgelegten Standards
unterwerfen müssen und sich im Einsatz weitgehend identisch verhalten.
Unterschiedliche Betriebssysteme greifen abhängig von dem bereitgestellten Befehlssatz auf
die Hardware zu und bieten systemeigene Verwaltungswerkzeuge zur Konfiguration.
Ein Betriebssystem, auf welchem vorgestellte Szenarien und Lösungen zum großen Teil
implementiert wurden, ist Pocket PC 2003, eine Variante von Windows CE. Entwickelt für
mobile Endgeräte, bietet Pocket PC 2003 hauptsächlich Schnittstellen und Methoden,
welche konkret auf die Hardwareanforderungen bezüglich integrierter Peripherie und
Funktionsumfang dieser kompakten Geräte zugeschnitten wurden. Mobile Endgeräte, wie
der zur Entwickelung genutzte HP iPAQ 5500, auf welchem das angesprochene
Betriebssystem zum Einsatz kommt, eignen sich auf Grund ihrer kompakten Größe und des
leistungsstarken XScale Prozessors hervorragend für den Einsatz in einem Fahrzeug. Das
Gerät lässt sich über einen Touchscreen bedienen und ist mit einem integrierten WLAN–
Adapter ausgerüstet, welcher den 802.11b Standard unterstützt. Die folgende Bewertung
systemeigener Software zur Verwaltung von IEEE 802.11 Netzwerken soll zum einen
Aufschluss über Verhaltensweisen bei der Verwaltung von drahtlosen Netzwerken liefern
und zum anderen zeigen, ob die erarbeiteten Anforderungen an den automatisierten WLAN–
Verbindungsaufbau im KFZ aus Kapitel 3 umsetzbar sind.
4.2
Der Pocket PC 2003 Connection Manager
Die zentrale Instanz zur Verwaltung von Netzwerkadaptern und Verbindungen unter dem
Betriebssystem Pocket PC 2003 übernimmt alle für die Vernetzung des Gerätes relevanten
Aufgaben.
So lassen sich Programme mit Netzwerkbedarf generell zwei Einsatzgebieten zuordnen:
Internet oder Firma. Über konfigurierbare Profile wird die Art des Verbindungsaufbaus in
Abhängigkeit des Einsatzgebietes definiert. Greift eine Anwendung auf ein Firmennetzwerk
zu, so wird das dafür reservierte Profil aktiviert. Konfigurierbar sind Einwählverbindungen
- 15 -
Verifizierung vorhandener Connection Manager Lösungen
über Modem, Bluetooth und Infrarot. Weiterhin kann ein VPN–Zugang und ein Proxyserver
spezifiziert werden. Um den Verbindungsmanager aufzurufen, muss durch einige, nicht
immer intuitiv auffindbare, Menüs navigiert werden. Ist die Wireless–Option „WLAN“ aktiviert,
so findet man hier auch die Verwaltungsinstanz für drahtlose Netzwerke.
Um eine neue WLAN–Verbindung zu konfigurieren oder eingerichtete Konfigurationen zu
verwalten, ist aufgeführte Menüstruktur abzuarbeiten:
Start –> Einstellungen –> Verbindungen –> Verbindungen –> Erweitert –> Netzwerkkarte –>
Drahtlos
Hier werden alle verfügbaren WLAN–Netzwerke aufgeführt. Über Selektion und die Option
„Verbinden“ werden Informationen zu Einsatzgebiet und Authentifizierung abgefragt. Werden
diese korrekt spezifiziert, erfolgt der Verbindungsaufbau.
Alternativ ist das Einrichten eines neuen, nicht erkannten, Netzwerkes möglich. Benötigt
werden
Angaben
zum
Netzwerknamen,
Infrastrukturmodus,
Einsatzgebiet
und
Authentifizierungsmerkmale.
Da das alleinige Auffinden des Verwaltungsdialoges schon recht kompliziert werden kann,
reagiert das System bei Erkennung eines neuen Netzwerkes in Form eines Assistenten. Da
zu einer funktionstüchtigen TCP/IP–Kommunikation auch eine netzkompartible IP–Adresse
an den Adapter gebunden werden muss, fließt dieser Aspekt ebenfalls in die Betrachtung mit
ein.
Die
TCP/IP–Konfiguration
der
integrierten
Adapter
erfolgt
im
Untermenü
„Netzwerkkarten“, an gleicher Stelle wie der Konfigurationsdialog der drahtlosen Netzwerke.
Ist die Bezeichnung des betreffenden WLAN–Adapters bekannt, kann hier zwischen
dynamischer und manueller Adressvergabe gewählt werden. Vorgegeben ist die dynamische
Zuweisung über einen DHCP–Server. Das Verhalten und Zusammenspiel dieser
Komponenten soll nun im Folgenden untersucht werden.
4.2.1
Aufwandsbetrachtung im Infrastrukturszenario
Betrachtet werden soll der Aufwand, der benötigt wird um eine WLAN–Verbindung zu einem
Access Point herzustellen. Als Testvoraussetzung wird angenommen, dass bisher noch
keine Konfiguration getätigt wurde, der WLAN–Adapter eingeschaltet ist und sich in direkter
Signalreichweite befindet.
Erkennt der Verbindungsmanager einen neuen Access Point, so erscheint selbstständig ein
Assistent, welcher dazu auffordert, die Art der Verwendung zu definieren. Zur Auswahl steht
„Internet“ oder „Firma“. Bei einer VPN–Verbindung zu einem Firmennetzwerk soll ebenfall
die „Internet“–Option gewählt werden.
Betätigt man nun die „Verbinden“–Schaltfläche, so fordert der Dialog zur Eingabe des auf
dem Access Point konfigurierten WEP–Schlüssels auf. Nach entsprechender Eingabe stellt
der WLAN–Adapter eine Verbindung her. Der Verbindungsstatus wird über eine LED in der
- 16 -
oberen rechten Ecke des Gehäuses signalisiert. Verbunden blinkt diese grün, andernfalls
rot.
Werden bei Aktivierung des Gerätes oder des Adapters zwei oder mehrere Access Points
vorgefunden, so kann die Verbindung selektiv erfolgen. Ist das Gerät aktiv verbunden und
ein weiterer Access Point kommt in Reichweite, so wird dies ignoriert. Auch nach
Verbindungsverlust zu dem vormals aktiven Access Point wird keine Verbindung zu dem neu
erkannten Netzwerkknoten angestrebt.
Bei zwei oder mehreren eingerichteten Verbindungen und ohne bereits aktivierte
Netzanbindung wird die Verbindung vom Connection Manager nach Verfügbarkeit aktiviert.
Das beschriebene Verhalten erfolgt automatisiert und komfortablerweise unter Verwendung
eines selbständig erscheinenden Assistenzdialoges.
Da die meisten Netzwerke über einen separaten DHCP–Server verfügen, oder ein solcher
im Access Point integriert ist, erfolgt die IP–Adressvergabe dynamisch. Identifizieren sich die
Hosts im Netzwerk über einen Dynamic Name Server (DNS) und orientiert sich die
Anwendung an der Geräteidentifikation, spielt die erhaltene IP–Adresse lediglich eine
untergeordnete Rolle, da der Name dynamisch mit der entsprechenden Adresse verknüpft
wird.
Befindet sich das Gerät nicht im Signalbereich des gewünschten WLAN–Netzwerkes, muss
die Einrichtung von Hand erfolgen. Eine solche Situation kann sich ergeben, wenn die
Verbindung im Vorfeld eingerichtet wird, um einen automatisierten Netzwerkzugang bei
Bedarf zu gewährleisten. Hierzu ist es nötig sich in das Konfigurationsmenü drahtloser
Verbindungen zu begeben. Nach Eingabe aller nötigen Parameter, wie in Kapitel 4.2
beschrieben, befindet sich das Profil in Bereitschaft und verhält sich wie eine über den
Assistenten konfigurierte Verbindung im Bezug auf die Dedektion weiterer WLAN–Zellen
oder Verbindungsverlust.
4.2.2
Aufwandsbetrachtung im Ad–hoc–Szenario
Das Einrichten einer Ad–hoc–Verbindung über den Assistenten oder die Anzeige
verfügbarer drahtloser Netzwerke kann nur durchgeführt werden, wenn sich bereits
mindestens ein Gerät im Ad–hoc–Modus befindet und diesbezüglich konfiguriert wurde.
Dies erfolgt über die manuelle Einrichtung einer neuen Verbindung. Sucht der Connection
Manager nach gemischten Infrastrukturmodi, so kann die Anzeige verfügbarer Netzwerke
recht widersprüchlich erscheinen. Der Ad–hoc–Verbindungsaufbau ist gänzlich unmöglich,
wenn das Gerät infrastrukturell eingebunden ist.
Das Bereitstellen der Parameter für die erkannte Verbindung wird ähnlich der Konfiguration
einer infrastrukturellen Konfiguration vorgenommen. Wechselt das Gerät, welches die
Verbindung anfänglich signalisierte in den verbindungslosen Zustand, so ergibt sich beim
Partnergerät keine Änderung. Es scheint weiterhin aktiver Teilnehmer eines Independent
Basic Service Sets zu sein. Dieses Verhalten liegt in der Natur des Ad–hoc–Protokolls. Da
- 17 -
ein solcher loser Netzwerkverbund keinerlei zentraler Kontrolle untersteht, kann eine aktive
Netzwerkanbindung nicht erkannt werden. Die WLAN–Adapter wechseln in den Ad–hoc
Modus und sind bereits eigenständige, aktive Netzwerkstationen.
Ist das Gerät einmal verbunden, so kann es nie von selbst in einen verbindungslosen
Zustand
wechseln
und
die
Verbindung
zu
einem,
in
Reichweite
befindlichen,
infrastrukturellen Netzwerk anstreben. Wenn ein uneinheitlicher WEP–Schlüssel vergeben
wird, bauen beide Geräte ein unabhängiges Ad–hoc–Netz auf, auf welches die Geräte
gegenseitig nie Zugriff erlangen werden.
4.3
Zusammenfassende Bewertung für den Einsatz im KZF
Bewertet man die erzielten Ergebnisse nach den Kriterien für den automatisierten
Verbindungsaufbau im KFZ, so kann gesagt werden, dass der Connection Manager über
sehr weitreichende Funktionalität verfügt, jedoch den Anforderungen an den mobilen Einsatz
im KFZ nicht gerecht wird.
Von grundlegendem Nachteil ist auf jeden Fall die komplizierte Menüführung, welche sich
durch den enormen Funktionsumfang ergibt. Der Assistenzdialog, welcher bei der
Erkennung von neuen WLAN–Netzwerken erscheint, erleichtert zwar die Konfiguration, lässt
sich aber nicht an die individuellen Bedürfnisse des Anwenders anpassen.
Ähnlich verhält es sich mit der systeminternen Netzwerkverwaltung. In Abhängigkeit von der
aktuellen Einstellung, werden verfügbare WLAN–Knoten nicht immer erkannt oder lassen
sich nicht anwählen.
Weiterhin kann das Verbindungsverhalten kaum beeinflusst werden. Will ein Anwender,
welcher bereits mit einem WLAN–Knoten verbunden ist, auf ein alternatives Netzwerk
ausweichen, so sind umfangreiche Konfigurationsvorgänge vorzunehmen. Bei einem Betrieb
im Ad-hoc–Modus muss die IP–Adressvergabe zusätzliche Berücksichtigung finden.
Meistens kommt man um manuelle Konfiguration nicht herum. Der bei dem Betrieb im KFZ
obligatorische dynamische Verbindungsaufbau kann ebenfalls nicht realisiert werden. Wird
nach Abarbeitung aller Infrastrukturkonfigurationen keine Verbindung hergestellt, so stellt
sich der WLAN–Adapter auf den Ad–hoc–Modus ein. Dies macht im konventionellen Einsatz
Sinn, ist jedoch für das behandelte Szenario von Nachteil.
Intelligente Verbindungsverwaltung, welche auf die Anforderungen der Anwendung eingeht,
kann daher nur durch eine individuelle Softwarelösung umgesetzt werden.
- 18 -
5. Vorbetrachtungen im allgemeinen WLAN–
Szenario
5.1
Notwendigkeit einer individuellen Softwarelösung
Aus der Erkenntnis, dass vorhandene Softwarelösungen unzureichend und mit den
Anforderungen für den Einsatz im KFZ nicht in Einklang zu bringen waren, entstand die
Notwendigkeit ein individuelles Softwaremodul zu entwickeln.
Es wurde nach einer Lösung gesucht WLAN–Verbindungen softwareintern zu verwalten und
zu überwachen, um dynamisch auf gegebene Zustände reagieren zu können. Diese
Zustände ergeben sich aus dem aktuellen Status des WLAN–Adapters, der Verfügbarkeit
möglicher WLAN–Netzwerkpartner und dem konkreten Bedarf an Netzwerkzugriffen.
Eine Kommunikationsanwendung muss beispielsweise erkennen können, ob eine Ad–hoc–
Verbindung zu einem Partnergerät möglich ist, um eine Voice over IP (VOIP) Sitzung mit
dem entsprechenden Gerät mit individueller IP–Adresse herzustellen. Ist dies nicht der Fall,
wird entweder aktiv ein Verbindungsaufbau mit spezifischen, vorgegebenen Parametern
eingeleitet, auf eine alternative Verbindungsvariante umgestiegen oder signalisiert, dass sich
kein kompatibles Gerät in Reichweite befindet .
Diese Aktionen müssen dem Benutzer durch Automatisierung in vollem Umfang
abgenommen werden.
Bei komplexeren Anwendungen kann die Notwendigkeit bestehen mehrere Netzwerke oder
Infrastrukturmodi prioritätsgesteuert zu verwalten. Eine solche Aufgabe ist nur mit einer
entsprechend intelligenten Software zu bewältigen.
5.2
Programmiersprache und Entwicklungsumgebung
Bei der Entscheidungsfindung für die Wahl einer geeigneten Programmiersprache waren
einige hinreichende Kriterien zu bedenken.
Der zu entwickelnde Quellcode sollte durch ein hohes Maß an Modularität problemlos in
bestehende oder neue Anwendungen im mobilen Einsatz integrierbar und auch auf
unterschiedliche Betriebssysteme portierbar sein.
Die Programmiersprache muss von dem eingesetzten Betriebssystem, in unserem Falle der
Windows CE Variante Pocket PC 2003, in vollem Umfang unterstützt werden.
Des Weiteren ist eine modulare, objektorientierte Softwarearchitektur wünschenswert, um
den Quelltext übersichtlich und verständlich zu halten.
- 19 -
Vorbetrachtungen im allgemeinen WLAN–Szenario
Die oben genannten Faktoren sowie der Wunsch, dass der zu entwickelnde Quelltext auf
das echtzeitfähige, in unseren Projektframeworks eingesetzte Betriebssystem QNX1
portierbar sein sollte, bildeten die Grundlage der Entscheidung für die Programmiersprache
C++.
Bei der Suche nach einer Entwicklungsumgebung fiel die Wahl auf das Embedded Visual
Studio 4.0 in Kombination mit dem Pocket PC 2003 Software Development Kit2 (SDK) von
Microsoft. Dieses SDK unterstützt die Entwicklung auf vorgegebener primärer Zielplattform,
welche sich durch die Verwendung des iPAQ H5500 Pocket PCs ergab. Es ergänzt die
Basisfunktionalität der Entwicklungsumgebung um betriebssystemspezifische APIs in Form
von Header–Dateien und Bibliotheken, welche spezielle Hardwareeigenschaften von
unterstützten mobilen Endgeräten berücksichtigen und ermöglicht das Übersetzen des
Quellcodes für Prozessoren mit ARM4 Befehlssatz. Zusätzlich wird der Service Pack 4 für
das Visual Studio benötigt.
Die Möglichkeit kompilierte Quelltexte aus der IDE (Integrated Development Environment)
auf dem externen System auszuführen und zu debuggen, ermöglicht direkten Zugang zum
Zielsystem. Hierbei werden die Programmdateien mittels Active Sync Software3 auf das
mobile Endgerät transferiert, zur Ausführung gebracht und der Programmablauf im
Debugging–Modus ausgewertet. Der Pocket PC ist dabei über USB oder seriell mit dem
Entwicklungs-PC verbunden.
Zusätzliche Werkzeuge helfen bei der Verwaltung und der Systemüberwachung. Mit Hilfe
des Remote Registry Editors lässt sich die Windows–Registrierung auf dem verbundenen
Gerät bearbeiten. Über den Remote Process Viewer erlangt man Kontrolle über Prozesse,
Threads und Module und kann diese gegebenenfalls terminieren. Will man Screenshots des
externen Gerätes erstellen, so bemüht man das Remote Zoom In Werkzeug.
5.3
Pocket
Anmerkungen zur Implementierung
PC
2003
unterstützt
ohne
Installation
von
Zusatzsoftware
keine
Konsolenanwendungen. Es ist zwar theoretisch möglich diese mit Hilfe eines speziellen
Software Delevopment Kits4 (SDK) zu implementieren und auf den Geräten auszuführen,
jedoch würde die Bedienung der Software zu unübersichtlich und für den praktischen
Einsatz im KFZ kaum praktikabel. Nützliche Konsolenanwendungen wie „ipconfig“, um die
IP–Konfiguration auszulesen und die „ping“–Anwendung, um die Funktionalität von
Verbindungen zu überprüfen, wurden beim Entwickeln und Testen zu Rate gezogen.
1
www.qnx.com
www.microsoft.com
3
www.microsoft.com/windowsmobile/downloads/activesync38.mspx
4
www.symbolictools.de/public/pocketconsole/developers/portsdk.htm
2
- 20 -
Möglich wurde dies nach dem Aufspielen eines Konsolen–Gerätetreibers5, der eigentlichen
Konsolenanwendung6 und den "Nettools"7.
Es wurde bereits im Anfangsstadium entschieden eine grafische Benutzeroberfläche zu
entwerfen, welche es dem Benutzer möglich machen sollte, per Softbutton optional in
Bereitschaft zu wechseln, entweder im Ad–hoc–Modus oder im Infrastruktur–Modus nach
potentiellen Netzwerkpartnern zu suchen und eine Verbindung zu diesen herzustellen.
Die übersichtliche grafische Aufbereitung des Verbindungsstatus zählt ebenfalls zu den
gestellten Anforderungen und spricht zusätzlich für den Einsatz grafischer Elemente.
Die Entwicklung der grafischen Benutzeroberfläche (GUI) wurde mittels Microsoft
Foundation Classes (MFC) realisiert. Diese beinhalten eine Sammlung von objektorientierten
Klassenbibliotheken und ermöglichen dem Programmierer vereinfachten Zugriff auf niedere,
zur Erstellung von grafischen Elementen notwendige, System–APIs [WIMFC05].
Die Implementierung der grafischen Komponente dient dem Zweck Benutzereingaben
entgegenzunehmen und Systemausgaben zu visualisieren und ist der Logik des Programms
kaum dienlich. In den folgenden Ausführungen wird auf wesentliche, für das Verständnis des
Programms wichtige Implementierungsaspekte eingegangen. Da die MFC-Programmierung
für das Thema der Arbeit lediglich aus gestalterischer Sicht von Interesse ist, wird
diesbezüglich auf detaillierte Kommentare verzichtet.
Bei den Quelltext–Listings wurde darauf geachtet, logisch zusammenhängende und
ausführlich kommentierte Befehlssequenzen aufzubereiten. Die Deklarationen wichtiger
Variablen
und
Header–Dateien,
sowie
eingebundene
Bibliotheksmodule
werden
vorangestellt um die praktische Verwertbarkeit zu garantieren. Der komplette Quelltext der
entwickelten „WLANConnector“–Anwendung für Pocket PC 2003 ist auf der beigefügten
CD–ROM zu finden.
5.4
Grundlegende Konzipierungsüberlegungen
Die Erkenntnis, das die komplette systeminterne Verbindungsverwaltung über den
ausführlich diskutierten Connection Manager abgehandelt wird, legte die Vermutung nahe,
dass WLAN–Verbindungen mittels der im Betriebssystem Pocket PC 2003 SDK integrierten
Connection Manager–APIs definiert und aktiviert werden können [PPCDG05].
Bei der Auseinandersetzung mit diesem Befehlssatz wurde jedoch deutlich, dass diese
Funktionssammlung für unser primäres Ziel kaum von Nutzen sein kann. Innerhalb des
Connection Managers, welcher sowohl Einwählverbindungen über Modem oder serielle
Schnittstellen
verwaltet
und
diese
Verbindungen
generell
zwei
verschiedenen
Anwendungsbereichen, nämlich „Internet“ oder „Firmennetzwerk“ zuordnet, erfolgt die
Verbindungskonfiguration auf sehr abstrakter Ebene.
5
www.symbolictools.de/public/pocketconsole/index.htm#download
www.symbolictools.de/public/pocketconsole/applications/cmd/index.htm
7
http://www.symbolictools.de/public/pocketconsole/applications/nettools/index.htm
6
- 21 -
Dabei kommt einer untergeordneten Instanz, welche als unabhängiges Modul in den
Connection Manager eingebunden ist, die Steuerung der WLAN–Komponenten zu.
5.5
Die Wireless Zero Configuration
Diese Instanz ist als Wireless Zero Configuration bekannt. Dieser systemeigene Dienst dient
der Konfiguration von drahtlosen Netzwerken auf den meisten Windows–Systemen und ist
für
das
Verhalten
bei
der
Erkennung
von
WLAN–Netzen
sowie
bei
der
Verbindungsherstellung zu selbigen verantwortlich.
Ein Implementierungsbeispiel der Wireless Zero Configuration, geschrieben in C++, kann
dem Windows CE.NET 4.2 Platform Builder8 entnommen werden. Bei Windows 2000 oder
Windows XP wird die WZC in einer Liste von verfügbaren Diensten innerhalb des
Dienstemanagers geführt und kann hier explizit gestartet oder gestoppt werden.
Bei deutschsprachigen Betriebssystemsversionen lautet die entsprechende Bezeichnung
"Konfigurationsfreie drahtlose Verbindung". Hersteller von WLAN–Adaptern schaffen mit
alternativer, individueller Konfigurationssoftware eine Möglichkeit der benutzerfreundlicheren
Installation ihrer WLAN–Karte, in einigen Fällen mit Hilfe von Assistenten, welche durch den
Einrichtungsvorgang führen. Der Einsatz dieser Programme ist erfahrungsgemäß nicht
immer intuitiv und empfehlenswert. Eingerichtete Verbindungen werden in manchen Fällen
bei einem Neustart des Rechners nicht automatisch wiederhergestellt und benötigen erneute
Aufmerksamkeit. Dieses Konfigurations–Utility, das bei der Integration der meisten WLAN–
Adapter optional installiert werden kann, ersetzt und beendet die WZC und stellt deren
"Starttyp" auf "manuell" um.
Angesprochenes Vorgehen ist in jedem Falle erforderlich, wenn mittels Fremdsoftware
manipulativ auf die WLAN–Adapterkonfiguration zugegriffen wird, und dient der Vermeidung
von internen Komplikationen [WRAPI05]. Da das Betriebssystem Pocket PC 2003, welches
auf dem HP iPAQ beheimatet ist, keinen Dienstmanager kennt, kann das Starten des
Dienstes wie folgt unterbunden werden: Ein Eintrag in der Windows CE Registrierung
verweist auf die Dynamic Link Library namens „WZCSVC.dll“, welche die Implementierung
des
WZC–Dienstes
verkörpert.
Ändert
man
diese
Zeichenkette,
welche
im
Registrierungspfad "HKEY_LOCAL_MACHINE\Drivers\BuiltIn\ZeroConfig" zu finden ist,
geringfügig um und führt einen Systemneustart durch, so kann die DLL nicht mehr gefunden
werden. Der Dienst wird folglich nicht gestartet und der Connection Manager für die
Konfiguration von WLAN–Verbindungen unbrauchbar [PPCDF05].
8
www.microsoft.com
- 22 -
Screenshot 5.1 : WZC–DLL in der Windows CE Registrierung
Es empfiehlt sich den Dienst bei der ersten Initialisierung der Anwendung zu beenden. Der
Aufruf der entwickelten „disableWZC“–Funktion9 wurde innerhalb der OnInitDialog–
Funktion10 der MFC–Anwendung platziert. Dies bewirkt das Abarbeiten der Befehlssequenz
bei der Initialisierung des Basisdialoges. Programmatisch wird dies durch folgende
Implementierung erreicht:
1
#include <Winreg.h>
2
3
void disableWZC()
4
{
5
HKEY hKey = NULL;
6
DWORD dwDisposition = 0;
7
CString wzc = _T("WZCSVC.dllx");
8
9
RegCreateKeyEx(
10
HKEY_LOCAL_MACHINE,
11
_T("Drivers\\BuiltIn\\ZeroConfig"),
12
0,
13
NULL,
14
0,
15
KEY_EXECUTE|KEY_READ|KEY_ALL_ACCESS,
16
NULL,
17
&hKey,
18
&dwDisposition );
19
20
21
22
9
WLANConnector – IpSwapper.cpp
WLANConnector – WLANConnectorDlg.cpp
10
- 23 -
23
24
RegSetValueEx (
25
hKey,
26
TEXT ("Dll"),
27
0,
28
REG_SZ,
29
(LPBYTE)(LPCTSTR)wzc,
30
_tcslen(wzc)*2+1);
31
}
LISTING 5.1 : Deaktivieren der Wireless Zero Configuration
11
Bei Beendigung der Anwendung sollte die Ausgangssituation wiederhergestellt werden um
bei Bedarf die volle Funktionalität des Connection Managers zu reaktivieren. Diese resultiert
aus
der
Abarbeitung
der
oben
dargestellten
Befehlssequenz
mit
der
DLL–
Originalbezeichnung.
So lange das System mit der Individualkonfiguration arbeitet ergibt sich bei erneutem
Ausführen der Anwendung keine Änderung, da die Originaleinstellungen erst mit einem
Neustart des Gerätes übernommen werden.
Sind die Vorkehrungen für die erfolgreiche Manipulation der WLAN–Adapter durch
Deaktivierung des WZC–Dienstes getroffen können die eigentlichen Gerätezugriffe
angegangen werden.
5.6
Das
NDIS-Benutzermodus-E/A-Protokoll (NDISUIO)
NDIS-Benutzermodus-E/A-Protokoll
(NDISUIO)
ermöglicht
Netzwerkadapter–
manipulationen durch Anwendungen auf Benutzerebene.
In diesem Kapitel werden NDISUIO–Implementierungsgrundlagen vermittelt, die Einordnung
dieser
Protokollzugriffe
innerhalb
der
Windows
802.11–Netzwerktreiber–Architektur
beleuchtet und ein zu wissenschaftlichen Zwecken frei nutzbares Softwaremodul vorgestellt,
welches den praktischen Einsatz dieser Hardwareschnittstellen an Hand von Quelltexten
demonstriert.
5.6.1
802.11–Netzwerktreiber–Architektur
Der so genannte Miniport–Treiber oder MAC–Treiber agiert auf hardwarenähester Ebene
und ist für eine Reihe von elementaren Aufgaben konzipiert. Er leistet die Weiterleitung von
Paketen an die Netzwerkadapterhardware zur physikalischen Übertragung. Er ruft Pakete
ab, welche von der WLAN–Adapterhardware empfangen werden, verwaltet Interrupts und ist
11
- 24 -
für die Durchführung von Hardware–Kontrolloperationen dienlich. Der Miniport–Treiber
kommuniziert mit dem so genannten Intermediate–Treiber, welcher auf einer höheren Ebene
Schnittstellen für Protokolltreiber zur Verfügung stellt um den Adapter zu konfigurieren und
um Pakte über das Netzwerk zu senden und zu empfangen.
Abbildung 5.1 : Windows 802.11 Netzwerktreiber–Architektur
12
Ein solcher Protokoll–Treiber ist das NDIS–Benutzermodus–E/A–Protokoll (NDISUIO). Über
die Network Driver Interface Specification, kurz NDIS, werden Schnittstellen zwischen
Miniport–Treiber, Intermediate–Treiber und Protokoll–Treiber definiert. Der Intermediate–
Treiber übernimmt dabei eine vermittelnde Position [WPDN03].
Da das NDIS–Interface sowohl den Miniport–Treiber als auch den Intermediate–Treiber
umschließt, wird oft von einem NDIS Wrapper (Hülle) gesprochen. Erste Versionen der
Network Driver Interface Specification wurden in Zusammenarbeit von Microsoft und 3COM
proprietär für alle gängigen Windows–Systeme entwickelt [WINDIS05].
Um grundsätzliche 802.11–Dienste zu unterstützen werden eine Reihe von NDIS Object
Identifiern (OIDs) definiert, welche über NDISUIO Zugriff auf den Miniport–Treiber
ermöglichen. Mit Hilfe dieser OIDs können Informationen ausgelesen werden und
Adapterkonfigurationen vorgenommen werden, mit welchen es möglich ist, WLAN–
Verbindungen zu konkretisieren und Verbindungen aufzubauen. Dabei wird ein fest
vorgegebenes Verhalten auf physikalischer Ebene vorausgesetzt [WPDN203].
12
www.filseclab.com/eng/products/sourcetech.htm
- 25 -
5.6.2
Implementierungsaspekte
Im Folgenden wird zunächst auf allgemeine Implementierungsaspekte im Umgang mit den
NDIS–APIs eingegangen, welche sowohl für den Ad–Hoc–Modus sowie für den
Infrastruktur–Modus gelten. Des Weiteren schließt sich eine gesonderte Betrachtung der
beiden Infrastruktur–Modi an, in welcher verbindungsspezifische Anforderungen für den
Betrieb im KFZ in den Vordergrund gerückt werden.
Da bei der Softwareentwicklung gesteigerter Wert auf Modularität gelegt wurde, erfolgte die
Implementierung der Adapterzugriffe über NDISUIO in der Klasse DeviceControl13. Die
„DeviceControl“–Klassenfunktionen „setAdHoc“ und „setInfrastructure“ versetzen das
WLAN–Netzwerkinterface
in
die
jeweilige
Verbindungsbereitschaft
und
werden
in
unterschiedlichen Kontexten der MFC–Anwendung aufgerufen.
Die Basis für den Zugriff auf einen Gerätetreiber bildet die Erzeugung einer abstrakten
Referenz auf ein Datenobjekt, genannt Handle, welche typisiert und mit entsprechenden
Zugriffsrechten versehen werden muss. Diese Datei fungiert als Stellvertreter oder Proxy
und wird unter Windows CE vorläufig noch nicht konkretisiert. Es wird lediglich festgelegt,
dass es sich um einen NDIS fähigen Protokolltreiber handelt [MSDN05].
Listing 5.1 zeigt eine Implementierungsvariante um das Handle „m_hDeviceHandle“ zu
erzeugen.
1
DWORD m_dwBytesReturned = 0;
2
bool
retval;
3
4
HANDLE m_hDeviceHandle = CreateFile(
5
NDISUIO_DEVICE_NAME,
6
GENERIC_READ | GENERIC_WRITE,
7
FILE_SHARE_READ | FILE_SHARE_WRITE,
8
NULL,
9
OPEN_EXISTING,
10
FILE_ATTRIBUTE_NORMAL| FILE_FLAG_OVERLAPPED,
11
(HANDLE)INVALID_HANDLE_VALUE
12
);
14
LISTING 5.2 : Erzeugung eines NDISUIO Handles
Um hardwareorientierte Operationen auf einem Gerät auszuführen wird mit Hilfe der
DeviceIoControl–API aus der „Winbase.h“ ein Kontrollcode und dessen Spezifizierung in
Form eines Datenpuffers an den Gerätetreiber weitergegeben.
Zur Anwendung kommen zwei Gerätekontrollcodes, oder IOCTLs (Ein–/Ausgabekontrolle):
Die IOCTL–Struktur „IOCTL_NDISUIO_SET_OID_VALUE“ wird zur Konfiguration verwendet
und
13
14
„IOCTL_NDISUIO_QUERY_OID_VALUE“
WLANConnector – DeviceControl.cpp
WRAPIb2.0 – WRAPI.cpp
- 26 -
zum
Auslesen
eines
angeforderten
Datenpuffers [MSDN05]. Diese und weitere IOCTL–Strukturen sind in der „nuioser.h“15
definiert. Der bei diesen Befehlen übertragene Datenpuffer birgt nun den gewünschten NDIS
Object Identifier (OID) in sich.
Da es sich bei der DeviceIoControl–Funktion16 um eine recht dominante und redundante
Operation bei der Interaktion mit dem Miniport–Treiber handelt, möchte ich im Folgenden
näher auf die benötigten Parameter und ihre Datentypen eingehen:
1
BOOL DeviceIoControl(
2
// Der Rückgabewert als Boolean: Bei erfolgreicher Ausführung die '0'
3
HANDLE hDevice,
4
// Handle/Verweis auf das Zielgerät – Erzeugung mittels CreateFile()
5
DWORD dwIoControlCode,
6
// Der IOCTL–Kontrollcode: IOCTL_NDISUIO_SET_OID_VALUE oder
7
// IOCTL_NDISUIO_QUERY_OID_VALUE
8
LPVOID lpInBuffer,
9
// Long–Zeiger auf den Datenpuffer, welcher die OID beinhaltet
10
DWORD nInBufferSize,
11
// Größe des Eingabepuffers in Bytes
12
LPVOID lpOutBuffer,
13
// Long–Zeiger auf den Ausgabepuffer bei "IOCTL_NDISUIO_QUERY_OID_VALUE"–Operationen
14
DWORD nOutBufferSize,
15
// Grösse des Ausgabepuffers in Bytes
16
LPDWORD lpBytesReturned,
17
// LongPointer auf eine Variable, welche die Grösse der Datenmenge im Ausgabepuffer
18
LPOVERLAPPED lpOverlapped
19
// Wird ignoriert und mit NULL festgesetzt
20
);
LISTING 5.3 : DeviceIOControl inklusive typisierter Parameter [MSDN05]
Die NDIS–OIDs werden innerhalb eines betriebssystemsspezifischen Header–Files mit der
Bezeichnung "ntddndis.h" konkretisiert. Es handelt sich hierbei um eine Liste von Define
Befehlen, welche eine textuelle Ersetzung der OID–Bezeichnung durch ein 32–Bit Datenwort
in hexadezimaler Darstellung vornehmen.
1
#define OID_GEN_HARDWARE_STATUS
LISTING 5.4 : Beispiel für die Definition einer NDIS–OID
0x00010102
17
„nuioser.h“ und „ntddndis.h“ müssen im Quellcode inkludiert sein um mit den NDIS User
Mode I/O Protocol arbeiten zu können [WPDN203].
15
nuioser.h - Pocket PC 2003 SDK
winbase.h – Embedded Visual Studio 4
17
ntddndis.h – Pocket PC 2003 SDK
16
- 27 -
5.6.3
Wireless Research API18 (WRAPI)
Bei der Wireless Research API, welche 2002 von der University of California entwickelt
wurde, handelt es sich um eine Softwarebibliothek, welche es Programmierern ermöglicht
Konfigurationen von 802.11–Netzwerkadaptern auszulesen und diese zu konfigurieren.
Die komplette Implementierung basiert auf NDISUIO–Protokollzugriffe und kann als DLL in
eigenen C++ Quellcode integriert werden.
WRAPI wurde explizit für den Einsatz unter Windows XP entwickelt. Da NDISUIO auf dem
NDIS 5.1 Standard arbeitet, wird weitgehende Hardwareunabhängigkeit erreicht. Der
Quellcode ist frei zugänglich und kann zu wissenschaftlichen Zwecken nach Belieben
genutzt und abgeändert werden. Das vorgefundene Softwaregerüst war eine große Hilfe bei
der Erstellung der entwickelten Software und ermöglichte einen konkreten Einblick in die
abstrakte NDIUIO–Funktionalität.
So
konnten
benötigte
Variablendeklarationen
weitgehend
übernommen
und
den
Anforderungen entsprechend angepasst werden. Die enthaltenen Funktionen wurden
ausgewertet und softwareintern verarbeitet.
Hierbei muss berücksichtigt werden, dass die einzelnen Funktionen an sich lediglich
einzelne Ausprägungen der 802.11–Adapterkonfiguration auslesen oder konkretisieren. Erst
durch die Verwendung im richtigen Kontext wird ein verwertbares Ergebnis erzielt.
Weiterhin musste der untersuchte Quelltext auf die Eigenheiten des Betriebssystems Pocket
PC 2003 angepasst werden. Kapitel 8 geht daher speziell auf die Besonderheiten unter
Windows XP ein.
Das komplette WRAPIb2.0–Projekt liegt der angefügten CD–ROM bei.
18
http://sysnet.ucsd.edu/pawn/wrapi/
- 28 -
6. WLAN–Verbindungsaufbau im Ad–hoc–Szenario
6.1
IP–Adressen–Problematik und Lösung
Die reine Verbindungsherstellung auf physikalischer / DataLink Ebene reicht für eine
praktikable Anwendung noch nicht aus. Es muss weiterhin ein Protokoll definiert und an den
Adapter gebunden werden.
Folgende Anforderungen müssen an die TCP/IP–Konfiguration gestellt werden: Die IP–
Adressen der Netzwerkadapter müssen in einem kompatiblen Netzwerksegment liegen,
dürfen jedoch nicht identisch sein.
Weiterhin muss die Möglichkeit gegeben sein die Netzwerkadresse der verbundenen Geräte
zu verbreiten und untereinander weiterzugeben. Da die IP–Problematik elementarer
Bestandteil des automatisierten Verbindungsaufbaus im KFZ ist, muss auch sie
automatisiert und softwaregesteuert gelöst werden.
6.1.1
Bewertung konventioneller Verfahren zur IP–Adressvergabe
IP–Adressen werden generell auf zwei Arten zugewiesen: Entweder man trägt diese
inklusive Subnetzmaske und Gateway im entsprechenden Netzwerkkonfigurationsdialog ein
oder man wählt die
Konfiguration über einen DHCP–Server. Legt man sich auf das
dynamische Zuweisungsverfahren fest und wird kein entsprechender Dienst im Netzwerk
angeboten, würde dem Adapter keine funktionelle Adresse zugewiesen.
Die meisten Windows–Systeme gehen auf diese Problematik ein, indem sie auf eine so
genannte Auto–IP zurückgreifen. Hierbei handelt es sich um eine in der Registrierung
abgelegte
IP–Adresse
aus
einem
speziell
festgelegten
Netzwerksegment.
Dieses
„Automatic Private IP Addressing“ (APIPA) genannte Verfahren vergibt Adressen aus dem
Bereich von 169.254.0.0 bis 169.254.255.255, welcher sich bei einer Subnetzmaske von
255.255.0.0. ergibt [AWAP02].
Obwohl diese Automatisierung einen brauchbaren Ansatz für die Lösung der entstandenen
IP Problematik bietet, erweist sich die enorme Anzahl potentieller Zuweisungen als
nachteilig. Die Tatsache, dass Verbindungen innerhalb TCP/IP–Netzwerken mit Hilfe des
bekannten „ping“–Programms überprüft werden können, führte zu der Idee eines
Netzwerkscans mittels ICMP–Echo–Requests. Kann dieser Befehl unter Verwendung der zu
verifizierenden IP–Adresse erfolgreich ausgeführt werden so kann auf einen erfolgreichen
Verbindungsaufbau
geschlossen werden.
Ein
solcher
Scan wäre bei
65025 zu
überprüfenden Möglichkeiten grenzenlos überfordert und würde eine enorme, nicht zu
tolerierende Zeitspanne benötigen. Identische Adresszuweisungen werden per Address
Resolution Protocol (ARP) verhindert [AWAP02]. Dennoch spricht Einiges für die
- 29 -
WLAN–Verbindungsaufbau im Ad–hoc–Szenario
Verwendung der Auto–IP Option: Da die IP–Adresse bei Betrieb im Infrastruktur–Modus per
DHCP geschieht, ist keinerlei Modifizierung der Einstellungen nötig. Der Protokoll–Treiber
erkennt den entsprechenden Service, ignoriert die Auto–IP Einstellungen und bezieht die
Adresse dynamisch. Doppelte Zuweisungen können hier prinzipiell ausgeschlossen werden.
Des Weiteren kann programmatisch eine neue Adresse angefordert werden.
Über die Konsole geschieht dies über die Eingabe von „ipconfig /renew“ [MSDN05]. Aus
dieser Erkenntnis entstand die Idee, die IP–Adresse als „Auto–IP“ in die Registrierung zu
schreiben und dann eine erneute Zuweisung zu erzwingen. Die Werte werden hierbei
innerhalb einer überschaubaren Spanne zufällig generiert. Ihre Eindeutigkeit wird überprüft
und sichergestellt.
6.1.2
Abwandlung von APIPA durch Registrierungsmanipulation
IP–Adressen
können
aus
praktischer
Erfahrung
in
der
Registrierung
für
jeden
Netzwerkadapter separat festgelegt werden.
Hier wird eine Sammlung von Konfigurationsparametern verwaltet und persistent abgelegt.
Diese Erkenntnis macht sich die erstellte Anwendung zu Nutzen, indem, mittels aus der
Deaktivierung des WZC–Dienstes bekannten Befehlen, entsprechende Werte in die
Registrierung eingetragen werden.
Dieses Vorgehen wurde zunächst im Registrierungseditor getestet. Screenshot 6.1 zeigt
rotumrandet alle Parameter, welche für die automatisierte Adresszuweisung über das
APIPA–Verfahren relevant sind.
Während in Screenshot 6.1, Ausschnitt 1, die über die automatisierte IP–Adressvergabe
zugewiesenen Werte spezifiziert werden, definieren die Werte aus Ausschnitt 2 die Art der
Zuteilung.
Der boolesche Wert 1 im Wertefeld „EnableDHCP“ aktiviert die dynamische IP–
Adresszuweisung
über
„DhcpDefaultGateway“,
einen
DHCP–Server,
„DhcpServer“,
welcher
„DhcpSubnetMask“
durch
und
die
Felder
„DhcpIPAddress“
konkretisiert wird.
Ist im Wertefeld „AutoCfg“ eine 1 eingetragen, so wird die IP–Konfiguration aus Ausschnitt 1
angewandt. Hierbei nimmt die „DhcpIPAddress“ den im „AutoIP“–Feld eingetragenen Wert
an, welcher der letztendlich zuzuweisenden Adresse entspricht. Die Adressspezifikation des
DHCP Servers nimmt mit der 255.255.255.255 („DhcpServer“) und der Subnetzmaske
(„DhcpSubnetMask“) 255.255.255.0 einen für den Broadcast typischen Wert, was lediglich
bedeutet das dieser unbekannt ist und nicht spezifiziert wird.
- 30 -
Screenshot 6.1 : Definition der "WZC"–DLL in der Windows CE – Registrierung
Zunächst wird mittels Random–Befehl19 eine Zufallszahl generiert. Über den Modulo–
Operator wird ein möglicher Wertebereich von 0 bis 30 erzwungen (Listing 6.1, Zeile 3). Es
gibt also 30 mögliche verschiedene IP–Adressen, welche dem Netzwerkadapter zugewiesen
werden können. Dieser Wert wurde gewählt, da die Wahrscheinlichkeit, dass zwei
Netzwerkadapter identisch adressiert werden recht gering (p = 0,03) und die Anzahl der im
schlechtesten Falle zu durchlaufenden Scan–Vorgänge in einem überschaubaren Rahmen
bleibt. Die Zahl 0 wird über die Addition der 1 bewusst ausgeklammert, da die 0 an letzter
Stelle das komplette Subnetz definiert.
1
int CIpSwapper::createIp()
2
{
3
int checkIp = Random()%30+1;
4
return checkIp;
5
}
20
LISTING 6.1 : Generierung einer Zufallszahl für letztes Segment der IP–Adresse
19
20
- 31 -
Der generierte Zufallswert ist vom Datentyp Integer und ist Rückgabewert der createIP–
Funktion21. Dieser wird im Hauptdialog als Parameter an die folgende Funktion „swapIp“22
weitergereicht, welche nun die Manipulation der entsprechenden Registrierungseinträge
vornimmt. Ziel ist die Vergabe einer IP–Adresse aus der Spanne von 192.168.1.1 bis
192.168.1.31. In Zeile 9 des Listings 6.2 wird der übergebene Wert an den statischen Teil
der IP–Adresse angefügt und bildet die zu manifestierende String–Zuweisung. Wie aus
Screenshot 6.1 ableitbar, müssen alle Werte welche die Auto–IP spezifizieren an die
entsprechende Stelle in der Registrierung geschrieben werden.
Dabei handelt es sich um die IP–Adresse („Auto–IP“) an sich, das verwendete Subnetz
(„AutoSubnet“) und die Subnetzmaske („AutoMask“).
1
void CIpSwapper::swapIp(int j)
2
{
3
HKEY hKey = NULL;
4
DWORD dwDisposition = 0;
5
DWORD dwSizeIp=13;
6
DWORD dwSizeSub=12;
7
DWORD dwSizeMask=14;
8
CString ip;
9
ip.Format(_T("192.168.1.%d"),j);
10
CString subnet = _T("192.168.1.0");
11
CString mask = _T("255.255.255.0");
12
CString dhcpip = ip;
LISTING 6.2 : Deklaration der Variablen innerhalb der swapIP–Funktion
Die Funktion RegCreateKeyEx23 erstellt einen neuen spezifizierten Key oder öffnet ihn, falls
dieser bereits existiert.
Der erste Parameter (Listing 6.2, Zeile 3) repräsentiert ein Handle (Verweis) auf einen
eigens zu spezifizierenden Hauptschlüssel oder einen vordefinierten Eintrag, in unserem Fall
HKEY_LOCAL_MACHINE, welcher konfigurationsspezifische Daten des Rechners enthält.
Der zu öffnende oder zu erstellende Key ist diesem untergeordnet. Der Begriff Key bezieht
sich hierbei auf einen Pfad innerhalb einer dateisystemsähnlichen Ordnerstruktur und ist
nicht mit den darin enthaltenen Werten zu verwechseln.
Es
sei
angemerkt,
dass
der
Registrierungspfad
(Listing
6.3,
Zeile
3)
„Comm\\vnetusba1\\Parms\\TCPIP” nicht allgemein gültig ist.
Der Parameter „vnetusba1“ steht konkret für die in HP iPAQ 5500 integrierten WLAN–
Adapter. Soll die Anwendung für andere Adapter angepasst werden, so muss die
Bezeichnung dynamisch ausgelesen werden. Dies kann mit geeigneten NDISUIO–APIs
geschehen (Kapitel 8.2).
21
23
Winreg.h – Embedded Visual Studio 4
22
- 32 -
Das auf der beiliegenden CD enthaltene Programm „ndistools2003“24 liest ebenfalls die
Bezeichnungen von aktiven an das NDISUIO–Protokoll gebundenen WLAN–Adaptern auf
Pocket PC 2003 Systemen aus und kann bei der Verifizierung von Ergebniswerten
Verwendung finden.
1
RegCreateKeyEx(
2
HKEY_LOCAL_MACHINE,
3
_T("Comm\\vnetusba1\\Parms\\TCPIP"),
4
5
0,
NULL,
0,
6
KEY_EXECUTE|KEY_READ|KEY_ALL_ACCESS,
7
NULL,
8
&hKey,
9
&dwDisposition );
LISTING 6.3 : Erstellen oder Öffnen eines Registry Keys
In Zeile 8 der RegCreateKeyEx–Funktion (Listing 6.3) wird ein Zeiger auf eine Variable
gesetzt, welche das Handle auf den geöffneten Key empfängt.
Dieses Handle findet nun in der RegSetValueEx–Methode verwendung, indem es den
Schlüssel spezifiziert, in welchem ein Wertefeld manipuliert oder erstellt wird. Listing 6.4
erläutert das Verfahren an der Veränderung des Datenfeldes mit der in Zeile 3 definierten
Bezeichnung „AutoIP“.
Der Zeiger auf den Datensatz, welcher an die angegebene Stelle geschrieben werden soll,
wird in Zeile 6 parametrisiert. Hierbei wird die Zeichenkette aus der Initialisierung der
Variablen „ip“ (Listing 6.2, Zeile 8) zu einem entsprechenden Datentyp gecastet, was einer
Neuinterpretation des Datensatzes entspricht. Beachtung muss hierbei der Informationstyp
des Datensatzes finden. In Zeile 5 des Listings 6.4 wird dieser in konkretisiertem Falle als
REG_SZ Wert festgelegt, was einer null terminierten Unicode–Zeichenkette entspricht.
1
RegSetValueEx (
2
hKey,
3
TEXT ("AutoIP"),
4
0,
5
REG_SZ,
6
(LPBYTE)(LPCTSTR)ip,
7
_tcslen(ip)*2+1);
LISTING 6.4 : Schreiben der AutoIP–Variablen in CE Registrierung
24
www.pcausa.com/Utilities/ndistools.htm
- 33 -
Das Schreiben der Werte für „AutoSubnet“, „AutoMask“ und „DhcpIPAddress“ erfolgt starr
nach diesem Muster und wird deshalb im Weiteren nicht näher beschrieben. Es ist lediglich
die Zeichenkette in Zeile 3 des Listings 6.4 entsprechend abzuändern.
Wird das Handle auf den geöffneten Registrierungsschlüssel nicht mehr gebraucht, sollte es
durch den RegCloseKey–Befehl wieder freigegeben werden (Listing 6.5) [PPCDA05]. Dies
bewirkt das Aufheben einer Zugriffssperre und erlaubt Manipulation durch andere Prozesse.
1
RegCloseKey(hKey);
LISTING 6.5 : Freigabe des Handles auf einen geöffneten Key[PPCDA05]
Die IP–Adresse des WLAN–Adapters im Ad–Hoc Modus
ist somit eindeutig festgelegt,
jedoch noch nicht aktiv übernommen. Bevor dies in die Tat umgesetzt werden kann wird
zunächst der eigentliche Verbindungsaufbau in die Wege geleitet.
6.1.3
IP–Adresszuweisung mittels IP–Helper–Funktionen
Die nun folgenden Operationen basieren auf einer Microsoft Bibliotheksdatei namens
„iphlpapi.lib“25, welche die Verwendung der Internet Protocol Helper API ermöglicht.
Diese Funktionen stehen dem Anwendungsentwickler innerhalb der zu inkludierenden
Headerdatei „Iphlpapi.h“ zur Verfügung und unterstützen das Auslesen von Informationen
über lokale Netzwerkadapter. Weiterhin dienen sie der Modifizierung der IP–Konfiguration
[MSDN05].
Im Fokus steht die Verwaltung von IP–Adressen auf dem WLAN–Adapter. Es geht darum,
die in der Registrierung abgelegte IP–Konfiguration über die DHCP–Adresszuweisung an
das entsprechende Device zu binden und somit für die Netzwerkommunikation über das
TCP/IP–Protokoll zu aktivieren.
Über die Funktion IpRenewAddress aus der „iphlpapi.lib“ „mietet“ sich der Netzwerkadapter
eine für ihn bereitgestellte Adresse von einem DHCP–Server. Dieses Verfahren wird in
entwickelter Software dazu eingesetzt, eine bereits in der lokalen Registrierung angelegte
IP–Konfiguration über Automatic Private IP Addressing (APIPA) umzusetzen.
Ein frei verfügbares Programm namens „MyIpConfig“26, welches auf beigelegter CD als
Executable und im Quelltext abgelegt wurde, arbeitet mit dieser Bibliothek und wurde zu
einer Wrapperklasse umgeschrieben und an die konkreten Anforderungen angepasst. Die
angepasste Klasse „CIpHelper“27 wurde in das „WLANConnector“ Embedded Visual Studio
Projekt eingebunden.
25
iphlpapi.lib – Embedded Visual Studio 4
http://sourceforge.net/projects/myipconfig
27
WLANConnector – IpHelper.cpp
26
- 34 -
Die
enthaltene
renew–Funktion28
wird
nach
erfolgtem
WLAN–Verbindungsaufbau
aufgerufen. Dies macht Sinn, da sich der Adapter erst im Ad–hoc Modus auf die
Verwendung des APIPA–Verfahrens einstellt.
Da der Adapter eine kurze Zeitspanne zur Verbindungsherstellung im Ad–hoc–Modus
benötigt, wurde die Programmausführung über die Sleep–Funktion29 um drei Sekunden
verzögert.
30
In Zeile 6 des Listings 6.6 werden durch die GetAdaptersInfo–Funktion
verfügbare
Netzwerkadapter enumeriert und in einem Array von IP_ADAPTER_INFO–Strukturen31
verwaltet. Diese Strukturen enthalten Informationen wie den Namen des Adapters,
Beschreibung, IP–Adresse, Gateway, DHCP Server Adresse usw.
Die find–Funktion aus Zeile 7 weist der Variablen „a“ vom Typ „IpAdapter“ den WLAN–
Adapter mit Namen „VNETUSBA1“ zu, auf welchem in Zeile 11 die IpRenewAddress–
Operation durchgeführt wird.
Der Übergabeparameter dieser Funktion ist eine vorgegebene Zeitspanne in Sekunden, in
welcher die Adresszuweisung abgeschlossen werden muss. Wird dieser Wert überschritten
wird die Operation abgebrochen und ein Fehlercode zurückgegeben.
1
CString CIpHelper::renew()
2
{
3
IpAdapter
currentAdapter;
4
IpAdapters*
pAdapterInfo;
5
6
pAdapterInfo = IpAdapters::GetAdaptersInfo();
7
IpAdapter a = pAdapterInfo–>find("VNETUSBA1");
8
9
Sleep(3000);
10
11
a.IpRenewAddress(3);
12
}
LISTING 6.6 : IpRenewAddress – Internet Protocol Helper API
28
WLANConnector – IPHelper.cpp
30
WLANConnector – IpHelper.cpp
31
iptypes.h – Embedded Visual Studio 4
29
- 35 -
6.2
Der
Ad–hoc–Adapterkonfiguration über NDISUIO
Verbindungsaufbau
innerhalb
der
ersten
zwei
Schichten
des
OSI
Kommunikationsmodells wird mittels der in Kapitel 5.6.2 erläuterten NDISUIO–Operationen
durchgeführt.
IOCTL–Kontrollnachrichten
werden
innerhalb
der
angesprochenen
DeviceIoControl–Befehle an den Adapter weitergeleitet und versetzen das WLAN–Device in
den gewünschten Zustand auf hardwarenaher Ebene.
Nachdem, wie in Kapitel 5.6.2 dokumentiert, ein Device–Handle erzeugt und an das
NDISUIO–Protokoll gebunden wird, können die Network Driver Interface Specification Object
Identifier geschrieben werden. Es ist dabei von der Hardware der WLAN–Adapter abhängig,
welche OID–Varianten unterstützt werden.
Jede dieser OIDs bewirkt eine in sich gekapselte Konfigurationsänderung. Die folgende
Auflistung der Vorgänge und der dazugehörigen OIDs erläutert die Reihenfolge, welche bei
der Implementierung Verwendung fand.
Es zeigte sich, dass lediglich das Schreiben der SSID die abschließende Operation sein
sollte, da mit dieser Aktion Änderungen übernommen werden und der Adapter einen
Verbindungsversuch in die Wege leitet [WPDN203].
• Setzen des Infrastrukturmodus
[OID_802_11_INFRASTRUCTURE_MODE]
• Setzen des Authentifizierungsmodus
[OID_802_11_AUTHENTICATION_MODE]
• Setzen des WEP Schlüssels (optional)
[OID_802_11_ADD_KEY]
• Aktivieren der WEP Verschlüsselung
[OID_802_11_ADD_WEP]
• Setzen der SSID / BSSID / IBSSID
[OID_802_11_SSID]
Î Adapter übernimmt Netzwerk Konfiguration
Um den Umgang mit den OIDs in den angeführten Quelltextauszügen zu verstehen macht
es Sinn, sich deren Struktur etwas näher zu betrachten.
In Zeile 7, Listing 6.7 wird eine Variable vom Typ PNDISUIO_SET_OID32 deklariert.
Die Variablenbezeichnung lässt darauf schließen, dass es sich hierbei um eine Struktur
handelt, welche schreibend, also konfigurierend, zugreift. Für Leseoperationen wird der
ebenfalls in der „nuiouser.h“ definierte Typ PNDISUIO_QUERY_OID verwendet.
Es handelt sich hier wieder um einen Datentyp, welcher untergeordnete Strukturen
umschließt und mit zusätzlichen Informationen versehen, in abstrakterem Kontext
weiterverwendet [MSDN05].
Wie der Strukturdefinition aus Listing 6.7 zu entnehmen ist, umschließt die
PNDISUIO_SET_OID–Struktur die Ausprägung des eigentlichen Object Identifiers vom Typ
NDIS_OID (Zeile 2).
32
nuiouser.h – Pocket PC 2003 SDK
- 36 -
Weiterhin ist ein Zeiger auf einen Datencontainer, welcher den Namen des zu
manipulierenden Gerätes entspricht (Zeile 4) und einen Puffer für OID–Werte und
Rückgabedaten (Zeile 6) beinhaltet.
Das ifdef aus Zeile 3 sagt aus, dass der Gerätename lediglich bei Windows CE und
Varianten zur Verfügung steht. Das Kapitel 9 geht näher auf diese Besonderheit ein.
1
typedef struct _NDISUIO_SET_OID {
2
NDIS_OID Oid;
3
#ifdef UNDER_CE
4
PTCHAR ptcDeviceName;
5
#endif
6
UCHAR Data[sizeof(ULONG)];
7
} NDISUIO_SET_OID,
LISTING 6.7 : Struktur NDISUIO_SET_OID
6.2.1
33
Setzen des Infrastrukturmodus
Der erste Konfigurationsvorgang bezieht sich auf die Spezifikation des Infrastruktur–Modus.
Betätigt man den Softbutton, welcher die Verbindungsbereitschaft im Ad–hoc–Modus
aktiviert, so wird die Funktion setAdhoc ausgeführt. Diese Methode ist der Klasse
„DeviceControl“ zugehörig und enthält alle NDISUIO–spezifischen Operationen. Alle nötigen
Netzwerkparameter sind in diese Funktion statisch integriert.
In den Zeilen 9 bis 11, Listing 6.8, wird die NDISUIO_SET_OID–Struktur gefüllt, welche in
Zeile 9 dem in den Zeilen 5 bis 6 reservierten Speicherplatz zugeordnet wird.
Die Zuweisung des Gerätenamens erfolgt in Zeile 10, wohingegen in Zeile 11 der Object
Identifier festgelegt wird.
In Zeile 14 und 15 wird der Wert der OID in den Datenpuffer kopiert. Dessen Ausprägung
entspricht bei Setzen des Infrastrukturmodus einem Integer Wert, welcher in Zeile 2
festgelegt wird.
Die Variablendeklaration Ndis802_11IBSS steht für das Independent Basic Service Set und
findet seine Wertezuweisung in der Header–Datei „ntddndis.h“. Mögliche Ausprägungen,
welche
die
OID_802_11_INFRASTRUCTURE_MODE–OID
Ndis802_11IBSS
für
die
Ad–hoc–Variante,
annehmen
Ndis802_11Infrastructure
kann
sind
für
den
Verbindungsaufbau zu einem AccessPoint und Ndis802_11AutoUnknown, was bedeutet,
dass der 802.11–Netzwerkadapter zwischen Ad–hoc und Infrastruktur je nach Bedarf
wechseln kann [MSDN05].
Die memcpy34–Funktion kopiert hierbei Binärdaten einer festgelegten Größe von einer durch
einen Zeiger definierten Speicheradresse zu einer anderen. Der erste Parameter steht für
33
34
nuiouser.h – Pocket PC 2003 SDK
stdlib.h – Embedded Visual Studio 4
- 37 -
die Zieladresse, der zweite Parameter für die Quelladresse, an welcher der zu kopierende
Datensatz abgelegt wird und der dritte Parameter bestimmt dessen Größe in Bytes
[MSDN05].
Über die DeviceIoControl–Funktion in Zeile 17 wird der bereits gefüllte Puffer an das durch
das Handle spezifizierte Device weitergegeben.
Eine Ausführliche Abhandlung des Befehles und seine Funktion innerhalb der NDISNetzwerktreiber-Architektur wurde in Kapitel 5.6.2 gegeben. Zur Vereinfachung des
Debuggens werden in Zeile 26 bis 30 Fehler bei der Ausführung der DeviveIoControl–
Funktion als Rückgabewert der „setAdhoc“–Methode35 ausgegeben.
1
int* pnNetworkMode;
2
int NMode = Ndis802_11IBSS;
3
pnNetworkMode = &NMode;
4
5
UCHAR SetBufferNetM[sizeof(NDIS_OID)+
6
sizeof(NDIS_802_11_NETWORK_INFRASTRUCTURE) + sizeof(DWORD)];
7
PNDISUIO_SET_OID
pSetOidNetM;
8
9
pSetOidNetM = (PNDISUIO_SET_OID) &SetBufferNetM[0];
10
pSetOidNetM–>ptcDeviceName = TEXT("VNETUSBA1");
11
pSetOidNetM–>Oid = OID_802_11_INFRASTRUCTURE_MODE;
12
13
14
memcpy(&pSetOidNetM–>Data[0],
15
pnNetworkMode,sizeof(NDIS_802_11_NETWORK_INFRASTRUCTURE));
16
17
retval = DeviceIoControl(m_hDeviceHandle,
18
IOCTL_NDISUIO_SET_OID_VALUE,
19
(LPVOID) &SetBufferNetM[0],
20
sizeof(SetBufferNetM),
21
(LPVOID) &SetBufferNetM[0],
22
0,
23
&m_dwBytesReturned,
24
NULL);
25
26
if(!retval)
27
{
28
DWORD m_dwError = GetLastError();
29
return ("Nach Ad–Hoc failed");
30
}
LISTING 6.8 : Setzen des Infrastrukturmodus auf Ad–hoc
35
36
WLANConnector – DeviceControl.cpp
Anpassung der WRAPIb2.0 – WRAPI.cpp
- 38 -
36
6.2.2
Setzen des Authentifizierungsmodus
Nachdem, nach Abarbeitung der obigen Befehlssequenz, die Ausprägung der Infrastruktur
festgelegt wurde, erfolgt im nächsten Schritt das Setzen des Authentifizierungsmodus
(Listing 6.9).
Die Implementierung kann hierbei fast identisch aus Listing 6.8 übernommen werden.
Das hier zu definierende Merkmal bestimmt die Art der Zugangskontrolle zu einem
Netzwerk, beispielsweise über einen RADIUS (Remote Authentication Dial–In User Service)
Server. Sicherheitsmaßnahmen innerhalb kabelloser Netzwerke wurden in Kapitel 2.5
erläutert und sind für diese Arbeit nur am Rande von Bedeutung.
Dennoch handelt es sich bei der Verwendung dieser OID um eine obligatorische
Maßnahme, ohne die kein Verbindungsaufbau eingeleitet werden kann.
Die Ausprägung der NDIS–OID OID_802_11_AUTHENTICATION_MODE über den Wert
Ndis802_11AuthModeOpen führt zur Verwendung eines Protokolls für Systeme ohne
weitere Zugangskontrolle und wurde in entwickelter Software eingesetzt.
Der Einsatz von WEP als Verschlüsselungsstandard wird hierbei nicht beeinflusst
[MSDN05].
1
int pnAuthMode = Ndis802_11AuthModeOpen;
2
UCHAR SetBufferAuth[sizeof(NDIS_OID) +
3
sizeof(NDIS_802_11_AUTHENTICATION_MODE)+sizeof(DWORD)];
4
PNDISUIO_SET_OID
pSetOidAuth;
5
6
pSetOidAuth = (PNDISUIO_SET_OID) &SetBufferAuth[0];
7
pSetOidAuth–>Oid = OID_802_11_AUTHENTICATION_MODE;
8
pSetOidAuth–>ptcDeviceName = TEXT("VNETUSBA1");
9
10
memcpy(&pSetOidAuth–>Data[0],
11
&pnAuthMode,sizeof(NDIS_802_11_AUTHENTICATION_MODE));
12
13
if (!DeviceIoControl(
14
m_hDeviceHandle,
15
16
(LPVOID) &SetBufferAuth[0],
17
sizeof(SetBufferAuth),
18
(LPVOID) &SetBufferAuth[0],
19
0,
20
&m_dwBytesReturned,
21
22
NULL))
{ DWORD m_dwError = GetLastError(); }
LISTING 6.9 : Setzen des Authentifizierungsmodus (Anpassung der WRAPI)
37
- 39 -
37
6.2.3
Setzen der SSID
Um den 802.11–Netzwerkadapter endgültig in den Ad–hoc–Modus zu versetzen wird der
Service Set Identifier des zu assoziierenden Netzwerkes an den Miniport–Treiber
weitergegeben.
Unabhängig von der Präsenz eines potentiellen Ad–hoc–Partners wird eine aktive Sende–
und Empfangsbereitschaft in die Wege geleitet. Dieses Verhalten liegt in der Natur eines
unabhängigen Netzwerkverbundes und unterscheidet sich maßgeblich von einem
Verbindungsversuch zu einem AccessPoint, bei welchem ein Statuswechsel von einem
verbindungslosen zu einem verbundenen Zustand nur bei Assoziation mit einem
entsprechend konfigurierten WLAN–Knoten stattfindet.
Die Ausprägung der OID_802_11_SSID wird in diesem Falle nicht durch einen ganzzahligen
Wert definiert, sondern über eine eigene Struktur namens NDIS_802_11_SSID.
Der Aufbau dieser Struktur sei in Listing 6.10 aufgeschlüsselt. Da die SSID durch eine
Zeichenkette von bis zu 32 Buchstaben gebildet werden kann, werden als Strukturelemente
zum einen das Unsigned Char Arrays, welches die Zeichenkette beinhaltet (Zeile 4), und
zum anderen dessen Länge (Zeile 3) benötigt.
1
typedef struct _NDIS_802_11_SSID
2
{
3
4
5
ULONG
SsidLength;
UCHAR
Ssid[32];
} NDIS_802_11_SSID, *PNDIS_802_11_SSID;
LISTING 6.10 : Struktur NDIS_802_11_SSID
38
In Zeile 12 wird eine Instanz dieser Struktur ins Leben gerufen, welcher in Zeile 18 die Länge
der SSID Zeichenkette und in Zeile 20 den Inhalt mit Hilfe des vertrauten memcpy–Befehls
(vgl. Kapitel 6.2.1) zugewiesen wird. Der weitere Ablauf unterliegt bekanntem Schema.
1
char strSSID[5];
2
strcpy(strSSID,"AdhocNet");
3
4
ULONG ISSIdLength;
5
ISSIdLength = strlen(strSSID);
6
7
UCHAR *pSSId = (UCHAR*)strSSID;
8
ULONG& lSSIdLength = ISSIdLength;
9
38
10
UCHAR SetBuffer[sizeof(NDIS_OID) + sizeof(NDIS_802_11_SSID)];
11
PNDISUIO_SET_OID
pSetOid;
ntddndis.h – Embedded Visual Studio 4
- 40 -
12
NDIS_802_11_SSID
SSID;
13
14
pSetOid = (PNDISUIO_SET_OID) &SetBuffer[0];
15
pSetOid–>ptcDeviceName = TEXT("VNETUSBA1");
16
pSetOid–>Oid = OID_802_11_SSID;
17
18
SSID.SsidLength = ISSIdLength;
19
20
memcpy(&SSID.Ssid[0],pSSId,ISSIdLength);
21
memcpy(&pSetOid–>Data[0], &SSID, sizeof(NDIS_802_11_SSID));
22
23
retval = DeviceIoControl(
24
m_hDeviceHandle,
25
26
(LPVOID) &SetBuffer[0],
27
sizeof(SetBuffer),
28
(LPVOID) &SetBuffer[0],
29
0,
&m_dwBytesReturned,
30
NULL);
31
32
33
if(!retval) return ("Set SSID failed");
39
LISTING 6.11 : Setzen der SSID / BSSID / IBSSID
Der Adapter wechselt nun in den Ad–hoc–Modus und übernimmt alle spezifizierten
Merkmale.
Da das charakteristische Ad–hoc–Verhalten auf Grund des auslesbaren Verbindungsstatus
keinen Aufschluss über die Existenz eines Gegenübers liefert, musste ein anderweitiger
Lösungsansatz entwickelt werden, welcher im nächsten Kapitel erläutert wird.
39
- 41 -
6.3
Netzwerkscan und dynamischer Verbindungsaufbau
Da das aktive Scannen nach Netzwerkpartnern ein Vorgang sein sollte, welcher unabhängig
von dem Interaktionsprozess auf grafischer Ebene und fortlaufend im Hintergrund
geschehen sollte, wurde ein so genannter Worker Thread implementiert.
Unter einem Worker Thread versteht man ein unabhängiges Softwaresegment, welches
quasi parallel zum eigentlichen Main Thread eine sequentielle Befehlsabarbeitung
durchführt.
Da
das
Testen
auf
Verfügbarkeit
von
Kommunikationspartnern
innerhalb
einer
Endlosschleife geschieht, würde die grafische Interaktion mit der Software solange
unterbunden werden, bis ein vordefiniertes Event das Durchlaufen der Schleife beendet.
Man spricht hierbei von aktivem Polling. Dies bedeutet, dass es im Stadium des Suchens
keine Möglichkeit gäbe, das Programm in einen anderen Zustand zu versetzen.
Ruft man sich die grundlegenden Anforderungen an den automatisierten WLAN–
Verbindungsaufbau aus Kapitel 3 ins Gedächtnis zurück, so erkennt man hier die Erfüllung
der Notwendigkeit des konfliktfreien Wechsels der Infrastrukturmodi aus Abschnitt 3.4.2.
Weiterhin
muss
es
der
Software
möglich
sein,
selbst
nach
einem
erfolgreich
abgeschlossenen Suchvorgang weiterhin auf Vorhandensein eines Gegenübers zu prüfen
um Verbindungsverluste innerhalb einer vorgegebenen Latenzzeit zu erkennen und
entsprechende Maßnahmen zu einzuleiten. Dies entspricht der Anforderung an den
dynamischen Verbindungsaufbau aus Kapitel 3.5.
Die Threadfunktion „ScanIP“40 wird bei der Initialisierung des Hauptdialoges aufgerufen.
Das Starten des Programmfadens (Threads) entspricht folgenden Programmzeilen:
1
DWORD dwThreadID1 = 0;
2
hThread2 = CreateThread(NULL, 0,ScanIP, this, 0, &dwThreadID1);
LISTING 6.12 : Erzeugen des Worker Threads mit der Threadfunktion ScanIP
Parameter 3 konkretisiert die auszuführende Funktion.
Über den this–Operator aus Zeile 2 wird ein Zeiger auf das aktuelle Objekt, aus dessen
Kontext die CreateThread–Funktion aufgerufen wird, übergeben. Dies ist in konkretem Falle
ein Zeiger auf eine Instanz der „CWLANConnectorDlg“–Klasse, welche die Implementierung
des MFC–Dialoges verkörpert. Damit wird dem Thread Zugriff auf klasseninterne Funktionen
und Variablen ermöglicht [PPCDG05].
Innerhalb der übergeordneten Endlosschleife wird zunächst geprüft, ob sich der Adapter im
Ad–hoc–Modus befindet und ob eine aktive Verbindung besteht.
Dies wäre nicht der Fall, wenn zwar eine Ad–hoc–Bereitschaft angestrebt, jedoch noch nicht
erfolgreich in die Wege geleitet wurde.
40
- 42 -
Erst wenn diese beiden Bedingungen erfüllt sind, wird der eigentliche Schleifenkörper in die
Befehlsabarbeitung einbezogen. Auch eine Lösung über Mutexe, bzw. Semaphoren oder
aktionsabhängiges Starten und Beenden des Threads wären denkbare Ansätze.
Über die Zustandsvariable „foundDevice“ wird gespeichert, ob ein Scanvorgang zum Erfolg
führte. Der Initialisierungswert ist „keine Verbindung“, also der Zahlenwert 0. In einem
Durchlauf der endlosen while–Schleife soll die komplette IP–Adressspanne potentieller
Partner überprüft werden.
Dies erfolgt innerhalb einer eingebetteten for–Schleife, welche in jedem der 30 Durchläufe
einen ICMP Echo Request auf eine Adresse absetzt.
Die Schleife startet bei der IP–Adresse 192.168.1.1 und endet im letzten Durchlauf mit der
192.168.1.30. Der Rückgabewert der IcmpSendEcho–API–Funktion41 signalisiert den Erhalt
eines ICMP Echo Reply Paketes und damit das Vorhandensein eines antwortenden Ad–
hoc–Gerätes.
Ist dies der Fall, wird die Zustandsvariable („foundDevice“) auf den Wert 1 eingesetzt und die
gefundene IP–Adresse inklusive Signalstärke ausgegeben.
Des Weiteren merkt sich das Programm, dass eine Antwort innerhalb des aktuellen
Durchlaufes erhalten wurde, in dem ein Fehlerzähler („failureCounter“) auf den Wert 0
zurückgesetzt wird.
Diese Information wird genutzt um kurzzeitige Verbindungsunterbrechungen innerhalb der
angesprochenen Latenzzeit zu berücksichtigen. Der Wert der Variable wird bei Austritt aus
der for–Schleife inkrementiert und speichert die Anzahl erfolgloser Durchläufe.
Er wird erst wieder auf 0 zurückgesetzt, wenn eine erneute Antwort eines Hosts eintrifft. Die
Zustandsvariable
„foundDevice“
nimmt
nach
einer
bestimmten
Anzahl
erfolgloser
Netzwerkscans den Wert „nicht verbunden“ an. Die Latenzzeit kann über Änderung der
Rücksetzbedingung dieser Variable gesteuert oder völlig deaktiviert werden.
Nach jedem kompletten Scandurchlauf wird die Statusanzeige aktualisiert, in dem die
Variable „foundDevice“ grafisch ausgewertet wird. Da ein Quelltext–Listing der „ScanIP“–
Funktion42 an dieser Stelle zu umfangreich und unübersichtlich wäre, verdeutlicht das
Struktogramm
aus
Abbildung
6.1
das
dargestellte
Verhalten.
Funktionen
und
Wertezuweisungen werden innerhalb der abgerundeten Rechtecke visualisiert. Die Rauten
weisen auf Programmverzweigungen hin, welche sich durch Erfüllung der jeweiligen
Bedingungen an den Pfaden ergeben. Die Ausgabeaktionen sind farbig unterlegt, was der
Farbgebung der Indikatorelemente in der entwickelten Software „WLANConnector“
entspricht. Die Farbe grün weist auf das Vorhandensein eines Ad–hoc–Partners hin,
während die Farbe rot dessen Fehlen symbolisiert. Das Inkrementieren der IP–Adresse
beschränkt sich in der Abbildung der Einfachheit halber auf das letzte Segment dieses
Konstruktes, welches softwareintern an seinen statischen Teil angefügt wird. Auch die
Parameterübergabe der IcmpSendEcho–Funktion wurde auf das Wesentliche, nämlich den
variierende Teil der IP–Kennung, reduziert.
41
42
icmpapi.h – Embedded Visual Studio 4
- 43 -
Abbildung 6.1 : Erzeugen des Worker Threads mit der Threadfunktion ScanIP
- 44 -
6.4
SCREENSHOT 6.2 :WLANConnector
SCREENSHOT 6.3 : WLANConnector
Ad–hoc Netzwerkscan
Ad–hoc verbunden
Integration einer 3rd Party Voice over IP Anwendung
Zum Testen der aufgebauten Ad–hoc–Verbindung wurde eine Voice over IP (VOIP)
Anwendung gewählt.
Gründe dafür waren der enorme praktische Nutzen für den Einsatz in einem Kraftfahrzeug
und der starke Bezug zu einleitendem Tankstellenszenario.
6.4.1
Voraussetzungen
Vorraussetzung an die Anwendung war der mögliche Betrieb im Ad–hoc–Modus und die
Unterstützung des Betriebssystems Pocket PC 2003.
Da die Entwicklung einer eigenen Software den Rahmen dieser Arbeit sprengen und eine
eigenständige Abhandlung füllen würde, wurde auf Vorhandenes zurückgegriffen. Das
softwarebasierte
VOIP–Telefon
SJphone®
von
SJ
Labs43
erfüllt
die
gestellten
Voraussetzungen und bietet zudem hervorragende Ergebnisse bezüglich der erreichbaren
Sprachqualität.
Die Software Skype44 schied bei Betrachtung der oben gestellten Kriterien aus, da ein
Betrieb nur mit vorhandener Internetanbindung möglich ist.
43
44
www.sjlabs.com/sjp.html
www.skype.com/products/skype/pocketpc/
- 45 -
Die Installation der gewählten VOIP–Anwendung wird mit Hilfe von Active Sync45 auf dem
Handheld durchgeführt.
Ideal wäre das softwareinterne Starten des VOIP–Telefons mit der IP–Adresse des
Netzwerkpartners
als
Parameter.
Unvorteilhafterweise
ist
diese
Option
von
den
Programmierern nicht vorgesehen. Um potentielle Gesprächspartner ausfindig zu machen,
arbeitet das Telefon mit dem Neighbourhood Discovery Protocol, welches im Internet
Protocol Version 6 (IPv6) Verwendung findet.
Eine Telefonkonferenz lässt sich bei gestarteter Anwendung mit einigen wenigen Aktionen
einleiten. Dies entspricht nicht dem Idealfall, ist aber zu Zwecken der Verifikation des
Verbindungsaufbaues und der Übertragungsqualität im mobilen Einsatz ausreichend.
6.4.2
Implementierung
Die Softwareintegration wird durch die „OnTalk“–Funktion46 aus Listing 6.13 umgesetzt.
Diese Funktion wird aufgerufen, wenn der entsprechende Softbutton im MFC–Hauptdialog
betätigt wird.
Die
Schaltfläche
wird
erst
aktiviert,
wenn
sich
der
Adapter
in
aktiver
Kommunikationsbereitschaft, entweder im Ad–hoc– oder im Infrastruktur–Modus, befindet.
In Zeile 7 wird mit Hilfe der CreateProcess–Funktion ein neuer Prozess gestartet, welcher
die in Zeile 8 spezifizierte Anwendung ausführt.
Die PROCESS_INFORMATION–Struktur aus Zeile 5 enthält Identifikationsinformationen
über den neuen Prozess, welche in Zeile 17 geschrieben werden. Alle weiteren Parameter
sind nicht weiter von Belang und können bei Bedarf in der Microsoft Developer Network
(http://msdn.microsoft.com/) nachgeschlagen werden.
1
#include <Winbase.h>
2
3
void CWLANConnectorDlg::OnTalk()
4
{
5
PROCESS_INFORMATION pInfo;
6
45
46
7
CreateProcess(
8
_T("\\Programme\\SJphone\\SJphone.exe"),
9
NULL,
10
NULL,
11
NULL,
12
FALSE,
13
0,
14
NULL,
www.microsoft.com/windowsmobile/downloads/activesync38.mspx
- 46 -
15
NULL,
16
NULL,
17
&pInfo);
}
LISTING 6.13 : Sofwareinternes Starten der VOIP Anwendung mit Hilfe von CreateProcess
6.4.3
Testdurchführung und Bewertung
Das erstellte Programm wurde nach der Integration des VOIP–Telefons einem Praxistest
unterzogen. Zwei Autos wurden mit je einem HP iPAQ mit identisch aufgespielter Software
ausgestattet. Innerorts und auf der Landstraße sollte eine aktive Ad–hoc–Verbindung
hergestellt und die IP–Adresse des Gerätes in dem anderen Fahrzeug ausgelesen werden.
Weiterhin sollte dann eine Telefonkonferenz mittels VOIP–Software hergestellt und genutzt
werden. Das Ergebnis war recht zufrieden stellend. Bei getesteten Geschwindigkeiten von
bis zu 100 km/h war eine Kommunikation möglich. Die überbrückbare Entfernung lag bei
circa 50 Metern, wobei unregelmäßiges Annähern und Entfernen des Öfteren Grund für
Verbindungsunterbrechungen waren. Die für den Einsatz in einem Kraftfahrzeug relativ
geringe Signalreichweite scheint unbefriedigend. Der Einsatz von externen Antennen und
Stromversorgung könnte Abhilfe schaffen.
SCREENSHOT 6.4 : VOIP Telefon SJphone
47
47
www.sjlabs.com/sjp.html
- 47 -
7. WLAN–Verbindungsaufbau im Infrastruktur–
Szenario
7.1
Adapterkonfiguration über NDISUIO
Die Konfiguration des WLAN–Adapters für die Verwendung im Infrastruktur–Modus
entspricht den in Kapitel 6.2 erläuterten DeviceIoControl–Operationen. Die verwendeten
OIDs sind identisch. Es müssen lediglich die Ausprägungen der NDIS Object Identifier an
den infrastrukturellen Verbindungsaufbau angepasst werden.
Beim
Setzen
des
Infrastrukturmodus
unter
Verwendung
des
OID_802_11_INFRASTRUCTURE_MODE Object Identifier wird der Integer–Wert, welcher
durch die Bezeichnung Ndis802_11Infrastructure konkretisiert wird, in den Datenpuffer der
instantiierten
PNDISUIO_SET_OID–Struktur
kopiert
und
an
den
WLAN–Adapter
weitergegeben.
Danach wird nach gewohntem Muster mit dem Authentifizierungsmodus verfahren.
Änderungen sind hier nicht notwendig.
Das Schreiben der SSID entspricht ebenfalls dem Quelltextauszug aus Listing 6.11 mit
angepasster SSID. Wie im Ad–Hoc–Modus wird nach diesem Vorgang die Konfiguration
vom Adapter übernommen.
Allerdings ändert sich das Verhalten bei der Verbindungsherstellung grundlegend. Während
im Ad–hoc–Modus generell und unabhängig von in Reichweite befindlichen WLAN–Geräten
Sende– und Empfangsbereitschaft hergestellt wurde, erfolgt ein Verbindungsaufbau nur bei
Vorhandensein eines kompatibel konfigurierten Access Points.
Wenn bereits eine Bindung zu einem Access Point mit anderer SSID besteht, so erfolgen
Verbindungstrennung und Statuswechsel. Der WLAN–Adapter befindet sich nun in
verbindungslosem
Zustand.
Dies
kann
über
eine
Abfrage
mit
Hilfe
der
OID_GEN_MEDIA_CONNECT_STATUS–OID überprüft werden, wie im nächsten Kapitel
beschrieben. Im Weiteren versucht sich der Adapter mit einem Netzwerk mit vorgegebener
SSID zu verbinden. Entspricht sich die Konfiguration, so wird dieser Vorgang erfolgreich
abgeschlossen. Dies resultiert in einem Zustandswechsel. Wird die OID geschrieben, wenn
eine Assoziation mit einem Netzwerk mit übereinstimmender SSID besteht, so wirkt sich dies
in einer Verbindungstrennung und einem erneuten Verbindungsvorgang zu diesem Access
Point aus. Dies muss sich nicht in einem Statuswechsel erkenntlich zeigen. Wird nicht
explizit über die OID_802_11_NETWORK_TYPE_IN_USE–OID ein Netzwerktyp wie
802.11b oder 802.11g festgelegt und sind alternative Netzwerkentsprechungen vorhanden,
so kann der Netzwerkadapter autonom nach bestimmten Kriterien, wie Signalstärke oder
Lebensdauer der Batterie, entscheiden [MSDN05].
- 48 -
WLAN–Verbindungsaufbau im Infrastruktur–Szenario
7.2
Dynamischer Verbindungsaufbau
Ist der Verbindungsversuch nach Schreiben der SSID nicht erfolgreich, so verbleibt der
Adapter in unverbundenem Zustand. Verbindungsversuche müssen daher wiederholt
eingeleitet werden bis ein entsprechender Access Point gefunden wurde.
Zu diesem Zweck wurde ein weiterer Worker Thread, welcher die Thread–Funktion
„ScanAP“48 ausführt, implementiert.
Innerhalb einer Endlosschleife wird hierbei der Verbindungsstatus abgefragt. Wenn sich die
Software in infrastruktureller Verbindungsbereitschaft befindet und die Statusabfrage ergibt,
dass keine Netzwerkanbindung besteht, bemüht sich das Programm erneut um
Verbindungsaufbau.
Eine Verzögerung von fünf Sekunden innerhalb eines Schleifendurchlaufes gewährleistet,
dass dem WLAN–Adapter genügend Zeit zur Verfügung gestellt wird, um eine erfolgreiche
Access Point Anbindung in die Wege zu leiten. Wird die Verzögerung zu kurz bemessen,
wird eine erneute Adapterkonfiguration vorgenommen obwohl ein Verbindungsversuch zu
einer verfügbaren Basisstation bereits initiiert wurde.
Abbildung 7.1 : Auslesen des Verbindungsstatus über NDISUIO
48
- 49 -
Das
SCREENSHOT 7.1 :WLANConnector
SCREENSHOT 7.2 : WLANConnector
Infrastruktur Netzwerkscan
Infrastruktur verbunden
Testen
auf
Verbindung
übernimmt
die
in
Listing
7.1
zusammengefasste
Befehlssequenz. Über eine IOCTL–Struktur wird diesmal lesend auf den Miniport–Treiber
zugegriffen. Das Kopieren der Ausprägungen in den Datenpuffer vor Ausführung des
DeviceIoControl–Befehles entfällt daher. In Zeile 6 wird ein Abfragepuffer angelegt und in
Zeile 7 eine Instanz einer PNDISUIO_QUERY_OID–Struktur erstellt. Die enthaltene OID
wird
mit
OID_GEN_MEDIA_CONNECT_STATUS
konkretisiert
(Zeile
11).
Die
Rückgabedaten werden in den Datenpuffer geschrieben (Zeile 17) und in Zeile 22 in den
Adressbereich der hierfür erstellten Variable vom Typ NDIS_MEDIA_STATE kopiert.
Dieser Datentyp kann zwei Ausprägungen annehmen: „NdisMediaStateConnected“ oder
„NdisMediaStateDisconnected“. Der Rückgabewert der Funktion wird in den Zeilen 24 bis 29
bestimmt. Ist der Netzwerkadapter verbunden so wird ein „wahr“, also eine 1
zurückgegeben, andernfalls ein „falsch“ in Form einer 0.
1
DWORD
2
bool retval;
m_dwBytesReturned = 0;
3
4
NDIS_MEDIA_STATE conn;
5
6
UCHAR QueryBufferCheckCon[1024];
7
PNDISUIO_QUERY_OID pQueryOidCheckCon;
8
9
pQueryOidCheckCon = (PNDISUIO_QUERY_OID)&QueryBufferCheckCon[0];
10
pQueryOidCheckCon–>ptcDeviceName = TEXT("VNETUSBA1");
11
pQueryOidCheckCon–>Oid = OID_GEN_MEDIA_CONNECT_STATUS;
12
- 50 -
13
retval = DeviceIoControl(m_hDeviceHandle,
14
IOCTL_NDISUIO_QUERY_OID_VALUE,
15
(LPVOID) &QueryBufferCheckCon[0],
16
sizeof(QueryBufferCheckCon),
17
(LPVOID) &QueryBufferCheckCon[0],
18
sizeof(QueryBufferCheckCon),
19
&m_dwBytesReturned,
20
NULL);
21
22
memcpy(&conn,&pQueryOidCheckCon–>Data[0],sizeof(NDIS_STATUS));
23
24
if (conn == NdisMediaStateConnected)
25
{
return 1;
26
27
}
28
else return 0;
29
}
LISTING 7.1: Auslesen des Verbindungsstatus über NDISUIO
7.3
49
Integration einer Informationsanwendung
Bei der Realisierung eines geeigneten Testszenarios wurde ein Weg gesucht, Dateien sowie
Informationen von einem Server in einem konventionellen Kabelnetzerk an den Client im
KFZ zu senden. Eine Möglichkeit wäre die Implementierung von TCP/IP–Sockets, über
welche Datenpakete jeglicher Form übermittelt werden könnten. Um die Informationen
verwertbar zu machen müsste dann jedoch eine ausgeklügelte Navigation umgesetzt
werden. Eine Software, welche die übersichtliche, strukturierte Visualisierung von
Informationen von Natur aus beherrscht, ist der Internetbrowser. Dieser ist zudem noch auf
allen gängigen Systemen in der Grundausstattung inbegriffen.
Ein Webserver, welcher sich hinter dem Access Point in das Netzwerk integriert, publiziert
Daten in Form von HTML–Strukturen und hostet alle Arten von Daten. Über eine
angebundene
Datenbank
lassen
sich
dynamische
Inhalte
verwalten.
Auch
eine
Zugriffsverwaltung ist hier problemlos umsetzbar.
Die ideale Technik ist vorhanden und muss lediglich in die Anwendung integriert werden.
Vergibt man eine spezifizierte IP–Adresse, so lassen sich Webserver an unterschiedlichen
Lokalitäten gleichermaßen ansprechen. Listing 7.2 zeigt eine Abwandlung der aus Kapitel
6.4 bekannten CreateProcess–Funktion.
Neben dem Konsolenbefehl zum Ausführen des Executables in Zeile 6 werden in Zeile 7
zusätzliche Parameter angegeben. Diese spezifizieren das Protokoll und die IP–Adresse des
Servers, von welchem Daten abgerufen werden sollen. Beim Abarbeiten dieser Funktion
49
- 51 -
wird der Internet Explorer gestartet und nimmt automatisch Kontakt zum Host mit der IP–
Kennung 192.168.1.100 (Zeile 7) auf. Da sich der Internet Explorer stets an der gleichen
Stelle im Dateisystem befindet, ist der Pfad aus Zeile 6 universell gültig.
1
void CWLANConnectorDlg::OnInfo()
2
{
3
PROCESS_INFORMATION pInfo;
4
5
CreateProcess(
6
_T("\\Windows\\iexplore.exe"),
7
_T("http://192.168.1.100"),
8
NULL,
9
NULL,
10
FALSE,
11
0,
12
NULL,
13
NULL,
14
NULL,
15
&pInfo);}
LISTING 7.2 : Sofwareinternes Starten des Internet Explorers mit spezifizierter Zielhost
Um vorgestelltes Verfahren zu testen wurde ein Apache50 Webserver auf einem Windows
Rechner installiert.
HTML–Dokumente, welche Nachrichten, Verkehrsmeldungen, Wetterinformationen und
Musikdateien präsentieren, wurden erstellt und auf dem Server abgelegt.
Über ein Navigationsmenü war ein strukturierter, gezielter Zugang zu gewünschten
Dokumenten und Software möglich.
Die Tatsache, dass es sich bei diesem Browser um ein systemeigenes Werkzeug handelt,
bietet
weiterhin
eine
komfortable
Möglichkeit
zum
ersten
Aufspielen
der
Anwendungssoftware. Wird über einen Hyperlink eine Datei angewählt, so wird dem
Anwender über einen Dialog ermöglicht, diese Datei mit der zugeordneten Anwendung
sofort zu öffnen oder an einer Stelle der Wahl im Dateisystem abzulegen.
Es wurden Überlegungen unternommen, diese Option auf eine Aktion zu reduzieren um die
Interaktion mit dem System zu minimieren.
50
www.apache.org/
- 52 -
SCREENSHOT 7.3 : Informationsanwendung mittels Webservers
- 53 -
8. Anmerkungen zur Entwicklung unter Windows XP
8.1
NDISUIO Schnittstellendefinition
Um die Abhandlung der softwareinternen WLAN–Steuerung über das NDISUIO–Protokoll
nicht auf Windows CE zu beschränken wird im Folgenden auf Adapterzugriffe unter anderen
aktuellen Windows–Varianten eingegangen.
Konkret erfolgte eine Portierung der erarbeiteten Softwarefunktionalität auf Windows XP
SP1. Diesbezüglich wurde die Konsolenanwendung „WLANConSol“ entwickelt, welche
verfügbare Instanzen von 802.11–Adaptern ausliest, diese zur Anzeige bringt und für die
weitere Verwertung vorbereitet. Quelltext und ausführbare Programmdatei sind beigelegter
CD–ROM zu entnehmen.
Um mittels NDISUIO–Zugriffen auf die WLAN–Hardware zuzugreifen, wird in jedem Falle
zuerst ein Handle benötigt. Dieses wird als Rückgabewert der CreateFile-Funktion erzeugt
und einer Variablen von Typ Handle zugewiesen. Anschließend können unter Pocket PC
2003 Konfigurations- und Informationsbeschaffungsvorgänge durchgeführt werden, indem
die Adapterbezeichnung, im Falle des untersuchten HP iPAQ 5500 Pocket PCs „vnetusba1“,
in den Strukturen PNDISUIO_SET_OID und PNDISUIO_QUERY_OID platziert wird.
Die Variable „ptcDeviceName“, welche einen Zeiger auf einen, den Namen der
Adapterinstanz enthaltenden, Puffer empfängt, wird allerdings nur für Windows CE zur
Verfügung gestellt.
Wird diese konkretisiert, so sind die implementierten DeviceIoControl–Zugriffe nur auf
spezifiziertem Gerät durchführbar. Soll der Code variabel gestaltet werden, so kann die
„ptcDeviceName“ –Struktur mit dem Wert nur „NULL“ initialisiert werden. Dieses Vorgehen
ist auch unter Windows CE praktikabel.
Die spezifische Übergabe des Gerätenamens legt die Funktionalität des Quelltextes fest und
macht Operationen unnötig, welche für die geräteunabhängige Implementierung eingesetzt
werden müssen [MSDN05].
8.2
Enumeration der WLAN–Adapter
Im Vorfeld macht es Sinn, zuerst alle verfügbaren WLAN–Netzwerkadater zu enumerieren
und in einer Liste zu veralten.
Die gewünschte Hardwareselektion erfolgt in einer separaten Funktion und kann sowohl
durch Mensch–Maschine–Interaktion, als auch automatisiert erfolgen.
Wird
der
IOCTL–Kontrollcode
IOCTL_NDISUIO_QUERY_BINDING
innerhalb
der
DeviceIoControl–Funktion eingesetzt, so wird es einer Anwendung ermöglicht, den Namen
- 54 -
Anmerkungen zur Entwicklung unter Windows XP
und die Bezeichnung aller an NDISUIO gebunden Netzwerkschnittstellen des ausführenden
Systems auszulesen.
Die Ergebnisdaten werden in den in Zeile 7 (Listing 8.1) initialisierten Datenpuffer
geschrieben. Dieser wird der DeviceIoControl–Funktion in Zeile 20 als Parameter übergeben
und verweist auf eine Instanz der NDISUIO_QUERY_BINDING–Struktur, welche die
Variablen
für
den
Namen
und
die
Beschreibung
der
Adapter
enthält.
Das
NDISUIO_QUERY_BINDING–Element „BindingIndex“ dient als Enumerationsindex. In der
for–Schleife aus Zeile 15, welche kein eigenes Abbruchkriterium kennt, wird dieser so lange
inkrementiert, bis der Rückgabewert der
DeviceIoControl–Funktion auf die erfolgte
Abarbeitung aller Adapter schließen lässt (Zeile 18) und die break–Anweisung aus Zeile 52
greift.
Innerhalb des Schleifenkörpers werden die Adapterdefinitionen mittels memcpy–Operationen
in ein Array (Liste) von WRAPI_NDIS_DEVICE–Strukturen, welche den Namen (Zeile 33 bis
35) und die Beschreibung (Zeile 37 bis 39) der Geräte verwalten, eingefügt. Eine variable
Zuordnung des benötigten Speicherplatzes für jede Adapterdefinition wird in Zeile 28 bis 31
über die malloc–Funktion vorgenommen.
Die Variable lItems, welche in Zeile 2 deklariert und mit dem Wert 0 initialisiert wird, enthält
die Anzahl der geführten Listenelemente.
1
WRAPI_NDIS_DEVICE
*pDeviceList = NULL;
2
long
lItems = 0;
3
4
WRAPI_NDIS_DEVICE **ppDeviceList = &pDeviceList;
5
long *plItems = &lItems;
6
7
CHAR
Buf[1024];
8
DWORD dwBytesWritten, i = 0;
9
10
m_pQueryBinding = (PNDISUIO_QUERY_BINDING)Buf;
11
12
*ppDeviceList = (WRAPI_NDIS_DEVICE *) malloc(NUM_DEVICES *
13
sizeof(WRAPI_NDIS_DEVICE));
14
15
for (m_pQueryBinding->BindingIndex = i;;m_pQueryBinding->BindingIndex =
16
++i)
17
{
18
if (DeviceIoControl(
19
m_hFileHandle,
20
IOCTL_NDISUIO_QUERY_BINDING,
21
m_pQueryBinding,
22
sizeof(NDISUIO_QUERY_BINDING),
23
Buf,
24
sizeof(Buf),
25
&dwBytesWritten,
- 55 -
NULL))
26
{
27
28
(*ppDeviceList)[i].pDeviceName = (WCHAR *)
29
malloc(m_pQueryBinding->DeviceNameLength);
30
(*ppDeviceList)[i].pDeviceDescription = (WCHAR *)
31
malloc(m_pQueryBinding->DeviceDescrLength);
32
33
memcpy((*ppDeviceList)[i].pDeviceName,
34
(PUCHAR)m_pQueryBinding+m_pQueryBinding->DeviceNameOffset,
35
m_pQueryBinding->DeviceNameLength);
36
37
memcpy((*ppDeviceList)[i].pDeviceDescription,
38
(PUCHAR)m_pQueryBinding+m_pQueryBinding->DeviceDescrOffset,
39
m_pQueryBinding->DeviceDescrLength);
40
memset(Buf, 0, sizeof(Buf));
41
42
}
43
else
44
{
45
m_dwError = GetLastError();
46
if (m_dwError != ERROR_NO_MORE_ITEMS)
{
47
48
printf("EnumerateDevices:\n terminated abnormally, error
49
%d\n", m_dwError);
50
m_hRes = E_FAIL;
51
}
break;
52
53
}
54
*plItems = i + 1;
55
}
LISTING 8.1 : Enumeration der WLAN–Adapter
51
Name und Beschreibung der enumerierten Adapter können nun ausgegeben werden.
1
for ( int j = 0; j < lItems; j++)
2
{
3
printf("Enumerierte NDIS Devices:\n %ws\n
4
pDeviceList[j].pDeviceDescription, pDeviceList[j].pDeviceName);
5
}
LISTING 8.2 : Ausgabe der enumerierten WLAN–Adapter über die Konsole
51
52
Anpassung der WRAPIb2.0 – WLANConSol.cpp
WLANConSol – WLANConSol.cpp
- 56 -
52
- %ws\n",
8.3
Assoziation des Adapters mit dem NDISUIO Handle
Um ohne OID–interne Adapterzuweisung zu arbeiten, muss das erzeugte Geräte–Handle
(Kapitel 5.6, Listing 5.2) mit der Hardware assoziiert werden.
Dies erfolgt innerhalb eines Hardwarezugriffes in Form einer DeviceIoControl–Funktion,
welche durch den IOCTL–Kontrollcode IOCTL_NDISUIO_OPEN_DEVICE definiert wird.
Weitere relevante Parameter sind ein Zeiger auf den Adapternamen (Zeile 16) und die
Größe des Namenspuffers (Zeile 17) in Bytes.
Jede Anwendung kann dabei nur einen Adapter zur selben Zeit beanspruchen [MSDN05].
Listing 8.3 schließt nahtlos an das vorangegangene Listing 8.2 an und bezieht sich auf
dessen Geräteenumeration „pDeviceList“. In Zeile 1 wird das Element mit dem Array–Index
1 selektiert. Dieses wird in der for–Schleife (Zeilen 6 bis 9) in den Zeichen–Container
„wNdisDeviceName“ transferiert, wobei sich die Länge des Strings in der Variablen
„wNameLength“ entsprechend anpasst.
DEVICE_LENGTH aus Zeile 2 ist über eine define–Operation dauerhaft mit der Zahl 47
verknüpft, was bedeutet, dass sich die Länge der Gerätebezeichnung auf diesen Wert
beschränkt.
In Zeile 12 wird die binäre 0 an den String angefügt, um den Abschluss der Zeichenkette zu
signalisieren.
Nach Ausführung der DeviceIoControl–Operation (Zeilen 14 bis 21), beziehen sich alle
weiteren NDISUIO–Zugriffe auf diesen WLAN-Adapter.
1
WCHAR *pwDeviceName = pDeviceList[1].pDeviceName;
2
WCHAR wNdisDeviceName[DEVICE_LENGTH] = {0};
3
int wNameLength, h = 0;
4
wNameLength = 0;
5
6
for ( h = 0; h < DEVICE_LENGTH-1; h++ )
7
{
8
wNdisDeviceName[h] = pwDeviceName[h];
9
wNameLength++;
10
}
11
12
wNdisDeviceName[h] = L'\0';
13
14
if (!DeviceIoControl(m_hFileHandle,
15
IOCTL_NDISUIO_OPEN_DEVICE,
16
(LPVOID) &wNdisDeviceName[0],
17
sizeof(WCHAR)*wNameLength,
18
NULL,
19
0,
20
&m_dwBytesReturned,
21
NULL))
- 57 -
22
{
23
m_dwError = GetLastError();
24
printf("Could not open NDIS Device, error %d\n", m_dwError);
25
m_hRes = E_FAIL;
26
}
27
else
28
{
29
printf("\n\n\nDevice %ws\nerfolgreich geoeffnet\n",
30
pDeviceList[1].pDeviceDescription);
31
}
LISTING 8.3 : Assoziation des Handles mit dem WLAN-Adapter
53
- 58 -
53
9. Prioritätsgesteuerter WLAN–Verbindungsaufbau
9.1
Motivation
Die bisherigen Konzipierungsüberlegungen zielten darauf ab, durch vorgegebene Merkmale
spezifizierte WLAN–Profile softwaregesteuert oder manuell zu aktivieren und dynamisch auf
erfolgten Verbindungsaufbau zu prüfen. Hierbei entscheiden die Ressourcenanforderungen
des Programms oder der Mensch, welcher Netzwerkzugang angestrebt wird.
Die nachstehenden Überlegungen binden einen zusätzlichen Faktor ein: Softwareinterne
Selektion
des
angestrebten
WLAN-Netzwerkes
nach
priorisierten
externen
Voraussetzungen.
Die folgenden Beispiele sollen diesen Gedankengang verdeutlichen. Angenommen eine
Anwendung beliebiger Art benötigt Zugriff auf eine Netzwerkressource. Es besteht Kenntnis
darüber, dass die Ressource über mehrere, eventuell gekoppelte, WLAN–Knoten erreichbar
ist, jedoch eine Netzwerkanbindung nach dem Least Cost Prinzip bevorzugt wird. Gründe
hierfür
können
variierende
Übertragungsgeschwindigkeiten,
Verbindungskosten,
Signalstärke oder generelle Verfügbarkeit sein.
Auch softwareinterne Aufgaben können priorisiert werden. Das Versenden einer Mail muss
schneller erfolgen als das Empfangen der aktuellen Staumeldungen. Die Software soll nun
im Vorfeld sondieren, welche äußeren Bedingungen gegeben sind und diese Auswerten.
Senden zwei oder mehrere Zugangspunkte im aktuellen Signalbereich, wird die Verbindung
hergestellt, welche das Senden von Mails unterstützt, obwohl ebenfalls Verkehrsnachrichten
über ein anderes
Netzwerk angerufen werden könnten. Erkennt der Algorithmus
unterschiedliche Anbindungsmöglichkeiten mit variierender Signalstärke, so wird der
Verbindungsaufbau, der zur besten Übertragungsleistung führt, initiiert.
Lässt die Signalstärke darauf schließen, dass ein Positionswechsel stattgefunden hat,
reagiert das Programm und präsentiert entsprechende Informationen.
Bei einer Messerundfahrt könnten mit Hilfe dieses Verfahrens standortabhängige Funktionen
ausgeführt werden.
Die Anwendung reagiert weiterhin dynamisch auf Veränderungen der gegebenen
Voraussetzungen. Ein Netzwerk, welches sich an einer Stelle durch hervorragende
Signalstärke ausgezeichnet hat, kann nach einer Positionsänderung kaum mehr erreichbar
sein. Dies wird programmatisch verwertet und eine günstigere Alternative angepeilt.
- 59 -
Prioritätsgesteuerter WLAN–Verbindungsaufbau
9.2
802.11 Netzwerkscan
Um einen prioritätsgesteuerten Verbindungsaufbau in Abhängigkeit von Verfügbarkeit,
Signalstärke oder SSID zu ermöglichen, müssen diese Informationen im Vorfeld
softwareintern gesammelt werden. Die 802.11–Adapterhardware wird hierbei als Sensor
genutzt. Grundsätzlich können Netzwerkscans auf verschiedene Arten durchgeführt werden.
Wird ein aktiver Netzwerkscan in die Wege geleitet, so sendet die 802.11–Adapterhardware
periodisch Sondierungsanfragen über einen selektierten Kanal an die Broadcast–Adresse
und wartet auf die Antwort von erreichten WLAN–Stationen.
Eine weitere Variante ist das passive Scannen. In diesem Fall verbreitet der Adapter keine
Anfragen, sondern verbleibt in untätigem Zustand bis Rundsendeinformationen von
verfügbaren Stationen bei ihm eintreffen.
Ein WLAN–Gerät identifiziert sich gegenüber seiner Umwelt mittels so genannter Beacons
(Leuchtfeuer). Diese Datenpakete sind für die Netzwerksynchronisation zuständig und
werden in vorgegebenen Intervallen ausgesendet um Steuersignale zu übermitteln und das
Auffinden von drahtlosen Netzwerken zu erleichtern. Auf einigen Access Points können
diese Intervalle individuell angepasst werden.
Empfängt
ein
Adapter
ein
solches
Leuchtfeuer
oder
eine
Antwort
auf
eine
Sondierunganfrage, so hinterlegt er diese Informationen in einer BSSID–Liste [MSDN05].
9.3
Implementierung eines BSSID List Scans
Dies wird über einen Gerätezugriff mittels OID_802_11_BSSID_LIST_SCAN veranlasst.
Erhält ein Adapter diese Kontrollstruktur, so reagiert er nach vorgegebenem Schema.
Zunächst wird der bisherige Inhalt der geführten BBSID–Liste verworfen. Unabhängig vom
aktuellen Infrastrukturmodus werden sowohl infrastrukturelle, als auch Ad–hoc–Netzwerke
gesucht. Hierbei werden alle Frequenzkanäle und Netzwerktypisierungen mit einbezogen.
Um die korrekte Initialisierung dieser Operation bereits nach kurzer Zeit zu evaluieren,
erfolgt eine Statusrückmeldung schon bevor der Scanvorgang beendet wurde.
Die erhaltenen Informationen werden in die dafür reservierte Speicherstruktur eingepflegt.
Listing 9.1 zeigt die konkrete Implementierung für eine Anwendung unter Windows XP.
Die folgenden Quelltextauszüge wurden größtenteils der „GetAPList“–Funktion aus der
Wireless Research API entnommen und an das eigens erstellte Programmgerüst
„WLANConSol“ angepasst.
Die OID–Spezifikation wird in bekannter PNDISUIO_QUERY_OID–Struktur abgelegt
(Zeile 5) und innerhalb der DeviceIoControl–Funktion an den Adapter gesendet
(Zeile 7 bis 14).
- 60 -
1
PNDISUIO_SET_OID
pSetOidList;
2
UCHAR QueryBuffer[1024];
3
4
pSetOidList = (PNDISUIO_SET_OID) &QueryBuffer[0];
5
pSetOidList->Oid = OID_802_11_BSSID_LIST_SCAN;
6
7
DeviceIoControl(m_hFileHandle,
8
9
(LPVOID) &QueryBuffer[0],
10
sizeof(QueryBuffer),
11
12
0,
13
&m_dwBytesReturned,
14
NULL);
LISTING 9.1 : Initiierung eines BSSID LIST SCANS
54
Aktives als auch passives erneuern der BSSID_LIST–Struktur führ zu einer vollständigen
Auffrischung des Tabelleninhaltes. Man spricht deshalb von expliziter Netzwerkerkundung.
Weiterhin führt das 802.11–Device implizite Scans durch. Dies bedeutet, dass der Adapter
eine eigenständige Aktualisierung der BSSID–Liste durchführt. Auf das Aussenden von
Broadcast–Nachrichten wird verzichtet. Die Einträge werden hierbei lediglich ergänzt. Greift
man innerhalb von sechs Sekunden nach Initiierung eines Scans lesend auf den BSSID–
Cachespeicher zu, so wird dessen vollständiger Inhalt zurückgegeben. Das Auslesen erfolgt
über eine OID mit der Ausprägung OID_802_11_BSSID_LIST.
Wird der Zugriff nach der erwähnten Zeitspanne durchgeführt, so muss das Ergebnis alle,
auch durch implizite Abfragen erlangte, Einträge preisgeben.
Wurde zuvor kein expliziter Scan in die Wege geleitet, werden WLAN–Knoten in
Abhängigkeit der aktuellen Konfiguration ausgegeben. Wenn sich der Adapter im Ad–hoc–
Modus befindet, beschränkt sich der zurückgegebene Inhalt daher auf Peer–to–Peer–
Knoten [MSDN05].
Das
vorangegangene
Listing
PNDISUIO_SET_OID–Struktur,
9.1
erläutert
wohingegen
den
schreibenden
das
Zugriff
nachfolgende
über
Listing
die
über
PNDISUIO_QUERY_OID lesend auf den WLAN-Adapter zugreift. Es müssen daher erst
einmal Container bereitgestellt werden, um die ausgelesenen Daten unterzubringen.
Es handelt es sich hierbei um ein Array von Informationsstrukturen, welche den
auszulesenden
Daten
entsprechen
müssen.
Nach
erfolgtem
Gerätezugriff
über
DeviceIoControl (Zeilen 17 bis 24), werden die bisher untypisierten Rückgabedaten, wie
gewohnt, in den dafür angelegten „QueryBuffer“ (Zeile 9) geschrieben.
In Zeile 26 wird der Inhalt des Datensegmentes als PNDIS_802_11_BSSID_LIST–Struktur
interpretiert und dem dafür dynamisch allokierten Speicherbereich (Zeile 7) zugewiesen. Die
PNDIS_802_11_BSSID_LIST–Spezifikation enthält einen „NumberOfItems” –Zähler und ein
54
- 61 -
Array von NDIS_WLAN_BSSID–Strukturen, dessen Aufbau in Listing 9.2 aufgeschlüsselt
wird. Wie der Rest der für das NDISUIO–Protokoll relevanten Strukturen findet auch dieses
Element ihre Definition im „ntddndis.h“ Header–File.
Die enthaltenen Merkmale treffen eine Aussage darüber, welche Informationen über
erkundete WLAN–Devices ausgelesen werden können. Es handelt sich hierbei um die
MAC–Adresse (Zeile 3), die SSID (Zeile 5), die Signalstärke (Zeile 7), den Netzwerktyp
(Zeile 8), die Konfigurationsspezifikationen (Zeile 9), den Infrastrukturmodus (Zeile 10) und
die unterstützten Übertragungsraten (Zeile 11). Alle diese Merkmale können beim
priorisierten Verbindungsaufbau Berücksichtigung finden.
1
struct _NDIS_WLAN_BSSID {
2
ULONG Length;
3
NDIS_802_11_MAC_ADDRESS MacAddress;
4
Uchar Reserved[2];
5
NDIS_802_11_SSID Ssid;
6
ULONG Privacy;
7
NDIS_802_11_RSSI Rssi;
8
NDIS_802_11_NETWORK_TYPE NetworkTypeInUse;
9
NDIS_802_11_CONFIGURATION Configuration;
10
NDIS_802_11_NETWORK_INFRASTRUCTURE InfrastructureMode;
11
NDIS_802_11_RATES SupportedRates;
12
} NDIS_WLAN_BSSID, *PNDIS_WLAN_BSSID;
LISTING 9.2 : Aufschlüsselung der NDIS_WLAN_BSSID–Struktur
55
Die Daten müssen anschließend für die weitere Verwendung aufbereitet und in
entsprechenden Variablen gespeichert werden. Die BSSID–Liste ist nicht beständig, da sie
vom Adapter eigenständig aktualisiert wird.
Zu diesem Zweck ist das Erstellen eigener Datencontainer nötig. In konkreten Falle handelt
es sich um ein Array von „AP_DATA“–Strukturen, welches in Zeile 1 mit einem Zeiger auf
den Speicherbereich versehen wird. wird. Die long–Variable „lItemsList” zählt dessen
Elemente.
Der Aufbau von „AP_DATA“ wird innerhalb der „WLanExports.h“–Datei, welche dem
Quelltext der WRAPI beiliegt, definiert und den Bedürfnissen entsprechend angepasst. Es
werden nur Informationen übernommen, welche für die Weiterverwendung von Bedeutung
sind. Der hierfür benötigte Speicherplatz wird in den Zeilen 30 und 31 allokiert.
In der for–Schleife von Zeile 33 bis 47 wird das Array gefüllt. Diese wird sooft durchlaufen,
wie WLAN–Geräte eingelesen wurden. Die eingebettete Schleife von Zeile 35 bis Zeile 39
liest hierbei die MAC–Adresse in ein Array ein, wohingegen die Schleife von Zeile 41 bis 45
für die SSID zuständig ist.
55
ntddndis.h – Windows XP SP1 DDK
- 62 -
Für die entwickelte Testapplikation wurde zusätzlich eine Strukturvariable „ssid“ für das
Speichern des Service Set Identifiers integriert (Zeile 46). Da die Strukturen mehrfach
ineinander verschaltet sind, ist es bei der Auswertung der Informationen notwendig, dessen
Elemente bis auf die unterste Ebene der Grunddatentypen zu durchleuchten. Bei der SSID
handelt es sich beispielsweise um ein Array von bis zu 32 uchar–Werten (unsigned
character). Die SSID lässt sich auf ein Array von sechs unsigned char Werten zurückführen
und die Signalstärke besteht aus einer long–Zuweisung.
1
AP_DATA *pAP_data = NULL;
2
long
3
AP_DATA **ppAP_data =&pAP_data;
4
long *plItemsList =&lItemsList;
lItemsList;
5
6
PNDISUIO_QUERY_OID
pQueryOid;
7
PNDIS_802_11_BSSID_LIST
pBssid_List;
8
9
UCHAR QueryBuffer[1024];
10
11
ULONG k = 0;
12
Int l = 0;
13
14
pQueryOid = (PNDISUIO_QUERY_OID) &QueryBuffer[0];
15
pQueryOid->Oid = OID_802_11_BSSID_LIST;
16
17
DeviceIoControl(m_hFileHandle,
18
IOCTL_NDISUIO_QUERY_OID_VALUE,
19
20
21
22
23
&m_dwBytesReturned,
24
NULL);
25
26
pBssid_List = (PNDIS_802_11_BSSID_LIST)pQueryOid->Data;
27
28
*plItemsList = pBssid_List->NumberOfItems;
29
30
*ppAP_data = (AP_DATA *)calloc(pBssid_List->NumberOfItems,
31
sizeof(AP_DATA));
32
33
for ( k = 0; k < pBssid_List->NumberOfItems; k++ )
34
{
35
for ( l = 0; l < 6; l++ )
36
{
37
(*ppAP_data)[k].mac_addr[l] =
- 63 -
38
(pBssid_List->Bssid[k]).MacAddress[l];
39
}
40
41
for ( l = 0; l < 32; l++ )
42
{
43
(*ppAP_data)[k].ssid[l] =
44
(pBssid_List->Bssid[k]).Ssid.Ssid[l];
45
}
46
(*ppAP_data)[k].Rssi = (pBssid_List->Bssid[k]).Rssi;
47
}
LISTING 9.3 : Auslesen der in der BSSID–Liste enumerierten WLAN–Geräte
9.4
56
Verwertung der gesammelten Geräteinformationen
Das folgende Listing 9.4 demonstriert den prioritätsgesteuerten Verbindungsaufbau an Hand
einer SSID–Auswertung. Der Service Set Identifier lässt hierbei auch auf den
Infrastrukturmodus schließen.
Das vorgestellte Programmgerüst (Listing 9.4) bezieht sich direkt auf das Anstoßen des
aktiven BSSID_LIST_SCAN–Vorgangs (Listing 9.1) und das Auslesen der BSSID–Liste
(Listing 9.3). Das Array, welches durch den Zeiger „pAP_data” gekennzeichnet wird, wurde
in
Listing
9.3
mit
Variablendeklarationen
Informationen
seien
in
über
angestelltem
verfügbare
WLAN–Geräte
Softwaregerüst
auf
Grund
gefüllt.
seines
exemplarischen Charakters außen vor gelassen. Der Quelltextauszug ist Teil der
entwickelten „WLANConSol“–Anwendung, welche auf beigefügter CD–ROM zu finden ist.
Das Verhalten der Anwendung lässt sich wie folgt beschreiben: Wird beim Auslesen der
BSSID–Liste ein Device mit der SSID „AdhocNet“ oder „InfraNet“ erkannt, so wird eine
entsprechende Verbindung angestrebt. Sind beide WLAN–Konfigurationen auffindbar, so
wird das „AdhocNet“ höher priorisiert. Dies wirkt sich dahingehend aus, dass selbst wenn
zuvor eine Assoziation mit den „InfraNet“ besteht, diese Netzwerkanbindung durch
eingeleiteten Verbindungsaufbau zu entdecktem „AdhocNet“ unterbrochen wird. Ist bereits
eine
Anbindung
im
Sinne
der
vergebenen
Prioritäten
erfolgt,
werden
weitere
Verbindungsoperationen unterbunden.
Die rahmende for–Schleife arbeitet alle in der
„AP_data“–Liste geführten Einträge
sequentiell ab.
Die if–Abfrage aus Zeile 3 vergleicht zunächst die SSID des ausgewählten Geräteeintrags
aus der „AP_data“–Liste mit dem String „AdhocNet“. Wird eine Entsprechung erkannt, so
wird der Verbindungsstatus geprüft. Befindet sich der 802.11–Adapter bereits in
kompatiblem Zustand, so wird dies lediglich durch eine Konsolenausgabe visualisiert
56
- 64 -
(Zeile 7). Ist dies nicht der Fall wird eine Konfigurationsänderung eingeleitet (Zeile 13) und
die Zustandsvariable angepasst (Zeile 14).
Die verwendeten Methoden „setAdhoc“ und „setInfrastructure“ wurden in Kapitel 6.2
ausführlich behandelt. Führt der if–Vergleich (Zeile 3) nicht zum Erfolg wird das else–Modul
(Zeilen 17 bis 30) in die Programmausführung mit einbezogen. Über eine weitere strcmp–
Funktion (string compare) in Zeile 18 wird nun getestet, ob die SSID des zu überprüfenden
Gerätes der Zeichenkette „InfraNet“ gleichsetzbar ist. Bei Rückgabe des Wertes true wird ein
entsprechender infrastruktureller Verbindungsaufbau in die Wege geleitet (Zeile 27), falls
dies noch nicht geschehen ist (Zeile 20).
1
for (m = 0;m< k; m++)
2
{
3
if(!strcmp((const char*)pAP_data[m].ssid,"AdhocNet"))
4
{
5
if(status==1)
6
{
printf("\nBereits im Ad-Hoc Modus ...");
7
8
}
9
else
10
{
11
printf("\nEs wurde ein priorisiertes Device gefunden\n
12
Initiiere Ad-Hoc Modus\n");
13
setAdHoc();
14
status = 1;
}
15
16
else
17
{
18
if(!strcmp((const char*)pAP_data[m].ssid,"InfraNet"))
19
{
20
if(status == 2)
21
{
22
printf("\nBereits im Infrastruktur Modus ...");
23
}
24
else
25
{
26
printf("\nInitiiere Infrastruktur Modus\n");
27
setInfrastructure();
28
status = 2;
}
29
30
}
31
}
LISTING 9.4 : Prioritätsgesteuerter Verbindungsaufbau
57
WLANConSol – WLANConSol.cpp
- 65 -
57
Um den priorisierten Verbindungsaufbau dynamisch zu gestalten, müssen innerhalb eines
vorgegebenen Zeitfensters neu erkannte WLAN–Adapter aufgespürt und verwertet werden.
Dies kann mit Hilfe einer übergeordneten Endlosschleife geschehen, in welcher der
Netzwerkscan,
das
Auslesen
der
BSSID–Liste
und
prioritätsgesteuerten Verbindungsaufbau integriert werden.
- 66 -
der
Algorithmus
für
den
10. WLAN–Integration eines Embedded Automotive
Frameworks unter QNX
10.1
Systembedingte Voraussetzungen
Ein weiterer Aspekt meiner Untersuchungen beschäftigt sich mit der kabellosen
Netzwerkanbindung von Embedded Automotive Frameworks unter dem echtzeitfähigen
Betriebssystem QNX.
Diese Systeme, ausgerüstet mit einem SH4 Prozessor, bieten eine experimentelle Plattform
für die Softwareentwicklung auf ressourcenbeschränkter Hardware und sind für die
Steuerung von Multimediaelementen im KFZ ausgelegt.
Grundsätzlich besteht ein solches Infotainment–System aus einer Headunit, welche die
Rechenarbeit übernimmt und darüber hinaus diverse Bedienelemente inklusive Display zur
Verfügung
stellt,
sowie
typischen
Multimediakomponenten
(Audiokomponenten,
Videokomponenten, Kommunikationsdevices, Navigationssystem, etc.) [JW04].
Auf Grund des experimentellen Charakters dieser Geräte entsteht die Notwendigkeit
Hardwarekomponenten hinzuzufügen, Software aufzuspielen und Prozessabläufe zu
überwachen. Da das eigentliche Framework keine Schnittstellen für die Manipulation von
Programmen
und
Kontrolle
von
Systemzuständen
oder
Abläufen
bietet
ist
die
Kommunikation mit externen Entwicklungssystemen obligatorisch.
Hierzu wird ein Ethernet–Netzwerk verwendet, welches alle Framework–Targets umfasst,
sowie eine Reihe von konventionellen Rechnern, welche mit der QNX Momentics IDE58
(Integrated Development Environment) ausgestattet sind um das Ausführen und Debuggen
von Programmen über das Netzwerkinterface zu ermöglichen.
Im Gegensatz zu statischen Netzwerkknoten eines herkömmlichen Kabelnetzwerkes in
einem Labor, stellt der Einsatz in einer mobilen Umgebung weit komplexere Anforderungen
an das Kommunikationsmedium.
Der Notwendigkeit einer kabellosen Netzwerkanbindung, welche auch über größere
Entfernungen und unabhängig von physikalischen Hindernissen wie Wänden oder
Karosserie aufrecht erhalten werden kann, wird man im Folgenden durch den Einsatz von
WLAN gerecht.
58
www.qnx.com
- 67 -
WLAN–Integration eines Embedded Automotive Frameworks unter QNX
Auch das bereits in der Einleitung angeführte Tankstellen–Szenario soll entsprechend den
erarbeiteten Anforderungen an den automatisierten Verbindungsaufbau im KFZ nachgebildet
werden
können.
So
soll
die
Infotainmenteinheit
an
speziell
eingerichteten
Verteilungspunkten Zugriff auf digitale Medieninhalte wie mp3s, Software, Informationen,
Systemupdates und Patches erlangen.
Die folgenden Ausführungen basieren auf praktischen Erfahrungen, welche im Laufe des
Projektseminares gesammelt wurden, und sollen ein grundlegendes Verständnis für die
Integration von Netzwerkkomponenten im Allgemeinen, sowie WLAN–Geräten auf einem
eingebetteten System unter dem Betriebssystem QNX im Speziellen vermitteln. Ebenso wird
auf im Laufe der Entwicklung auftretende Probleme und Fragen eingegangen um einen
einführenden Leitfaden für Installation, Integration und Implementierung bei ähnlichen
Problemstellungen zu vermitteln.
10.2
Realisierung mittels WLAN Karte
Da die Mainboards sowohl mit einer PCMCIA–Schnittstelle, sowie mit einem PCI–Interface
ausgestattet sind, konzentrierten sich die Bemühungen zunächst auf die Installation interner
Steckkarten.
10.2.1
Verbindungsaufbau mittels Systembefehlen
Einen einschränkenden Faktor bei der Inbetriebnahme und Installation stellt die Tatsache
dar, dass sämtliche Kommandos von einem zweiten Rechner mit entsprechenden Ein– und
Ausgabeeinheiten abgesetzt werden müssen. Dies bedeutet, dass die Funktionstüchtigkeit
des Ethernet–Interfaces in jedem Falle gewährleistet bleiben muss, um die Kontrolle über
die Geräte aufrechtzuerhalten.
Gravierende Änderungen der Netzwerkkonfiguration können dazu führen, dass die Einheit
von Außen nicht mehr zugänglich ist und ein Wiederaufspielen eines Systemimages nötig
wird.
Die
Befehle
zum
Starten
der
benötigten
Netzwerkdienste
und
Aktivierung
der
Netzwerkkarten werden während des Bootvorganges über ein Bootscript abgearbeitet.
Befehle, die während der Systemlaufzeit ausgeführt werden sollen, werden innerhalb einer
Telnet–Session abgesetzt. Der Telnet–Dienst basiert auf einem unverschlüsselten
eigenständigen Protokoll auf der Anwendungsschicht und ermöglicht den Zugang auf die
Kommandozeile eines Fremdrechners via TCP/IP [WITEL05].
Unter QNX, ähnlich wie bei anderen Variationen von UNIX Systemen, bietet der IO–NET–
Dienst die Basis für grundsätzliche Netzwerkfunktionen. Ist dieser Dienst gestartet können
entsprechende Geräte gemountet werden. Unter diesem Begriff versteht man in der Regel
das optionale Einbinden von Ein– und Ausgabegeräten. Ein gemountetes Device kann über
- 68 -
den unmount–Befehl wieder aus dem System entfernt werden. Alle Devices, welche in ein
laufendes System eingebunden wurden, sind als symbolische Einträge an statisch definierter
Stelle im Dateisystem zu finden. Der Pfad zu den Netzwerkkarten ist in unserem System
\dev\io–net\.
Jedes
Device
benötigt
eine
spezifische
Beschreibung
seiner
individuellen
herstellerabhängigen Hardwarezugriffsfunktionen. Eine solche Sammlung von APIs wird
durch ein so genanntes Shared Objekt File zur Verfügung gestellt und ist mit der
Dateiendung .so versehen. Abstrakt gesehen handelt es sich hierbei um einen Gerätetreiber.
Shared Objects können als Pendant zu DLLs unter Windows gesehen werden und sind ein
C++ Kompilat meist mehrerer Quellcode–Dateien, welche sich an fest vorgegebenen
Strukturen und Funktionen orientieren müssen um eine standardisierte Systemintegration zu
ermöglichen. Wird eine .so–Datei ohne expliziten Speicherort beispielsweise innerhalb eines
mount–Befehles angegeben, so wird diese in ihrem Standardpfad \etc\dll\ gesucht. Es
empfiehlt sich diese Vorgabe bei der Installation von Drittanbieter–Treibern zu übernehmen,
um die Verwirrung nicht zusätzlich zu steigern [QNX05].
Treiber für WLAN–Karten werden von QNX nur bedingt zur Verfügung gestellt. Einige fertig
kompilierte Treiber–Dateien werden bei der lizenzierten Version von QNX Momentics 6.3
distributiert und unterstützen diverse WLAN–Karten59 einiger weniger Hersteller.
Eine weiterführende Problematik ergibt sich aus der Tatsache das Treiber für QNX auf
Grund des Nischencharakters kaum von den Herstellerfirmen direkt angeboten werden.
Oben angesprochene Shared Object Dateien für WLAN–Karten, welche bei QNX auf der
Liste der unterstützen Hardware zu finden sind, können ausschließlich von X86er
Prozessoren verarbeitet werden. Quellcodes werden aus kommerziellen Gründen nicht
publiziert und können daher nicht auf andere Architekturen, wie unsere SH4 Prozessoren
übertragen werden.
Der Versuch im Internet veröffentlichte Quellcodedateien60 anzupassen und zu kompilieren
scheiterte an internen Architekturänderungen, welche im Laufe von Versionsweiterführungen
des QNX Frameworks durchgeführt wurden. Bei den zum freien Download angebotenen
Quellen handelte es sich um Portierungen von Linux–Treibern für WLAN–Karten mit
Chipsatz der Firma ATMEL, welcher auf einigen Karten unterschiedlicher Hersteller zum
Einsatz kommt. Diese Erkenntnis wurde zusätzlich durch Korrespondenz mit dem
Entwickler61 untermauert.
Ein Treiber im Experimentalstadium, welcher von der Firma Becker entwickelt und vertrieben
wurde, führte ebenfalls nicht zum gewünschten Ziel.
Zur Verfügung standen eine PCI– und eine PCMCIA-WLAN-Karte. Nach umfangreichen
Bemühungen in Zusammenarbeit mit dem laborinternen Systemintegrationsteam, die Karte
mit unterschiedlichsten Parametern zu mounten, konnte lediglich das PCI–Gerät erkannt
59
www.qnx.com/developers/hardware_support/
www.qnxzone.com/%7Ephearbear/?go=Atmel%20Wi-Fi
61
phearbear@home.se
60
- 69 -
werden. Jedoch wurde der Adapter nicht als Netzwerk–Device an entsprechender Stelle im
System angezeigt und konnte daher nicht konfiguriert und in Betrieb genommen werden.
Um einen erfolgreichen mount–Vorgang zu bewerkstelligen müssen unter Umständen
etliche Parameter wie IRQ, Speicherbereiche, usw. angegeben werden. Dies ist größtenteils
vom Grad der automatisierten Hardwareerkennung abhängig und kann sich bei jedem Gerät
individuell unterscheiden [QNX05].
Die folgenden Ausführungen wurden auf Grund der oben dargestellten Treiberproblematik
theoretisch erarbeitet und teilweise mit herkömmlichen Ethernetkarten, für welche
bekanntermaßen funktionstüchtige Treiber existieren, auf QNX–Systemen getestet. Wie
bereits erwähnt basiert jeglicher Netzwerkkartenbetrieb unter QNX auf dem IO–NET–Dienst.
Ist bereits ein Netzwerk–Device in das System integriert und wird dieses beim Bootvorgang
initialisiert, so ist dieser Dienst bereits gestartet. Im Falle unserer Projekt–Frameworks wird
dieser Vorgang innerhalb eines Skriptes, welches beim Hochfahren der Systeme ausgeführt
wird, sequentiell abgearbeitet.
Ist der Service noch nicht gestartet, so kann dies mit angeführtem Kommando geschehen:
/ io–net $
Ebenso können bei der Ausführung dieses Befehls zusätzliche Parameter angegeben
werden um direkt angegebene Netzwerkgeräte über ihre Shared–Objekt–Files zu mounten.
Das Präfix der Shared Object Bezeichnung „devn“ weißt darauf hin, dass es sich um ein
Netzwerkdevice handelt. Wird dieser Befehl erfolgreich ausgeführt, werden die Geräte
symbolisch innerhalb des Dateisystems als typisiertes Modul geführt.
/ io–net /lib/dll/devn-bcm43xx.so
Läuft bereits eine Instanz von IO–NET, so ist das erneute Starten dieses Dienstes nicht
ratsam. Es kann zu Systeminstabilität führen und die komplette Netzwerkanbindung
beeinträchtigen. Alternativ ist es praktikabel in einem solchen Falle den mount–Befehl zu
bemühen. Der Parameter „–T io-net“ spezifiziert das angegebene Gerät als Netzwerkdevice.
/ mount -T io-net /lib/dll/devn-bcm43xx.so
Wird das Entfernen eines Netzwerkgerätes angestrebt, kann dies über die unmount–
Anwendung geschehen. Die Typisierung des Gerätes wird über die explizite Angabe des
symbolischen Pfades im Dateisystem konkretisiert. Hierbei steht die Modulbezeichnung
„en0“ für das Ethernet–Modul mit Index 0.
/ umount /dev/io-net/en0
- 70 -
Anders als bei Windows–Systemen muss keine komplizierte Adapterkonfiguration
vorgenommen werden, da das Device in einem konkreten Zustand gemountet werden kann.
Alle für die Definition eines WLAN–Netzwerkes relevanten und aus vorangestellten Kapiteln
dieser Arbeit wohl vertrauten Parameter können hierbei übergeben werden. Es handelt sich
hierbei um die SSID, den Infrastruktur–Modus, den Authentifizieruns–Modus und die
Verschlüsselung. Optionale gerätespezifische Parameter können durch Voranstellen des „-o“
–Flags angegeben werden. Das angestellte Systemkommando mountet eine Netzwerk
Interface Card (NIC), konkretisiert dessen SSID mit der Kennung „work“ und setzt den
Infrastrukturmodus durch Angabe von „mode=ibss“ auf Ad–hoc (Independent Basic Service
Set). Weiterhin wird die Authentifizierung mittels „authtype=open“ deaktiviert.
Das Flag „-p“ spezifiziert die Art des anzubindenden Protokolls, in konkretem Falle den
kompletten TCP/IP–Protokollstapel [QNX05].
/ mount -T io-net /lib/dll/devn-bcm43xx.so -o ssid=work mode=ibss
authtype=open -p tcpip
Eine ähnliche Konfiguration im Infrastruktur–Modus wird durch Ändern der „mode“–
Ausprägung auf „bss“ (Basic Service Set) erzielt.
/ mount -T io-net /lib/dll/devn-bcm43xx.so -o ssid=work mode=bss
authtype=open -p tcpip
Will man beispielsweise vom Ad–Hoc–Modus in den Infrastruktur–Modus wechseln muss
man lediglich das Device, welches auf IBBS konfiguriert wurde mit Hilfe des unmount–
Kommandos aus dem System entfernen um es im nächsten Schritt mit den Parametern für
den Infrastruktur–Modus einzubinden.
Der Zugriff über komplizierte APIs, wie bei der Network Driver Interface Specification unter
Windows, wird weitgehend unnötig.
Auch das Zuweisen einer kompatiblen IP–Adresse ist von erstaunlicher Einfachheit:
/ ifconfig en0 192.168.1.3
Die erläuterten Operationen können innerhalb eines QNX–Skriptes zusammengefasst und
ausgeführt werden. Aber auch eine softwareinterne Verwertung ist denkbar. Damit können
die Systemaufrufe in Abhängigkeit von Programmzuständen automatisiert werden, wir das
nächste Kapitel zeigt.
- 71 -
10.2.2
Integration der Systemkommandos
Will man aufgeführte Konsolenkommandos programmatisch verwerten, so kann man sich
der C++ system–Funktion bedienen und die Rückgabewerte abfragen, um auf Erfolg zu
prüfen.
Das angestellte C++ Quellcode–Fragment demonstriert das Starten des IO–Net–Dienstes,
das Einbinden eines WLAN–Adapters und das Zuweisen einer IP–Adresse auf
entsprechendem Interface.
Um die Quellcodefragmente so verständlich wie möglich zu halten wird auf Embedded
Speicherkonzepte, wie das Verbot dynamischer Speicherallokation verzichtet.
1
if((rc = system("mount -T io-net devn-speedo.so"))== -1)
2
{
printf("Kommando konnte nicht ausgefÃ¼hrt werden\n");
3
4
}
5
else
6
{
printf("Network Device Unmount erfolgreich\n\n");
7
8
};
9
10
srand((int) time( NULL ));
11
12
int IPlast = rand()%50;
13
14
char cd1[30];
15
char ddest[40];
16
17
strcpy(cd1,"ifconfig en0 192.168.1.");
18
19
sprintf(ddest,"%s%d",cd1,IPlast);
20
21
if((system(ddest))== -1)
22
{
printf("Kommando konnte nicht ausgefuehrt werden\n");
23
24
}
25
else
26
{
27
printf("IP Adressvergabe auf 192.168.1.%d erfolgreich\n\n",IPlast);
28
};
Listing 10.1 : Softwareinterne Integration von WLAN–Systembefehlen
62
WLANConCheck – WLANConCheck.cpp
- 72 -
62
Aufgeführte Systemkommandos ermöglichen eine recht unkomplizierte Konfiguration der
WLAN–Devices. Jedoch kann die volle Funktionalität der Gerätezugriffe nach Art der NDIS–
APIs mit Konsolenkommandos nicht erreicht werden. Es ist nicht möglich erweiterte
Informationen auszulesen oder in die Konfiguration zu schreiben, wie in entsprechendem
Kapitel erläutert. Weiterhin kann es von Nachteil sein bei jeder Modusänderung das
komplette Device aus dem System zu entfernen um es mit anderen Einstellungen wieder zu
integrieren.
10.2.3
Verbindungsaufbau mittels DeviceControl Zugriffen
Auf Unix–Systemen und speziell unter QNX bietet die devctl–Funktion eine Möglichkeit
Geräte nach NDISUIO–Art zu manipulieren. Diese DeviceControl–Funktion sendet
gerätespezifische Kommandos an verwaltende Prozesse, welche als File–Handles in Form
einer symbolischen Datei erzeugt werden.
Eine Portierung des unter Linux verfügbaren Programms "iwconfig"63, welches unter der
GNU LGPL im Internet zu finden war zeigt die Art und Weise dieser Zugriffe und ist auf
beigelegter CD–ROM abgelegt.
Bei Einsatz der Software wird vorausgesetzt dass der Netzwerkadapter bereits vom System
erkannt und in der Netzwerkgeräteliste im Pfad /dev/io–net/ aufgeführt wird. Das Programm
konnte daher bei der WLAN–Anbindung der Framework–Targets nicht eingesetzt werden.
10.3
Realisierung mittels Ethernet–WLAN–Bridge
Da manche Systeme, welche grundsätzlich über Ethernet–Funktionalität verfügen, auf
Grund einschränkender Faktoren, welche sowohl auf verfügbare Hardware als auch
Software zurückzuführen sind, nicht systemintern erweiterbar sind, bieten Ethernet–WLAN–
Brücken dennoch die Möglichkeit einer räumlich flexiblen Netzwerkanbindung.
10.3.1
Beschaffenheit der Netzwerkgeräte und Integration in das bestehende
Kabelnetzwerk
Um sowohl infrastrukturelle als auch Ad–Hoc–Szenarien nachbilden zu können, werden zwei
Ethernet–WLAN–Adapter und ein Access Point benötigt. Die Ethernet–WLAN–Brücken sind
für den Betrieb an je einem Framework gedacht, der Access Point soll die Verbindung zum
bestehenden Kabelnetzwerk herstellen.
63
www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
- 73 -
Die kompakten Adapter sind jeweils mit zwei Netzwerkschnittstellen oder Interfaces
ausgestattet und fungieren als "externe" WLAN–Karten. Das 802.11–Interface übernimmt
die
eigentliche
WLAN–Funktionalität,
wohingegen
die
Ethernet–Schnittstelle
die
kabelgebundene Überbrückung der Geräte gewährleistet. Die Kombination von Ethernet–
WLAN–Adapter
und
Framework
ergibt
einen
in
sich
geschlossenen,
mobilen
Netzwerkknoten [WIEW05].
Abbildung 10.1 stellt die Einbindung der WLAN–fähigen Targets in das bestehende
Labornetzwerk an Hand eines Netzwerkdiagrammes dar.
Da sich die Framework–Targets, als auch die Labor–PCs in einem eigenständigen
Netzwerksegment befinden, wird die netzübergreifende Kommunikation mit Hilfe eines
Routers realisiert. Die Targets agieren hierbei im Netz 172.16.166.0, während die
Workstations IP–Adressen aus dem 141.100.47.0 Segment zugewiesen bekommen. Die IP–
Adressvergabe erfolgt in beiden Fällen durch einen DHCP–Server mit der Adresse
141.100.47.200. Über das Gateway 141.100.47.254 erfolgt die Anbindung an das
Hochschulnetz, welches den Internetzugang des Labors gewährleistet.
Ziel der Target–WLAN–Integration ist die vollständige Erhaltung der bestehenden
Funktionalität im Kabelnetz. Dies bezieht sich auf die Erreichbarkeit der Workstations,
dynamische Konfiguration über den DHCP–Server und Zugang zu übergeordneten Netzen,
wie Hochschulnetz und Internet.
Da die Targets für den Betrieb in einem Kraftfahrzeug konzipiert wurden, schafft man durch
eine drahtlose Netzwerkanbindung eine
praxisnahe Testumgebung. Unter realen
Bedingungen können entwickelte Erweiterungen verifiziert und an den mobilen Einsatz
angepasst werden. Weiterhin wird es möglich hardwarespezifische Anforderungen zu
erkennen und umzusetzen.
Die Konfiguration der Ethernet–WLAN–Brücken und des Access Points wird in den
folgenden Kapiteln beschrieben.
- 74 -
Abbildung 10.1 : WLAN Integration ICM Labor FH–Darmstadt
- 75 -
10.3.2
Interface–Bridging
Jedem Interface ist eine weltweit eindeutige Netzwerkkennung zugewiesen.
Bei den vorliegenden Geräten werden die Netzwerkschnittstellen über das so genannte
Bridging–Verfahren überbrückt. So werden zwei physikalische Interfaces mit nur einer IP–
Kennung adressiert. Das geräteinterne Routing der Daten–Pakete wird somit verschleiert
und die Konfiguration vereinfacht. Für jeden kabellosen Netzwerkteilnehmer müsste
ansonsten eine eigene Adresse für das Ethernet Interface und zwei für die Schnittstellen des
Adapters
reserviert
werden,
was
bei
mehreren
Geräten
zu
einem
enormen
Verwaltungsaufwand führen kann.
10.3.3
Konfiguration des AccessPoints
Auf dem Access Point werden alle nötigen Netzwerkparameter vergeben. Die Clients, in
diesem Fall die Ethernet–WLAN–Brücken, müssen dieser Konfiguration vollständig
entsprechen.
Da das Gerät ab Werk mit einer vorgegebenen IP–Adresse konfiguriert ist, kann es noch
nicht in das vorhandene Netzwerk integriert werden. Ist das Gerät physikalisch über ein
Netzwerkkabel in das LAN eingegliedert, muss der Rechner, welcher für die Konfiguration
genutzt werden soll, mit einer kompatiblen Netzwerkkennung versehen werden.
Identifiziert sich der Access Point beispielsweise über die Adresse 192.168.2.5 bei einer
Subnetzmaske von 255.255.255.0, so muss die IP–Kennung des Netzwerkpartners aus dem
Bereich 192.168.2.X gewählt werden, wobei der Variablen X eine Zahl zwischen 1 und 254
zugewiesen werden kann. Die 5 muss ausgeklammert werden, da die Pakete ansonsten
kollidieren würden. Die 0 und die 255 dürfen nicht vergeben werden, da es sich hierbei um
reservierte Adressen handelt, welche für die Netzwerkverwaltung von Bedeutung sind. Die 0
spezifiziert das komplette Netzwerksegment und die 255 definiert einen Broadcast. Über das
ping–Kommando kann nun die Kommunikation getestet werden.
Der Konfigurationsdialog des Access Points kann mit jedem beliebigen HTTP–Browser
geöffnet werden, in dem die entsprechende IP–Adresse in das Adressfeld eingegeben wird.
In den meisten Fällen ist ein Standardpasswort vergeben, welches der beiliegenden
Konfigurationsanleitung zu entnehmen ist. Ist der Zugang gewährleistet wird das drahtlose
Netz eingerichtet. Obligatorisch ist die Spezifikation der SSID, über welche sich das
Netzwerk identifiziert. Das Rundsenden dieser Kennung kann optional unterbunden werden.
Weiterhin kann der Netzwerktyp spezifiziert werden. Hierbei wird zwischen dem 802.11b
oder dem abwärts kompatiblen 802.11g Standard gewählt. Im Weiteren muss eine
netzinterne IP–Adresse vergeben werden. Diese wird aus dem Adressbereich des
Kabelnetzwerkes gewählt und muss auf jeden Fall individuell sein. Um grundlegende
Sicherheitsvorkehrungen zu treffen wird danach eine Verschlüsselungs– und
- 76 -
Authentifizierungsvariante64 spezifiziert. Hat man sich diesbezüglich festgelegt kann der
Access Point in Betrieb genommen werden.
10.3.4
Konfiguration der Ethernet–WLAN Adapter
Die Vergabe der IP–Adressen kann entweder manuell oder per DHCP erfolgen.
In jedem Fall müssen die vergebenen IP–Adressen zwingenden Vorgaben entsprechen. Sie
müssen sich alle im selben Subnetz befinden, was einer fest vorgegebenen Spanne von
Adressfolgen entspricht. Die Anzahl der möglichen Adressierungen ergibt sich aus der
Subnetzmaske.
In unserem speziellen Falle wurde die manuelle Zuweisung vorgezogen um über die
spezifische Adresse einfacher auf den integrierten Webserver zwecks Konfiguration
zuzugreifen.
Wenn eine beständige Integration der Geräte erfolgreich abgeschlossen wurde, können
diese jedoch auch ohne weiteres auf dynamisch vergebene IP–Adressen umgestellt werden,
da ein expliziter Zugriff nur noch bei Änderung der Einstellungen von Nöten ist.
Der Zugang zu den eigentlich wichtigen Endgeräten wird in beiden Fällen über deren
statische Adressierung gewährleistet. Diese sind von jedem Netzwerknoten aus erreichbar.
10.3.5
Dynamische IP–Adresszuweisung für Endgeräte
Im Kabelnetzwerk wurden die Automotive Frameworks über den DHCP Server mit einer
eindeutigen IP–Adresse versorgt. Der Netzwerkadapter identifiziert sich im Laufe des
Verbindungsvorganges über seine MAC Kennung. Der eigentliche Vorteil dieser etwas
umständlich erscheinenden Zuweisungsvariante liegt darin, dass die Konfiguration von
zentraler Stelle durchgeführt, geändert und überwacht werden kann.
Gerade bei Systemen, welche nur indirekt gewartet werden können und das Einstellen von
Parametern umfangreiche Arbeitsvorgänge erfordert, geht man dazu über, identische
Images zu erstellen und aufzuspielen.
Die individuelle IP–Adresse ergibt sich dann aus der hardwareabhängigen MAC
Adressierung.
64
siehe Kapitel 2.5
- 77 -
10.4
Verbindungsgesteuerte Client–Server–Kommunikation
Unabhängig der 802.11–Anbindungsrealisierung der Embedded Automotive Framework
Targets soll nun im Folgenden das Prinzip einer verbindungsgesteuerten Client–Server–
Anwendung unter QNX erläutert werden.
Hierbei
nimmt
das
Target
die
Rolle
des
Clients
ein,
Netzwerkanbindung eine TCP/IP–Socketvebindung initiiert und
welcher
bei
erkannter
eine Anfrage an einen
Server sendet.
Dieser kann Bestandteil eines Kabelnetzes sein und reagiert auf die empfangene Nachricht,
in dem ein Datenstrom an den Client gesendet wird. Das Target nimmt die Daten entgegen
und legt sie in seinem Speicher ab. Dies kann sowohl die Festplatte, als auch der
Arbeitsspeicher des Gerätes sein. Angedacht ist die Übertragung einer digitalen Bilddatei,
welche automatisiert auf dem Human–Machine–Interface (HMI) zur Anzeige kommt.
Die softwaretechnische Realisierung dieses Szenarios wird in fünf logische Komponenten
zerlegt:
o
WLAN–Verbindungsaufbau
o
Identifikation des Netzwerkpartners
o
Initiierung einer Socket–Verbindung
o
Übertragung einer Datei
o
Anzeige der Datei auf der HMI
Der WLAN–Verbindungsaufbau wird über die Ethernet–WLAN–Brücken bewerkstelligt. Es ist
sowohl
ein
Einsatz
im
Ad–Hoc–Modus
denkbar,
als
auch
eine
infrastrukturelle
Netzwerkanbindung. Auf Grund des Client–Server–Prinzips ist die Verwendung einer
Access–Point–Lösung vorzuziehen, da mehrere Clients zu einem Server verbinden können
und findet Entsprechung im einleitenden Tankstellenszenario.
Die Einstellungen der Ethernet–WLAN–Adapter werden im Vorfeld der Konfiguration des
Access Points angepasst. Bei Installation der Targets inklusive Ethernet–WLAN–Brücken im
Kraftfahrzeug erfolgt ein Verbindungsaufbau, wenn sich die mobile WLAN–Station innerhalb
des Signalbereiches des Access Points befindet.
Durch die externe WLAN–Lösung ist es dem Target nicht möglich durch Gerätezugriffe auf
einen erfolgten Verbindungsaufbau zu prüfen.
Dies wird über die bekannten ICMP Echo Requests gelöst. Beim Einsatz der
infrastrukturellen Netzwerkanbindug erfolgt die IP–Adressvergabe über den eingebundenen
DHCP–Server oder manuell.
Die Identifikation des Netzwerkpartners ist trivial, da die IP–Adresse des Servers eindeutig
spezifiziert wurde. Es wäre beispielsweise eine Vergabe der 192.168.0.1 denkbar.
Das Target beschränkt sich daher lediglich auf die Erkennung von ICMP Echo Replys dieser
IP–Kennung.
- 78 -
Auf der Server–Seite ist das Auslesen der Client–IP–Adresse belanglos, da die
softwareinterne Angabe dieser nur beim Initiieren der Socket–Verbindung durch den Client
angegeben werden muss. Der Server ist so konfiguriert, dass ein Verbindungsaufbau von
jeder beliebigen Adresse akzeptiert wird. Eine einfache Verbindungserkennung über eine
spezifizierte IP–Adresse könnte folgendermaßen implementiert werden (Listing 10.2).
Der hier implementierte Netzwerkscan orientiert sich an der Windows CE Lösung aus Kapitel
6.3, Listing 6.12, und erlaubt das Erkunden von ganzen Adressbereichen. Innerhalb einer
Endlosschleife (Zeile 6) wird die komplett verfügbare Adressspanne durchlaufen. Dies
geschieht im Körper der for–Schleife (Zeile 9 bis 38). Der Schleifenzähler „j“ definiert sowohl
die Anzahl der durchgeführten Schleifendurchläufe, als auch das letzte Segment der zu
testenden IP–Adresse. Über diesen Indexwert kann die zu testende Adressspanne beliebig
angepasst werden.
Die ICMP Echo Requests werden durch Integration des ping–Kommandos, welches
softwareintern mit Hilfe der system–Funktion (Zeile 20) ausgeführt wird, durchgeführt.
In den Zeilen 11 bis 14 werden char–Arrays initialisiert, welche durch das strcpy–Kommando
gefüllt (Zeile 16 bis 18) und in Zeile 19 im Container „cdest“ mit Hilfe der sprintf–Funktion
zusammengeführt werden. Der daraus resultierende String enthält das komplette
Systemkommando „ping -c 1 -w 1 192.168.1.j >NULL“, wobei „j“ durch den aktuellen Wert
des Schleifenzählers ersetzt werden muss.
Die Parameter des ping–Befehls lassen sich wie folgt aufschlüsseln:
-c 1
Abbruch nach senden „eines“ ECHO_RESPONSE Paketes
-w 1
Abbruch nach „einer“ Sekunde Zeitüberschreitung
Die Zeitspanne zwischen zwei ping–Vorgängen wird durch Anagabe dieser Parameter
wesentlich verkürzt, was ein schnelleres Auffinden des WLAN–Partners garantiert.
Über Angabe von „>NULL“ wird die komplette Konsolenausgabe ins Nichts umgeleitet.
Der Rückgabewert des system–Befehls, welcher als Integer–Wert interpretierbar ist, lässt
auf den Erfolg der eingebetteten Anwendung schließen. Ist dieser -1, so konnte das
Kommando nicht ordnungsgemäß ausgeführt werden.
Andernfalls kann über das WEXITSTATUS–Macro (Zeile 28) der Status des spezifizierten
Kommandos ermittelt werden. Dieser wird in Zeile 28 ausgewertet. Bei Rückgabe des
Wertes 0 wurde ein ICMP Echo Response Paket empfangen und ein Netzwerkpartner
identifiziert (Quelle: QNX Momentics V6.3 Documentation).
- 79 -
1
int rz;
2
int j = 0;
3
4
printf("Scanne nach WLAN Partnern\n");
5
6
while(true)
7
{
8
9
for(j=1;j<=50;j++)
10
{
11
char cs1[20];
12
char cs2[10];
13
char cs3[5];
14
char cdest[40];
15
16
strcpy(cs1,"ping -c 1 -w 1 ");
17
strcpy(cs2,"192.168.1.");
18
strcpy(cs3,">NULL");
19
sprintf(cdest,"%s%s%d%s",cs1,cs2,j,cs3);
20
rz = system(cdest);
21
22
if( rz == -1 )
23
{
printf( "Kommando konnte nicht ausgefuehrt werden\n" );
24
25
}
26
else
27
{
28
if(WEXITSTATUS( rz )==0)
29
{
30
printf("WLAN Device 192.168.1.%d verfuegbar\n",j);
31
break;
32
}
33
else
34
{
printf("Scanning... IP 192.168.1.%d\n",j);
35
}
36
}
37
}
38
39
40
}
41
42
printf("Socketverbindung zu Server wird initiiert...\n");
Listing 10.2 : Softwareinterne Identifikation des Netzwerkpartners
- 80 -
Das in Listing 10.2 dargestellte Schleifenkonstrukt ist auf der angehängten CD–Beilage im
Quelltext der „WLANConCheck“–Anwendung eingebunden, welches eigenständig zu
Testzwecken entwickelt wurde.
Nachdem eine Netzwerkanbindung erkannt wurde (Zeile 28 bis 32) kann der Schleifenkörper
über eine break–Anweisung verlassen werden. Das Programm ist nun in Kenntnis der Server–
IP–Adresse und kann den entsprechenden Socket aufbauen.
Hierzu können die ebenfalls beiliegenden Quelltexte für Client und Server in das Projekt
integriert werden, welche ebenfalls für die Datenübertragung verwendet werden.
Der Client schickt hierbei nach Initiierung der Socket–Verbindung eine Anfrage in Form von
GETFILE [Dateiname], auf welche der Server entweder mit NOTFOUND reagiert, falls die
Datei nicht vorhanden ist, oder die Datenübertragung in die Wege leitet. Die Datei wird hierbei
in Pakete von 1024 Bytes unterteilt. Die Anzahl der Pakete lässt sich daher als Quotient der
Dateilänge in Bytes und dem Wert 1024 bestimmen.
Abschließend werden die empfangenen Daten interpretiert und auf der HMI mit Hilfe des
systemeigenen QNX Photon microGUI Windowing-Systems zur Anzeige gebracht.
Beschriebene
verbindungsgesteuerte
Client–Server–Anwendung
wurde
bis
dato
komponentenweise realisiert und getestet, eine vollständige Realisierung und Präsentation
befindet sich in Arbeit.
- 81 -
11. Ergebnis
11.1
Zusammenfassung
Ziel der Arbeit war es die WLAN–Technologie im Bezug auf den Einsatz im KFZ zu
durchleuchten und softwaretechnische Lösungsstrategien aufzuzeigen.
Eine Verifizierung vorhandener Verbindungsmanager nach speziellen Kriterien, welche der
mobile Einsatz im Kraftfahrzeug mit sich bringt, bot hierbei die Grundlage für die
entwickelten Implementierungsstrategien. Die Notwendigkeit eine softwareinterne WLAN–
Verbindungsverwaltung zu schaffen um Netzwerkanbindungen in Abhängigkeit von
spezifischen Zuständen und Anforderungen anzustreben, führte zur Entwicklung der
Anwendung "WLANConnector" für das Embedded Betriebssystem Pocket PC 2003.
Hierbei bot das NDISUIO–Protokoll die benötigten Schnittstellen zur hardwarenahen
Manipulation der WLAN–Adapter. Der Umgang mit diesen APIs stellte sich dabei als recht
kompliziert heraus, da sich die Gerätezugriffe über mehrfach verschachtelte Strukturen als
sehr abstrakt erwiesen. Das Microsoft Developer Network (MSDN) bot hierbei zwar eine
recht ausführliche Beschreibung des Befehlssatzes und seiner Funktion, jedoch wurde dies
kaum mit praxisnahen Beispielen und Quelltextausschnitten untermauert.
Zusätzliche Korrespondenz in fachspezifischen Foren65 erwies sich als außerordentlich
hilfreich. Die bei umfangreichen Internetrecherchen ausfindig gemachte Wireless Research
API (WRAPI), welche wesentliche WLAN–spezifische NDISUIO–Operationen in modularer
Form enthält, konnte als implementierungstechnische Grundlage genutzt werden.
Hierbei wurden die aufgeführten Funktionen, welche für den Einsatz auf Windows XP
entwickelt wurden, an das Betriebssystem Pocket PC 2003 angepasst und in den
entsprechenden Kontexten verwertet. Unterschiede, die sich bei der Nutzung auf diesen
Plattformen ergaben, wurden berücksichtigt und sind in dieser Arbeit ausführlich
dokumentiert. Die Tatsache, dass sich das Verhalten von WLAN–Geräten in den zwei
Infrastrukturmodi grundlegend unterscheidet, führte zu gesonderter Untersuchung und
Softwarekonzipierung. Das Bestreben, eine vollständig einsatzfähige Anwendung zu
entwickeln, welche Benutzerinteraktion weitgehend vermeidet, band die weiterführende
Betrachtung der IP-Adressvergabe in das Projekt ein.
Die entwickelte Software konnte durch Integration von softwareintern eingebundenen
Anwendungskomponenten auf Praktikabilität getestet werden. Schwachstellen wurden daher
in den verschiedenen Implementierungsphasen erkannt und ausgemerzt.
Eine Portierung des entwickelten Softwaregerüstes für den Einsatz in einem Embedded
Automotive Framework, unter den Betriebssystem QNX, wurde durch grundlegende
systemspezifische Faktoren beeinträchtigt.
65
www.pocketpcdn.com/forum/
- 82 -
Ergebnis
Der Versuch interne WLAN–Adapter einzubinden scheiterte an der Tatsache, dass keine
funktionstüchtigen Treiber zur Verfügung standen.
Um einen Einstieg in die Geräteverwaltung im Allgemeinen und den Umgang mit
Netzwerkadaptern im Besonderen zu bieten, setzt sich die Arbeit im Weiteren mit
systemspezifischen Kommandos und ihren Funktionen auseinander.
Eine alternative Lösung zur drahtlosen Netzwerkanbindung wurde durch den Einsatz von
externen Ethernet–WLAN–Adaptern geschaffen. Damit war eine vollständige WLAN–
Integration in das vorhandene Labornetzwerk möglich. Nachteilig an diesem Verfahren ist
die eingeschränkte Konfigurierbarkeit dieser Geräte. Dem angeschlossenen Target sind
keine Möglichkeiten gegeben Adapterkonfigurationen vorzunehmen. Hiermit konnte das
einleitende Tankstellenszenario nachgebildet werden. Über eine Anwendung, welche eine
hergestellte Netzwerkanbindung dynamisch erkennt, wird eine Client-Server-Kommunikation
in die Wege geleitet, welche die Möglichkeit bietet automatisiert Daten auf das Target zu
transferieren.
11.2
Bewertung
Es wurde bewiesen, dass der WLAN–Einsatz in Kraftfahrzeugen mit individuellen
Softwarelösungen problemlos realisierbar ist.
Weiterhin konnten vorteilhafte Nutzungsszenarien vorgestellt werden, welche auf Tank– und
Raststätten, ebenso wie im privaten oder geschäftlichen Umfeld, umsetzbar sind und eine
komfortable dynamische WLAN–Netzwerkanbindung ermöglichen.
11.3
Ausblick
Beständige Weiterentwicklung des WLAN–Standards im Bezug auf Dynamik und
Signalreichweite erhöhen die Attraktivität der vorgestellten Lösungen.
So soll die Entwicklung eines 802.11p Standards speziell für den Einsatz im KFZ
zugeschnitten werden. Hierbei kommen eigens entwickelte Routingprotokolle zum Einsatz,
welche die Kommunikation über mehrere Netzwerkstationen hinweg ermöglichen sollen.
Diese so genannten Mesh–Netze [WIMAH05] wurden bereits in der Einleitung erwähnt.
Durch
erweiterte
Abtastverfahren,
Netzwerkpartnern
erkundet
Sekundenbruchteilen
wird,
ermöglicht
bei
denen
soll
eine
werden.
Ein
66
Geschwindigkeiten wird dadurch realisierbar.
die
Umgebung
Kommunikation
nach
verfügbaren
innerhalb
Verbindungsaufbau
bei
von
hohen
Einige Ansätze, welche auch bei der
Erforschung dieser zukunftsorientierten Technik von Bedeutung sind, wurden in dieser Arbeit
aufgezeigt und erläutert.
66
siehe: http://www.funkschau.de/heftarchiv/pdf/2005/fs13/fs_0513_s45.pdf
- 83 -
Ergebnis
Ein weiterer Vorzug der WLAN–Technologie ist die Unabhängigkeit von kommerziellen
Vermittlungsinstanzen.
UMTS (Universal Mobile Telecommunications System) bietet Datenübertragungsraten von
bis zu 2 Mbit/s und ist deutschlandweit großflächig verfügbar. Internetzugang kann somit fast
von überall erlangt werden. Die Tatsache, dass die Kommunikation über zentrale
Vermittlungsstellungen
gesteuert
wird,
schließt
jegliche
direkte
Interaktion
mit
Netzwerkknoten von vorneherein aus und ist daher für das behandelte Einsatzgebiet
bedeutungslos.
Abschließend kann gesagt werden, dass der WLAN–Technologie, gerade im mobilen
Bereich eine viel versprechende Zukunft prophezeit werden kann.
WLAN – Eine Technik mit Zukunft
- 84 -
A Abbildungsverzeichnis
2.1
Einordnung von IEEE 802.11 im ISO OSI Kommunikationsmodell . . . . . . . . . .
6
2.2
Infrastruktur–Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
Ad–hoc–Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
5.1
Windows 802.11 Netzwerktreiber–Architektur . . . . . . . . . . . . . . . . . . . . . . . . . .
25
6.1
Erzeugen des Worker Threads mit der Threadfunktion „ScanIP“ . . . . . . . . . . . .
44
7.1
Auslesen des Verbindungsstatus über NDISUIO . . . . . . . . . . . . . . . . . . . . . . . .
49
10.1
WLAN Integration ICM Labor FH–Darmstadt . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
B Screenshots
5.1
WZC–DLL in der Windows CE Registrierung . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
6.1
Definition der "WZC"–DLL in der Windows CE – Registrierung . . . . . . . . . . . . .
31
6.2
WLANConnector – Ad–hoc Netzwerkscan . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
6.3
WLANConnector – Ad–hoc verbunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
6.4
VOIP Telefon SJphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
7.1
WLANConnector – Infrastruktur Netzwerkscan . . . . . . . . . . . . . . . . . . . . . . . . .
50
7.2
WLANConnector – Infrastruktur verbunden . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
7.3
Informationsanwendung mit Webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
- 85 -
C Listings
5.1
Deaktivieren der Wireless Zero Configuration . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.2
Erzeugung eines NDISUIO–Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5.3
DeviceIoControl inklusive typisierter Parameter [MSDN05] . . . . . . . . . . . . . . . .
27
5.4
Beispiel für die Definition einer NDIS–OID . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
6.1
Generierung einer Zufallszahl für letztes Segment der IP–Adresse . . . . . . . . . .
31
6.2
Deklaration der Variablen innerhalb der swapIP–Funktion . . . . . . . . . . . . . . . . .
32
6.3
Erstellen oder Öffnen eines Registry Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
6.4
Schreiben der AutoIP–Variablen in CE Registrierung . . . . . . . . . . . . . . . . . . . .
33
6.5
Freigabe des Handles auf einen geöffneten Key . . . . . . . . . . . . . . . . . . . . . . . .
34
6.6
IpRenewAddress – Internet Protocol Helper API . . . . . . . . . . . . . . . . . . . . . . . .
35
6.7
Struktur NDISUIO_SET_OID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
6.8
Setzen des Infrastrukturmodus auf Ad–hoc . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
6.9
Setzen des Authentifizierungsmodus (Anpassung der WRAPI) . . . . . . . . . . . . .
39
6.10
Struktur NDIS_802_11_SSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.11
Setzen der SSID / BSSID / IBSSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.12
Erzeugen des Worker Threads mit der Threadfunktion „ScanIP“ . . . . . . . . . . . .
42
6.13
Sofwareinternes Starten der VOIP–Anwendung mit Hilfe von CreateProcess . .
46
7.1
Auslesen des Verbindungsstatus über NDISUIO . . . . . . . . . . . . . . . . . . . . . . . .
51
7.2
Sofwareinternes Starten des Internet Explorers mit spezifizierter Zielhost . . . . .
52
8.1
Enumeration der WLAN–Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
8.2
Ausgabe der enumerierten WLAN–Adapter über die Konsole . . . . . . . . . . . . . .
56
8.3
Assoziation des Handles mit dem WLAN-Adapter . . . . . . . . . . . . . . . . . . . . . . .
57
9.1
Initiierung eines BSSID LIST SCANS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
9.2
Aufschlüsselung der NDIS_WLAN_BSSID–Struktur . . . . . . . . . . . . . . . . . . . . .
62
9.3
Auslesen der in der BSSID–Liste enumerierten WLAN–Geräte . . . . . . . . . . . . .
64
9.4
Prioritätsgesteuerter Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
10.1
Softwareinterne Integration von WLAN–Systembefehlen . . . . . . . . . . . . . . . . . .
72
10.2
Softwareinterne Identifikation des Netzwerkpartners . . . . . . . . . . . . . . . . . . . . .
80
- 86 -
D Quellenverzeichnis
[AWAP02]
Arnold Willemer: APIPA – Automatic Private IP Addressing
http://www.willemer.de/informatik/net/apipa.htm
[JW04]
Joachim Wietzke, Manh Tien Tran: Softwareentwicklung für Embedded
Systeme, 2004
[MLMMS04] Dr. Marie-Louise Moschgath: Script zur Vorlesung „Sicherheit in der
Mobilkommunikation“, 2004
[MSDN05]
Microsoft Developer Network – http://msdn.microsoft.com/
[PPCDG05]
Pocket PC 2003 Help - Pocket PC 2003 Development Guide
[PPCDA05]
Pocket PC Developer Network – Article: Working with registry on Pocket PC
http://www.pocketpcdn.com/articles/registry.html
[PPCDF05]
PC Developer Network – Forum – http://www.pocketpcdn.com/forum/
[QNX05]
QNX Momentics (v6.3) Documentation
[WIEW05]
http://de.wikipedia.org/wiki/Wireless_Adapter
[WIOSI05]
http://de.wikipedia.org/wiki/ISO-OSI-Referenzmodell
[WIMFC05]
http://de.wikipedia.org/wiki/Microsoft_Foundation_Classes
[WINDIS05]
http://de.wikipedia.org/wiki/NDIS
[WIMAH05]
http://de.wikipedia.org/wiki/Mobiles_Ad-hoc-Netzwerk
[WITEL05]
http://de.wikipedia.org/wiki/Telnet
[WPDN103]
Windows Platform Design Notes - Native 802.11 Frameworks for IEEE 802.11
Networks, Microsoft 2003
[WPDN203]
Windows Platform Design Notes - IEEE 802.11 Network Adapter Design
Guidelines for Windows XP
[WRAPI05]
WRAPI Documentation
http://sysnet.ucsd.edu/pawn/wrapi/doc.html
- 87 -
E Eigenständigkeitserklärung
Hiermit erkläre ich, dass ich die vorliegende Bachelorarbeit selbständig und nur mit den
angegebenen Hilfsmitteln erstellt habe.
Darmstadt, den 18. Oktober 2005
Dirk Andres
- 88 -

Konzipierung und Implementierung von automatisiertem WLAN

Transcription

Similar documents

Vorlesung Betriebssysteme I Organisatorisches

Testen von Benutzeroberflächen - Department of Information Systems

DEL POSTO DIALETTOMETRICO ChE SPETTA AI PUNTI