Die Thesis zum Drucken

Transcription

Fachhochschule Wiesbaden
Fachbereich Design Informatik Medien
Studiengang Allgemeine Informatik
Bachelor-Thesis
zur Erlangung des akademischen Grades
Bachelor of Science - B.Sc.
Schnelles Roaming im WLAN
mittels Dual-Transceiver Stations
vorgelegt von Ralph Robert Erdt
am 20. Dezember 2007
Referent: Prof. Dr. Martin Gergeleit
Korreferent: Prof. Dr. Reinhold Kröger
II
Erklärung
Ich versichere, dass ich die Bachelor-Thesis selbständig verfasst und keine anderen als
die angegebenen Hilfsmittel benutzt habe.
Wiesbaden, 20.12.2007
Ralph Robert Erdt
Hiermit erkläre ich mein Einverständnis mit den im Folgenden aufgeführten Verbreitungsformen dieser Bachelor-Thesis:
Verbreitungsform
Einstellung der Arbeit in die
Bibliothek der FHW
Veröffentlichung des Titels der
Arbeit im Internet
Veröffentlichung der Arbeit im
Internet
Wiesbaden, 20.12.2007
ja
nein
√
√
√
Ralph Robert Erdt
III
IV
Inhaltsverzeichnis
1
Vorwort
1
2
Zielsetzung
3
3
Einleitung
5
3.1
WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.2
Roaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.3
Schwierigkeiten von Roaming . . . . . . . . . . . . . . . . . . . . . . .
8
3.3.1
Frequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.3.2
Auswirkungen . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4
Konzept
13
4.1
Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.1.1
Switched WLAN . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.1.2
Sync Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
4.1.3
802.11r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.2
Idee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.3
Möglichkeit A: Dezidiertes Scannen . . . . . . . . . . . . . . . . . . . .
15
4.3.1
Scannen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
Möglichkeit B: Wechselnde Aufgaben . . . . . . . . . . . . . . . . . . .
18
4.4
5
Implementierung
21
5.1
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.2
Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . .
22
5.3
Wireless Extensions for Linux . . . . . . . . . . . . . . . . . . . . . . .
22
5.4
madwifi-ng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
V
5.5
5.6
6
5.4.1
Virtuelle Devices mit madwifi-ng . . . . . . . . . . . . . . . . .
23
5.4.2
Probleme des madwifi-ng . . . . . . . . . . . . . . . . . . . . .
24
Umsetzung der Methode A . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.5.1
Übertragen der Scan-Informationen . . . . . . . . . . . . . . . .
25
5.5.2
I/O Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.5.3
Scannen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.5.3.1
Empfang der Pakete . . . . . . . . . . . . . . . . . . .
27
5.5.3.2
Verwaltung des Scannens . . . . . . . . . . . . . . . .
28
5.5.4
Hauptprogramm . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.5.5
Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.5.6
Ausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.5.7
Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
Umsetzung der Methode B . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.6.1
Unterschiede zwischen Variante I und II . . . . . . . . . . . . . .
32
5.6.2
Scannen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.6.3
Auslesen der Scandaten . . . . . . . . . . . . . . . . . . . . . .
33
5.6.4
Hauptprogramm . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.6.4.1
Variante II . . . . . . . . . . . . . . . . . . . . . . . .
34
5.6.5
Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.6.6
Ausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.6.7
Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
Messung
39
6.1
Erläuterung der Messung . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.1.1
Visualisierung mittels WI-Spy . . . . . . . . . . . . . . . . . . .
39
6.1.2
Ort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.1.3
Methodik, Messverfahren . . . . . . . . . . . . . . . . . . . . .
40
6.1.4
Störgrößen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
6.1.5
Messaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
6.1.5.1
Konfiguration . . . . . . . . . . . . . . . . . . . . . .
46
6.1.5.2
Erzwingen des Roamings . . . . . . . . . . . . . . . .
46
6.1.6
Durchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
6.1.7
Erläuterung des Vorgehens bei der Auswertung . . . . . . . . . .
49
VI
6.2
Messung der Methode „A“ . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.2.1
UDP-Versand von Festnetz auf die WLAN-Station . . . . . . . .
51
6.2.1.1
Auswertung UDP-Test . . . . . . . . . . . . . . . . . .
51
6.2.1.2
Auswertung Ethereal . . . . . . . . . . . . . . . . . .
51
UDP-Versand von der WLAN-Station auf das Festnetz . . . . . .
52
6.2.2.1
52
6.2.2.2
53
6.3
Messung der Methode „B I“ . . . . . . . . . . . . . . . . . . . . . . . .
54
6.4
Messung der Methode „B I b“ . . . . . . . . . . . . . . . . . . . . . . .
55
6.4.1
55
6.4.1.1
55
6.4.1.2
56
57
6.4.2.1
57
6.4.2.2
58
Messung der Methode „B II“ . . . . . . . . . . . . . . . . . . . . . . . .
59
6.5.1
59
6.5.1.1
59
6.5.1.2
59
61
6.5.2.1
61
6.5.2.2
61
6.2.2
6.4.2
6.5
6.5.2
7
Bewertung
63
7.1
Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
7.2
Methode A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
7.2.1
Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
7.2.2
Vorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
Methode B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
7.3.1
Methode B I b . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
7.3.2
Methode B II . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
7.3.3
Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
7.3.4
Vorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
Andere Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
7.3
7.4
VII
8
9
Fazit
67
8.1
Beurteilung der getesteten Methoden . . . . . . . . . . . . . . . . . . . .
67
8.2
Beurteilung der Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . .
67
8.2.1
Vergleich zu „Switched WLAN“ . . . . . . . . . . . . . . . . . .
68
8.2.1.1
Vergleich der Zeiten . . . . . . . . . . . . . . . . . . .
68
8.2.2
Vergleich zu „Sync Scan“ . . . . . . . . . . . . . . . . . . . . .
69
8.2.3
Vergleich zu „802.11r“ . . . . . . . . . . . . . . . . . . . . . . .
69
8.3
Energie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
8.4
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
8.5
Sonstiges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
8.5.1
70
Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anhang
71
9.1
Installation von SuSE 10.2 auf einem WRAP . . . . . . . . . . . . . . .
71
9.1.1
Voraussetzung . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
9.1.2
Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
9.1.3
Software installieren . . . . . . . . . . . . . . . . . . . . . . . .
73
9.1.4
Kernel und Module kompilieren . . . . . . . . . . . . . . . . . .
74
9.1.5
Die Karte bootfähig machen . . . . . . . . . . . . . . . . . . . .
75
9.1.6
WRAP verbinden . . . . . . . . . . . . . . . . . . . . . . . . . .
77
9.1.7
Erster Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
9.1.8
Allgemeine Hinweise . . . . . . . . . . . . . . . . . . . . . . . .
78
9.1.9
Klonen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
9.1.9.1
Karte auslesen . . . . . . . . . . . . . . . . . . . . . .
78
9.1.9.2
Karte bespielen . . . . . . . . . . . . . . . . . . . . .
79
9.1.9.3
Einstellungen korrigieren . . . . . . . . . . . . . . . .
79
UDP-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
9.2.1
Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
9.2.2
Arbeitsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
9.2.2.1
Senden . . . . . . . . . . . . . . . . . . . . . . . . . .
80
9.2.2.2
Empfangen . . . . . . . . . . . . . . . . . . . . . . . .
81
9.2.3
Ausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
9.2.4
Anleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
9.2
VIII
10 Literaturverzeichnis
83
11 Weblinks Verzeichnis
85
IX
X
Abbildungsverzeichnis
3.1
Verhältnis von Entfernung zur Verbindungsgeschwindigkeit, Quelle: Texas Instruments 2002 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Empfangsstärke und damit erreichbare maximale Geschwindigkeit, Quelle: [Ahl02] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Screenshot Ausleuchtungstools. links: Ringmaster, rechts: FL Wireless Simulation Tool Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.4
Roaming: Eine Station wechselt in eine andere Zelle . . . . . . . . . . .
8
4.1
Sync Scan: Versatz zwischen den Beacons. . . . . . . . . . . . . . . . . .
14
4.2
Schaubild: Vorgang des Roamens von Access Point 1 nach Access Point
2, Methode A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.3
Aufbau eines Beacons. Quelle [HM03] . . . . . . . . . . . . . . . . . . .
17
4.4
Schaubild: Vorgang des Roamens von Access Point 1 nach Access Point
2, Methode B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
5.1
WRAP2e mit Gehäuse . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.2
Diagramm des struct w2l2_setzeAP . . . . . . . . . . . . . . . . . . . .
26
6.1
Screenshot WI-Spy. Normale Nutzung des Kanal 6 (g) . . . . . . . . . . .
40
6.2
Logo des w2l2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.3
Screenshot WI-Spy. Störung durch eine Mikrowelle . . . . . . . . . . . .
43
6.4
Messaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
6.5
Folienabschirmung der Antenne . . . . . . . . . . . . . . . . . . . . . .
47
6.6
Screenshot WI-Spy, Traffic der Messung: Methode A, UDP-Pakete werden
von Festnetz an das WLAN-System gesendet . . . . . . . . . . . . . . . .
48
6.7
Methode B I, Schema Netzverbindung . . . . . . . . . . . . . . . . . . .
54
6.8
Methode B I, Screenshot Wireshark . . . . . . . . . . . . . . . . . . . . .
55
3.2
3.3
XI
XII
Tabellenverzeichnis
3.1
ISO OSI Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5.1
Beispiel des logischen Aufbaus der Scan-Daten . . . . . . . . . . . . . .
34
6.1
Liste aller MAC Adressen aller Geräte . . . . . . . . . . . . . . . . . . .
45
6.2
Messung: Methode A, Netz → WLAN. Versatz der dump Dateien . . . . .
51
6.3
Messung: Methode A, Netz → WLAN. Roaming Zeiten Layer 2 . . . . . .
52
6.4
Messung: Methode A, WLAN → Netz. Versatz der dump Dateien . . . . .
53
6.5
Messung: Methode A, WLAN → Netz. Roaming Zeiten Layer 2 . . . . . .
53
6.6
Messung: Methode B I b, Netz → WLAN. Versatz der dump Dateien . . .
56
6.7
Messung: Methode B I b, Netz → WLAN. Roaming Zeiten Layer 2 . . . .
57
6.8
Messung: Methode B I b, Fehlende Pakete dem Roaming-Vorgang zugeordnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
Messung: Methode B I b, WLAN → Netz. Versatz der dump Dateien . . .
58
6.10 Messung: Methode B I b, WLAN → Netz. Roaming Zeiten Layer 2 . . . .
58
6.11 Messung: Methode B II, Netz → WLAN. Versatz der dump Dateien . . . .
60
6.12 Messung: Methode B II, Netz → WLAN. Roaming Zeiten Layer 2 . . . . .
60
6.13 Messung: Methode B II, WLAN → Netz. Versatz der dump Dateien . . . .
62
6.14 Messung: Methode B II, WLAN → Netz. Roaming Zeiten Layer 2 . . . . .
62
8.1
68
6.9
Roamingzeiten Switched WLAN Systeme [Sar07] . . . . . . . . . . . . .
XIII
XIV
Verzeichnis der Quellcodes
5.1
Erzeugen eines STA Interfaces . . . . . . . . . . . . . . . . . . . . . . .
23
5.2
Erzeugen eines Monitor-Interfaces . . . . . . . . . . . . . . . . . . . . .
23
5.3
Ändern der Sendekraft . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.4
Linux/include/asm-generic/ioctl.h . . . . . . . . . . . . . . . . . . . . .
27
5.5
Radiotap Header für den MadWifi aktivieren . . . . . . . . . . . . . . . .
28
5.6
Vorbereitungsskript für Methode A . . . . . . . . . . . . . . . . . . . . .
30
5.7
Ausgabe der Methode A . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.8
Vorbereitungsskript für Methode B . . . . . . . . . . . . . . . . . . . . .
35
5.9
Ausgabe der Methode B . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.10 Ausgabe der Methode B II, Fehlermeldung . . . . . . . . . . . . . . . . .
36
6.1
Dump des Netzwerkverkehrs auf dem WLAN . . . . . . . . . . . . . . . .
47
6.2
Wireshark Filter zum ausblenden der Beacons . . . . . . . . . . . . . . .
50
6.3
Methode A, Netz → WLAN. Ausgabe UDP-Test . . . . . . . . . . . . . .
51
6.4
Methode A, WLAN → Netz. Ausgabe UDP-Test . . . . . . . . . . . . . .
52
6.5
Methode B I b, Netz → WLAN. Ausgabe UDP-Test . . . . . . . . . . . .
55
6.6
Methode B I b, WLAN → Netz. Ausgabe UDP-Test . . . . . . . . . . . .
57
6.7
Methode B II, Netz → WLAN. Ausgabe UDP-Send . . . . . . . . . . . .
59
6.8
Methode B II, WLAN → Netz. Ausgabe UDP-Test . . . . . . . . . . . . .
61
9.1
Aufruf von fdisk, wenn die Karte nach sda gemountet wurde . . . . . . . .
72
9.2
Formatieren der Partitionen . . . . . . . . . . . . . . . . . . . . . . . .
72
9.3
Auswerfen der Karte . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
9.4
Mounten der Karte . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
9.5
Konfigurieren des Kernels . . . . . . . . . . . . . . . . . . . . . . . . . .
74
9.6
Kernel kompilieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
9.7
Kernel kopieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
XV
9.8
Module kompilieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
9.9
Module kopieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
9.10 RAM-Disk generieren . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
9.11 Boot-Loader (grub) installieren . . . . . . . . . . . . . . . . . . . . . . .
75
9.12 Serielle Ausgabe des Grubs aktivieren . . . . . . . . . . . . . . . . . . .
75
9.13 Serielle Ausgabe des Kernels aktivieren . . . . . . . . . . . . . . . . . .
76
9.14 Seriellen Login aktivieren . . . . . . . . . . . . . . . . . . . . . . . . . .
76
9.15 Login als root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
9.16 Login als root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
9.17 fstab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
9.18 damit kann der sshd starten . . . . . . . . . . . . . . . . . . . . . . . . .
77
9.19 Rechtekorrektur, um kermit als normaler User zu nutzen . . . . . . . . . .
77
9.20 kermit Befehle, um sich zu verbinden . . . . . . . . . . . . . . . . . . . .
77
9.21 Befehle für den ersten Start . . . . . . . . . . . . . . . . . . . . . . . . .
78
9.22 LED Steuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
9.23 Unmounten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
9.24 low-level kopieren: Karte auslesen . . . . . . . . . . . . . . . . . . . . .
79
9.25 low-level kopieren: Karte beschreiben . . . . . . . . . . . . . . . . . . .
79
9.26 IP Adresse setzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
9.27 Beispielausgabe UDP-Test, Empfangsmodus . . . . . . . . . . . . . . . .
81
XVI
Kapitel 1
Vorwort
Das Studium ist für mich wesentlich besser gelaufen, als ich gedacht und gehofft hatte.
Daher will ich mich bei Allen bedanken, die an mich geglaubt und mich unterstützt haben;
dadurch wurde mein Studium erst möglich gemacht!
Ich bedanke mich bei:
Meiner Familie, die mir sowohl finanziell über so manchen Engpass hinweggeholfen haben, als auch moralisch immer wieder den Rücken gestärkt hat.
Der Firma Makrolog AG, die mir nicht nur zwei Jahre lang einen sichern Verdienst gegeben habt, sondern auch sehr verständnisvoll mit meinem studentischen Problemen umgegangen ist.
Meinen Kommilitonen, die mit meinen Eigenarten sehr gut umgegangen sind. Insbesondere Andreas Textor, der nicht nur viele Nerven auf meine Rechtschreibung verwendet
hat, sondern auch einige Projekte mit mir gemeinsam erfolgreich durchgezogen hat. Auch
will ich mich bei Frank Meffert bedanken, der mir einige gute Tips für die Thesis gegeben
hat.
Den Professoren:
Herrn Prof. Dr. Gergeleit, der mir nicht nur einen Arbeitsstelle im w2l2 (Wiesbadener
Wireless LAN Labor) gegeben hat, sondern auch die Möglichkeit, die Thesis „verfrüht“
zu schreiben.
Herrn Prof. Dr. Kleuker, der unseren Jahrgang vier Semester lang begleitet hat, und somit
ein fester Ruhepol in dem sonst unruhigen Studentenleben war.
Auch will ich mich bei der großen Open Source Community bedanken, ohne deren Wirken und Schaffen ein wesentlicher Bestandteil dieser Arbeit nicht entstanden wäre.
1
Kapitel 1. Vorwort
Zuletzt will ich mich noch beim BaFög-Amt bedanken. Sowohl für die ungewollt tiefen
Einblicke in die Deutsche Bürokratie, als auch, daß ich dadurch bei bei einigen Banken /
Ämtern / Versicherungen einen bleibenden Eindruck hinterlassen habe.
2
Kapitel 2
Zielsetzung
Wireless LAN wird heutzutage in vielen Bereichen genutzt. Neben dem trivialen Datentransfer (zum Beispiel für das Surfen von einem mobilen Laptop aus) wird es verstärkt
für Echtzeitanwendungen, wie zum Beispiel Voice over IP, genutzt. Auch in der Automatisation wird WLAN verstärkt eingesetzt, zum Beispiel in autonom fahrenden Robotern.
Für diese Bereiche ist heutzutage die Bandbreite kein kritischer Faktor mehr. Kritischer
sind vielmehr Latenzzeiten, Jitter und Nachrichtenverlustrate. Im 802.11e Standard gibt
es daher Mechanismen, diese Quality of Service Anforderungen zu erfüllen. Diese QoSMechanismen sind allerdings nur für eine Zelle definiert. Zellwechsel, das so genannte
Roaming, wurde bisher weniger betrachtet.
Die Zeiten des normalen, clientseitigen Roamings beim WLAN liegen heutzutage immer
noch im Bereich von mehreren 100 ms. Bestimmte Systeme und Vorgehensweisen können
diese Zeiten auf ca. 100ms drücken. Damit erfüllen diese Systeme aber immer noch nicht
die Anforderungen der oben genannten Anwendungen.
Das Ziel dieser Arbeit ist es nun, ein Roaming zu realisieren, das im Bereich von wenigen
10ms liegt. Dazu wird untersucht in welchem Umfang dazu eine zweite WLAN-Karte
verwendet werden kann.
Die Untersuchung beschränkt sich dabei auf den eigentlichen Roaming-Vorgang. Verschlüsselte Verbindungen, zum Beispiel mittels WPA und dem damit verbundenem
Schlüssel-Management, wird nicht näher betrachtet, da diese Aspekte undabhängig sind.
Die Aspekte des Schlüssel-Management beim Roaming wird in der laufenden Standardisierung der IEEE 802.11r Task Group "Fast Roaming"betrachtet.
3
Kapitel 2. Zielsetzung
4
Kapitel 3
Einleitung
3.1
WLAN
Wireless LAN (WLAN, IEEE802.11 [IEE]) ist eine Netzwerktechnologie, die auf Funk
basiert: Die Computer oder ähnliche Systeme (wie z.B. PDAs, Handscanner, etc.) kommunizieren über Funk miteinander. So sind die Systeme mobil und nicht ortsgebunden.
Im ISO OSI Schichtenmodell ist dieses auf Layer eins (Physikalische Schicht) und Layer
zwei (Sicherungsschicht) / MAC angeordnet.
Layer Bezeichnung „Sublayer“
7
Anwendung
6
Darstellung
5
Sitzung
4
Transport
3
Vermittlung
2
Sicherung
1
Physikalisch
LLC (Logical Link Control)
MAC (Media Access Control)
Tabelle 3.1: ISO OSI Schichtenmodell
Ein abgekapseltes Funknetz ohne Verbindung zu einem festen Netz (Hausnetz, Firmennetz und sogar: Internet) ist allerdings nur von begrenzter Nützlichkeit. Es werden auch
Zugriffe auf Rechner, bzw. Systeme eines stationären Netzes gebraucht. Zum Beispiel,
um Messdaten zu speichern, oder im Lager die nächsten Aufträge zu holen. Oder man
5
3.1. WLAN
Kapitel 3. Einleitung
will ganz trivial draußen unter dem Baum im Internet surfen.
Als Vermittler hierzu gelten so genannte „Access Points“ (APs). Diese sind stationär und
an ein stationäres Netz angeschlossen (meist mittels eines Netzwerkkabels, wie z.B. Twisted Pair, also IEEE 802.3). An diesen Access Points kann sich ein WLAN-System anmelden und dann über diesen Access Point in das angeschlossene Netzwerk kommunizieren.
Die maximale Entfernung von WLAN beträgt bei 802.11b (11MBit/s bei 2,4 GHz) auf
„freier Wiese“, also ohne Hindernisse zwischen Sender und Empfänger, theoretisch bis
zu 500m ([HM03], Seite 165), bei den in Deutschland maximal 100mW erlaubten Sendeleistung [VWL] .
Aber die Verbindungsqualität nimmt mit der Entfernung ab. Um da noch mit der Gegenstelle kommunizieren zu können, reduzieren die WLAN-Interfaces die Übertragungsgeschwindigkeit.
Abbildung 3.1: Verhältnis von Entfernung zur Verbindungsgeschwindigkeit, Quelle: Texas
Instruments 2002
Allerdings wird WLAN kaum auf freier Fläche, sondern in Gebäuden (Büro oder Produktsionsräume) eingesetzt. Solche Räume bestehen aus funktechnischer Sicht aus vielen
Hindernissen: Wände, Schränke (Metall), selbst eine große Hydrokultur kann das Signal
dämpfen. Zusätzlich wird das Funksignal nicht nur gedämpft sondern teilweise auch reflektiert. Dadurch beträgt die typische maximale Reichweite nur noch 40 Meter [Ahl02].
Durch diese starke Beschränkung kann ein Access Point alleine maximal kleine Büroräume versorgen. Um größere Büroräume, oder einen ganzes Firmengelände zu versorgen
braucht man mehrere Access Points, die „strategisch“ über das ganze Gelände verteilt
sind. Wenn man mehr Access Points als notwendig verwendet, und damit den Abstand
zwischen den Access Points verringert, dann kann man einen höhere Durchsatz erwarten, da die Stationen immer ein Access Point in der Nähe haben. Dadurch müssen die
6
3.2. Roaming
Abbildung 3.2: Empfangsstärke und damit erreichbare maximale Geschwindigkeit, Quelle: [Ahl02]
WLAN-Stationen nicht über eine „große“ Strecken funken, und müssen daher nicht auf
eine langsamere Übertragungsgeschwindigkeit zurückgreifen.
Für die Planung gibt es so genannte „Ausleuchtungstools“, wie z.b. den Ringmaster von
Trapeze Networks [Rin] oder das FL Wireless Simulation Tool Basic von Phoenix Contact. In diesen Programmen zeichnet man den Grundriss der Büros nach, inklusive der
Möbel und sonstiger Hindernisse. Diese geben dann graphisch aus, wo welche Empfangsstärke zu erwarten ist. Obwohl das theoretische Werte sind, die durch reale Messungen
gefestigt werden müssen, können die Simulationsergebnisse ein guter Anhaltspunkt für
eine optimale Verteilung der Access Points ergeben.
Abbildung 3.3: Screenshot Ausleuchtungstools. links: Ringmaster, rechts: FL Wireless
Simulation Tool Basic
3.2
Roaming
Ortsgebundene Systeme werden nur selten mit WLAN ausgestattet, da eine feste Verkabelung mehr Durchsatz und eine höhere Sicherheit bieten. Nur in speziellen Fällen, wenn
7
3.3. Schwierigkeiten von Roaming
man kein Kabel legen kann (zum Beispiel weil das Gebäude denkmalgeschützt ist) wird
man solche Systeme mit WLAN ausstatten.
WLAN wird daher mehr bei mobilen Systemen eingesetzt. Aber dadurch, daß diese Systeme mobil sind, können diese sich auch aus dem Funkbereich des Access Points (auch
„Zelle“ genannt), an dem sie angemeldet sind, entfernen. So verlieren diese Systeme die
Verbindung zum Access Point, und daher auch zum stationären Netz. Wenn allerdings
dieses System in den Bereich eines anderen Access Points kommt, so kann es sich zu
diesem Access Point verbinden, und hat wieder Zugriff auf das stationäre Netz. Im Idealfall überlappen sich die Zellen beider Access Points, sodas die Station schnell umschalten
kann. Den kombinierten Vorgang von Abmelden von einem Access Point und anmelden
an einen anderen Access Point nennt man Roaming.
In den mobilen Telekomunikationsnetzen (GSM, UMTS, etc.) nennt man diesen Vorgang
auch „Handover“, bzw. „Cell-Handover“.
Abbildung 3.4: Roaming: Eine Station wechselt in eine andere Zelle
3.3
3.3.1
Schwierigkeiten von Roaming
Frequenzen
Für WLAN sind in Europa im 2.4 GHz Band dreizehn Kanäle ([HM03], Seite 63), in
Amerika elf Kanäle, mit einem Frequenzabstand von fünf MHz definiert. Dieses gilt aber
nur für den 802.11b Standart. Der 802.11g Standart nutzt auch diese Kanäle, braucht aber
ein Spektrum von 20 Mhz. Um möglichst kompatibel zu bleiben, nutzt der 11g Standart
die gleiche Kanalbelegung wie der 11b Standart. Das hat aber zur Folge, daß ein 11g Gerät
8
auch auf den benachbarten Kanälen sendet. Wenn eine Station auf Kanal sechs sendet, so
nutzt das die Kanäle vier bis acht mit. Eine zweite 11g Station, die auf diesen Kanälen
liegt wird dadurch gestört. Diese Station kann aber noch erkennen, daß eine Übertragung
stattfindet, so daß sich die beiden Stationen abstimmen können. Sollte der zweite Sender
aber in einem der nahen benachbarten Kanäle liegen, zum Beispiel auf Kanal neun, so
stören sich diese beiden Sender, ohne daß die sich abstimmen können.
Dadurch ergibt sich eine maximale Anzahl von drei nutzbaren Kanälen im 11g Betrieb.
In Europa sind das die Kanäle eins, sieben und dreizehn. Dadurch hat man je ein Kanal
(vier und zehn) als Puffer. Wenn man zu den amerikanischen WLAN-Karten kompatibel
bleiben will (zum Beispiel, weil amerikanische Kollegen sich in das Netz einklinken),
sollte man sich auf die Kanäle eins bis elf beschränken. Die Aufteilung der 11g Kanäle
ist dann: eins, sechs und elf.
Im 5GHz Band sind außerdem zwölf und fünf Kanäle definiert ([Kaf05], Seite 78). Die
zwölf Kanäle für eine normale Geschwindigkeit, und die weiteren fünf für den so genannten „Turbo Modus“.
In Deutschland ist das 2.4 GHz Band mehr genutzt als das 5 GHz Band, da das 5 GHz
Band in Deutschland lange Zeit nicht lizenzfrei genutzt werden durfte [Ger07].
3.3.2
Auswirkungen
Das Funknetz ist ein so genanntes „Shared Medium“. Das heißt, daß es viele Stationen
gibt, die auf das gleiche Medium senden. Wenn mehrere Stationen gleichzeitig - oder fast
gleichzeitig senden, dann überlagern sich die Signale. Man spricht von einer Kollision.
Die Empfänger sind nicht in der Lage, das empfangene Signal einer Station zuzuordnen, oder gar beide Datenströme zu demultiplexen. Die Übertragung aller Sender ging
verloren, und muss wiederholt werden. Aus diesem Grund ist im 802.11 Standart ein CSMA/CA1 Verfahren festgelegt: Jede Station sendet im Layer zwei Frame mit, wie lange es
brauchen wird (Feld „Duration“). Sollten mehrere Frames verschickt werden so wird die
Gesamtdauer aller Frames angegeben. Die anderen Station warten diese Zeit, plus eine
genügend lange Zeit für das „ACK“ ab. Dieses vermindert Kollisionen, aber vermeidet
diese nicht komplett. Daher kann eine Station auf stark belasteten Medien erst ein kurzes
Frame - ohne Daten - verschicken, mit dem diese Station nur den Kanal belegt. Das Frame heisst „RTS“ - Request to Send. Der Access Point antwortet darauf mit „CTS“ - Clear
to Send. Die Wahrscheinlichkeit einer Kollision ist durch die Kürze des Paketes geringer.
1
Carrier Sense, Multiple Access / Collision Avoidant
9
Sollte es trotzdem zu einer Kollision kommen, ist es nicht sehr teuer, da eine wesentlich
geringere Zeit verloren geht, als wenn ein großes Datenpaket kollidiert.
Durch diese ganzen Mechanismen sind Kollisionen unwahrscheinlich. Die Stationen müssen sich aber immer noch die knappe Ressource „Bandbreite“ teilen. Um die Wahrscheinlichkeit von Kollisionen noch weiter zu verringern und um zusätzlich mehr Bandbreite zu
nutzen, können die Access Points auf verschiedene Frequenzen eingestellt werden (Frequenzmultiplexing).
Ein Transceiver, also die Sende/Empfangseinheit des Netzwerksinterfaces, kann nur auf
eine Frequenz justiert werden. Es kann daher nicht die Signale der Access Points auffangen, die mit einer anderen Frequenz arbeiten.
Wenn sich eine Station einen „Überblick“ verschaffen will, so hat diese Station zwei
Möglichkeiten:
Diese kann aktiv oder passiv scannen.
Jeder Access Point verschickt in regelmäßigen Abständen ein „Beacon“ Signal (Beacon,
deutsch: „Leuchtfeuer“), mit dem er sich bekannt macht, und alle seine technischen Daten
verschickt. Dieses Signal wird normalerweise alle 100ms verschickt. Dieses kann man für
einen passiven Scan verwenden:
Bei einem passiven Scan muss die Station nacheinander auf alle Frequenzen schalten. Bei
jeder Frequenz muss es auf Beacons warten und diese auswerten.
Für einen aktiven Scan muss die Station wie beim passiven Scan auch auf alle Frequenzen schalten. Bei jeder Frequenz muss die Station ein „Probe Request“ Signal schicken.
Auf dieses Signal antworten alle erreichten Access Points mit einem „Probe Response“
Signal. Auf dieses Signal muss die Station nur sehr kurze Zeit warten, bis es zur nächsten
Frequenz wechseln kann.
Der passive Scan hat den Nachteil, das es extrem lange dauert. Bei einem Beacon-Intervall
von 100ms muss die Station mindestens 100ms plus doppelte der Übertragungszeit des
Beacons warten. Das Doppelte daher, da das Beacon schon gesendet werden könnte, wenn
die Station gerade auf diesen Kanal umschaltet. Dieses Beacon empfängt die Station dann
aber nicht mehr. Um sicherzugehen, das die Station alle Beacons empfängt, sollte die Station aber 200ms in jedem Kanal verweilen. Bei dreizehn Kanälen sind das dann 2,6 Sekunden, plus die Zeit, die die WLAN-Karte braucht, um den Transceiver auf eine andere
Frequenz umzuschalten.
Der aktive Scan hat zwar den Vorteil, das die WLAN-Karte nur sehr kurz bei einer Frequenz verweilen muss, allerdings wird durch das Versenden des „Probe-Request“ Signals
10
das Medium belastet, da während dieser Zeit keine andere Station senden kann. Es können
dadurch sogar Kollisionen auftreten. Bei wenigen Stationen fällt das nicht ins Gewicht.
Allerdings wenn viele Stationen alle paar Sekunden scannen, so ist das unnötiger Traffic.
Bei beiden Scan Varianten kann die WLAN-Karte einige Zeit nicht auf Ihrer eigentlichen
Frequenz arbeiten, und verliert so Pakete. Aktuelle Treiber können dem Paketverlust vorbeugen, indem Sie dem Access Point mitteilen, das diese in den Powersave Modus gehen.
Dadurch cached der AccessPoints solange die Pakete, bis diese wieder abgeholt werden.
Zusätzlich muss die Station auch die zu sendenden Pakete zurückhalten, bis die Station wieder im eigentlichen Kanal ist. So wird zwar dem Paketverlust vorgebeugt, aber
es kommt zu einer zusätzlichen Verzögerung (Delay) in der Übertragung. Diese Verzögerung kann gerade Echtzeitanwendungen stören, da dieses zum Bufferunderrun durch
einen unerwartet hohen Jitter (Abweichung des Delays) kommen kann.
11
12
Kapitel 4
Konzept
4.1
4.1.1
Verwandte Arbeiten
Switched WLAN
Große Installationen arbeiten mit einem „Switched WLAN“. In einem switched WLAN
sind die Access Points „dumme Antennen“ eines zentralen Switches. Diese Access Points
geben einen großen Teil ihrer „Intelligenz“ an den zentralen Switch ab. Daher nennt man
diese Access Points auch „Thin APs“.
Die Access Points leiten einfach die gesamte empfangene Kommunikation an den zentralen Switch weiter. Dieser entscheidet dann, was damit zu tun ist. Der Switch leitet also
nicht nur die Datenpakete weiter, sondern kann auch die Access Points steuern, die Nutzer
authentifizieren, u.v.m. Dadurch wird die gesamte Verwaltung an einen zentralen Punkt
verlagert. Dieses hält die Administrationskosten niedrig.
In der Diplomarbeit von Uwe Mülder von 2005 [Mü05] ist ein ausführlicher Überblick
über Switched WLAN enthalten.
Um in dieser Umgebung ein schnelles Roaming zu gewährleisten, gibt es zwei Ansätze:
Die Firma Extricom zum Beispiel lässt alle Access Points auf dem selben Kanal senden,
und spannt so eine virtuelle Zelle über alle Zellen auf. Das mobile System merkt also
nicht, wenn es von einem anderen Access Points Daten gesendet bekommt.
Ein anderer Ansatz ist der 802.11V Standard. Die Access Points, bzw. der zentrale Switch
sollte die Möglichkeit bekommen, die WLAN-Karten in den Stationen zu steuern. So
kann zum Beispiel der zentrale Switch, sobald dieser erkennt, daß er die WLAN Station
13
4.1. Verwandte Arbeiten
Kapitel 4. Konzept
über einen anderen Access Point besser versorgt wäre (z.B. wegen Signalstärke, Auslastung der Zelle oder Wartungsarbeiten), das Roaming anstoßen. Dazu gibt dieser der
WLAN-Karte der Station den Befehl, auf einen anderen Access Point zu wechseln. Das
Roaming ist also transparent für die überliegenden Protokolle und Anwendungen, und an
der WLAN-Station selber sind keine weiteren Arbeiten notwendig.
Frau Nuray Saracoglu hat 2007 in ihrer Diplomarbeit [Sar07] die Switched-WLAN Lösungen von Aruba, Extricom und Cisco vermessen.
4.1.2
Sync Scan
Eine von Ishwar Ramani and Stefan Savage an der University of California in San Diego
ausgegebenes Papier [RS05] beschreibt, wie man die Scan-Zeiten minimieren kann.
Die Autoren schlagen vor, daß die Access Points die Beacons mit definierten Abständen
zueinander schicken.
Wenn also die Access Points auf Kanal eins die Beacons zum Zeitpunkt t schicken, so
schicken die Access Points auf den anderen Kanälen die Beacons zum Zeitpunkt t +
(Kanal − 1) ∗ d. Ein Access Point auf Kanal zwei würde also zum Zeitpunkt t + d sein
Beacon abschicken. Ein Access Point auf Kanal 3 zum Zeitpunkt t + 2 ∗ d.
Abbildung 4.1: Sync Scan: Versatz zwischen den Beacons.
Durch den Zeitpunkt des Beacon Signals des Access Points, mit dem die WLAN Station
14
Kapitel 4. Konzept
4.2. Idee
verbunden ist, kann diese relativ genau ermitteln, wann die Beacons auf den anderen
Kanälen gesendet werden.
Zum Scannen muss die WLAN Station nur kurz vorher auf einen anderen Kanal wechseln,
und empfängt dann schnell die Beacons. Die Wartezeit reduziert sich dadurch drastisch.
So verringert sich auch die Zeit drastisch, in dem die Station nicht auf dem ursprünglichen
Kanal ist, und Daten verliert. Zusätzlich hat das den Vorteil gegenüber dem aktiven Scan,
daß diese Methode den Kanal nicht zusätzlich mit „Probe Response“ Paketen belastet.
4.1.3
802.11r
Aktuell ist die Taskgruppe „r“ der IEEE 802.11 dabei, einen Standard für das Fast Roaming zu definieren. Ziel ist es, das Roaming schnell genug für Voice over IP und ähnlich
zeitkritische Anwendungen zu machen. Ein Hauptaugenmerk fällt darauf, die Reauthentifizierung am neuen Access Point durch deutlich wenigere Pakete zu beschleunigen.
4.2
Idee
Aufgrund des notwendigen Kanalwechsels - sowohl für das Scannen, wie in der Einleitung beschrieben, als auch beim eigentlichem Roamen - ist ein schnelles clientseitiges
Roaming über mehrere Frequenzen mit nur einen Transceiver, also einer WLAN-Karte,
im Rahmen der Anforderungen nicht möglich.
Kostengünstige industrielle Systeme kosten ca. 400 Eur. Selbst günstige aktuelle Laptops
kosten noch 500 Eur und mehr. Eine WLAN Karte oder Modul kostest ca. 20 Eur. Das
sind ca. 5% der Gesamtkosten, und sind daher heutzutage keine Kostenfaktoren mehr.
Aus diesem Grund kann man auch zwei WLAN Karten oder Module verbauen.
Durch den Einsatz von zwei WLAN-Karten ergeben sich mehrere Möglichkeiten, ein
Clientseitiges Roaming zu implementieren.
4.3
Möglichkeit A: Dezidiertes Scannen
Mit einem WLAN Interface wird die Verbindung gehalten. Das andere Interface setzt man
nur zum Scannen ein.
15
4.3. Möglichkeit A: Dezidiertes Scannen
Kapitel 4. Konzept
Während das Hauptinterface immer die Netzwerkverbindung hält, scannt das andere Interface regelmäßig. Ein Programm auf der Station vergleicht regelmäßig die Empfangsstärke des Access Points, mit dem das Hauptinterface verbunden ist, mit dem Access
Point, der aktuell am besten zu empfangenen ist. Sollte der stärkste Access Point wesentlich stärker sein, dann muss es sich vom aktuellen Access Point abmelden und bei dem
neuen Access Point anmelden.
Man muss davon ausgehen, daß die Antennen beider Interfaces unterschiedlich sind. Die
Antennen haben nicht nur eine andere räumliche Position, sondern die Ausrichtung kann
um wenige Grad abweichen. Auch die Verarbeitungsqualität kann unterschiedlich sein.
Dadurch empfangen die Interfaces die WLAN-Übertragung nicht mit der gleichen Stärke,
sondern mit einer leicht unterschiedlichen Stärke. Deswegen darf man nicht die Stärke der
Signale vom Hauptinterface mit der Stärke der Signale vom Scan-Interface vergleichen.
Zum Beurteilen, ob ein Access Point stärker sendet als der Access Point, mit dem die
Station aktuell verbunden ist, muss man beide Werte aus dem Scan-Interface lesen. Sonst
kann es dazu führen, daß entweder erst sehr spät geroamt wird, oder es zwischen zwei
Access Points hin und her schaltet.
Bei dieser Methode ist die Station nur eine kurze Zeit, und das nur zu bestimmten Augenblicken, vom Netzwerk getrennt. Der Paketverlust sollte sich also in Grenzen halten, und
gegebenenfalls von den Protokollen der höheren Schichten aufgefangen werden.
Abbildung 4.2: Schaubild: Vorgang des Roamens von Access Point 1 nach Access Point
2, Methode A
16
Kapitel 4. Konzept
4.3.1
4.3. Möglichkeit A: Dezidiertes Scannen
Scannen
Ein weiteres Problem ist, daß der Access Point mit dem Beacon oder Probe Response Signal wichtige technische Informationen mitliefert, die notwendig sind, um sich zu diesem
Access Point zu verbinden, wie z.B. die unterstützten Protokolle, Frequenz, u.s.w. (siehe
Abbildung 4.3). Diese Informationen sind zwar im Treiber des Scan-Interfaces enthalten,
aber nicht im Treiber des Hauptinterfaces. Das Hauptinterface müsste also auch noch
einmal scannen, um diese Information zu finden. Um dieses zu vermeiden, muss eine
Möglichkeit gefunden werden, die Scan-Informationen zu übergeben.
Abbildung 4.3: Aufbau eines Beacons. Quelle [HM03]
Die Treiber internen Scan-Funktionen sind aber nur minimal konfigurierbar. Da aber ein
Interface dezidiert zum Scannen verwendet werden soll, und man die Scan-Informationen
irgendwie übertragen muss, kann man auch eine eigene Scan-Routine schreiben. Dieses
hat den großen Vorteil gegenüber der Treiber internen Scan-Funktionen, daß man nicht
nur alles unter Kontrolle hat, man kann auch die zu scannenden Kanäle sehr genau einstellen. Es müssen nur noch die Kanäle angegeben werden, die auch wirklich gebraucht
werden. z.B.: Kanal eins, sieben und dreizehn. Dadurch verringert sich die Zeit des tatsächlichen Durchlaufs von 13 ∗ wz (Wartezeit in ms) auf n ∗ wz. In diesem Beispiel mit
3
n = 3 : 3 ∗ wz. Also um 13
, also mehr als 14 schneller. Ausfälle von Access Points können
so schneller erkannt und kompensiert werden. Auch kann man nach Bedarf weitere Parameter den eigenen Bedürfnissen anpassen, zum Beispiel die Verweilzeit in einem Kanal,
wenn man ein anderes Beacon-Intervall einstellt.
17
4.4. Möglichkeit B: Wechselnde Aufgaben
4.4
Kapitel 4. Konzept
Möglichkeit B: Wechselnde Aufgaben
Die WLAN-Karten wechseln sich mit dem Scannen und dem Halten des Netzwerks ab.
Zuerst hält ein Interface das Netzwerk. Die andere Karte wird wie in Variante A zum
Scannen verwendet. Sobald ein Access Point deutlich stärker wird, verbindet sich das
Scan-Interface mit dem neuen Access Point, und das Interface, das bisher die Verbindung
gehalten hat, disconnectet sich. Es wird nun zum scannen verwendet.
Abbildung 4.4: Schaubild: Vorgang des Roamens von Access Point 1 nach Access Point
2, Methode B
Da die Netzwerkkarten aber unterschiedliche MAC-Adressen haben, ist die Station nach
dem Roamingvorgang eine logisch neue Station, die erstmal nichts mit der logischen alten
Station zu tun hat. Auch wenn man dem neuen Interface die gleiche IP-Adresse vergibt,
so haben die anderen Stationen noch die alte MAC-Adresse gechached, und senden weiterhin an die alte MAC-Adresse, die aber nicht mehr zu erreichen ist. Bis also die anderen
Stationen ein neuen ARP-Request durchführen, gehen Pakete verloren.
Um dieses Problem zu umgehen, gibt es diese Möglichkeiten:
• I. Einsatz von einer virtuellen Bridge (z.B. [vBr])
Die beiden WLAN Karten werden zu einer Bridge zusammengefasst. Es entsteht
ein neues Interfaces, mit einer eigenen MAC Adresse. Auf dieses Interface legt
man dann die IP.
Da das Scan-Interface nicht zu einem Access Point assoziiert ist, hat es des Status
„kein Kabel angeschlossen“ und wird von der Bridge nicht beachtet.
18
Kapitel 4. Konzept
• II. Vergabe gleicher MAC-Adressen mit gleichen IP-Adressen
Als Alternative kann man den WLAN-Karten die gleiche MAC- und IP-Adressen
geben.
Durch die gleiche MAC-Adresse ist es für das Netzwerk immer noch die gleiche
Station, auch wenn der Datenstrom über eine andere WLAN-Karte fließt.
Durch die gleiche IP-Adresse gibt es allerdings Routenprobleme: Das Station wird
die Pakete immer von dem ersten Interface schicken wollen. Dieses muss in der
Implementierung gelöst werden.
Vorteil ist bei dieser Variante, daß man nicht die Scan-Informationen übertragen muss.
Nachteil, daß das Netz kurzzeitig durch den Wechsel der Karte, des Access Points und
der Frequenz „verwirrt“ wird, was dazu führt, das einige Pakete den „alten“ Weg gehen,
und andere den „neuen“. Allerdings schicken die Access Points im Normalfall ein so genanntes „LLC-Update Frame“. Dieses enthält die MAC Adresse der WLAN-Station und
wird an alle gebroadcastet. Dadurch lernen die Backbone-Switches und alle erreichbaren
Access Points, über welche Verbindung diese Station nun zu erreichen ist. Dadurch sollte
die Zeit der „Verwirrung“ sehr kurz sein.
19
20
Kapitel 4. Konzept
Kapitel 5
Implementierung
5.1
Hardware
Dem Wireless Labor der Fachhochschule Wiesbaden stehen vier WRAP 2e (Wireless
Router Application Platform) der Firma PC Engines (http://www.pcengines.ch/wrap.htm)
zur Verfügung. Die WRAPs sind embedded PCs mit einem 486 kompatiblen AMD Geode
Prozessor.
Abbildung 5.1: WRAP2e mit Gehäuse
Der WRAP 2e hat ein 10/100 MBit Interface, sowie zwei Mini-PCI Steckplätze, die mit
mit je einer 11g WLAN Karte mit Atheros Chipsatz belegt sind.
Als „Festplatte“ steht eine 1GB Compact-Flash Karte zur Verfügung.
Als Betriebssystem wird SuSE Linux 10.2 eingesetzt. Der Kernel ist für diese Umgebung
speziell kompiliert worden.
Im Anhang, Kapitel 9.1, Seite 71, befindet sich eine kurze Installationsanleitung.
21
5.2. Entwicklungsumgebung
5.2
Kapitel 5. Implementierung
Entwicklungsumgebung
Entwickelt wird die Software wegen den geringen Ressourcen nicht auf dem WRAP, sondern auf einem normalen PC unter Linux (SuSE 10.2). Die fertige binär-Datei wird dann
per scp auf einen WRAP kopiert und dann getestet.
Als Compiler wird der gcc 4.1.2 eingesetzt - der gleiche, mit dem auch der Kernel und
die Module des WRAPs übersetzt wurden (Siehe Anlage: WRAP).
Als Treiber für die WLAN Karten wird der madwifi-ng eingesetzt. Und zwar immer die
neueste Version aus dem Subversion-Repository. Es hat sich gezeigt, daß viele Probleme
mit einem „svn update“ verschwinden.
5.3
Wireless Extensions for Linux
Die Wireless Extensions for Linux [Tou] wurden von 1996 von Jean Tourrilhes initiiert
und sind von HP gesponsort. Die Wireless Extensions wurden geschrieben, um ein einfache und für alle Treiber kompatible Methode zu haben, die WLAN-Einstellungen zu
ändern.
Die Wireless Extensions bestehen aus zwei „Modulen“. Einmal die Kernel-Module, die
in den Kernel kompiliert werden, und die User-Space Tools, um die Kernel-Module zu
steuern.
Als User-Space Tools werden diese Programme bereitgestellt
• iwconfig
Grundlegende Einstellungen
• iwpriv
Setzen von Treiberspezifischen Einstellungen
• iwlist
Auflistung von möglichen Parametern, aber auch von Scan-Informationen
• iwspy
Anzeige von WLAN Ereignissen (Kanalwechsel, Assoziation, etc.)
22
5.4
5.4. madwifi-ng
madwifi-ng
Der MadWifi (http://madwifi.org/) ist ein Linux-Treiber für WLAN-Karten mit einem
Atheros Chipsatz. Der Treiber wird aber langfristig von dem Treiber „ath5k“ abgelöst,
der ohne proprietäre HAL 1 auskommen soll [Kap07]. Doch einerseits ist der Treiber
noch nicht produktionsbereit, andererseits wurde mit dem „madwifi-ng“ schon Erfahrung
gesammelt, sodas in diesem Projekt der Treiber „madwifi-ng“ verwendet wird.
5.4.1
Virtuelle Devices mit madwifi-ng
Madwifi unterstützt virtuelle Devices. Das wirkt sich so aus, daß das eigentliche Interface
„wifiX“ nicht zur Kommunikation verwendet werden kann. Dafür muss man mit dem
Tool „wlanconfig“ virtuelle Devices für den entsprechenden Zweck anlegen. Der Wireless
Extension Befehl iwconfig athX mode master funktioniert mit dem nadwifi-ng
nicht.
Zum Beispiel, wenn man eine ganz normale Verbindung aufbauen will:
1
# wlanconfig ath create wlandev wifi0 wlanmode sta
Quellcode 5.1: Erzeugen eines STA Interfaces
Mit diesem Interface kann man sich mit Access Points verbinden, scannen u.s.w. Aber
einen eigenen Access Point aufmachen (Master Modus) oder gar das Medium monitoren
geht nicht.
Zum Monitoren muss man ein Interface als Monitor-Interface erzeugen.
1
wlanconfig ath create wlandev wifi0 wlanmode monitor
Quellcode 5.2: Erzeugen eines Monitor-Interfaces
Vorteil ist, daß man mehrere virtuelle Devices auf ein reales Device legen kann, und getrennt nutzen kann. Es gibt aber die physikalische Beschränkung, daß alle diese Devices
auf dem selben Kanal arbeiten müssen.
1
HAL: „Hardware Abstraction Layer“. Bei einer WLAN-Karte ist dieses die Firmware. Aufgrund nationaler
Gesetzgebungen ist diese für jedes Land unterschiedlich, um so die Kanäle und Sendestärken einzuhalten.
Da dieses HAL zur Zertifizierung der WLAN-Karte dazugehört, darf der Source nicht freigegeben werden.
Damit soll verhindert werden, daß die WLAN-Karte außerhalb der zugelassenen Spezifikationen betrieben
wird.
23
5.4. madwifi-ng
5.4.2
Probleme des madwifi-ng
Der Madwifi-ng ist kein vollständig korrekt arbeitender Treiber. Im Laufe der Implementierungsarbeiten habne sich diese Probleme herausgestellt:
• Wechsel des Access Points mittels iwconfig
Der Wechsel von Access Points mittels des Wireless Extensions Befehls iwconfig
<if> AP <MAC> oder der entsprechenden API sorgt zwar im Treiber dafür, daß
er meint, sich an einem Access Point angemeldet zu haben. Allerdings findet der
„four-way handshake“ (anmelden an den Access Point) nicht statt, so das ein normaler Access Point die Pakete der Station ignoriert.
Allerdings hat der Madwifi einen speziellen I/O Control: „IEEE80211_IOCTL_SETMLME“. Durch diesen kann man viele weitere Funktionen ansteuern.
Dieser I/O Control verlangt eine Struktur vom Typ „ieee80211req_mlme“. Im Feld
„im_op“ kommt die ID, der Operation: „IEEE80211_MLME_ASSOC“. Im Feld
„im_macaddr“ kommt die MAC - Adresse des Access Points.
Nach diesem Aufruf meldet sich das System korrekt am Access Point an.
• Roaming im gleichen Kanal
Wenn der Treiber sich zu einem Access Point verbinden soll, der im gleichen Kanal
wie der vorige ist, dann durchläuft der Treiber den Zustandsautomaten nicht richtig,
und das Assoziieren schlägt fehl.
Da der Fall „unterschiedliche“ Frequenzen in der Praxis aber wahrscheinlicher ist,
um die Last zu verteilen, wurde dieses Problem ignoriert, und mit Access Points
auf verschiedenen Frequenzen getestet. Dieses Problem betrifft nur Methode A.
• Paketverlust bei Änderungen der Konfiguration
Beim Ändern der Konfiguration, z.B. der Sendeleistung mittels iwconfig:
1
iwconfig ath0 txpower 20
Quellcode 5.3: Ändern der Sendekraft
gibt es einen kurzen Zeitraum, bei dem nichts gesendet wird. Ein Interface in der
Konfiguration „Master“ kann dadurch Pakete verlieren.
24
5.5
5.5. Umsetzung der Methode A
Umsetzung der Methode A
Das Problem beim Roaming ist, wie in der Einleitung beschrieben, daß ein Transceiver
nur auf eine Frequenz eingestellt werden kann. Mit einem zweiten Transceiver kann man
alle Frequenzen scannen ohne daß die Netzverbindung abreißt.
Hier wird beschrieben, wie man die Scan-Informationen der WLAN Karte auslesen und
nutzen kann, um das Netzwerkinterface gezielt zu roamen.
5.5.1
Übertragen der Scan-Informationen
Damit der Wechsel des Interfaces von einem Access Point auf den anderen Access Point
möglichst schnell geht, müssen die Scan-Informationen von dem Scan-Interface auf das
Netzwerkinterface übertragen werden.
Eine API Funktion zum Übergeben von Scan-Informationen gibt es nicht. Aber im Treiber
selber gibt es die Funktion „ieee80211_add_scan“, die einen Scan-Eintrag in die Tabelle
hinzufügt. Diese Funktion benötigt nur einen überschaubaren Eingansdatensatz mit den
Scan-Informationen und den ungefilterten WLAN-Header. Die Funktion fügt dann den
übergeben Access Point in die Scan-Liste hinzu.
5.5.2
I/O Control
Um die Scaninformationen nun in den Treiber zu bekommen, wird ein I/O Control benötigt. Es wurde das I/O Control „w2l2_ioctl_addscan“ angelegt. Als Parameter bekommt
es eine Struktur vom Typ „w2l2_setzeAP“. Diese Struktur enthält wiederum die zwei
Strukturen: „w2l2_scanparams“ und „ieee80211_frame“. Abbildung 5.2 zeigt ein UML
änliches Schema des Aufbaus.
Die Struktur „ieee80211_frame“ enthält den unaufbereiteten WLAN-Header, wie dieser
empfangen wurde. Die Struktur „w2l2_scanparams“ enthält alle weiteren Werte, die das
I/O Control braucht. Zum Beispiel „chan“ - der Kanal, auf dem es gesendet wurde oder
„bchan“ - der Kanal, auf dem es empfangen wurde (wie in dem Kapitel 3.3.1, Seite 8, beschrieben, kann man 11g Übertragungen auch in den Nachbarkanälen empfangen). Wichtig sind auch die unterstützen Übertragungsraten (Feld „rates“ und „xrate“, damit die
Station weiß, mit welchen Übertragungsraten es arbeiten kann. Diese Werte sind wichtig,
damit es sich mit dem Access Point verbinden kann. Alle Felder sind als Array ausgelegt,
damit diese direkt in den Kernelspace kopiert werden können.
25
Abbildung 5.2: Diagramm des struct w2l2_setzeAP
Als Präfix wurde „w2l2“ gewählt, da dieser Code im „Wiesbadener Wireless LAN Labor“
entstanden ist.
Die Funktion bereitet zuerst die übergebenen Parameter auf: Anlegen der benötigen Struktur, und kopieren von Variablen, bzw. die Zeiger auf die übergebenen Arrays zeigen lassen.
Danach wird der Scan-Cache geleert, um zu verhindern, daß ein Speicherleck entsteht.
Im Treiber sind Sicherheitsmechanismen eingebaut, um eine falsche Abarbeitungsreihenfolge zu verhindern. Es könnten zum Beispiel schon „Beacon“-Pakete empfangen werden,
obwohl der Treiber nicht soweit ist, überhaupt irgendwelche Pakete zu verabeiten, weil
zum Beispiel die interne Struktur dafür noch nicht angelegt wurde. Daher ist ein Flag gesetzt, das dafür sorgt, das empfangene Pakete verworfen werden. Dadurch kann es dazu
kommen, daß ein Access Point, den das Raoming-Programm setzen will, nicht in die Liste
aufgenommen wird. Wenn dann ein Assoziierungsbefehl zu einem Access Point kommt,
der nicht in der Liste ist, dann wird der Treiber einen aktiven Scan über alle Kanäle machen. Daher wurde die Funktion „w2l2_no_discard“ eingebaut. Diese sorgt dafür, daß der
Treiber diesen Access Point nicht verwirft. Diese Funktion wird nun aufgerufen.
Am Ende wird die aufbereitete Datenstruktur an die Madwifi Funktion „ieee80211_add_scan“
26
übergeben, die die Informationen dann in die interne Struktur bringt.
Ein weiteres Problem besteht in der ID-Nummernvergabe des Linux-Kernels. Jeder I/O
Control wird durch eine Nummer repräsentiert, die systemweit eindeutig sein muss. Diese
Nummer wird dem Befehl „ioctl“ übergeben. Für die Privaten I/O Controls hat man ein
Bereich von 32 IDs reserviert. Erschwerend kommt hinzu, das in den letzten beiden Bits
die Übergaberichtung kodiert ist:
[..]
40 #define _IOC_NONE
#define _IOC_WRITE
42 #define _IOC_READ
[..]
0U
1U
2U
Quellcode 5.4: Linux/include/asm-generic/ioctl.h
Zur Übergabe von Daten in den Kernel braucht man also eine ID, die hinten mit 102
endet. Dadurch kopiert die Funktion „ioctl“ die Daten vom User-Space in den KernelSpace. Doch es sind beim Madwifi-Treiber alle geraden Nummern vergeben. Um dieses
Programm zu testen wurde daher das I/O Control „IEEE80211_IOCTL_KICKMAC“ von
der ID 30 auf die 31 gelegt. Dem I/O Control „w2l2_ioctl_addscan“ wurde die freigewordene ID 30 zugeteilt, sodas die Implementierung getestet werden konnte.
5.5.3
Scannen
5.5.3.1
Empfang der Pakete
Den WLAN-Header, den die Funktion „ieee80211_add_scan“ aus dem Kapitel „Übertragen der Scan-Informationen“ benötigt, kann man aber nicht aus der vorhanden Struktur
aus dem Treiber auslesen.
Da ein eigenes Scannen ohnehin geplant war, kann man dieses aus den 802.11 Frames
auslesen.
Für das Scannen braucht das Programm alle Pakete, wie diese auf dem Interface ankommen. Allerdings sind normalerweise die WLAN-Interfaces in dem „Station“-Modus.
In diesem Modus können sich die Interfaces zu Access Points verbinden und normalen Netzwerkverkehr bearbeiten. Die 802.11 Management Pakete (wie zum Beispiel des
Beacon-Paket) braucht der Treiber, um diese normale Operationen zu bewerkstelligen.
Der Treiber gibt diese Management Pakete aber nicht an das System, oder User-SpaceProgramme, weiter. Um alle Pakete, inklusive der Management Pakete, zu empfangen,
27
muss man das Interface in den „Monitor“-Modus schalten. So agiert das Interface komplett passiv - es können keine Pakete mehr gesendet werden, aber das System und die
User-Space-Programme erhalten alle Pakete, inklusive der Management-Pakete.
Diese Pakete sind aber nur Datenpakete der zweiten OSI-Schicht. Eine Verbindung auf
einen höheren OSI-Schicht, also Layer 4 (TCP, UDP), wie man diese normalerweise mit
den Systemcalls bekommt, ist daher nicht brauchbar, da die Beacons keine IP-Pakete sind.
Deswegen öffnet das Programm einen RAW Socket, und bekommt so alle empfangenen
Pakete übermittelt.
Allerdings bekommt man im RAW Modus zwar alle empfangene Pakete, aber in diesen
Paketen stehen keine Informationen zur Empfangsqualität und Übertragungsgeschwindigkeit. Um diese Informationen zu erhalten, schicken die Treiber noch einen Header mit.
Standardmäßig schickt der madwifi Treiber einen Prism-Header mit. Prism deshalb, weil
dieses zuerst von den Treibern des Prism-Chipsatzes gemacht wurde. Allerdings schickt
der madwifi keine Qualitätsinformationen mit, und es wurde keine Konfigurationsmöglichkeit dafür gefunden. Daher baut diese Routine auf den Radiotap-Header auf, den man
mit
1
# echo 803 >/proc/sys/net/ath0/dev_type
Quellcode 5.5: Radiotap Header für den MadWifi aktivieren
aktivieren kann.
Der Radiotap-Header hat den Vorteil, daß die Felder, die übergeben werden, in einem
32-Bit Feld markiert werden. Wenn zum Beispiel die Übertragungsrate mit übergeben
wird, dann ist das Bit 0x04 gesetzt. Dieses kann man mit einfachen und schnellen BitOperationen abfragen um so schnell den Header durchzuarbeiten.
Danach kommt dann das eigentliche Beacon-Paket. In [HM03] (Der Autor verwechselt
manchmal „Bit“ und „Byte“) sind alle Management Frames beschrieben. Nach dieser
Vorlage wertet das Programm das Frame aus und speichert die wichtigsten Werte.
5.5.3.2
Verwaltung des Scannens
Um das Scannen unabhängig vom restlichen Ablauf zu machen, wurde es als separater
Thread realisiert. Sobald dieser angestartet wird, wird sofort gescannt.
Das Beacon Intervall liegt normalerweise bei 100ms. Daher ist in diesem Programm, wie
in der Einleitung mit dem Nyquist-Shannon-Abtasttheorem erklärt, eine Wartezeit von
28
200ms eingebaut.
Das Scannen wartet in jedem Kanal 200ms. Falls irgendwelche Pakete aufgefangen werden, werden diese auf Beacons überprüft. Sollten es Beacons sein, wird diese Information
gespeichert. Sollte der Access Point aber schon bekannt sein, so wird diese Information
geupdatet.
Wenn die Zeit abgelaufen ist, wechselt das Programm in den nächsten Kanal, und wartet
dort wieder 200ms. Wenn alle Kanäle durch sind, wird analysiert, ob ein Access Point in
der Liste ist, der sich aber nicht beim letzten Durchlauf gemeldet hat. Wenn ja, wird dieser
aus der Liste entfernt. Zur Zeit ist noch eine Sicherheit von drei Durchläufen eingebaut:
Erst wenn der Access Point sich drei Durchläufe hintereinander nicht meldet, wird er
entfernt.
Um Race Conditions zu vermeiden, werden Zugriffe auf die Liste der Access Points mit
Mutexen abgesichert.
5.5.4
Hauptprogramm
Das eigentliche Haupt-Programm vergleicht jede Sekunde die Stärke das aktuellen Access
Points mit der Stärke des am stärksten empfangenen Access Points. Wie im Konzept
beschrieben, wird hier die Stärke des aktuellen Access Points aus den Scan-Informationen
ausgelesen.
Wenn die Stärke sich um mehr δ Einheiten 1 unterscheidet, dann roamt das Programm.
Zuerst deassoziiert sich die Station vom aktuellen Access Point, dann verbindet sich das
System mit dem neuen Access Point. Der Kanalwechsel findet bei der Assoziierung automatisch statt.
Die Empfangsstärke schwankt im Normalfall um vier Einheiten. Daher wurden empirisch
verscheidene δ zwischen acht und zwanig getestet. Bei einem δ von zehn Einheiten war
das Optimum von erzwingbaren Roamen (siehe Kapitel 6.1.5.2 auf Seite 46) und stabiler
Verbindung, auch wenn eine Person in dem Übertragungsweg steht, erreicht.
Für Deassoziieren und Assoziieren wird der private I/O Control „IEEE80211_IOCTL_SETMLME“ genutzt. Dieses ist dazu da verschiedenste Funktionen zu einem I/O Control zusammenzufassen.
1
Alle Treiber geben die Empfangsstärke in einem eigenen Wertesystem wieder. Dieses müsste man zu dBm
umrechnen, um absolute Werte zu bekommen. Dieses ist hier aber nicht notwendig, da nur die relativen
Werte dieses Interfaces miteinander verglichen werden, und keine Werte aus anderen Quellen reinkommen.
29
Dieser I/O Control verlangt eine Struktur vom Typ „ieee80211req_mlme“. Im Feld
„im_op“ kommt die ID, der Operation: Zum Assoziieren „IEEE80211_MLME_ASSOC“
oder zum Deassoziieren „IEEE80211_MLME_DISASSOC“.
5.5.5
Vorbereitung
Am Anfang müssen die Interfaces richtig eingestellt werden. Da dieses eine einmalige
Aktion ist, reicht es, vor dem Start des Roamingprogrammes dieses Script auszuführen:
1 #Zuerst alles resetten:
ifconfig ath0 down
3 ifconfig ath1 down
5 wlanconfig ath0 destroy
wlanconfig ath1 destroy
9
#SuSE hat die unangenehme Eigenschaft, die vorigen Einstellungen zu speichern. Daher
diese löschen:
11 rm /etc/udev/rules.d/30-net_persistent_names.rules
13 #Etwas warten, damit das System diese Änderungen auch wirklich durchführt.
sleep 2
15
#Interfaces anlegen
17 wlanconfig ath1 create wlandev wifi0 wlanmode monitor
wlanconfig ath0 create wlandev wifi1 wlanmode sta
19
#Etwas warten, damit das System diese Änderungen auch wirklich durchführt.
21 sleep 2
23 #Interfaces konfigurieren
iwconfig ath0 essid w2l2-wrap
25 iwpriv ath0 bgscan 0
iwpriv ath1 bgscan 0
27 iwpriv ath0 hostroaming 2
sleep 2
31
#Interfaces aktivieren
33 ifconfig ath1 up
ifconfig ath0 up
35 iwlist ath0 scan
Quellcode 5.6: Vorbereitungsskript für Methode A
30
Neben dem Zerstören und neu Anlegen der virtuellen Interfaces wird hier das Station
Interface konfiguriert:
1
Nachdem alle eventuell vorhandenen Interfaces gelöscht worden sind, um alles komplett
neu zu initzialisieren, werden die Interfaces angelegt, die gebraucht werden: Ein Monitor
Interface, um das oben beschriebene Scannen zu realisiseren und ein Station Interface,
um die Verbindung zum Access Point aufzunehmen.
Mit „bgscan 0“ (Zeile 24, 25) und „hostroaming 2“ (Zeile 26) wird verhindert, daß der
Treiber Hintergrundscans macht und eigenmächtig roamt. Das soll ja dieses Programm
übernehmen.
Mit „iwlist ath0 scan“ wird dafür gesorgt das das Station-Interface einmal scannt. Dieses
ist notwendig, damit die Speicherstruktur für die Scandaten aufgebaut wird, und dann
nachher die Scandaten mit dem I/O Control hinzuzufügen.
5.5.6
Ausgabe
Die Methode A hat diese Bildschirmausgabe:
Current: 0:d:88:94:e1:d3, 1, 59, Best: 0:d:88:94:e1:d3, 1, 59,
Current: 0:d:88:94:e1:d3, 1, 60, Best: 0:d:88:8c:9c:ba, 13, 72,
0.010932s
Current: 0:d:88:8c:9c:ba, 13, 66, Best: 0:d:88:8c:9c:ba, 13, 66,
2
(2): OK
(2): Change..
(2): OK
Quellcode 5.7: Ausgabe der Methode A
In der ersten Spalte steht, mit welchen Access Point die WLAN Karte Verbunden ist, und
auf welchem Kanal. Danach die Empfangsstärke dieses Access Points.
Danach steht, welcher Access Point der aktuell stärkste ist, mit dem Kanal und der Empfangsstärke.
Am Ende zeigt er an, ob es OK so ist, oder der Roaming Vorgang durchgeführt wird. Die
Zahl danach zeigt an, wie lange das Programm in den Systemcalls war - in Sekunden.
Diese Zeit ist aber für das Roamen nicht repräsentativ, da das eigentliche Assoziieren
asynchron abläuft.
1
Station Interface / Station Modus: Der „normale“ Modus, mit dem sich eine WLAN-Karte zum Access
Point verbinden kann und dann als normale Netzwerkkarte agiert.
31
5.6. Umsetzung der Methode B
5.5.7
Probleme
Die Methode A hat zwei Probleme:
• Übertragung der Scaninformation
Damit die Scan-Information zum Netzwerkinterface übertragen wird, musste der
Treiber verändert werden, um ein extra I/O Control einzufügen. Damit ist diese
Lösung treiberabhängig.
Das Problem, das nur eine der wenigen I/O Control IDs verbraucht und ein anderes
ID „verdrängt“ wird, ist hingegen mit Mehraufwand lösbar.
• Abwesenheit vom Netz
Auch wenn die Zeit, die das Roamen verbraucht, sehr kurz ist, so ist das System
kurze Zeit vom Netz getrennt, und verliert unter Umständen wichtige Pakete.
5.6
Umsetzung der Methode B
Um die Probleme der Methode A zu umgehen, wird eine andere Roaming-Strategie implementiert: Beide Karten wechseln sich mit dem Scannen und Netzwerk halten ab. Zuerst Hält Interface A das Netzwerk, und Interface B scannt. Sobald geroamt wird, baut
Interface B die Verbindung auf, und Interface A lässt die Verbindung fallen. Jetzt scannt
Interface A. Weitere Details siehe im Konzept, Abschnitt 4.4 auf Seite 18.
5.6.1
Unterschiede zwischen Variante I und II
Im Konzept, Kapitel 4.4, Seite 18 werden zwei verschiedene Varianten betrachtet. Aus
Implementationssicht unterscheiden sich beide Varianten nur gering. In der Vorbereitung
leicht und im eigentlichem Roaming muss bei der Variante II nur ein weitere Funktion
aufgerufen werden, die die IP-Adresse abändert. Daher werden hier beide Varianten zusammen betrachtet.
5.6.2
Scannen
Das Scannen wird hier mit den im Treiber eingebauten Methoden realisiert. So muss
man nicht die Scan-Informationen übertragen, sondern diese liegen bei Bedarf sofort vor.
Außerdem sind keine Änderungen des Treibers notwendig.
32
Nachteil ist, daß man sich auf die Scanroutine des Treibers verlassen muss, man hat fast
keine Kontrolle über diesen Vorgang.
Dazu kommt noch, daß der MadWifi die Scaninformationen sehr zügig (<1/2 Sekunde) rausgibt, obwohl er nicht alle Kanäle gescannt hat. Diese Informationen sind daher
unvollständig. Um dieses zu umgehen, wird einmal das Scannen sofort nach dem Assoziieren angestartet, diese Informationen werden aber verworfen. Zusätzlich wird eine
fünf-sekündige Pause eingelegt.
Damit bekommt man nach jedem Scan zwar teilweise „veraltete“ Informationen, und zwar
die Informationen vom vorigen Scan. Da in dieser Arbeit aber nicht davon ausgegangen
wird, das sich die mobilen Station sehr schnell bewegen, ist diese Lösung akzeptabel.
5.6.3
Auslesen der Scandaten
Das Auslesen und Verarbeiten der Scandaten ist nach den Wireless Extension for Linux
[Tou], mit leichten Anpassungen, gemacht worden.
Nachdem der Scanauftrag abgeschickt wurde, wird alle 41 Sekunden nachgefragt, ob schon
Ergebnisse vorliegen (Polling Betrieb1 ). Sobald Ergebnisse vorliegen, muss man prüfen,
ob der Buffer, den man zur Verfügung stellt, ausreicht. Wenn nicht, dann könnte der Treiber zurückgeben, wie groß der Buffer sein muß. Wenn der Treiber diese Information gibt,
dann den Buffer mit dieser Größe anlegen. Ansonsten wird der Buffer immer verdoppelt,
bis dieser ausreicht.
Schlüssel
Wert
Access Point
00:0D:88:94:E1:D3
ESSID
w2l2_wrap
Kanal
1
Empfangsstärke
64
Unterstütze Übertragungsraten 48, 56
Access Point
00:0D:88:8C:9C:BA
ESSID
w2l2_wrap
Kanal
13
Empfangsstärke
53
Unterstütze Übertragungsraten 48, 56
1
Der Madwifi schickt auch Events [sca]. Allerdings habe ich bis auf zwei Posts, bei denen dieses erwähnt
wird, und den Quellcode vom wpa_supplicant nichts gefunden. Im Quellcode vom wpa_supplicant habe
ich es in der zur Verfügung stehenden Zeit nicht gefunden. Anfragen in diversen Chats waren erfolglos.
33
Tabelle 5.1: Beispiel des logischen Aufbaus der Scan-Daten
In Tabelle 5.1 ist ein Beispiel der logische Aufbau der Scan-Daten skizziert. Dieses ist
ein flache Tabelle mit einer Menge von Schlüssel-Wert-Paaren. Zu jedem Access Point
existieren eine Menge an Schlüsseln. Diese werden für jeden Access Point wiederholt.
Die einzige Möglichkeit zu erkennen, wo die Daten eines neuen Access Points anfangen, ist der Schlüssel „Access Point“. In „interpretiere_scan“ wird daher diese Tabelle
sequenzell durchgegangen, bis diese leer ist, und jede Zeile einzeln geholt. Wichtige Werte werde in Zwischenvariablen gespeichert. Bei dem Schlüssel „Access Point“ wird ein
Gruppenwechsel gemacht, und die zwischengespeicherten Werte ausgewertet, und bei
Bedarf gespeichert.
5.6.4
Hauptprogramm
Das Hauptprogramm ist ganz einfach. Jede Sekunde wird gescannt und die Daten interpretiert.
Wenn ein anderer Access Point deutlich stärker ist, die Empfangsstärke sich also um mehr
als zehn Einheiten (Fußnote 1 auf Seite 29) unterscheidet, assoziiert er zuerst das ScanInterface mit dem neuen Accesspoint, und deassoziiert dann das bisherige Netz-Interface.
Danach werden beide getauscht.
5.6.4.1
Variante II
Sollte Variante II eingesetzt werden, so wird zwischen dem Assoziieren und Deassoziieren die IP-Adresse der Interfaces geändert. Das alte Netz-Interface bekommt eine IP, die
nicht im normalem Netz vorhanden ist.
Wenn zwei Interfaces die gleiche IP haben, bzw. im gleichen Subnet sind, so kollidieren
die Routinginformationen, und es wird nur über ein Interface geroutet, egal ob verbunden
ist1 , oder nicht. Auch kann man (unter Linux) diese Route nicht löschen.
Daher wird beim Scan-Interface eine nicht vorhandene IP gesetzt, und das Netz-Interface
erhält die richtige IP. Beim Roamen wird auch dieses umgeschaltet.
1
LAN: Kabel im Port, WLAN: Verbindung zum Access Point besteht
34
5.6.5
Vorbereitung
Wie in Kapitel 5.5.5 müssen am Anfang die Interfaces richtig eingestellt werden. Dieses
wird durch dieses Script erledigt (je nach Variante die auskommentierten Befehle aktivieren!).
1 #Zuerst alles resetten:
ifconfig ath0 down
3 ifconfig ath1 down
5 #Bei Variante I:
#ifconfig br0 down
7 #brctl delbr "br0"
15
#SuSE hat die unangenehme Eigenschaft, die vorigen Einstellungen zu speichern. Daher
diese löschen:
17 sleep 1
rm /etc/udev/rules.d/30-net_persistent_names.rules
19
#Interfaces konfigurieren
21
#Bei Variante II
23 #ip link set dev wifi0 down
#ip link set dev wifi1 down
25 #ip link set addr 00:80:48:3D:EE:67 dev wifi0
#ip link set addr 00:80:48:3D:EE:67 dev wifi1
27
wlanconfig ath create wlandev wifi1 wlanmode sta -bssid
29 wlanconfig ath create wlandev wifi0 wlanmode sta -bssid
sleep 1
33
iwpriv ath0 bgscan 0
35 iwpriv ath1 bgscan 0
iwpriv ath0 hostroaming 2
37 iwpriv ath1 hostroaming 2
39 iwconfig ath0 essid w2l2-wrap
iwconfig ath1 essid w2l2-wrap
41
#Bei Variante I
43 #brctl addbr "br0"
#brctl addif "br0" ath0
45 #brctl addif "br0" ath1
35
sleep 2
49
#Interfaces aktivieren
51 ifconfig ath0 up
ifconfig ath1 up
53 #Bei Variante I
#ifconfig br0 192.168.1.100 up
Quellcode 5.8: Vorbereitungsskript für Methode B
Im Unterschied zur Vorbereitung von Methode A wird hier kein Monitor Interface angelegt. Dafür werden bei Variant I die Brücke angelegt und bei Variante II die MACAdressen der wifi-Interface gleichgesetzt
5.6.6
Ausgabe
Die MethodeB hat diese Bildschirmausgabe:
1
3
scannen: (ath0,2) aktuell: 00:0D:88:94:E1:D3(60), best: 00:0D:88:8C:9C:BA(70) OK
scannen: (ath0,2) aktuell: 00:0D:88:94:E1:D3(60), best: 00:0D:88:8C:9C:BA(71) roaming
OK, warte..scannen:
scannen: (ath1,2) aktuell: 00:0D:88:8C:9C:BA(59), best: 00:0D:88:94:E1:D3(68) OK
Quellcode 5.9: Ausgabe der Methode B
In der ersten Klammer steht das Scan-Interace mit der der Gesamtanzahl der empfangenen Access Points. Danach der Access Point, mit dem der aktuell verbunden ist, mit der
Empfangsstärke. Anschließend der beste zu empfangene Access Point, auch mit Empfangsstärke.
Am Ende zeigt das Programm an, ob es OK so ist, oder der Roaming-Vorgang durchgeführt wird. Das „scannen“ kommt dadurch, daß das Programm - wie im Kapitel 5.6.2 auf
Seite 32 erläutert - direkt nach dem Deassoziieren einen Scan anstartet, und die Ergebnisse verwirft.
Die Methode B II wird als erste Zeile dieses ausgeben:
1 scannen: (ath1,2) aktuell: 00:00:00:00:00:00(-1), best: 00:0D:88:8C:9C:BA(67) roaming
SIOCSIFNETMASK: Die angeforderte Adresse kann nicht zugewiesen werden
Quellcode 5.10: Ausgabe der Methode B II, Fehlermeldung
36
Diese Fehlermeldung kommt daher, daß die IP-Adressen zum ersten Mal zugewiesen werden. Da dieses nur einmal und deterministisch kommt, außerdem die Verarbeitung nicht
stört, wurde auf eine weitere Analyse und Fehlerbehebung verzichtet.
5.6.7
Probleme
Diese Methode hat ein Problem:
Dadurch daß es zwei Interfaces sind, hat jedes Interface seine eigene, unabhängige Scantabelle mit eigenen Werten. So kann es vorkommen, daß Interface A der Meinung ist, daß
Access Point A stärker ist. Interface B ist aber der Meinung, Access Point B sei stärker.
So kann es dazu kommen, daß eine Weile hin und her geschaltet wird, bis bei einem Interface die Werte korrigiert sind. Durch das Fast-Roaming sollte dieses „Fehlverhalten“ nur
eine unschöne Eigenschaft sein, und keine Auswirkung auf höhere Protokolle und deren
Anwendung haben. Daher ist es das beste, dieses zu ignorieren.
Außerdem ist in den Scanroutinen des Treibers eine gewisse „Trägheit“ eingebaut, um
grobe Schwankungen auszugleichen. Daher braucht das Programm - im Gegensatz zur
Methobe A - länger, bis es erkennt, daß eine Station nur noch sehr schwach sendet.
37
38
Kapitel 6
Messung
Das Thema in dieser Arbeit ist das schnelle Roamen. Die Station muss also so schnell
wie möglich von einem Access Point zum anderen roamen.
In der Automatisation ist ein Maximalzeitraum von 10ms gefordert. In [sie] beschreibt
Siemens ein Netzwerk, das Antwortzeiten bis 10ms garantiert.
Optimale Roamingzeiten für Voice over IP konnten nicht in Büchern gefunden werden. In
[Bad04] werden gute Zeiten für eine „Ende-zu-Ende-Verzögerung“ mit maximal 150ms
angegeben. Somit ist VoIP unkritischer als Automatisationsanwendungen.
6.1
Erläuterung der Messung
6.1.1
Visualisierung mittels WI-Spy
Zur Visualisierung von des Traffics auf dem 2,4 GHz Band wird in diesem Kapitel
Screenshots vom WI-Spy eingesetzt.
Der WI-Spy ist ein USB-Stick, mit dessen Hilfe die Sendestärken in den einzelnen Frequenzen des 2,4GHz Bandes anzeigt werden können.
Der Screenshot vom WI-Spy Abb.: 6.1 ist dreigeteilt:
Oben ein Zeitlicher Verlauf: Die Y-Achse der Graphik ist Zeit, die vorbei ist. Also ist
y = 0 „jetzt“. Je roter die Farbe, desto stärker wurde gesendet.
In der Mitte ist eine Ansicht: Stärke des Signals. Je stärker, desto weiter oben wird gezeichnet. Die Farbcodierung ist hier „Nutzung“: Die Stärken, die rot gezeichnet sind,
39
6.1. Erläuterung der Messung
Kapitel 6. Messung
Abbildung 6.1: Screenshot WI-Spy. Normale Nutzung des Kanal 6 (g)
kommen häufig vor. Daher sehr gut zu erkennen: Es gab zum Aufzeichnungszeitpunkt
drei Stationen. Die Kurve, die ganz oben gezeichnet ist, stammt von dem Laptop eines
Kommilitonen. Dieser saß im gleichen Raum und surfte zu diesem Zeitpunkt im Internet.
Die beiden anderen Kurven sind einmal der Access Point, und eine andere Station.
Unten ist die augenblickliche Nutzung (weiße Linie). Wobei man beachten muss, dass der
WI-Spy nicht alle Kanäle gleichzeitig misst, sondern in sehr kurzen Abständen zwischen
den Kanälen wechselt. Blau ist der Bereich, dessen Stärke in der letzten Zeit erreicht
wurde. Grün ist der Bereich, der fast immer überschritten wird, also das „Hintergrundrauschen“.
6.1.2
Ort
Diese Messungen werden im w2l2 (Wiesbadener Wireless LAN Labor) durchgeführt.
Abbildung 6.2: Logo des w2l2
6.1.3
Methodik, Messverfahren
Um die Roaming-Zeit nachzuweisen, werden zwei Messungen vorgenommen:
40
Kapitel 6. Messung
• passives monitoren
Einer der WRAPs wird zum monitoren des WLAN-Traffics verwendet. Da es zwei
Interfaces hat, kann jedes Interface auf einem anderen Kanal monitoren. Dazu wird
der ethereal zweimal gestartet, und die empfangenen Pakete für eine spätere Auswertung mit Hilfe des Wireshark 1 gespeichert. Die Leistung der WRAP ist für
Kanäle, die nicht unter starker Last (>50% Maximalen Nettotransfervolumen) sind,
ausreichend.
Obwohl beide Sessions per Script fast gleichzeitig gestartet werden, so ist ein minimaler Versatz in der gemessenen Zeit bei beiden Programminstanzen. Um diesen
Versatz zu messen, werden einige Broadcastpaket genommen, die vom Hauptrechner generiert werden und auf das Backbone geschickt werden. Daher ist dieses Paket quasi gleichzeitig in beiden WLAN Kanälen.
Um dieses Paket einfach zu generieren, wird ein Ping auf eine nicht-existente IPAdresse (192.168.1.254) abgeschickt. Die ARP-Pakete, die der Ping erzeugt, kann
man einfach im Wireshark erkennen.
• aktives UDP Senden
Um zu messen, wie lange lange das Netz wirklich braucht, bis es die Pakete der
siebten Schicht (Anwendungsschicht) wieder richtig leitet, wurde ein spezielles
Programm geschrieben.
Dieses Programm versendet alle fünf Millisekunden per UDP eine fortaufende Zahl
(1, 2, 3, ...). Dieses wird vom gleichen Programm auf der Gegenseite empfangen.
Sollten nun Lücken im Zahlen-Strom sein, so gibt das Programm diese Lücken aus.
Anhand der Anzahl der verlorenen Pakete kann man auf die Zeit schließen, wie
lange das Netz wirklich braucht, bis es das Roaming akzeptiert hat. Weiteres siehe
im Anhang Kapitel 9.2, Seite 80.
Die Messung wird für jede Methode zweimal gemacht. Der einzige Unterschied ist,
in welche Richtung das UDP-Senden gerichtet ist.
– Von WLAN an Fest
Das Programm wird auf der Roaming-Test-WLAN-Station im Sendemodus
gestartet. Es sendet an einem Rechner im WLAN Backbone.
– Von Fest an WLAN
Das Programm wird auf einem Rechner im WLAN Backbone im Sendemodus
1
ethereal ist eine Konsolenanwendung, daher auf dem WRAP lauffähig. Zur Auswertung wird aber der
Wireshark herangezogen, da dieser mit einer GUI übersichtlicher und einfacher zu handhaben ist.
41
Kapitel 6. Messung
gestartet. Es sendet an die Roaming-Test-WLAN-Station.
Aufgrund der Kernel Timingproblematik (wie es im Anhang zu UDP-Test,
Kapitel 9.2, Seite 80 beschrieben ist) muss für das Programm UDP-Send im
Messteil „Von Fest an WLAN“ ein spezieller Kernel verwendet werden. Um
aber nicht die Stabilität des Hauptsystems zu gefährden, wird das Programm
für diese Aufgabe von einem dritten WRAP gestartet, der mit diesen Kernel
versehen wurde.
6.1.4
Störgrößen
An der FH gibt es viele Störgrößen:
• andere WLANs
Im wl2l kann man mehrere WLANs empfangen, die einen Kanal belegen:
– FBI-WLAN
Das ist das WLAN des früheren Fachbereichs Informatik, jetzt vom Studiengang allgemeine Informatik des Fachbereichs DCSM (Design, Informatik,
Medien). Die Access Points, die im w2l2 zu empfangen sind, senden auf den
Kanälen sechs und elf. Wobei der der Access Point auf dem Kanal elf nur sehr
schwach zu empfangen ist.
– Dopsy
Das benachbarte Labor für verteile Systeme (Dopsy) sendet auf Kanal drei.
Allerdings ist hier kein Verkehr zu verzeichnen, sodas es nicht stört.
– CampusWLAN
Das ist ein campusweites WLAN, das erst im Sommersemester 2006 eingerichtet wurde. Der hier zu empfangene Access Point sendet auf Kanal fünf.
– Adhoc Netze
Auch kann man hin und wieder Adhoc Netze beobachten, die aber nicht so
häufig sind.
• Mitbenutzer
Während der Test verbanden sich einige Leute mit den Test Access Poins.
Alle Schutzmaßnahmen, wie zum Beispiel MAC-Filter, sind kein wirkliches Hinderniss, stören aber dafür die Messung, da dieses weitere mögliche Fehlerquellen
sind.
42
Kapitel 6. Messung
Da aber auf allen Stationen nur notwendige Ports offen sind, war es bisher das beste,
diese „Mitbenutzer“ zu ignorieren.
• Mikrowellen
Es gibt in dem Gebäude eine Mikrowelle, die scheinbar ein kleines Leck hat. Es
kommt hin und wieder mal vor, daß eine Verbindung nur möglich ist, wenn man
die beiden Stationen in Abstand von wenigen Zentimetern hinstellt. Dieses kommt
aber selten vor, sodas es bisher das beste war, einige Minuten zu warten.
Die anderen Mikrowellen verschlechtern den Empfang nur unwesentlich, wenn eine
aktiv ist.
Abbildung 6.3: Screenshot WI-Spy. Störung durch eine Mikrowelle
Alle diese Störgrößen sorgen für einen schlechten Empfang, und teilweise viele verlorene
Pakete. Die Verlustrate erreicht manchmal ein Prozent. Ein normales Nutzen des WLAN,
zum Beispiel um zu surfen, ist immernoch möglich, da das TCP-Protokoll verloren gegangene Pakete neu anfordert. Der Paketverlust hat höchstens in einem etwas langsameren
Aufbau der Webseite zur Folge. Messungen sind aber nicht mehr möglich, da das UDPTest-Programm zu viele Lücken ausgibt, die man einem Roaming-Ereignis nicht mehr
zuordnen kann. Es wäre zwar möglich, in den Dump-Dateien danach zu suchen, das hat
aber gegenüber der Alternative einen zu hohen Aufwand.
Alternativ kann man am Freitag Abend messen. Da sind kaum noch Lehrveranstaltungen,
und die meisten Leute sind im Wochenende. Daher sind zu diesem Zeitpunkt die Kanäle
frei und fast ohne Störungen zu nutzen.
43
6.1.5
Kapitel 6. Messung
Messaufbau
Abbildung 6.4: Messaufbau
Als Access Points kommen zwei DLink DWL-2000AP+ zum Einsatz. Diese wurden
in einer Entfernung von einigen Metern zueinander aufgestellt. Mittig davon wird der
Roaming-Test-WRAP (WRAP 1) aufgestellt. Ebenso der Monitor-WRAP (WRAP 2).
Für die Messung der Methode A kommt der WRAP beta zum Einsatz. Da die Methode A
aber einen modifizierten Treiber braucht, wird für die Messung der Methode B der WRAP
delta mit einem unmodifizierten madwifi Treiber verwendet.
Diese beiden kommen mittig zwischen die Access Points. Von diesen wird der WRAP, der
bei der Messung nicht testet, als Scanner eingesetzt. Ein dritter WRAP (WRAP 3), angeschlossen am WLAN-Backbone, sorgt für das UDP-Senden in der Messvariante „Von
44
Kapitel 6. Messung
Fest an WLAN“.
Der Steuerrechner verbindet sich mittels SSH über das Steuersubnet an die WRAPs. Von
dort aus wird alles gesteuert.
Um die MAC-Adressen in den Dump-Dateien einzelnen Geräten zuordnen zu können,
hier eine Liste aller MAC-Adressen:
Gerät
MAC-Adresse
WRAP alpha
LAN
WLAN 1
WLAN 2
00:0D:B9:05:4F:F0
00:80:48:3D:5B:77
00:0B:6D:4E:DF:36
WRAP beta
LAN
WLAN 1
WLAN 1
00:0D:B9:05:45:A4
00:80:48:3F:5B:7E
00:0B:6D:4E:DD:6D
WRAP gamma
LAN
WLAN 1
WLAN 2
00:0D:B9:05:50:08
00:80:48:3D:5B:66
00:0B:6D:4E:DD:51
WRAP delta
LAN
WLAN 1
WLAN 2
00:0D:B9:05:45:B8
00:80:48:3D:5B:67
00:0b:6D:4E:D9:D0
DLink AP 1
00:0D:88:94:E1:D3
DLink AP 2
00:0D:88:8C:9C:BA
Hauptrechner LAN
„Backbone“
00:50:BA:5D:2F:DD
„Steuer“
00:02:B3:1A:66:E9
Virtuelle MAC 1
„Methode B I b“2
„Methode B II“
00:80:48:3D:EE:67
00:80:48:3D:EE:67
Tabelle 6.1: Liste aller MAC Adressen aller Geräte
1
Bei den Methoden B I b und B II werden die MAC-Adressen der Karten geändert. Dieses sind die geänderten Adressen.
2
Die Methode B I b wird in Kapitel 6.3, Seite 54 näher beschreiben.
45
6.1.5.1
Kapitel 6. Messung
Konfiguration
Da der Kanal 6 durch das FBI-WLAN belegt und genutzt ist, sowie der Kanal 5 vom
Campus-WLAN, wird der Access Point eins auf den Kanal eins und der Access Point
zwei auf den Kanal dreizehn gelegt.
Als ESSID wird „w2l2_wrap“ verwendet.
Eine Nutzung der WRAPs als Access Points hat sich als nicht optimal herausgestellt: Um
volle Access Point Funktionalität zu gewährleisten, muss das LAN Interface mittels einer
virtuellen Brücke [vBr] mit dem WLAN Interface gekoppelt werden.
Die Bridge Software ist aber nicht darauf optimiert, mit ständig wechselnden Stationen
zu arbeiten. Daher braucht die Software zu lange, bis sie erkennt, daß eine Station jetzt
über einen anderen Weg zu erreichen ist.
6.1.5.2
Erzwingen des Roamings
Während der Durchführung der Messung muss erzwungen werden, daß der Roaming-Test
WRAP sich mit einem anderen Access Point verbindet.
Da aber im Labor nicht genügend Fläche besteht, um ein Roaming mittels „laufen“ auszulösen wird das Roaming mittels „manuellem“ Abschwächen der Signale erzwungen.
Zum Beispiel wird die Antenne des Access Points, von dem sich die Station abmelden
soll, mit der Hand zugehalten, hinter einem Rechner „versteckt“ oder mit einer Aluminiumfolie abgeschirmt (Abb. 6.5) (Dank an Frank Meffert).
Ein Ändern der Sendestärke wie es z.B. bei Linux Access Points möglich wäre, ist bei
den DLink Access Poins nicht machbar, da dieser danach das Gerät neu startet.
Wenn alles funktioniert, dann sieht die Kanalbelastung wie in der Abb. 6.6 aus. Deutlich
ist zu erkennen, daß der Traffic zwischen den Kanälen 1 und 13 wechselt.
Auf diese Weise wird mindestens sechs mal ein Roaming erzwungen.
6.1.6
Durchführung
Folgende Schritte in dieser Reihenfolge sind notwendig, um eine Messung durchzuführen:
46
Kapitel 6. Messung
Abbildung 6.5: Folienabschirmung der Antenne
• Vorbereitung
Zuerst verbindet man zwei SSH-Session zum WRAP, auf dem das Roaming getestet
werden soll.
In der ersten Session wird zuerst das entsprechende Start-Skript, wie es in der Einleitung beschrieben ist, ausgeführt. Dieses sorgt dafür, daß die Interfaces im richtigen Modus aktiv sind.
Wenn dies die Messung für den Messfall „UDP-Pakete von Fest nach WLAN“ ist,
dann wird in der zweiten Session das Programm UDP-Test ohne Parameter gestartet.
Wenn dies aber die Messung für den Messfall „UDP-Pakete von WLAN nach Fest“
ist, dann wird das Programm UDP-Test auf dem Hauptrechner ohne Parameter gestartet.
• Starten der Aufzeichnung
Eine zweite Verbindung wird zu dem anderen Roaming-Test WRAP geöffnet, und
darauf dieses Script gestartet:
1 # zuerst alle eventuell vorhandenen Interfaces löschen
47
Kapitel 6. Messung
Abbildung 6.6: Screenshot WI-Spy, Traffic der Messung: Methode A, UDP-Pakete werden
von Festnetz an das WLAN-System gesendet
sleep 1
11
# Dump-Dateien des letzten Durchgangs löschen
13 rm kanal1*
15 #SuSE hat die unangenehme Eigenschaft, die vorigen Einstellungen zu speichern.
Daher diese löschen:
rm /etc/udev/rules.d/30-net_persistent_names.rules
17
19 #Interfaces anlegen
wlanconfig ath create wlandev wifi0 wlanmode monitor
21 wlanconfig ath create wlandev wifi1 wlanmode monitor
sleep 1
25
#Interfaces konfigurieren
27 iwconfig ath0 channel 1
iwconfig ath1 channel 13
29
#Etwas warten, damit das System diese Änderungen auch wirklich durchführt.
31 sleep 10
33 #Interfaces aktivieren
ifconfig ath0 up
35 ifconfig ath1 up
sleep 2
39
#Den Dump anstarten
48
Kapitel 6. Messung
41 tcpdump -i ath0 -s 0 -w kanal1 &
tcpdump -i ath1 -s 0 -w kanal13 &
Quellcode 6.1: Dump des Netzwerkverkehrs auf dem WLAN
Dieses Script speichert nun den ganzen Verkehr auf den Kanälen eins und dreizehn.
Auf dem Hauptrechner wird noch zusätzlich mit dem Wireshark der Verkehr auf
dem WLAN Backbone aufgezeichnet.
• Broadcast Pakete generieren
Jetzt wird auf dem Hauptrechner ein Ping an 192.168.1.254 gestartet und nach einigen Sekunden abgebrochen. Dieses generiert ARP Pakete, die man wie oben Beschrieben zum Synchronisieren der Zeiten verwenden kann.
• UDP-Pakete senden
Wenn das der Messfall „UDP-Pakete von Fest nach WLAN“ ist, dann wird das
UDP-Senden von dem WRAP 3 aus an die WLAN Station gestartet. Ansonsten
von der WLAN-Station an den Hauptrechner.
• Roaming starten und durchführen
Jetzt wird das eigentliche Roaming auf der WLAN Station angestartet. Anfangs hat
diese Station noch keine Verbindung. Daher wird er sich sofort verbinden. Sobald
die Station verbunden ist, wird das Programm UDP-Test ausgeben, daß es Pakete
empfängt.
Jetzt wird das Roamen sechs mal nach Kapitel 6.1.5.2 erzwungen.
• Beenden
Am Ende werden alle Programme beendet (abgeschossen), und die Ergebnisse gespeichert. Diese Rohdaten sind auf der beiliegenden CD im Verzeichnis „Messung“.
6.1.7
Erläuterung des Vorgehens bei der Auswertung
Alle Auswertungen der Messungen sind nach dem gleichen Schema aufgebaut. Zu allen
Methoden gibt es wie oben beschrieben zwei Messvariationen: Einmal wird das UDPSenden vom Backbone an das WLAN angestoßen (Netz → WLAN). Das andere Mal von
der WLAN-Station an das Backbone (WLAN → Netz). Zu jeder dieser Variante wird die
komplette Messreihe durchgeführt.
Zuerst wird bei jeder Messung die Ausgabe vom UDP-Test ausgewertet. Wieviele Pakete
verloren gegangen sind, und was das für ungefähre Zeiten sind.
49
6.2. Messung der Methode „A“
Kapitel 6. Messung
Danach werden die tcp-dump Dateien ausgewertet:
Da die Zeiten in den dump Dateien beider Kanäle (eins und dreizehn) nicht syncron sind,
muss zuerst ein Korrekturwert gebildet werden. Dazu werden für beide Kanäle die Zeiten
der ARP-Pakete, die das „ping 192.168.1.254“ ausgelöst hat, notiert. Dann wird die Differenz der Zeiten ausgerechnet. Zu allen Differenzen wird der arithmetischer Mittelwert
gebildet:
max
P
mw =
di
i=1
max
Dieser Wert wird in den folgenden Auswertung zu dieser Messvariante auf die Zeiten des
Kanal dreizehn aufaddiert.
Als nächstes werden die Dateien nach dem Roaming durchsucht.
Um nicht den Überblick zu verlieren, sollte man im Wireshark zumindest die Beacons,
Probe-Request und Probe-Response Pakete ausblenden:
1
!(wlan.fc.type_subtype == 8) && !(wlan.fc.type_subtype == 0x04) &&
!(wlan.fc.type_subtype == 0x05)
Quellcode 6.2: Wireshark Filter zum ausblenden der Beacons
Zu jedem Roamingvorgang wird notiert, von und zu welchem Kanal er wechselt. Dazu
wird der genaue Zeitpunkte vom „Deassoziation“ Paket und vom ACK des „Assoziation
Response“ Paketes notiert. Dann wird die Differenz ausgerechnet, wobei die Differenz
um den vorher ermittelten Mittelwert bereinigt ist. So hat man die reine Zeit, die das Roamen im Layer zwei braucht.
Bei Bedarf werden noch die Nummern des letzten UDP-Pakets und des ersten UDPPakets vor und nach dem Roamen notiert.
Anschließend folgt eine kurze Auswertung ohne Beurteilung. Eine Beurteilung ist im
nächsten Kapitel verfasst.
6.2
Messung der Methode „A“
Es wird die Methode A „Dezidiertes Scannen“ gemessen.
50
Kapitel 6. Messung
6.2.1
UDP-Versand von Festnetz auf die WLAN-Station
Die UDP-Pakete werden von einem Rechner im Festnetz auf das Roaming-WLAN System geschickt.
Es wurde sechs Mal das Roamen erzwungen.
6.2.1.1
Auswertung UDP-Test
1 wrap-beta:~ # ./_UDP-test
Empfangsmodus
3 Öffne Socket..
Empfange, habe aber die ersten 473 verpasst
5 [..]
Bei 14494, Lücken: {[1-472(472)], [4870-4871(2)], [6989-6991(3)], [8287-8289(3)],
[9431-9433(3)], [10406-10407(2)], [12685-12686(2)], }
Quellcode 6.3: Methode A, Netz → WLAN. Ausgabe UDP-Test
Die erste Lücke (1-472) entstand dadurch, daß die Station erst später mit dem WLAN
verbunden wurde, nachdem das Senden angestartet wurde.
Es gab keine sonstigen Paketverluste wegen der Luftschnittstelle. Alle Paketverluste sind
auf das Roamen zurückzuführen. Maximal 3 verlorene Pakete (entspricht 15ms), minimal
2 verlorene Pakete (entspricht 10ms).
6.2.1.2
Auswertung Ethereal
Zuerst die Analyse des Versatzes:
ARP Paket Zeitpunkt Kanal 1 Zeitpunkt Kanal 13 Differenz
1
1.631064
1.453318
0.177746
2
2.630848
2.453097
0.177751
3
3.630569
3.452967
0.177602
Tabelle 6.2: Messung: Methode A, Netz → WLAN. Versatz
der dump Dateien
Das arithmetische Mittel ist 0,177700. Dieses wird zur Korrektur der Zeiten bei Kanal 13
verwendet (aufaddiert).
51
Kapitel 6. Messung
Nr
Kanal
Deassoziation Assoziation Differenz
1
13 → 1
36.770743
36.962956
0.014513
2
1 → 13
49.979930
49.816818
0.014588
3
13 → 1
57.824868
58.018091
0.015523
4
1 → 13
65.025919
64.861522
0.013303
5
13 → 1
70.866188
71.059666
0.015778
6
1 → 13
85.075003
84.911742
0.014439
Tabelle 6.3: Messung: Methode A, Netz → WLAN. Roaming
Zeiten Layer 2
Minimale Zeit: 13,3ms, Maximale Zeit: 15,7ms. Arithmetisches Mittel: 14,7 ms.
6.2.2
UDP-Versand von der WLAN-Station auf das Festnetz
Die UDP-Pakete werden von dem WRAP 3 auf die roamende WLAN-Station gesendet.
Es wurde zwölf Mal das Roamen erzwungen.
6.2.2.1
Auswertung UDP-Test
Öffne Socket..
2 Empfange, habe aber die ersten 330 verpasst
[..]
4 Bei 26124, Lücken: {[1-329(329)], [2328-2493(166)], [2662-2820(159)], [1]
[4372-4536(165)], [5620-5784(165)], [6541-6706(166)], [7664-7820(157)],
[13768-13928(161)], [15202-15361(160)], [20998-21146(149)], [22076-22240(165)],
[22574-22575(2)], [25221-25385(165)], }
Paketverlust: Erwarte 26335, empfange 26499=57824868+177700
Quellcode 6.4: Methode A, WLAN → Netz. Ausgabe UDP-Test
Der letzte Paketverlust beträgt 26499 − 26335 + 1 = 165.
Es gibt drei Pakete, die durch schlechte Übertragungsqualität verlorengegangen sind. Einmal [1], und dann (2) bei 22574-22575.
Minimaler Paketverlust: 149, Maximaler Paketverlust: 165. Das entspricht: 715ms bis
825ms.
52
Kapitel 6. Messung
6.2.2.2
Auswertung Ethereal
Zuerst die Analyse der Versatzes:
1
3.265747
2.831926
0.433821
2
4.265464
3.831790
0.433674
3
5.265249
4.831574
0.433675
Tabelle 6.4: Messung: Methode A, WLAN → Netz. Versatz
der dump Dateien
Nr
Kanal
1
13 → 1
22.112006
22.561537
0.015808
2
1 → 13
24.560921
24.141729
0.014531
3
13 → 1
35.156223
35.603783
0.013837
4
1 → 13
43.611333
43.192679
0.015069
5
13 → 1
49.167450
49.645842
0.044669
6
1 → 13
56.652270
56.233086
0.014539
7
13 → 1
95.292152
95.740421
0.014546
8
1 → 13
104.750301
104.330546
0.013968
9
13 → 1
141.381992
141.834541
0.018826
10
1 → 13
148.843611
148.424318
0.014430
11
13 → 1
168.450880
168.899324
0.014721
12
1 → 13
175.904891
175.485517
0.014349
Tabelle 6.5: Messung: Methode A, WLAN → Netz. Roaming
Zeiten Layer 2
Da die sonstigen Zeiten bis maximal 18ms gehen, werte ich den Vorgang Nummer fünf,
der mit 44ms mehr als das doppelte der Zeiten der anderen Roaming Vorgänge braucht,
als Ausreißer.
Minimale Zeit: 13,8ms, Maximale Zeit: 18,8ms. Arithmetisches Mittel: 15ms.
Diese Werte verblüffen gegenüber der UDP Messung, da die UDP Messung wesentlich
53
6.3. Messung der Methode „B I“
Kapitel 6. Messung
schlechter ist. Dieses wird im Kapitel 7.1 „Bewertung“, Seite 63, näher betrachtet.
6.3
Messung der Methode „B I“
00:80:48:3D:EE:67 Diese Methode B I hat keinen Erfolg gebracht.
Abbildung 6.7: Methode B I, Schema Netzverbindung
Die virtuelle Brücke bekommt die MAC-Adresse eines seiner Interfaces. In der Abbildung
6.7 hat die Brücke die MAC-Adresse vom Interface 0. Bei den Tests hatte die Brücke
und ein Interface die MAC-Adresse 00:0b:6D:4E:D9:D0. Das andere Interface hatte die
MAC-Adresse 00:80:48:3D:5B:67.
Die IP-Adresse wird auf die virtuelle Brücke gesetzt.
Sobald sich das Interface mit der anderen MAC als die Brücke verbindet, können die
Pakete nicht mehr versendet werden:
Wie in Bild 6.8 zu erkennen, assoziiert sich das Interface mit der MAC 00:80:48:3D:5B:67
mit dem Access Point (2. Zeile). Aber die IP Pakete haben als Absender-MAC-Adresse
die 00:0b:6D:4E:D9:D0. Das ist die MAC-Adresse der virtuellen Brücke, und damit logisch. Allerdings kennt der Access Point diese MAC-Adresse nicht, und verwirft dieses
Paket folgerichtig.
Daher ist die Methode in dieser Art ein Fehlschlag.
Um das zu umgehen, und diese Methode doch noch zum Gelingen zu führen, kann man
beiden Interfaces die gleiche MAC Adresse geben. Damit hat man fast die gleiche Konstellation, wie bei Methode B II, nur daß kein Wechsel der IP-Adresse stattfinden muss.
Dieses Variante wird im folgenden Kapitel unter der Bezeichnung „Methode I b“ gemessen.
54
Kapitel 6. Messung
6.4. Messung der Methode „B I b“
Abbildung 6.8: Methode B I, Screenshot Wireshark
6.4
Messung der Methode „B I b“
Da die Methode „B I“ keinen Erfolg gebracht hat, wird hier die Variante „B I b“: „Abwechselndes Scannen: virtuelle Brücke“ mit der Änderung, daß beide Interfaces die gleiche MAC-Adresse erhalten, gemessen.
6.4.1
6.4.1.1
Auswertung UDP-Test
1 Empfangsmodus
Öffne Socket..
3 [...]
5 Bei 57494, Lücken: {[1-487(487)], [1] [2974-2977(4)], [3173-3174(2)], [1] [1] [1] [1]
[1] [1] [1] [5532-5533(2)], [1] [1] [1] [1] [1] [1] [1] [1] [12378-12379(2)],
[12381-12384(4)], [1] [13231-13232(2)], [1] [1] [20919-21692(774)],
55
Kapitel 6. Messung
[22585-22587(3)], [1] [1] [1] [1] [24373-24374(2)], [25141-25143(3)], [1] [1] [1]
[27694-27695(2)], [1] [1] [1] [29405-29406(2)], [1] [1] [31144-31919(776)], [1] [1]
[1] [35403-35404(2)], [1] [1] [40522-41291(770)], [1] [1] [44771-44772(2)], [1] [1]
[1] [46493-47264(772)], [1] [1] [1] [55016-55787(772)], [1] [1] }
Quellcode 6.5: Methode B I b, Netz → WLAN. Ausgabe UDP-Test
Trotz einer abendlichen Messung kann man einen relativ hohen Paketverlust verzeichnen.
Es gibt zwar größere Lücken, die auf das Roaming schließen lassen, aber um zu erkennen,
welche fehlende Pakete auf das Roaming zurückzuführen sind, wird bei der Analyse des
Ethereals noch die fehlenden Paketnummern mit angegeben.
6.4.1.2
Auswertung Ethereal
1
2.597022
2.141303
0.455719
2
3.596911
3.141047
0.455864
3
4.596693
4.140828
0.455865
Tabelle 6.6: Messung: Methode B I b, Netz → WLAN. Versatz
der dump Dateien
Bei der Tabelle 6.7 zu den Roaming Zeiten Layer 2 wird zusätzlich notiert, welches das
letzte UDP-Paket auf einem Kanal war, und welches das erste UDP Paket auf dem anderen
Kanal war. Anhand der Informationen kann man dann mit der Auswertung vom UDP-Test
vergleichen, welche Pakete aufgrund des Roaming verlorengegangen sind.
Nr
Kanal
Deassoziation Assoziation Differenz UDP letztes UDP erstes
1 1 → 13
73.295482
72.845339
0.005673
10687
10688
2 13 → 1
135.882813
136.339563
0.000934
20918
20920
3 1 → 13
199.386141
198.931387
0.001062
31143
31144
4 13 → 1
256.717229
257.175945
0.002900
40518
40523
5 1 → 13
293.957166
293.505389
0.004039
46492
46494
6 13 → 1
346.036492
346.495410
0.003102
55015
55017
56
Kapitel 6. Messung
Nr
Kanal
Tabelle 6.7: Messung: Methode B I b, Netz → WLAN. Roaming Zeiten Layer 2
Minimale Zeit: 1ms, Maximale Zeit: 5,6ms. Arithmetisches Mittel: 2,9ms.
Dies entspricht den Lücken im UDP-Test:
Nr
Lücke Anzahl
1
-
-
2 20919-21692
774
3 31144-31919
776
4 40522-41291
770
5 46493-47264
772
6 55016-55788
773
Tabelle 6.8: Messung: Methode B I b, Fehlende Pakete dem
Roaming-Vorgang zugeordnet
Beim ersten Vorgang geht kein Paket verloren, bei den anderen durchschnittlich 773 Pakete. Das entspricht 3,9ms.
Obwohl das Umschalten im Layer 2 innerhalb von maximal 6ms geht, und es zu maximal
4 Paketen Verlust auf dem Medium kommt, kommen die Pakete, die auf dem Medium
kurz nach dem Roamen übertragen werden, nicht auf der Station an.
6.4.2
Die UDP-Pakete werden von dem Roaming-WLAN System auf einen Rechner im Festnetz geschickt.
6.4.2.1
Auswertung UDP-Test
1 Empfangsmodus
Öffne Socket..
57
Kapitel 6. Messung
[..]
5 Bei 82977, Lücken: {[1-308(308)], [1] [8204-13022(4819)], [19610-20385(776)], [1]
[34945-35713(769)], [43773-44527(755)], [1] [1] [1] [1] [73569-74336(768)],
[80804-81566(763)], }
Quellcode 6.6: Methode B I b, WLAN → Netz. Ausgabe UDP-Test
Es ist nur zu geringen Paketverlusten gekommen. Alle großen Lücken sind dem RoamingVorgängen zuordnenbar.
Da die sonstigen Lücken sich im 755 bis 776 Pakete bewegt, werte ich die erste Lücke
mit 8419 fehlenden Paketen als Ausreißer. Rest: Minimal 755 fehlende Pakete, Maximal
776 fehlende Pakete. Das entspricht 3,7 bis 3,8 Sekunden.
6.4.2.2
Auswertung Ethereal
1
3.761038
3.678193
0.082845
2
4.760830
4.677987
0.082843
3
5.760693
5.677708
0.082985
Tabelle 6.9: Messung: Methode B I b, WLAN → Netz. Versatz
der dump Dateien
Nr
Kanal
1
1 → 13
61.753198
61.671265
958
2
13 → 1
135.214918
135.301447
3638
3
1 → 13
235.120696
235.038688
883
4
13 → 1
292.833597
292.917264
776
5
1 → 13
487.268489
487.189199
3601
6
13 → 1
534.471405
534.557830
3534
Tabelle 6.10: Messung: Methode B I b, WLAN → Netz. Roaming Zeiten Layer 2
58
Kapitel 6. Messung
6.5. Messung der Methode „B II“
Minimale Zeit: 0,8ms, Maximale Zeit: 3,6ms. Da es zwei „Blöcke“ gibt - einmal um 1ms
und einmal um 3,5ms, ist ein Arithmetisches Mittel nicht sinnvoll.
6.5
Messung der Methode „B II“
Es wird die Methode B II „Abwechselndes Scannen: gleiche MAC-Adresse“ gemessen.
6.5.1
Es wurde sechs Mal das Roamen erzwungen. Aufgrund des in Kapitel 5.6.7 auf Seite
37 erwähnten Problems, wurde beim ersten Roamen einmal hin und hergeschaltet, sodas
insgesamt acht Mal geroamt wurde.
6.5.1.1
Auswertung UDP-Test
1 Empfangsmodus
Öffne Socket..
[..]
5 Bei 51431, Lücken: {[1-319(319)], [1] [1755-1756(2)], [1] [3674-3675(2)], [1] [1] [1]
[1] [1] [1] [1] [1] [1] [1] [1] [1] [1] [1] [1] [1] [1] [1] [1] [22536-22537(2)],
[1] [1] [1] [1] [1] [1] [1] [1] [1] [33679-33680(2)], [33682-33684(3)], [1] [1] [1]
[1] [1] [1] [1] [1] [1] [1] [42268-42273(6)], [1] [1] [1] [1] }
Quellcode 6.7: Methode B II, Netz → WLAN. Ausgabe UDP-Send
Neben einem erhöhten Paketverlust gibt es eine größere Lücke im Datenstrom: [4226842273(6)]. Das heisst, daß durch das Roaming entweder nur ein Paket verloren gegangen
ist, oder keines. Das muss man in der Auswertung zum Ethereal kontrollieren.
6.5.1.2
Auswertung Ethereal
Zuerst die Analyse des Versatzes:
59
Kapitel 6. Messung
ARP Paket Zeitpunkt Kanal 1 Zeitpunkt Kanal 13
Differenz
1
2.095689
2.173793
-0.078104
2
3.095406
3.173995
-0.078589
3
4.095586
4.173385
-0.077799
Tabelle 6.11: Messung: Methode B II, Netz → WLAN. Versatz der dump Dateien
verwendet (subtrahiert).
Bei der Tabelle 6.12 zu den Roaming Zeiten Layer 2 wird zusätzlich notiert, welches
das letzte UDP-Paket auf einem Kanal war, und welches das erste UDP Paket auf dem
anderen Kanal war. Anhand der Informationen kann man dann mit der Auswertung vom
UDP-Test vergleichen, welche Pakete aufgrund des Roaming verlorengegangen sind.
Nr
Kanal
1 13 → 1
23.395035
23.319546
0.002675
1976
1977
2 1 → 13
70.781379
70.862760
0.003217
9677
9678
3 13 → 1
81.539610
81.466944
0.005498
11408
11410
4 1 → 13
92.144482
92.226617
0.003971
13140
13142
5 13 → 1
134.425517
134.351075
0.003722
19984
19988
6 1 → 13
176.550526
176.629481
0.000791
26841
26842
7 13 → 1
229.334973
229.262098
0.005289
35390
35391
8 1 → 13
260.961310
261.040161
0.000687
40543
40544
Tabelle 6.12: Messung: Methode B II, Netz → WLAN. Roaming Zeiten Layer 2
Minimale Zeit: 0,7ms, Maximale Zeit: 5,4ms. Arithmetisches Mittel: 3,2ms.
Bei den Roaming Vorgängen vier bis acht ist je ein Paket auf dem Kanal verloren gegangen.
Bei den Roaming Vorgängen sechs bis acht ist es jeweils das letzte Paket, was auf den
Kanal, von dem weggeroamt wurde, gesendet wurde.
Die Analyse mit der UDP-Test Ausgabe zeigt, das zusätzlich die Roamingvorgänge zwei
und drei je ein Paketverlust erzeugt haben.
60
Kapitel 6. Messung
Beim Vorgang Nummer fünf war das letzte Paket das mit der Nummer 19984, die Anwendung hat aber trotzdem die Pakete 19985 und 19986 empfangen. Die massiven Wiederholungen des ACKs zu diesem Zeitpunkt lassen auf eine Störung im Kanal schließen,
die dafür gesorgt haben, daß die Scan-Station dieses Pakete nicht einwandfrei empfangen
hat. Und so wurden diese Pakete schon im Layer eins oder zwei/MAC verworfen, ohne
daß der Treiber dieses zu sehen bekommen hätte.
Die ersten beiden Roaming Vorgänge haben also keinen Paketverlust verursacht, die anderen immer nur ein einzelnes Paket.
6.5.2
Die UDP-Pakete werden von dem Roaming-WLAN System auf einen Rechner im Festnetz geschickt.
Das Roamen wurde sechs Mal erzwungen.
6.5.2.1
Auswertung UDP-Test
1 Empfangsmodus
Öffne Socket..
[..]
5 Bei 68016, Lücken: {[1-106(106)], [1] [12361-12386(26)], [20632-20812(181)], [1]
[34528-34698(171)], [43595-43765(171)], [53394-53574(181)], [65778-65946(169)], }
Quellcode 6.8: Methode B II, WLAN → Netz. Ausgabe UDP-Test
Zwei Paketverluste durch Übertragungsfehler.
Minimaler Paketverlust: 26, Maximaler Paketverlust: 181. Das entspricht: 130ms bis
905ms.
6.5.2.2
Auswertung Ethereal
1
1.572126
1.469941
0.102185
2
2.571836
2.469802
0.102034
61
Kapitel 6. Messung
3
3.571746
3.469515
0.102231
Tabelle 6.13: Messung: Methode B II, WLAN → Netz. Versatz der dump Dateien
verwendet (addiert).
Nr
Kanal
1
1 → 13
86.063974
85.962916
0.001092
2
13 → 1
138.661045
138.763239
0.000044
3
1 → 13
228.240721
228.142148
0.003877
4
13 → 1
286.084077
286.188677
0.002450
5
1 → 13
349.397391
349.298072
0.002831
6
13 → 1
428.265753
428.388421
0.020518
Tabelle 6.14: Messung: Methode B II, WLAN → Netz. Roaming Zeiten Layer 2
Die Differenz des Roaming-Vorgangs Nummer zwei ist sehr klein, und nicht reproduzierbar. Daher betrachte ich diese Differenz im weiteren nicht.
Bei dem Roaming-Vorgang Nummer sechs wurde das Authentications- und AssociationPaket mehrfach gesendet. Zu diesem Zeitpunkt war scheinbar der Kanal gestört, so das
es zu einer extremen Abweichung gegenüber den anderen Zeiten gekommen ist. Daher
betrachtet ich diese Differenz bei der weiteren Betrachtung auch nicht.
Minimale Zeit: 1,0ms, Maximale Zeit: 3,8ms. Arithmetisches Mittel: 2,6ms.
62
Kapitel 7
Bewertung
7.1
Allgemein
Die durchweg schlechten Zeiten bei der Messvariante „UDP Versand von der WLANStation auf das Festnetz“ (bis zu einer Sekunde Paketverlust) im Gegensatz zu den guten
(3,2ms) bis brauchbaren Zeiten (15ms) bei der Messvariante „UDP Versand von Festnetz
auf die WLAN-Station“ lassen darauf schließen, daß im IP-Stack des Kernels der WLANStation etwas nicht wie geplant läuft. Was und wieso konnte aus Zeitgründen nicht geklärt
werden.
Aus diesen Grund werden die Messergebnisse des UDP-Versands der Messvariante „UDP
Versand von der WLAN-Station auf das Festnetz“ nicht beachtet.
7.2
Methode A
Die Zeit, die die Station braucht, um sich abzumelden, Kanal zu wechseln, und wieder
anzumelden beträgt ungefähr 15 ms. Dieses wird von dem UDP-Versand bestätigt.
Damit ist diese Variante eine brauchbare Roaming Lösung.
7.2.1
Nachteile
Diese Methode braucht einen geänderten Treiber.
Das birgt Probleme mit der Aktualität. Ob und wann die Treiberentwickler die Funktionalität abändern, auf den dieser Ansatz baut, kann man nicht vorhersagen.
63
7.3. Methode B
Kapitel 7. Bewertung
Das man eine bereits genutzte I/O Control ID verdrängen muss, ist ein weiteres Problem.
Man weiß nicht, welche Drittsoftware darauf aufbaut. Dieses dürfte aber mit einigem
Aufwand zu lösen sein.
Ein Übertragen auf andere Treiber ist auch nicht möglich, da alle Treiber unterschiedliche
Interna haben.
7.2.2
Vorteile
Ein Vorteil ist, daß aus Netzsicht keine unsauberen Dinge passieren. Wie zum Beispiel,
daß die WLAN-Station wie bei Methode B zu einem Zeitpunkt zweimal eingeloggt ist.
Auch kann man das Interface ohne Probleme mit DHCP konfigurieren.
Das man hier ein eigenes Scannen nutzen kann, ist weiter von Vorteil.
7.3
Methode B
Die Methode B I ist fehlgeschlagen. Dafür ist die Methode B I b von gewissem Erfolg.
Bei beiden Varianten (B I b und B II) fällt auf, daß der madwifi Treiber einen aktiven
Scan macht. Aus diesem Grund sind in den dump-Dateien viele „Probe Request“ Pakete
verzeichnet. Dieses ist zwar nicht gut, aber ein passiver Scan war keine Bedingung dieser
Arbeit, sodas es ignoriert wurde.
Erstaunlich ist auch bei allen Messungen, daß alle Differenzen positiv sind. Man würde negative Differenzen erwarten, da zuerst assoziiert wird, und erst danach deassoziiert
wird. Das liegt aber daran, daß die WLAN-Karte die Befehle asynchron ausführt. Es
nimmt den „Auftrag“ zum assoziieren entgegen, und leitet die Kommunikation ein. Aber
das Programm wird hier nicht blockiert. Daher gibt das Programm fast zeitgleich der anderen WLAN Karte den Deassoziierungsbefehl. Und zusätzlich wird der Zeitpunkt des
ersten Paketes beim Deassoziieren und der Zeitpunkt des letzten Paketes beim Deassoziieren notiert. Da zusätzlich das Assoziieren einen höhere Paketanzahl benötigt, ist die
Differenz positiv.
7.3.1
Methode B I b
Die Roaming Zeiten im Layer zwei von maximal 5,6 sind gut. Aber die UDP-Pakete
kommen fast vier weitere Sekunden nicht an, egal, ob diese gesendet oder empfangen
64
7.3. Methode B
werden.
Bei den Messungen der anderen Methoden kommt es zumindest beim Empfang der Pakete
nicht zu diesen katastrophalen Zeiten.
Das Problem ist die virtuelle Bridge, die nicht dafür ausgelegt ist, schnelle Wechsel der
Interfaces zu erkennen und darauf zu reagieren. Zusätzlich ist die virtuelle Bridge darauf
ausgelegt, mit STP zu arbeiten. Daher hat die virtuelle Bridge alle dafür notwendigen Zustände (learning, u.s.w.), die zunächst durchlaufen werden, wenn eine Netzwerkänderung
erkannt wird. Und das ist bei jedem Roamen gegeben. Man kann zwar das STP bei der
Bridge deaktivieren, aber die Bridge läuft dann immer noch durch die einzelnen Stati.
Diese könnte man umgehen, indem man die Bridge-Software anpasst und verändert.
7.3.2
Methode B II
Die Durchschnittszeit von 3,2ms ist sehr gut. Diese Zeit wird auch vom UDP-Send bestätigt, daß maximal ein Paket Verlust pro Roaming Vorgang hat.
7.3.3
Nachteile
Bei der Methode B II ist es nicht möglich, den Standart-DHCP Client zu verwenden.
Dieser arbeitet immer nur auf ein Interface, und „kontrolliert“ es. Die Methode B II ändert
aber bei jedemn Raoming die IP-Adresse der Interfaces ab, um das Routing richtig zu
stellen. Dazu muss es ein Interface mit einer „falschen“ IP belegen, was den DHCP Client
aber durcheinander bringen würde.
Ein Lösung wäre es, im Roaming Programm selber ein DHCP zu implementieren.
7.3.4
Vorteile
Beide Methoden arbeiten mit den originalen madwifi Treibern und der gegeben API. Diese sollte stabil sein, und sich nicht mehr ändern. Wenn doch, so ist der Änderungsaufwand
nur minimal.
Obwohl das Programm in der aktuellen Version nur mit den madwifi zusammenarbeitet,
ist es sehr einfach möglich, das Programm so umzuschreiben, daß es für alle WLANTreiber funktioniert. Mann muss nur an der Stelle, bei dem assoziiert / deassoziiert wird,
den API Aufruf einfügen, der hinter iwconfig ifX ap XX:XX:XX:XX:XX:XX
steckt.
65
7.4. Andere Ergebnisse
7.4
Andere Ergebnisse
Während der Implementierung und den direkten Tests ist bei der Methode B II eine Besonderheit aufgefallen:
Wenn man zwischen dem Assoziieren und Deassoziieren eine Wartezeit einbaut - durch
Warten auf die Bestätigung, daß die WLAN-Karte sich zum Access Point assoziiert hat,
oder durch ein simples „sleep(1)“, dann gibt es bei der Messvariante „WLAN → Netz“
massiven Paketverlust von 500ms und mehr. Interessant dabei ist, daß beim eigentliche
Roamingvorgang kein Paketverlust auftritt, sondern vorher.
Und zwar meldet der Access Point, mit dem sich die Station assoziiert hat, mittels eines
LLC-Update Frame, daß die WLAN Station jetzt bei diesem Access Point zu finden ist.
Der Access Point, der die alte Verbindung noch hält, deassoziiert daraufhin die WLANStation. Gleichzeitig sendet die WLAN-Station noch über die alte Verbindung. Der Treiber stößt also ein Reassoziieren an, und verbindet sich so neu mit dem alten Access Point.
Diese Zeit ohne Verbindung sorgt für den Paketverlust.
Dadurch, daß bei der aktuellen Variante das Assoziieren und Deassoziieren fast gleichzeitig aufgerufen wird, und es daher nicht mehr zu dem oben beschriebenen Fall kommt,
hat die aktuelle Variante dieses Problem nicht.
66
Kapitel 8
Fazit
8.1
Beurteilung der getesteten Methoden
Eine angestrebte Zeitdauer für ein Roaming Vorgang im industriellen Bereich liegt bei
maximal 10ms [sie].
Für VoIP sind Zeiten besser als 150ms gewünscht.
Die Methode A liegt mit 15ms nicht in dem Bereich, der für eine Automatisation notwendig wäre. Die Zeit geht hauptsächlich für den Kanalwechsel verloren.
Die Methode B I b ist mit 4 Sekunden komplett unakzeptabel.
Die Methode B II liegt bei 3,2ms und erreicht damit die geforderten Werte ohne Probleme.
Bei allen Methoden gibt es aber noch das Problem, wie in dem Kapitel 7.1, Seite 63
beschrieben, daß der IP-Stack noch ein effizientes schnelle Roamen verhindert, während
die Station unter Sendelast steht. Das Problem muss vorher gefunden und gelöst werden.
8.2
Beurteilung der Infrastruktur
Die Methode des Clientseitigen Roamings verlagert ein Teil der Netzintelligenz auf den
Client.
Dieses ist teilweise in Ordnung: Der Client ist die optimale Stelle, um die aktuelle Lage
im Funknetz zu beurteilen, da er ja „mittendrin“ ist.
Die Nachteile sind aber, daß das Roaming für das umgebenen Netz zu nicht vorhersagbaren Zeiten stattfindet, und deshalb bei jedem Roamingvorgang Pakete verloren gehen, die
die Protokolle der höheren Ebenen erst wieder neu anfordern / schicken müssen.
67
8.2. Beurteilung der Infrastruktur
8.2.1
Kapitel 8. Fazit
Vergleich zu „Switched WLAN“
Switched WLAN zeichnet sich durch die vollständige Kontrolle der Clients durch eine
zentrale Stelle, den Switch, aus. Dieser Switch hat die gesamte Netzstruktur im Überblick.
Das Clientroaming kennt nur das Netz an der aktuellen Stelle. Daher ist das Switched
WLAN eher in der Lage, die Clients optimal zu verteilen.
Auch sind die Systeme beim Clientroaming unabhängig, und ein Administrator muss jedes System einzeln konfigurieren. Selbst bei kleinen Änderungen muss ein Administrator
an jedes System diese Änderung nachziehen. Beim Switched WLAN muss der Administrator diese Änderung nur an dem zentralen Switch machen, der diese an die Clients
weiterleitet. Das Switched WLAN hat also einen erheblichen Administrationsvorteil.
Obwohl es einen Standard für Switched WLAN gibt, nutzen viele Hersteller noch eigenene, propritäre Protokolle, oder propritäre Erweiterungen zu dem Standard. Daher ist man
darauf angewiesen, die gesamte Hardware von einem einzigen Hersteller zu beziehen.
Beim Clientseitigen Roaming setzt man aber auf normale Standardkomponenten, und ist
daher in der Lage, kostengünstig das Netz aufzubauen oder zu erweitern.
Bei mittleren bis großen Installation dürfte daher das Switched WLAN von Vorteil sein,
da es die Administrationskosten niedrig hält.
Bei kleinen und nicht lebenskritischen Installationen hat das Clientseitige Roaming starke
Kostenvorteile.
8.2.1.1
Vergleich der Zeiten
Frau Nuray Saracoglu hat 2007 hat in ihrer Diplomarbeit [Sar07] die folgenden Zeiten
erhalten:
System
Zeiten
Aruba
76 - 303
Extricom
-1
Tabelle 8.1: Roamingzeiten Switched WLAN Systeme
[Sar07]
Die Ergebnisse dieser Arbeit sind wesentlich besser als die des Aruba-Systems. Das Extricom schafft es allerdings komplett ohne Zeitverlust, aber mit dem Nachteil, das alles
1
Siehe Beschreibung im Konzept, Kapitel 4.1.1, Seite 13
68
Kapitel 8. Fazit
8.3. Energie
auf einer Frequenz arbeiten muss.
8.2.2
Vergleich zu „Sync Scan“
Obwohl beim Sync Scan die Scanzeit sehr kurz ist, ist die dennoch vorhanden.
Dieses fällt beim Fast-Roaming durch die zwei WLAN-Karten weg, da die Station zum
Scannen nicht mit dem Hauptinterface den Kanal verlassen muss.
8.2.3
Vergleich zu „802.11r“
Dieser Standard ist noch nicht verabschiedet, daher kann man nichts Genaues sagen. Aber
nach den Berichten, die man liest, liegt das Hauptaugenmerkt beim 11r Standard auf der
schnellen Reassoziation bei verschlüsselter Verbindung. Daher ist das Ziel ein anderes als
beim Fast-Roaming mittels zwei WLAN -Karten.
8.3
Energie
Trotz Powermanagementoptionen ist die WLAN Hardware nicht auf Stromsparsamkeit
optimiert. Das ist unter anderen einer der Gründe, wieso sich WLAN in aktuellen PDAs
und Handys noch nicht durchgesetzt hat. Mit einem zweiten WLAN Interface ist die Energieversorgung noch kritischer.
In kleinen, mobile Systemen wie PDAs, Handys oder Voice-voer-IP Headsets dürfte daher
das Fast-Roaming mittels einer zweiten WLAN-Karten keine Option sein. Erst ab Systemen der „Laptop-Klasse“, bei denen die anderen Komponenten wesentlich mehr Energie
verbrauchen als eine WLAN-Karte, kann man eine zweite WLAN-Karte verbauen, ohne
den Energiehaushalt wesentlich zu beinträchtigen.
8.4
Hardware
Ein großer Nachteil des hier vorgestellen Clientseitigen Roamings ist, daß die Ausrichtung und die Lage der Antennen sehr ähnlich sein muss, sonst gibt es erhebliche Falschmessungen.
Ein logischer Schritt wäre es, zwei Transceiver auf einem Interface unterzubringen. Allerdings bin ich nachrichtentechnisch nicht in der Lage, das zu beurteilen.
69
8.5. Sonstiges
Kapitel 8. Fazit
Ein denkbarer Zwischenschritt könnte sein, daß man auf dem WLAN Interface einen
zweiten Receiver unterbringt. Entweder direkt mit der Antenne gekoppelt, oder man legt
eine zweite Antenne neben die „Hauptantenne“. Mit diesem ist zwar ein Senden nicht
möglich, aber dieser Recveiver könnte nonstop einen passiven Scan machen. Mit einem
entsprechenden Treiber wären auch diese Informationen direkt im Treiber vorhanden,
sodas ein Raoming nach Methode A möglich wäre, ohne aber die Scaninformationen
übertragen zu müssen.
8.5
8.5.1
Sonstiges
Verschlüsselung
Beide Methoden bauen auf einer unverschlüsselten Verbindung auf. Eine WEP Verschlüsselung wäre möglich, aber heutzutage nicht zu empfehlen, da diese binnen Minuten gebrochen werden kann. Eine WPA Verbindung verlangt aber weitere Authentifizierungsschritte.
Unter Linux wird die WPA-Verbindung nicht mit den Treiber-Grundfunktionen hergestellt, sondern dazu wird das Programm „wpa_supplicant“ genutzt. Der wpa_supplicant
kontrolliert selber die Verbindungen zum Access Point, und steuert diese. Um hier ein
Fast-Roamen mittels einer zweiten WLAN-Karte zu ermöglichen, sind die externe Programme nicht zu gebrauchen, da der wpa_supplicant die Kontrolle über die Verbindung
zu den Access Points braucht. Daher muss man, um das Roamen zu ermöglichen, hierfür
den wpa_supplicant abändern und erweitern.
70
Kapitel 9
Anhang
9.1
Installation von SuSE 10.2 auf einem WRAP
Im Internet stehen an vielen Stellen kurze Hinweise, die man für die Installation von SuSE
10.2 auf den WRAP benötigt. Allerdings ist bei jedem Problem eine Suche notwendig,
die sich Aufgrund der Falschaussagen etwas ziehen kann. Daher hier ein kurzer Überblick
der Installation.
Alle Angaben sind Vorschläge, wie Sie im w2l2 genutzt werden. Diese Angaben kann
man je nach Bedarf anpassen.
9.1.1
Voraussetzung
Dieses ist notwendig, um SuSE 10.2 auf einen WRAP zu installieren:
• Eine Compact-Flash Karte. Mindestens mit einem Gigabyte Speicher.
• Ein Compact-Flash Kartenleser
• Ein laufendes System mit SuSE 10.2, mit zusätzlich:
– Kernelquellen
• Grundlegende Kenntnisse in Linux und PC Administrationsaufgaben, wie z.B.
„Partitionieren“.
• Außerdem ist es notwendig, bei diesem Dokument mitzudenken. Zum Beispiel
sind alle Pfade Beispielpfade, die sich unterscheiden können.
71
9.1. Installation von SuSE 10.2 auf einem WRAP
9.1.2
Kapitel 9. Anhang
Vorbereitung
Die Compact-Flash Karte muss zuerst partitioniert werden. Dazu muss die Karte angeschlossen werden. Unter welchem Namen die Karte gemountet wird, bitte mit dmesg
nachsehen.
Dann fdisk aufrufen, und diese Partitionen als Primärpartitonen anlegen
1
# fdisk /dev/sda
Quellcode 9.1: Aufruf von fdisk, wenn die Karte nach sda gemountet wurde
• 128 MB für Swap: Typ 82. Mehr sollte man nicht nutzen, eher weniger, da der
Speicherplatz auf einer Gigabyte Karte stark beschränkt ist. Außerdem reicht der
Arbeitsspeicher von 128MB des WRAP im Normalfall vollkommen aus.
• den restlichen Platz mit einer normale Linux-Partition belegen
dann die Partitionen formatieren:
1
3
# mkswap /dev/sda1
# mkfs.ext2 /dev/sda2
# tune2fs /dev/sda2 -c 1
Quellcode 9.2: Formatieren der Partitionen
Der letzte Aufruf wird benötigt, damit das Betriebssystem diese Partion bei jedem mounten prüft. Dieses ist notwendig, da sich im Laborbetrieb herrausgestellt hat, das die
WRAPs gerne zu früh vom Strom getrennt werden, sodaß der Puffer nicht vollständig
geleert werden konnte.
Sobald die Formatierung erledigt wurde, muss man die zweite Partition einbinden. Dazu
hat man zwei Möglichkeiten:
a) Automatisch: Die Karte mit
1
# eject /dev/sda
Quellcode 9.3: Auswerfen der Karte
72
Kapitel 9. Anhang
logisch auswerfen (alle Bindungen lösen). Danach einfach die Karte aus dem Leser ziehen
und neu einstecken. Sofern das automatische Mounten nicht deaktiviert wurde, erscheint
die Karte kurze Zeit später unter /media/disk
b) manuell: Die Karte mit
1
# mount /dev/sda2 /mnt
Quellcode 9.4: Mounten der Karte
nach /mnt mounten.
9.1.3
Software installieren
Zum Installieren der Software muss man unter YaST den Menüpunkt „Installation in Verzeichnis“ wählen. Hier gibt man den Pfad der Karte an.
In der Softwareauswahl sollte man die folgenden Pakete auf „Tabu“ stellen. Je mehr auf
Tabu steht, desto mehr Speicherplatz hat man am Ende zur Verfügung! Aber die YAST Pakete sollte man nicht anfassen, da diese sehr obskure Abhängigkeiten haben, bei denen
man das ganze Zielsystem nicht mehr lauffähig machen könnte.
• Schema: Apparmor
• Schema: ZMD
• Schema: XWindows
• Paket: qt3
• Pakete: gtk*
• Pakete: alsa*
• Pakete: cups*
Diese Pakete müssen angehakt sein: ssh, vi
Dann die Installation laufen lassen. Das kann bis zu einer halben Stunde dauern.
Danach löscht man von der Karte die Verzeichnisse: /lib/modules/*-default/, da der
WRAP einen eigenen Kernel benötigt.
73
9.1.4
Kapitel 9. Anhang
Kernel und Module kompilieren
In den Kernelquellen (/usr/src/linux) mit
1
# make xconfig
Quellcode 9.5: Konfigurieren des Kernels
die Kernelkonfiguration starten.
Diese Einstellungen müssen gemacht werden:
• Als Erweiterung „wrap“ wählen. Wichtig, da es sonst zu Kollisionen mit der Installation des Hauptsystems kommen kann.
• Als Modul kompilieren: „scx200“
• Als Modul kompilieren: „sc1200“
• Zielsystem: AMD Geode, Sub: x86.
• So viele nicht notwendige Dinge wie z.B. „Framebuffer“ wie möglich abwählen.
Allerdings muss man hierbei Vorsicht walten lassen, sonst funktioniert der Kernel
nicht.
Danach den Kernel mit
1
# make
Quellcode 9.6: Kernel kompilieren
kompilieren. Dieses dauert SEHR lange!
Wenn der Kernel fertig kompiliert wurde, diesen auf die Karte kopieren:
1
# cp /usr/src/linux/arch/i386/boot/bzImage /media/disk/boot/bzImage-wrap
Quellcode 9.7: Kernel kopieren
Im Anschluss die Module kompilieren:
1
# make modules
Quellcode 9.8: Module kompilieren
74
Kapitel 9. Anhang
Und auf die Karte kopieren:
1
# cp -r /lib/modules/2.6.18.2-34-wrap /media/disk/lib/modules/
Quellcode 9.9: Module kopieren
9.1.5
Die Karte bootfähig machen
Jetzt muss die initziale RAM-Disk erzeugt werden:
1
# mkinitrd -k /media/disk/boot/bzImage-wrap -i /media/disk/boot/initrd-wrap
-M/usr/src/linux/System.map -m "scx200 sc1200" -s 0
Quellcode 9.10: RAM-Disk generieren
Mit „-m“ wird angegeben, daß diese Module in die RAM-Disk aufgenommen werden
müssen. Da dieses die Festplatten-Controler Treiber sind, ist dieses zum Booten notwendig. Mit „-s“ Wird der Boot-Splash deaktiviert.
Nun muss der Boot-Loader installiert werden:
1
# grub-install --root-directory=/media/disk --no-floppy /dev/sda2
Quellcode 9.11: Boot-Loader (grub) installieren
Wenn die Fehlermeldung „/dev/sda2 does not have any corresponding BIOS drive.“ erscheint, liegt es daran, daß /dev/sda in der device.map auskommentiert wurde. Einfach
die device.map löschen.
Sollte der grub-installer irgendwelche Dateien vermissen, kann man diese einfach von
dem Hauptsysten auf die Karte kopieren.
Da der WRAP keinen VGA Ausgang hat, sondern nur eine serielle Konsole, muss man
die Boot-Meldungen auf die Konsole umleiten. Dazu in der „menu.lst“ vom grub die Zeile
„gfxmenu“ auskommentieren und dafür eintragen:
1 serial --unit=0 --speed=38400 --word=8 --parity=no --stop=1
terminal --timeout=1 serial console
Quellcode 9.12: Serielle Ausgabe des Grubs aktivieren
75
Kapitel 9. Anhang
Als Boot-Eintrag anlegen, bzw. einen vorhanden überschreiben:
title openSUSE 10.2 Wrap
root (hd0,1)
kernel /boot/bzImage-wrap root=/dev/hda2 resume=/dev/hda1 splash=silent showopts
console=tty0 console=ttyS0,38400n8 reboot=bios
4
initrd /boot/initrd-wrap
2
Quellcode 9.13: Serielle Ausgabe des Kernels aktivieren
Jetzt das Login über die serielle Schnittstelle erlauben. Dazu auf der Karte in der Datei
/media/disk/etc/inittab dieses anfügen:
co:2345:respawn:/sbin/agetty ttyS0 38400 vt100
Quellcode 9.14: Seriellen Login aktivieren
Man kann in diesem Zuge auch die lokalen Konsolen auskommentieren.
Damit man sich als root anmelden kann, muss man in der Datei /etc/securetty folgende
Zeile hinzuzufügen:
1 ttyS0
Quellcode 9.15: Login als root
Um den Bootvorgang über die serielle Konsole besser verfolgen zu können, muss man in
die Datei /etc/sysconfig/init eintragen:
1 BOOTUP=-serial
PROMPT=no
Quellcode 9.16: Login als root
Die Datei /etc/fstab muss noch angepasst werden:
/dev/hda1
swap
2 /dev/hda2
/
proc
/proc
proc
4 sysfs
/sys
sysfs
devpts /dev/pts
swap
defaults 0 0
ext2
acl,user_xattr 1 1
defaults 0 0
noauto 0 0
devpts mode=0620,gid=5 0 0
Quellcode 9.17: fstab
76
Kapitel 9. Anhang
Der SSH-Deamon muss startbar gemacht werden. Dazu in der Datei /etc/passwd anhängen:
1 sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
Quellcode 9.18: damit kann der sshd starten
9.1.6
WRAP verbinden
Wenn alle vorigen Arbeiten erledigt sind, kann man die Karte einbauen, und den WRAP
zusammenbauen.
Um den WRAP steuern zu können, ist ein Terminal Programm, wie z.B. „kermit“, notwendig.
Das Problem bei kermit ist es, das Programm unter einem normalen Useraccount zum
Laufen zu bekommen. Dazu muss man einige Rechte abändern:
1 # chmod 660 /dev/ttyS0
# chmod 770 /var/locks
Quellcode 9.19: Rechtekorrektur, um kermit als normaler User zu nutzen
Danach muss der User nur noch zur Gruppe „UUCP“ zugefügt werden.
Mit diesen Befehlen kann man sich verbinden:
set modem type none
2 set line /dev/ttyS0
set carrier-watch off
4 set speed 38400
connect
Quellcode 9.20: kermit Befehle, um sich zu verbinden
9.1.7
Erster Start
Beim ersten Start muss das root-Passwort gesetzt werden. Dazu muss Linux in Runmode
1 gestartet werden. Um dieses zu veranlassen drückt man im grub auf der Zeile des WRAP
Kernels die Taste „e“. Nun kann man die Boot Parameter ändern. In der Zeile „kernel“
muss „init=/bin/bash“ eingetragen werden.
77
Kapitel 9. Anhang
Nun startet man das System.
Bei dem gestarteten System gibt man diese Befehle an:
1 # passwd root
# sync
3 # mount -o remount,ro /
Quellcode 9.21: Befehle für den ersten Start
Mit „passwd root“ ändert man das root-Passwort.
Im Anschluss drückt man „STRG+D“ und startet den WRAP neu.
9.1.8
Allgemeine Hinweise
Wenn man
1 echo "A"|dd of=/dev/port bs=1 count=1 seek=62466
Quellcode 9.22: LED Steuerung
als vorletzen Befehl in /etc/rc.d/halt schreibt, sorgt das dafür, daß die dritte LED kurz vor
dem Ende des Herunterfahrens anfängt zu leuchten.
9.1.9
Klonen
Wenn man eine Karte erfolgreich zum Laufen bekommen hat, so kann man diese klonen,
und sich so viel Arbeit sparen.
9.1.9.1
Karte auslesen
Zuerst muss man die Original Karte kopieren. Dazu diese in den Kartenleser schieben.
Wenn das autoamtsiche Mounten aktiviert ist, muss man die Karte zuerst unmounten:
1 # umount /media/disk
Quellcode 9.23: Unmounten
Nun kann man die komplette Karte kopieren:
78
Kapitel 9. Anhang
1 # dd if=/dev/sda of=/tmp/dateiname
Quellcode 9.24: low-level kopieren: Karte auslesen
Danch die Karte mit „eject“ auswerfen.
9.1.9.2
Karte bespielen
Wichtig ist, daß die Ziel-Karte genau die gleichen logischen Eigenschaften hat, wie die
Original Karte (Sektoren, Zyliner, etc.)
Die Ziel-Karte bespielt man mit
1 # dd if=/tmp/dateiname of=/dev/sda
Quellcode 9.25: low-level kopieren: Karte beschreiben
Danach die Karte mit „eject“ auswerfen, und damit den WRAP booten.
9.1.9.3
Einstellungen korrigieren
Wenn das System gebootet ist, einloggen und:
• Die Datei „/etc/udev/rules.d/30-net_persistent_names.rules“ löschen, und neu starten.
• Bei Bedarf die Bezeichnung in der Datei „/etc/motd“ abändern
• Mit
1
# ifconfig eth1 192.168.0.11 netmask 255.255.255.0
Quellcode 9.26: IP Adresse setzen
dem Netzwerk die richtige IP geben. Das Interface ist eth1, da eth0 noch an das
Interface der Originalkarte gebunden ist. Man sollte schon hier die richtige IP nehmen. Das erleichtert nachher Einiges.
• Mit SSH auf das Gerät gehen, und „yast2 lan“ ausführen. Der ist per serieller
Konsole nicht nutzbar.
Im yast die alte Karte löschen (das ist die, bei der eine IP dabei steht).
Die neue Karte „National DP...“ konfigurieren. Dabei den Hostnamen korrigieren.
79
9.2. UDP-Test
9.2
Kapitel 9. Anhang
UDP-Test
Zur Messung der Geschwindigkeit wurde speziell ein Programm geschrieben, das per
UDP fortlaufend aufsteigende Zahlen verschickt.
9.2.1
Hintergrund
Eine Messung per Netzwerksniffen, wann die Anmelderoutine gelaufen ist, ist nicht wirklich aussagekräftig. Wichtig ist die Zeit, ab wann das Netzwerk dahinter diesen Wechsel
registriert und sich eingestellt hat.
Daher muss man richtige Pakete verschicken, und beobachten, ob diese an der Gegenstation ankommen.
TCP Pakete haben zur Messung den entscheidenden Nachteil, daß das Protokoll verlorene
Pakete nachfordert. Man wird unter TCP außer einem Komplettversagen nichts messen
können.
Deshalb wurde Versand per UDP gewählt, da diese Pakete nur einmal versendet weden.
Und wenn ein Paket verloren geht, dann ist es weg. Als Port wurde der Port 52972 gewählt. Diese Nummer hat keine tiefere Bedeutung.
9.2.2
Arbeitsweise
Das Programm besteht aus zwei Teilen: Einem Sende- und einem Empfangsteil.
9.2.2.1
Senden
Der Sendeteil sendet im Abstand von fünf Millisekunden eine fortlaufende Zahl (in Networkbyteorder).
Wichtig ist aber, daß der Kernel hierzu mit einer Frequenz von 1.000 Hz kompiliert wurde. Standardmäßig wird dieser (in Suse 10.2) mit 250Hz kompiliert, so daß Taskwechsel
maximal alle 4 ms oder einem Vielfachen davon stattfinden kann. Aber selbst wenn der
Kernel mit 1.000 Hz kompiliert wurde, dann kann man immer noch nicht davon ausgehen,
daß man genau eine Millisekunde warten kann. Messungen mit einer Millisekunde Wartezeit haben gezeigt, daß die reale Zeit zwischen den Paketen zwei bis fünf Millisekunden
war, nur ganz selten eine Millisekunde.
80
Kapitel 9. Anhang
9.2. UDP-Test
Mit einer Wartezeit von 5 Millisekunden auf einem 1.000 Hz Kernel sind die Zeiten zwischen den Paketen aber stabil.
9.2.2.2
Empfangen
Das Empfangsteil öffnet den UDP-Socket und wartet auf die Pakete. Es vergleicht immer
die aktuell übertragene Nummer mit der vorigen Nummer. Wenn diese nicht fortlaufend
ist, gibt das Programm dieses aus.
Um dem Effekt „ein Paket überholt ein anderes“ zu erkennen, wurde außerdem eine
„Lückenverwaltung“ eingebaut: Das Programm zeigt alle tausend Pakete die fehlenden
Pakete (mit der Paketnummer) an. Sollte jetzt dieser Effekt auftreten, so wird das zwar
gemeldet, aber die „Lücke“ wird sofort geschlossen, und nicht mehr angezeigt.
9.2.3
Ausgabe
Im „Senden“ Teil zeigt das Programm alle 1.000 gesende Pakete an, bei welcher Nummer
es gerade ist.
Beim Senden hat es z.B. diese Ausgabe:
1
3
5
7
9
wrap-delta:~ # ./_UDP-test
Empfangsmodus
Öffne Socket..
Bei 1488, Lücken: {[1-487(487)], }
Paketverlust: Erwarte 2130, empfange 2131
Bei 2490, Lücken: {[1-487(487)], [1] }
Bei 3498, Lücken: {[1-487(487)], [1] [2974-2977(4)], [3173-3174(2)], }
Quellcode 9.27: Beispielausgabe UDP-Test, Empfangsmodus
Sobald das Programm eine Zahl empfängt, zeigt es an, daß es was empfängt. Sollte es die
ersten Zahlen verpasst haben, so zeigt es eine Meldung wie in Zeile 4 an.
Bei Paketverlusten zeigt das Programm, wie in den Zeilen sechs, acht und neun, an, welche Nummer es erwartet hat, und welche es empfangen hat.
Zusätzlich wird nach 1.000 empfangenen Paketen, wie in den Zeilen fünf, sieben und
zehn, eine Übersicht ausgegeben. Zuerst die Zahl, bei der er ist. Dann die Lücken, die
aufgetreten sind, mit den genauen vermissten Zahlen. Wenn nur ein Paket vermisst wird,
dann wird ganz kurz [1] geschrieben, da einzelne Paketverluste öfter auftreten können.
81
9.2. UDP-Test
9.2.4
Kapitel 9. Anhang
Anleitung
Zum Senden startet man das Programm mit UDP_test <IP>. In IP kommt die IP-Adresse
des Zielsystems. Zur Anzeige der Aktivität wird nach allen 1.000 angezeigt, bei welcher
Nummer das Programm ist.
Auf dem Zielrechner startet man das Programm nur mit UDP_test. Es wartet nun auf die
Pakete.
Abbrechen muss man das Programm mit STRG+C.
82
Kapitel 10
Literaturverzeichnis
[Ahl02]
A HLERS, Ernst: Leinenlos. In: c’t (2002), Nr. 25, S. 200
[Bad04] BADACH, Anatol: Voice over IP - Die Technik. Carl Hanser Verlag, 2004
[EKK04] E VA -K ATHARINA K UNST, Jürgen Q.: Linux-Treiber entwickeln: Gerätetreiber für Kernel 2.6 systematisch eingeführt. dpunkt-Verlag, 2004
[Ger07]
G ERGELEIT, Prof. Dr. M.: WLAN Einführung. 2007. – Vorlesungsfolien der
Veranstaltung Telekommunikation
[HM03] H EIN, Mathias ; M ACIEJEWSKI, Dr. B.: Wireless LAN. Franzis’ Verlag, 2003
[JC02]
J ONATHAN C ORBERT, Alessandro R.: Linux-Gerätetreiber: [deckt Kernel 2.4
ab]. O’Reilly, 2002
[Kaf05]
K AFKA, Gerhard: WLAN. Carl Hanser Verlag, 2005
[Sar07]
S ARACOGLU, Nuray: Vermessung und Vergleich von „Switched-WLANArchitekturen“ mit besonderer Berücksichtigung der Roaming Verzögerung,
FH-Wiesbaden, Diplomarbeit, 2007
[Tan03]
TANENBAUM, Andrew S.: Computernetze. Bd. 4.Auflage. Pearson Studium,
2003
83
Kapitel 10. Literaturverzeichnis
84
Kapitel 11
Weblinks Verzeichnis
[IEE]
IEEE 802.11.
11.html
http://standards.ieee.org/getieee802/802.
[Kap07] K APS, Reik: Linux-WLAN: ath5k löst langfristig MadWifi ab. In: heise newsticker (2007), 09, Nr. 96359. http://www.heise.de/newsticker/
meldung/96359
[Mü05] M ÜLDER, Uwe:
Konzept und Implementierung einer offenen Switched WLAN Infrastruktur, FH-Wiesbaden, Diplomarbeit, 2005.
http:
//www.informatik.fh-wiesbaden.de/~gergelei/Dipl_Uwe_
Muelder.pdf
[Rin]
Ringmaster von Trapeznetworks.
com/products/ringmaster/
http://www.trapezenetworks.
[RS05] R AMANI, Ishwar ; S AVAGE, Stefan: SyncScan: Practical Fast Handoff for
802.11 Infrastructure Networks. University of California http://www.cs.
ucsd.edu/~iramani/sync_scan.pdf
[sca]
Post mit ’scan complete event’. http://madwifi.org/ticket/108
[sie]
http://www.automation.siemens.com/download/internet/
cache/3/1236966/pub/en/e20001-a11-m116-v1-7600.pdf
[Tou]
T OURRILHES, Jean: Wireless Extensions for Linux. http://www.hpl.hp.
com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.
Extensions.html
85
Kapitel 11. Weblinks Verzeichnis
[vBr]
Virtuelle Bridge für Linux. http://www.linux-foundation.org/en/
Net:Bridge
[VWL] WLAN 2,4 GHz
Allgemeinzuteilung von Frequenzen im Frequenzbereich 2400,0 - 2483,5 MHz
für die Nutzung durch die Allgemeinheit in lokalen Netzwerken; Wireless Local
Area Networks (WLAN- Funkanwendungen).
Vfg. 89/03.
http://www.bundesnetzagentur.de/media/
archive/313.pdf
86

Die Thesis zum Drucken

Transcription

Similar documents

Testbericht - StudioIsolation.de

Full Text

Projekt WiTAP Wireless Switch und Thin Access Points für KMU

AirMagnet WiFi Analyzer - Atlantik Systeme GmbH Shop

agenzia delle entrate agentur der einnahmen modello 730/2003