Technische Universität Ilmenau Fakultät für

Transcription

Technische Universität Ilmenau
Fakultät für Elektrotechnik und Informationstechnik
Studienarbeit
GPRS-Kommunikationsmodul
vorgelegt von:
Florian Evers
verteidigt am:
23. 04. 2004
E-Mail Adresse:
geboren am:
Studiengang:
Studienrichtung:
Ingenieurinformatik
Multimediale Informations- und
Kommunikationssysteme
Betreuer:
Betrieblicher Betreuer:
Bei Firma:
Prof. Dr. rer. nat. habil. Jochen Seitz
Dr. Jan Rudorfer,
BN Automation AG
Gewerbegebiet Am Wald“ 5a, 98693 Ilmenau
”
2
Zusammenfassung
In der Wasserversorgungswirtschaft steht als häufiges Problem die kostengünstige Erschließung von räumlich verteilten Objekten (wie Regenüberlaufbecken oder Wasserzählschächten) zum Zweck der Überwachung
und Datenerfassung an. Gewünscht wird eine laufende Prozessüberwachung mit der Möglichkeit einer Alarmierung in Ausnahmesituation. Dazu
soll vor Ort eine Automatisierungsstation verwendet werden, die Daten
aufnehmen und lokal zwischenspeichern kann. Die gesammelten Daten sollen ausgewertet und später an eine übergeordnete Station übertragen werden. Diese Auswertung umfasst beispielsweise die Erkennung kritischer Systemzustände oder eine Mittelung über mehrere Messwerte im Sinne einer
Datenreduktion.
Als Übertragungstechnik bietet sich hierbei der mittlerweile quasi flächendeckend verfügbare, drahtlose Datenübertragungsdienst GPRS1 an.
Er kann mit Hilfe von handelsüblicher Hardware genutzt werden.
Als erste Teilaufgabe gilt es ein GPRS-Modem2 an einer auf Microsoft Windows CE 4.1 basierenden Automatisierungsstation in Betrieb zu
nehmen. Ziel ist eine Einwahlverbindung ins Internet, damit ein TCP/IP
basierter Datenaustausch mit einer Leitstation erfolgen kann.
Als nächstes soll eine Modulstruktur entworfen und implementiert werden, die eine parallele Verwendung mehrerer verschiedener Kommunikationswege erlaubt. Die einzelnen Module sollen dabei über eine fest definierte
Schnittstelle verfügen, damit sie transparent gegeneinander ausgetauscht
werden können. Zu lösende Aspekte sind dabei das Verhalten im Fehlerfalle
(Verbindungsabriss), die Behandlung von Prioritäten und die Anpassung
der zu versendenden Daten an das Übertragungsmedium.
Nebenher sind viele Tests und Recherchen notwendig. Speziell das Thema Sicherheit ist wegen der Verwendung von Microsoft Windows CE ein
wichtiger Punkt, der betrachtet werden soll.
1
2
General Packet Radio Service, ein Mobilfunk-Datendienst.
Ein Modem vom Typ Siemens MC35i.
INHALTSVERZEICHNIS
3
Inhaltsverzeichnis
1 Vorwort
1.1 Über die Firma . . . . . . . . . . . . . . . . .
1.2 Das Hochbehälterproblem“ . . . . . . . . . .
”
1.2.1 Die verteilten Stationen . . . . . . . .
1.2.2 Die Leitstation . . . . . . . . . . . . .
1.2.3 Die Aufgaben der Stationen im Detail
1.3 Aufgabe . . . . . . . . . . . . . . . . . . . . .
1.3.1 Situation vor der Arbeitsaufnahme . .
1.3.2 Aufgabenstellung . . . . . . . . . . . .
.
.
.
.
.
.
.
.
6
6
6
8
9
9
11
11
11
.
.
.
.
.
.
13
13
14
14
16
17
19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
23
24
25
26
26
26
29
30
30
30
32
33
35
35
35
36
4 Kommunikation über GPRS
4.1 Nutzerschnittstelle des GPRS-Modems . . . . . . . . . . . . . . .
4.2 Inbetriebnahme des GPRS-Modems . . . . . . . . . . . . . . . . .
39
39
39
2 Modulares Kommunikationsmodell
2.1 Schichtenmodelle . . . . . . . . . . .
2.2 Kommunikationsmodell . . . . . . . .
2.2.1 Beteiligte Komponenten . . .
2.2.2 Trennung in einzelne Module
2.2.3 Der Kommunikationsmanager
2.2.4 Die Kommunikationsmodule .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Die einzelnen Module im Detail
3.1 Der Kommunikationsmanager . . . . . . . . . . . . . . . . .
3.1.1 Kommunikation über Dateien . . . . . . . . . . . . .
3.1.2 Warteschlangen und Prioritäten . . . . . . . . . . . .
3.1.3 Fragmentierung / Reassemblierung . . . . . . . . . .
3.1.4 Datenbank für die Kommunikationsmodule . . . . . .
3.1.5 Wegewahl / Routing . . . . . . . . . . . . . . . . . .
3.2 Die Kommunikationsmodule . . . . . . . . . . . . . . . . . .
3.2.1 Anpassung an das Übertragungsmedium . . . . . . .
3.2.2 Telegrammdienst . . . . . . . . . . . . . . . . . . . .
3.2.3 Quittierungen . . . . . . . . . . . . . . . . . . . . . .
3.3 Interprozesskommunikation . . . . . . . . . . . . . . . . . . .
3.3.1 Kommunikation zwischen den Modulen . . . . . . . .
3.3.2 Mögliche Ansätze zum Datenaustausch . . . . . . . .
3.3.3 Interprozesskommunikation über Sockets . . . . . . .
3.4 Schnittstellen und Protokolle . . . . . . . . . . . . . . . . . .
3.4.1 Schnittstelle oberhalb des Kommunikationsmanagers
3.4.2 Protokoll zwischen Kommunikationsmanagern . . . .
3.4.3 Protokolle des Prototyp . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
INHALTSVERZEICHNIS
4.3
4.4
4.2.1 Die Hardware vorbereiten . . . . . . . . . . . . . . .
4.2.2 Testen des AT-Befehlssatzes . . . . . . . . . . . . . .
4.2.3 Konfiguration zur Einwahl in das Internet über PPP
4.2.4 Test der aufgebauten Verbindung . . . . . . . . . . .
Windows CE .NET 4.1 und GPRS . . . . . . . . . . . . . .
4.3.1 Zur Einwahl notwendige Schritte . . . . . . . . . . .
4.3.2 Die einzelnen Schritte im Detail . . . . . . . . . . . .
Besonderheiten bei der Nutzung von GPRS . . . . . . . . .
4.4.1 Quality of Service . . . . . . . . . . . . . . . . . . . .
4.4.2 Die TCP/IP Problematik . . . . . . . . . . . . . . .
4.4.3 Nutzbare Datenraten . . . . . . . . . . . . . . . . . .
5 Versuchsaufbau und verwendete Hardware
5.1 Aufbau des Netzwerkes . . . . . . . . . . . . . .
5.2 Der embedded PC . . . . . . . . . . . . . . . .
5.3 Der PC: Entwicklungsumgebung und Leitstation
5.4 Der Router / Gateway . . . . . . . . . . . . . .
5.5 Dynamische DNS-Einträge . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Sonstige Betrachtungen
6.1 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Offene Ports . . . . . . . . . . . . . . . . . . .
6.1.2 Firewall . . . . . . . . . . . . . . . . . . . . .
6.1.3 Nessus-Scan . . . . . . . . . . . . . . . . . . .
6.1.4 Fehlende Langzeiterfahrung, versteckte Lücken
6.1.5 Kostenpflichtige Luftschnittstelle . . . . . . .
6.2 Zukunftsaussichten . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
40
44
44
45
45
46
51
51
51
52
.
.
.
.
.
54
54
55
56
57
59
.
.
.
.
.
.
.
60
60
60
60
61
62
63
64
7 Zusammenfassung / erreichte Ziele
66
A Technische Daten: Modem Siemens MC35i
69
B Tarifübersicht GPRS Tarife
B.1 T-D1 Tarife . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Vodafone Tarife . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
70
70
C Konfiguration des Routers
C.1 Informationen zum Skript . . . . . . . . . . . . . . . . . . . . . .
C.2 Das Skript bridge-up . . . . . . . . . . . . . . . . . . . . . . . .
71
71
71
D Portscans: Windows CE.NET 4.1
D.1 Ergebnisse des TCP/IP Portscans . . . . . . . . . . . . . . . . . .
D.2 Ergebnisse des UDP/IP Portscans . . . . . . . . . . . . . . . . . .
74
74
74
INHALTSVERZEICHNIS
E Nessus-Report: Windows CE.NET 4.1
E.1 Routerkonfiguration für Nessusscan . .
E.2 Das Skript nessus-up . . . . . . . . .
E.3 Mitteilung des Testergebnisses . . . . .
E.4 Scanergebnis Nessus-Scan . . . . . . .
5
.
.
.
.
75
75
75
76
76
F Konfiguration des Modems unter Linux
F.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.2 Bildschirmfotos von Yast2 . . . . . . . . . . . . . . . . . . . . . .
82
82
82
G Logfile: Interneteinwahl GPRS-Modem
86
H Abkürzungsverzeichnis
88
Literaturverzeichnis
91
Abbildungsverzeichnis
93
Tabellenverzeichnis
94
Abschlusserklärung
95
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
1 VORWORT
1
1.1
Vorwort
Über die Firma
Die vorliegende Studienarbeit wurde bei der selben Firma absolviert, bei der der
Autor auch schon sein Betriebspraktikum im 7. Semester durchgeführt hatte.
Die Firma BN Automation AG ist im Bereich der Ver- und Entsorgung von
Wasser/Abwasser tätig und hat sich auf die Entwicklung von Gesamtlösungen im
Bereich der Automatisierungstechnik spezialisiert.
Der zweite Schwerpunkt der Firma liegt im Bereich der Netzwerktechnik. Sie
bietet hier als DATEV-Systempartner ein eigenständiges Dienstleistungsangebot
an. Hier wurden bereits vielen Steuerberatern und Industriebetrieben die rechentechnischen Einrichtungen eingerichtet und gepflegt.
Die Firma BN Automation AG ist über die folgende Anschrift zu erreichen:
BN Automation AG
Gewerbegebiet Am Wald“ 5a
”
98693 Ilmenau
Homepage unter http://www.bn-automation.de
1.2
Das Hochbehälterproblem“
”
Sowohl die damalige Praktikumsaufgabe als auch diese Studienarbeit drehen sich
um ein Themengebiet, welches innerhalb der Firma unter dem Oberbegriff Das
”
Hochbehälterproblem“ bekannt ist. Dabei geht es um die Überwachung mehrerer
räumlich verteilter Objekte, wie zum Beispiel die genannten Hochbehälter aus
der Wasserversorgungswirtschaft.
An diesen Hochbehältern sollen laufend Prozessgrößen wie der aktuelle Wasserstand ermittelt werden. Kritische Zustände (Füllstand oder Beobachtung von
Alarmkontakten) sollen erkannt und gemeldet werden. Hauptproblem dabei ist
die weiträumige Verteilung der einzelnen Stationen. Sie bringt spezielle Anforderungen an die Mechanismen zur Datenübermittlung mit sich. Bei der Anbindung
stehen je nach Umfeld mehrere Technologien zur Verfügung. Das Spektrum reicht
dabei von klassischen Wählverbindungen über GPRS bis hin zu speziellen Übertragungstechniken wie der Nutzung von Betriebsfunk.
Lösungsansatz hierfür soll ein neues Gerät“ mit einer gewissen Eigenintelli”
genz sein. Der spätere Anwender installiert es am zu überwachenden Prozess, wo
die Station die Aufgabe der Messwerterfassung übernimmt. Gleichzeitig soll sie
die Daten vorverdichten3 und kritische Prozesszustände4 erkennen können. Zwischen den abgesetzten Stationen und der Leitstation existieren keine dauerhaften
3
Beispielsweise durch Mittelung mehrerer Messwerte. Dies dient der Entfernung von Störeinflüssen und der Reduktion des Datenaufkommens.
4
Zum Beispiel drohende Havarie.
1.2 Das Hochbehälterproblem“
”
7
Standleitungen. Ein Verbindungsmanagement verwaltet hierbei die nur zeitweise genutzten Datenübertragungseinrichtungen. Es soll die anfallenden Übertragungskosten minimieren. Ein Anwendungsbeispiel ist das Sammeln von Daten
über den Tag hinweg, um sie einmal täglich über eine Telefonleitung an die Leitstation zu übermitteln. Zusätzlich kann eine Station im Falle eines auftretenden
Alarmzustandes eine außerplanmäßige Verbindung aufbauen, um kritische Zustände zu melden.
10
10
Embedded PC
Embedded PC
10
10
Embedded PC
Embedded PC
10
Embedded PC
10
Embedded PC
Abbildung 1: Eine Leitstation überwacht mehrere verteilte Stationen
Abbildung 1 zeigt eine solche Anordnung. Eine Leitstation kann mit mehreren verteilten Automatisierungsstationen kommunizieren. Die Stationen sammeln
direkt am Prozess Daten und speichern diese zwischen. Bei Bedarf können die Stationen beidseitig eine Datenverbindung aufbauen, um die gesammelten Daten zu
übermitteln.
Dieser sternförmige Aufbau ist dabei nicht die einzige Netztopologie, die in der
Praxis vorkommen kann. Einzelne Stationen müssen in bestimmten Einsatzszenarien in der Lage sein, eine Art Wegewahl durchzuführen. Bei der Verwendung
von Betriebsfunk kann es vorkommen, dass eine Art Vermittlungsstation“ auf
”
einem hoch gelegenen Punkt montiert wird. Sie kommuniziert über Funk mit
den restlichen Automatisierungsstationen. Die Verbindung mit der Leitstation
erfolgt hierbei ausschließlich über die zentrale Vermittlungsstation. Sie ist mit
der Leitstation beispielsweise über eine Wählverbindung verbunden. Eine solche
Anordnung wird in Abbildung 2 gezeigt.
8
1 VORWORT
Funk
10
Embedded PC
10
Embedded PC
Berg
Funk
Funk
10
Embedded PC
ISDN
10
Embedded PC
Abbildung 2: Erreichbarkeit über eine Vermittlungsstation
1.2.1
Die verteilten Stationen
Für die verteilten Automatisierungsstationen kommen Industrie-PC’s der Firma
Beckhoff zum Einsatz. Diese basieren auf eingebetteten5 PC’s, die aufgrund ihrer
Bauform6 direkt mit in den Schaltschränken verbaut werden können. Abbildung
3 zeigt ein Bild eines solchen Beckhoff-PC’s.
Abbildung 3: Bilder der verwendeten Beckhoff-Station
Der zum Einsatz kommende Beckhoff CX1001-0011“ verfügt über ein klemm”
bares Bussystem. Über dieses können weitere Baugruppen7 hinzugefügt werden.
Sie hängen direkt am Beckhoff-PC und bilden eine Klemmleiste.
5
Eingebettet bedeutet, dass es sich hierbei technisch um einen PC handelt, welcher aber
nicht als solcher in Erscheinung tritt. Er ist Bestandteil einer bestimmten Komponente, wie
hier einer intelligenten Klemmleiste.“
”
6
Sie sind direkt auf Hutschinen montierbar.
7
Es gibt unter anderem Baugruppen mit mehreren analogen Eingängen, digitalen Eingängen
oder digitalen Ausgängen.
1.2 Das Hochbehälterproblem“
”
9
Auf dem integrierten Rechner läuft als Betriebssystem Microsoft Windows
CE.NET 4.1, sowie eine vom Beckhoff ausgelieferte Soft-SPS8 . Sie kümmert sich
um die gesamte Messwertaufnahme. Es bleibt noch genügend Rechenkapazität
übrig, damit ein Programmierer selbstentwickelte Programme auf der Station
betreiben kann.
1.2.2
Die Leitstation
Als zentrale Leitstation kommt ein handelsüblicher PC mit Microsoft Windows
2000 zum Einsatz. Er sammelt die Daten, die an den verteilten Stationen anfallen.
Eintreffende Alarmmeldungen werden von der Leitstation sofort bearbeitet oder
weitergeleitet. Sie angesammelten Daten können dann von der Leitstation auf
vielfältige Weise weiterverarbeitet werden. Die Verwendungszwecke reichen von
einer Speicherung in einem Geschichtsdatenarchiv bis zur sofortigen Weiterleitung
an eine übergeordnete Leitwarte.
Die Leitstation bietet außerdem eine zentrale Parametrierschnittstelle für das
verteilte System. Im Idealfall soll hier der Nutzer einen Zugriff auf alle Datenpunkte erhalten und gegebenfalls Änderungen durchführen können. Die geänderten Konfigurationen werden dann den verteilten Stationen mitgeteilt.
1.2.3
Die Aufgaben der Stationen im Detail
Kern der Automatisierungsstationen ist eine auf Software basierende, Speicher”
programmierbare Steuerung“ (Soft-SPS). Um diese Soft-SPS herum arbeiten diverse Module, die ihr noch weitere Funktionalität hinzufügen. Eine der Hauptaufgaben ist die automatische Aufnahme von Messwerten an einem Prozess und
deren Zwischenspeicherung. Je nach Konfiguration übertragen die Stationen diese Daten entweder sofort oder beim nächsten Sammelabruf an die übergeordnete
Leitstation.
Die Aufgabe dieser Studienarbeit zielt nicht auf die Funktionalität innerhalb
der Soft-SPS oder deren nachgeschaltete Bearbeitungsmodule, sondern auf die
Ausarbeitung einer modularen Kommunikationsschnittstelle. Sie soll den Datentransfer über mehrere Datenübertragungstechnologien9 ermöglichen.
Die zu Grunde liegenden Kommunikationstechnologien sollen einfach gegeneinander austauschbar sein. Die gesamte Funktionalität zur Kommunikation wird
dafür in spezialisierte Kommunikationsmodule gruppiert.
Einen Überblick über die interne Struktur einer Station gibt Abbildung Nr.
4 auf Seite 10. Dort befindet sich die Soft-SPS, die für die Prozesskopplung zuständig ist. Sie enthält einen integrierten Timer, um periodische Ereignisse anzustoßen.
8
9
Eine auf Software basierende, speicherprogrammierbare Steuerung.
ISDN, GPRS, Betriebsfunk sowie diverse Weitere und Zukünftige.
10
1 VORWORT
Verarbeitungsmodule
Dispatcher
Soft SPS
Timer
Spontan−
archiv
Zyklische
Meldungen
Realtime
Grenzwert−
überwachung
stromausfallsicherer Zwischenspeicher
Webserver
Kommunikationsmanager
LAN
Funk
GPRS
Abbildung 4: Interner Aufbau einer Automatisierungsstation
Die von der Soft-SPS ermittelten Messwerte und Datenpunkte reicht sie dann
an spezielle Weiterverarbeitungsmodule weiter. Hier können zum Beispiel Filter
realisiert werden, die über mehrere gemessene Analogwerte mitteln10 .
Die in Abbildung 4 gezeigten Verarbeitungsmodule sind jeweils für einen bestimmten Typ von Datenpunkt zuständig:
• Spontanarchiv:
In diese Kategorie fallen alle Datenpunkte, die von der Station auf Veränderungen überwacht werden sollen. Dies kann ein umspringender Zählerstand
oder ein ein Toleranzintervall verlassender, analoger Messwert sein. Ausnahme sind binäre Signale, die so genannten Meldungen. Sie bilden eine
eigene Gruppe.
• Zyklische:
Zyklische Messwerte sind Datenpunkte, deren Zustände von der Station periodisch neu gemessen werden. Ein Beispiel ist die minütliche Messung eines
Wasserstandes an einer Talsperre. Das Verarbeitungsmodul ist in der Lage, die gewonnenen Daten auf Wunsch weiter zu verarbeiten. Es verrechnet
dabei mehrere zeitlich aufeinander folgende Messwerte zu einem Mittelwert
(Vorverdichtung der Daten).
• Meldungen:
Zu der Gruppe der Meldungen gehören alle binären Datenpunkte. Solche
Signale werden von vielen Baugruppen zum Signalisieren von Störungen
verwendet ( Störungsmelde-Ausgänge“). Zur Weiterverarbeitung kann das
”
Modul so genannte Totzeiten berücksichtigen. Es meldet dann nur längerfristige Störungen an die Leitstation.
10
Generell: Aufbereitung der Daten und Vorverdichtung.
1.3 Aufgabe
11
• Realtime:
Das Realtime-Modul hält ein so genanntes Prozessabbild“ vor. Wenn sich
”
ein entfernter Nutzer sofort über den aktuellen Zustand diverser Datenpunkte informieren möchte, kann er hiermit die aktuellen Messwerte auch
unabhängig von eingestellten Messintervallen prüfen.
• Grenzwertüberwachung:
Das Grenzwertmodul überwacht Datenpunkte auf Über- oder Unterschreitung eines Grenzwertes. Es erzeugt immer dann eine Nachricht, wenn ein
Datenpunkt ein Gültigkeitsintervall verlässt oder wieder betritt.
An diesem Punkt ist die Automatisierungsstation fertig mit der Vorverarbeitung der Daten. Sie muss die Daten an die Leitstation versenden. Diese Aufgabe
fällt dem nachgeschalteten Kommunikationsmanager zu. Um ihn zu nutzen, versehen die Verarbeitungsmodule den zu übertragenden Datenpunkt mit der Stationsadresse des Empfängers11 und legen die Nachricht als Datei in einem einem
stromausfallsicheren Übergabeverzeichnis ab. Der Kommunikationsmanager wird
die Nachricht daraufhin an die Zielstation versenden.
1.3
1.3.1
Aufgabe
Situation vor der Arbeitsaufnahme
Bei Beginn der Studienarbeit näherte sich bereits eine funktionstüchtige Umsetzung des Gesamtprojektes seiner Fertigstellung. Sie war jedoch sehr spezialisiert und nur mit einer einzigen Datenübertragungsmöglichkeit über Betriebsfunk
ausgestattet. Es funktionierte zwar bereits, jedoch war der gesamte kommunikationsbezogene Programmteil ein einziger monolithischer Block. Es wäre schwierig geworden, diese Struktur um weitere Kommunikationswege zu erweitern. Die
funkspezifischen Mechanismen waren zu eng mit dem Hauptprogramm verstrickt.
1.3.2
Aufgabenstellung
Der Kern dieser Studienarbeit ist die Ausarbeitung einer modular aufgebauten
Kommunikationsschicht“, die den bisherigen monolithischen Kommunikations”
block ersetzen soll. Diese Struktur soll mit den unterschiedlichsten Kommunikationstechnologien zusammenarbeiten, und eine einfache Erweiterung um neue
Kommunikationswege ermöglichen. Die Station soll dann im laufenden Betrieb
aus einer gegebenen Anzahl von Kommunikationswegen den günstigsten heraussuchen und hierüber die Daten versenden. Günstig“ kann dabei Verschiedenes
”
bedeuten. Zielstellung kann eine Kostenminimierung oder eine möglicht hohe Datenübertragungsrate sein.
11
Der Empfänger wird in diesem Falle die Leitstation sein.
12
1 VORWORT
Der neue Ansatz basiert dabei auf einer Gruppierung der bereits vorhandenen
Kommunikationsroutinen. Speziell auf eine konkrete Übertragungstechnologie zugeschnittene Kommunikationsmodule erledigen den Zugriff auf die verwendeten
Medien, während ein modulübergreifender Kommunikationsmanager die einzelnen Module verwaltet und anspricht.
Alle diese Kommunikationsmodule verfügen über eine fest definierte Schnittstelle, damit sie sich später gegeneinander austauschen lassen. Dies vereinfacht
die Entwicklung zukünftiger Kommunikationsmodule, die auf jetzt noch nicht verwendeten Kommunikationstechnologien basieren werden. Der Entwickler braucht
dann lediglich ein weiteres Kommunikationsmodul zu entwickeln, ohne dass Änderungen an anderen Stellen des Systems notwendig werden.
Des Weiteren stand der konkrete Wunsch im Raum, Stationen in zukünftigen
Projekten mit GPRS anzusprechen. GPRS ist dank der mittlerweile fast flächendeckenden Verfügbarkeit von GSM12 ein vielversprechender Ansatz zur Datenübertragung. Dies gilt besonders wenn mit weit voneinander entfernten Stationen
gearbeitet werden soll.
Zusammenfassend umfasst die Studienarbeit mehrere Teilaufgaben:
• Inbetriebnahme eines GPRS-Modems (Siemens MC35i) unter Microsoft
Windows CE.NET 4.1.
• Entwicklung einer C++ -Klasse zur Ansteuerung des Modems mit Dokumentation der zur Einwahl notwendigen Schritte.
• Entwurf einer modularen Kommunikationsstruktur.
• Implementierung eines auf GPRS spezialisierten Prototyps eines Kommunikationsmoduls für den Beckhoff-PC.
• Implementierung eines auf Ethernet spezialisierten Prototyps eines Kommunikationsmoduls für die Leitstation, welche über Ethernet13 mit dem
Internet verbunden ist.
• Weiterentwicklung des Prototyps bis zu einer Ausbaustufe, die den Datenaustausch zwischen der Leitstation und einem embedded PC im Rahmen
eines Versuchsaufbaus ermöglicht. Er soll speziell die Modulstruktur umsetzen und GPRS als Kommunikationsmedium nutzen.
12
Global System for Mobile Communication.
Die Leitstation ist Bestandteil eines lokalen Netwerkes. Die Internetverbindung wird über
einen Router bereitgestellt.
13
13
2
Modulares Kommunikationsmodell
2.1
Schichtenmodelle
Bevor die einzelnen Modelle beschrieben werden, müssen die verwendeten Begrifflichkeiten geklärt werden. Die folgenden Abschnitte enthalten diverse Fachbegriffe
aus dem Themenbereich Schichtenmodelle nach ISO/OSI14“, deren Kenntnis in
”
den entsprechenden Abschnitten vorausgesetzt wird.
Die einzelnen entworfenen Module enthalten selbst entwickelte Mechanismen
zur Aufbereitung und Versendung von Daten, was der Oberbegriff des Proto”
kolls“ zusammenfasst. Die einzelnen Module stehen untereinander in einer Abhängigkeitsbeziehung, und unterscheiden sich in ihrer Funktion als Dienstneh”
mer“ und Diensterbringer“. Bei der Spezifikation von Protokollen und Diensten
”
trifft man unweigerlich auf eine Ansammlung an dreibuchstabigen Abkürzungen,
wie in Schema 5 dargestellt.
(N+1)−PCI
(N)−ICI
(N+1)−SDU
(N+1)−PDU
Schicht N+1
Schicht N
(N)−IDU
(N)−SDU
(N)−PCI
(N)−PCI
(N)−ICI
(N−1)−ICI
(N)−SDU
(N)−PDU
Schicht N
Schicht N−1
IDU
PCI
SDU
ICI
PDU
:
:
:
:
:
Interface Data Unit
Protocol Control Information
Service Data Unit
Interface Control Information
Protocol Data Unit
(N−1)−IDU
(N−1)−SDU
(N−1)−ICI
Abbildung 5: Protokollinformationen und -overhead nach ISO/OSI
An dieser Stelle sollen die dahinterstehenden Ideen und Mechanismen aber
nicht vertieft werden, denn dafür sind Fachbücher zum Thema Kommunikationsnetze (siehe [KrRe02]) besser geeignet. Eine solche Wiederholung würde den
Rahmen dieses Berichtes sprengen, aber es ist schon von Vorteil, wenn der Leser
an der entsprechenden Stelle im Bericht Begriffe wie PDU“ (Protocol Data Unit)
”
einordnen kann.
14
International Organization for Standardization/ Open Systems Interconnection.
14
2.2
2.2.1
2 MODULARES KOMMUNIKATIONSMODELL
Kommunikationsmodell
Beteiligte Komponenten
Die gewünschte Infrastruktur soll Daten in Form einzelner Dateien zwischen zwei
beteiligten Stationen übertragen. Diese Dateien können gemessene Werte einzelner Datenpunkte, aber auch Steuerungsinformationen enthalten. Der Inhalt der
Dateien ist an dieser Stelle unwichtig. Die Infrastruktur soll die Daten transparent
versenden, ohne sie zu interpretieren.
Der Kommunikationsmanager nimmt dabei die Dateien von den Verarbeitungsmodulen entgegen. Er ist ein selbständiges Programm, welches auf allen
Stationen des verteilten Verbundes läuft und sich um die Zustellung zur Zielstation kümmert. Dort angekommen, werden die Daten vom lokalen Kommunikationsmanager wieder in Form von Dateien im Dateisystem (Übergabeverzeichnis)
abgelegt. Wenn man den gesamten Kommunikationsmechanismus als Black-Box“
”
ansieht, dann verdeutlicht Abbildung 6 diesen Ansatz der Dateienübertragung.
Station1
VM
Station 2
Datei
Archiv
Datei
Übertragungsmedium
VM : Verarbeitungsmodule
Abbildung 6: Versendung von Dateien: Kommunikationsmanager
Der Kommunikationsmanager bedient sich der Funktionen seiner Kommunikationsmodule, die ihm einen vereinfachten Zugriff auf die zur Verfügung stehenden Kommunikationsanbindungen bieten. Verschiedene Anbindungen erfordern
verschiedene Strategien zum Datentransfer. Die Kommunikationsmodule fassen
die für ein spezielles Medium notwendigen Funktionen zu spezialisierten Blöcken
zusammen.
Die zu übertragenden Dateien werden vom Kommunikationsmanager aufbereitet15 und an ein passendes16 Kommunikationsmodul übergeben. Dieses überträgt
die Daten an die nächste Station, auf der wiederum ein Kommunikationsmodul
15
Die Dateien werden nach Prioritäten sortiert und in kleinere Fragmente zerteilt.
Diese Auswahl erfolgt nach verschiedenen Kriterien (Erreichbarkeit, Kosten, . . . ), die noch
genauer betrachtet werden.
16
2.2 Kommunikationsmodell
15
arbeitet welches die Daten entgegennimmt. Das Zusammenspiel ist in Schema 7
erkennbar.
Station1
Station 2
Datei
Datei
GPRS−Modul
Sonstiges Modul
LAN−Modul
Internet
GSM
LAN
DSL
DSL−Einwahlrouter
Abbildung 7: Nutzung von Kommunikationsmodulen zur Datenübertragung
Eine einzelne Station kann dabei über mehrere Anbindungen verfügen. In bestimmten Szenarien werden einzelne Stationen als so genannte Relaisstationen17“
”
eingesetzt, die die Datenpakete von nicht direkt mit der Leitstation verbundenen
Stationen entgegennehmen und weiterleiten. Abbildung 8 zeigt einen solchen Fall.
Hier sind neben der Leitstation noch zwei verteilte Stationen zu erkennen, die in
einem Local Area Network“ (LAN) miteinander kommunizieren. Die im Schema
”
linke Station ist per GPRS mit der Leitstation verbunden, und erhält für den Fall
des Ausfalles von GPRS noch eine Ersatz-Anbindung (Backup-Link) über ISDN.
Leitstation
Embedded PC Nr. 1
Embedded PC Nr. 2
Übergabeverzeichnis
Kommunikations−
manager
Kommunikations−
manager
Kommunikations−
manager
GPRS
ISDN
LAN
LAN
ISDN
GPRS
LAN
RAS−Einwahlserver auf Server und Client, PPP−Verbindung
Einwahl ins GPRS−Netz mit IP−Adresse auf Client, Providerzugang ins Internet beim Server
Abbildung 8: Vernetzung mehrerer Stationen über mehrere Dienste
17
Veranschaulicht im Funkszenario auf Abbildung 2 (Seite 8), wo eine Station die Aufgabe
einer Vermittlungseinrichtung übernimmt.
16
2.2.2
Trennung in einzelne Module
Eine der Hauptaufgaben dieser Studienarbeit ist die Ausarbeitung einer modularen Kommunikations-Infrastruktur. Bevor damit begonnen wurde, gab es bereits
eine bestehende Umsetzung der Betriebsfunkanbindung. Deren funkspezifische
Routinen waren jedoch monolithisch mit denen des Kommunikationsmanagers
verschmolzen.
Doch wie lassen sich diese verschiedenen Funktionalitäten geschickt voneinander trennen? Dazu boten sich verschiedene Varianten an: Eine Gruppierung
der Funktionen in so genannte Dynamic Linked Libraries“ (DLL’s), oder eine
”
Verkapselung in eigenständige Programme (.exe-Dateien).
Beide Ansätze haben speziellen Eigenheiten. Unabhängig davon fiel die Wahl
zur Erstellung des Prototyps auf die Trennung in eigenständige Programme18 .
Der Prototyp sollte möglichst schnell entwickelt werden, und dem Autor fehlte
die Erfahrung im Umgang mit dem DLL-Konzept. Deswegen basiert der Prototyp
auf verschiedenen Modulen, die als eigenständige Programme modelliert werden.
In Bezug auf die Ausführungsgeschwindigkeit wird das DLL-Konzept dem EXEKonzept allerdings überlegen sein. Bevor später die Produktivversion implementiert wird, sollte der Entwickler das DLL-Konzept genauer untersuchen19 .
Die folgende Liste fasst die Konsequenzen zusammen, die sich aus der Gruppierung der Funktionen in einzelne Module ergeben:
• Austausch von Komponenten:
Möglichkeit des Austausches veralteter Programmkomponenten gegen aktualisierte Versionen. Der Austausch eines einzelnen Moduls kann beispielsweise über FTP“ (File Transfer Protocol) erfolgen. Anschließend wird das
”
neue Modul aktiviert. Dazu muss der Nutzer weder die Automatisierungsstation neu starten, noch der laufende Betrieb wichtiger Komponenten unterbrochen werden. Der Austausch wird im laufenden Betrieb der Station
durchgeführt.
• Nachträgliche Erweiterung:
Einfache Erweiterung um weitere Kommunikationsschnittstellen: Anschluss
der Hardware, Platzierung des zugehörigen Kommunikationsmoduls (evtl.
über FTP) und abschließende Anmeldung des neuen Moduls beim Kommunikationsmanager. Das Modul wird jetzt vom Kommunikationsmanager
gestartet und in den Prozess der Datenübertragung mit eingebunden.
• Mehrere Module gleichzeitig:
Parallel vorhandene Kommunikationswege: Ein Gerät kann mehr als eine
18
Bei dem Kommunikationsmanager und den Kommunikationsmodulen handelt es sich um
eigenständige .exe-Dateien.
19
Dies geschah parallel zu dieser Studienarbeit.
17
einzelne Anbindung aufweisen. Zusätzlich zu einer GPRS-Anbindung könnte ein ISDN-Anschluss für den Fall des Ausfalls von GPRS bereit stehen.
Das macht in der Summe zwei Anbindungen, die jeweils ein eigenes Kommunikationsmodul erfordern.
Bei einem lokalen Verbund mehrerer Stationen (verbunden über ein LAN)
wird nur eine einzige Station am Tor zur Welt“ hängen. Dies zeigt Abbil”
dung 8 auf Seite 15. In diesem Falle startet der Kommunikationsmanager
drei Kommunikationsmodule20 .
• Übersichtliche Schnittstellen:
Die Kommunikation zwischen dem Kommunikationsmanager und den einzelnen Kommunikationsmodulen erfolgt über eine festgelegte und einheitliche Schnittstelle. Diese ist idealerweise unabhängig von den Möglichkeiten
und Erfordernissen der den Modulen zugrundeliegenden Übertragungstechnologien, denn erst dies ermöglicht einen transparenten Austausch der Module untereinander.
• Wartbarkeit:
Der Programmierer erhält durch die strikte Trennung der Schichten als
eigenständige Programme einen modularen Quellcode. Jeder Block weist
spezialisierte Fähigkeiten auf. Dadurch werden die Programme kleiner und
übersichtlicher, was sich positiv auf die Pflege der Programme auswirkt.
• Sicherheit durch Trennung
Ein abstürzendes Modul reißt nicht den gesamten Kommunikationsmanager
mit in den Tod. Ein Modul bleibt schlimmstenfalls hängen, was aber vom
darüberliegenden Kommunikationsmanager erkannt werden kann21 . Dieser
ist jetzt in der Lage diese Leiche“ abzuschießen und das Modul erneut zu
”
starten. Bei der Trennung in .dll’s ist diese Abschottung nach Kenntnisstand des Autors nicht möglich.
2.2.3
Der Kommunikationsmanager
Dieses Modul ist ein eigenständiges Programm, welches beim Hochfahren der
Station vom System mitgestartet wird und dann immer läuft. Der Kommunikationsmanager hat einen Überblick über sämtliche verfügbaren Kommunikationswege sowie deren Eigenschaften. Da sich die einzelnen Kommunikationswege sehr
stark voneinander in ihrer Benutzung unterscheiden22 , werden alle auf die Medien
zugeschnittenen Routinen in spezialisierte Kommunikationsmodule ausgelagert.
20
Eines für ISDN, eines für GPRS und ein drittes für Ethernet.
Zum Beispiel über Timeouts.
22
Bei ISDN muss eine nach Zeittakten abgerechnete Wählverbindung aufgebaut werden,
GPRS dagegen benötigt lediglich einen einzelnen Verbindungsaufbau, bei dem keine weiteren
Zeitkosten anfallen.
21
18
Für den Kommunikationsmanager ist an dieser Stelle wichtig, dass jedes seiner Module eine identische Schnittstelle aufweist und sich der Manager bei jedem
dieser Module identisch verhalten kann. Dadurch braucht er nur eine universelle Schnittstelle zu unterstützen, ohne Rücksicht auf bestimmte Eigenheiten des
konkret genutzten Übertragungsmediums nehmen zu müssen.
Der Kommunikationsmanager enthält die Menge an Funktionen, die unabhängig von denen der Übertragungsmedien zur Kommunikation gebraucht werden.
Dazu gehören die folgenden Aufgaben:
• Versenden von Dateien:
Zu übertragende Daten werden vom Dispatcher23 und seinen nachgeschalteten Verarbeitungsmodulen24 in einem Übergabeverzeichnis im Dateisystem
abgelegt. Danach ist die Datei unter der Kontrolle des Kommunikationsmanagers, und wird von diesem erst nach vollständigem Versand gelöscht.
Auf der Gegenstation läuft der Mechanismus genauso ab, nur in umgekehrter Richtung. Die einzelnen Datenpakete wandern über das verwendete
Medium und werden auf der Gegenseite von einem Kommunikationsmodul entgegengenommen. Dieses gibt das Datenpaket sofort an den dortigen
Kommunikationsmanager, damit dieser es weiterverarbeiten kann. Er rekonstruiert die Datei und speichert das Ergebnis wiederum als Datei in
einem lokalen Übergabeverzeichnis ab.
• Start- und Stopp von Kommunikationsmodulen:
Der Kommunikationsmanager schaut beim Starten in einer modulinternen
Datenbank nach, welche Kommunikationsschnittstellen existieren und wie
deren spezifische Eigenschaften lauten. Zu jeder Anbindung gibt es ein spezialisiertes Kommunikationsmodul, welches der Manager bei Bedarf nachladen muss.
Um einen Datenaustausch über ISDN zu ermöglichen, startet der Manager das ISDN-Kommunikationsmodul. Ist zusätzlich noch eine GPRS-Anbindung vorhanden25 , lädt er parallel zum ISDN-Modul noch das GPRSModul.
• Wegewahl:
Eine Zielstation kann gleichzeitig über mehrere Kommunikationswege erreichbar sein. Dann muss der Kommunikationsmanager eine Entscheidung
treffen. Er wählt das passendste Kommunikationsmodul nach einem aktuellen Entscheidungskriterium aus. In diese Auswahl spielen mehrere Faktoren
mit ein:
23
Das Bindeglied zwischen der Soft-SPS und den Verarbeitungsmodulen.
Siehe Diagramm 4 auf Seite 10.
25
diese Information steht in der Konfigurationsdatenbank des Kommunikationsmanagers.
24
19
– Auswahl an Schnittstellen:
Gibt es eine Auswahl an verschiedenen Kommunikationswegen? Gibt
es eventuell nur eine einzige Anbindung?
– Erreichbarkeit:
Welche aktiven Kommunikationsmodule sind relevant, da sie eine Verbindung zum gewünschten Zielrechner ermöglichen?
– Kosten für die Datenübermittlung:
Eine momentan aufgebaute ISDN-Verbindung könnte billiger sein als
der alternative Versand über GPRS.
– Zustand einzelner Kommunikationsmodule:
Wenn sich ein Modul zeitweise als nicht benutzbar“ meldet, kann das
”
mehrere Ursachen haben. Eine Möglichkeit ist ein Hardwaredefekt,
aber auch eine momentan gestörte oder besetzte Leitung führen dazu.
Damit der Kommunikationsmanager diese Entscheidung fällen kann, benötigt er eine Datenbank. Sie speichert alle verfügbaren Eigenschaften der
vorhandenen Kommunikationsmodule und ermöglicht eine Auswahl des gerade am geeignetesten Weges.
• Übergabe von Datenströmen:
Was passiert, wenn während einer laufenden Datenübertragung eine Datenverbindung wegstirbt?“ Das betroffende Kommunikationsmodul wird
”
diesen Zustand erkennen und ihn sofort dem darüberliegenden Kommunikationsmanager mitteilen. Dieser wird von nun an seine Wegewahl anders
gestalten, und die zu versendenden Datenpakete über eine eventuell vorhandene Ersatzleitung schicken (Handover von Datenströmen).
2.2.4
Die Kommunikationsmodule
Die Kommunikationmodule sind unterhalb des Kommunikationsmanagers angesiedelt. Sie werden vom Programmierer jeweils für ein spezielles Übertragungsmedium konzipiert und stellen eine Art Anpassungsschicht dar. Sie weisen alle
eine fest definierte Schnittstelle zum Kommunikationsmanager auf. Er kann daher
alle Formen von Kommunikationsmodulen einheitlich ansprechen. Die Kommunikationsmodule dienen als Bindeglieder zwischen dem Kommunikationsmanager
und den vorhandenen Übertragungsmedien. Sie enthalten jeweils speziell an das
Medium angepasste Routinen um Daten zu versenden oder zu empfangen.
Es lassen sich Kommunikationsmodule für alle denkbaren Übertragungsmedien entwickeln. Dank ihrer einheitlichen Schnittstelle kann sie der Anwender auch
nachträglich in ein älteres System integrieren. Relevante Kommunikationstechniken sind bisher:
20
• Betriebsfunk:
Eine bereits in der Firma verwendete Übertragungstechnik ist Betriebsfunk.
Hierbei weist einem die RegTP“ (Regulierungsbehörde für Telekommuni”
kation und Post) eine feste Frequenz und einen Zeitschlitz zu. Man kann
dann mit Hilfe eines entsprechenden Modems einmal pro Minute für ein
fünfsekündiges Zeitintervall mit 9600Bit/s Daten versenden. Da sich alle
Stationen diesen Zeitschlitz teilen müssen, sind umfassende Synchronisationsmechanismen notwendig.
• ISDN:
Es gibt bei ISDN zwei Möglichkeiten: Einmal die Einwahl bei einem Internetprovider mit anschließender Kommunikation über das Internet, oder die
direkte Punkt-zu-Punkt-Verbindung zu einer Zielstation. In beiden Fällen
kommen PPP26 und TCP/IP zur Anwendung.
• GPRS:
GPRS ist Bestandteil von GSM und fast flächendeckend verfügbar. Ein
Schwerpunkt dieser Studienarbeit ist die Erstellung eines funktionierenden
Prototyps27 zur Nutzung von GPRS.
• Analoge Modems:
Die Anbindung über Analogmodems ist mit der bereits genannten Anbindung über ISDN vergleichbar. Die beiden Module werden sich nur in wenigen Details28 unterscheiden.
• Direkte Anbindung über IP:
Diese Kategorie behandelt alle Stationen, die eine bereits vor Modulstart
verfügbare IP-Anbindung nutzen. Im Moment sind dies alle Formen von IPbasierten lokalen Netzen29 . Die angeschlossenen Stationen kommunizieren
direkt über einen Router/Gateway mit dem weltweiten Internet.
• SMS oder MMS:
Der Short Message Service (SMS) und der neuere Multimedia Messaging
Service (MMS) sind bereits heute Bestand der verbreiteten GSM-Technologie. Mit ihnen kann der Anwender Datenpakete an andere Stationen
versenden. Diese Form der Datenanbindung zeichnet sich durch eine hohe
Laufzeit und eine Beschränkung auf 160 Zeichen30 pro Nachricht aus. Beim
26
Point-to-Point-Protocol: Wird als Schicht-2-Protokoll beim Datentransfer über Telefonleitungen eingesetzt.
27
Der Prototyp umfasst ein GPRS-Kommunikationsmodul und den Kommunikationsmanager.
28
Wie zum Beispiel den notwendigen Einwahlkommandos.
29
In der Regel wird ein Ethernet zum Einsatz kommen.
30
Mit stark eingeschränktem Zeichenvorrat. Pro Zeichen können ca. 6 Bit codiert werden,
was einem Informationsgehalt von 120 Bytes pro SMS entspricht.
21
Nachfolger MMS sind im Vergleich zur SMS größere Datenblöcke mit den
vollen 8 Bit an Information pro Symbol handhabbar.
• Sonstige Techniken:
Eine Anpassung an zukünftige Übertragungsmedien wird keine Anpassungen an anderen Stellen im System notwendig machen. Es genügt, wenn
der Programmierer ein weiteres Kommunikationsmodul erstellt. Er kann es
dank der einheitlichen Schnittstelle ohne Änderung anderer Komponenten
in das System integrieren.
22
3 DIE EINZELNEN MODULE IM DETAIL
3
Die einzelnen Module im Detail
3.1
Der Kommunikationsmanager
Im letzten Abschnitt wurden bereits die einzelnen Aufgaben des Kommunikationsmanagers erläutert. Es ging dort um die folgenden Punkte:
• Versendung von Dateien ( Informationscontainer“)
”
• Start- und Stopp von einzelnen Kommunikationsmodulen
• Wegewahl
• Übergabe von Datenströmen (Handover)
3.1.1
Kommunikation über Dateien
Jede zu versendende Datei liegt in einem stromausfallsicheren Übergabeverzeichnis oberhalb“ des Kommunikationsmanagers. Dort können die einzelnen Dateien
”
auch eine längere Zeit sicher verweilen. Im vorliegenden Fall dient dazu ein Verzeichnis, welches auf einem stromausfallsicheren Medium31 liegt.
Damit der Kommunikationsmanager mit der Übertragung beginnen kann,
schickt ihm der Dienstnehmer ein so genanntes Event32“ (Ereignis) als Anstoß“.
”
”
Es enthält den Dateinamen und noch weitere Parameter33 , die dem Kommunikationsmanager mitgeteilt werden müssen.
Die Datei steht jetzt unter der Kontrolle des Kommunikationsmanagers, und
wird erst nach ihrer vollständigen Versendung von ihm gelöscht. Der Ersteller der
Datei erhält keine weitere Rückmeldung, wenn seine“ Datei vollständig am Ziel
”
angekommen ist34 .
Für die Versendung der Dateien werden noch weitere Informationen benötigt
als ihr bloßer Inhalt ( Die Nachricht“). Hier kommen die bereits angsprochenen
”
Parameter ins Spiel, denn sie geben Auskunft über die weitere Behandlung der
Datei:
• Adressierung:
Zum erfolgreichen Versand wird der Name oder eine Adresse des Empfängers benötigt: Der Kommunikationsmanager muss wissen, wohin er die
Datei zustellen soll. Auch die Angabe einer Absenderadresse ist sinnvoll.
Sie ermöglich dem Empfänger zu erkennen woher die Datei gekommen ist.
31
Hier: Ein Compact-Flash Modul.
Dazu wird der Mechanismus der Window Messages“ verwendet.
”
33
Unter anderem die Priorität der Nachricht und die Stationsadresse der Zielstation.
34
Auf dieser höchsten“ Ebene gibt es keine Ende-zu-Ende Quittierungen.
”
32
3.1 Der Kommunikationsmanager
23
• Dringlichkeiten:
Es gibt unwichtigere“ Daten ( niedrige Priorität“). Sie dürfen vom Kom”
”
munikationsmanager mit Blick auf eine Kostenersparnis verzögert versendet
werden. Andererseits gibt es auch hoch priorisierte Nachrichten, die eine sofortige Einwahl mit allen daraus resultierenden Zusatzkosten rechtfertigen.
Die Aufgabe der Wahl einer geeigneten Priorität fällt dem Sender zu. Dies
ist im vorliegenden Fall der Dispatcher mit seinen nachgeschalteten Verarbeitungsmodulen.
• Die Nachricht:
Die Motivation des Dateienaustausches liegt im Austausch von Informationen. Sie sollen transparent und ohne Modifikation durch die an der Kommunikation beteiligten Komponenten an die Zielstation übertragen werden.
Es ist irrelevant, wie der Inhalt der Nachricht aussieht. Sie kann in Form
gepackter Binärdaten35 oder als strukturiertes XML-Telegramm36 ( eXten”
ded Markup Language“) vorliegen. Das, was vom Dispatcher und seinen
Modulen als Datei im Übergabeverzeichnis abgelegt wird, taucht so auch
wieder im Übergabeverzeichnis des Kommunikationspartners auf.
3.1.2
Warteschlangen und Prioritäten
Während des Betriebes können sich am Komunikationsmanager mehrere Dateien, die alle an die selbe Zielstation versendet werden sollen, sammeln. Gleichzeitig wird zwischen unwichtigeren und wichtigeren Daten unterschieden. Einem zu
übertragenden Logfile wird beispielsweise eine geringere Priorität zugewiesen als
einer ausgelösten Alarmmeldung.
Der Kommunikationsmanager fällt anhand der Prioritäten eine Entscheidung
über die Bearbeitungsreihenfolge. Er achtet darauf, dass Dateien mit hoher Priorität bevorzugt übertragen werden. Für diese Aufgabe wurde vom Autor ein Warteschlangenmechanismus entworfen. Er wird in Abbildung 9 gezeigt.
Die interne Warteschlange erlaubt eine Trennung in 256 verschiedene Prioritäten, und hält für jede dieser Prioritäten eine verkettete Liste bereit. In ihr
verwaltet der Kommunikationsmanager die Jobs“. Jeder dieser Jobs besteht aus
”
einem Informationsblock mit den Parametern zum Dateiversand. Dazu gehören:
• Der vollständige Dateiname mit Pfad im Verzeichnisbaum der Station
• Die Absenderadresse, die besagt wo die Datei ursprünglich37 herkommt
• Die Stationsadresse der Zielstation
35
Falls nur wenig Übertragungskapazität zur Verfügung steht.
XML ist ein Hilfsmittel zur Darstellung von Daten, das aber sehr aufgeblasene“ Telegram”
me erzeugt.
37
Wichtig für ein Netzwerk mit Relais-Knoten.
36
24
Datei 1
Datei 2
Datei 3
0
1
2
3
4
5
6
−
−
−
252
253
254
255
−
Infoblock:
IB 2
IB "x"
−
−
−
−
Dateiname mit vollem Pfad
Ankunftszeit
Absenderadresse
Zieladresse
Dateilänge
Offset in Datei
Quittierungsinformationen
IB 1
IB 3
nächstes
Listenelement
steigende Priorität
−
−
−
Sendewarteschlange
(256 Prioritäten)
Scheduler
Wegewahl
Fragmentierung
Sendeprotokoll
Kommunikationsmodule
Hauptlink
Backuplink
Abbildung 9: Priorisierte Warteschlange zum Dateiversand
• Die Dateilänge in Bytes
• Der Dateizeiger (Offset), der auf den nächsten zu versendenden Bereich
zeigt
• Quittierungsinformationen. Mit ihnen wird überwacht, welche Dateibereiche bereits fehlerfrei vom nächsten Knoten empfangen wurden
• Die Ankunftszeit am Kommunikationsmanager, zur Bestimmung von Timeouts
Mit Hilfe dieser Informationen kann der Kommunikationsmanager die nächste zu
versendende Datei auswählen. Die Dateien werden dabei nicht als Ganzes“ ver”
sendet, sondern in Form kleinerer Fragmente. Es käme sonst zu Planungsproblemen, wenn eine hochpriore Meldung auf einen sehr umfangreichen, niederprioren
Datentransfer treffen würde. Die Meldung müsste entweder warten38 , oder den
bereits laufenden Datentransfer unterbrechen und unbrauchbar machen. Beide
Alternativen sind nicht akzeptabel.
3.1.3
Fragmentierung / Reassemblierung
Da die einzelnen Dateien sehr groß sein können, muss der Kommunikationsmanager sicherstellen, dass eine Datei eine Übertragungsstecke nicht für lange Zeit
38
Dieser Effekt wird als Prioritätsumkehr bezeichnet [Butt97].
3.1 Der Kommunikationsmanager
25
blockieren kann. Später eintreffende aber höher priorisierte Dateien müssen weiterhin bevorzugt versendet werden. Ein solches Verhalten wird durch die Fragmentierung ermöglicht. Hierbei werden die zu versendenden Dateien in kleinere
Datenblöcke zerteilt. Solche Datenblöcke sind hinreichend klein, und blockieren
das Medium nicht, wenn ein höher priorisierter Datenstrom verzögert eintrifft.
Die Fragmentierung hat noch einen weiteren Vorteil: Sie ermöglicht, dass Paketverluste behandelt werden können. Einzelne Fragmente lassen sich effizienter
wiederholen als eine komplette Datei.
Die Kommunikationsmodule erwarten ihre Nutzlasten“ in Form von Frag”
menten mit einer maximalen Größe. Beim Funkmodul zum Beispiel ist jedes Paket zwingend 128 Byte groß39 , bei IP-basierten Medien werden größere Fragmente
verwendet. Diese Fragmentierung wird in Absprache mit den Kommunikationsmodulen vom Kommunikationsmanager durchgeführt.
Diese Technik erfordert einen Protokolloverhead, damit der Empfänger die
einzelnen Fragmente wieder demultiplexen (trennen) und reassemblieren (zusammenfügen) kann. Um nicht für jedes Paket alle notwendigen Informationen (Dateiname, Absender, . . . ) erneut zu versenden, kommunizieren die Kommunikationsmanager über einen verbindungsorientierten Mechanismus miteinander.
Wenn eine Datei versendet wird, handeln beide Stationen einen logischer Kanal aus. Sie verknüpfen jeweils alle zur Übertragung wichtigen Parameter (wie
zum Beispiel den Dateinamen) mit diesem Kanal. Jedem Paket wird als Header
der Kanalkenner in Form eines 32bit-Integerwertes vorangestellt, und der Empfänger kann das Paket eindeutig zuordnen.
3.1.4
Datenbank für die Kommunikationsmodule
Jedes dem Kommunikationsmanager bekannte Kommunikationsmodul weist spezielle Eigenschaften auf, die die vom ihm bereitgestellten Dienste beschreiben.
Dazu gehören alle Parameter, die die Wegewahl beeinflussen (Art der Verbindung, Kosten, erreichbare Stationen, . . . ), aber auch programmiertechnische Details wie der Dateinamen des entsprechenden Kommunikationsmoduls und modulinterne Daten. Ein Teil dieser Informationen wird vom Kommunikationsmodul
gebraucht, der andere vom Kommunikationsmanager. Alternativ dazu wäre eine
Speicherung der Konfigurationsdaten in jedem Kommunikationsmodul denkbar,
jedoch ermöglicht die zentralisierte Datenhaltung im Manager einen gesammelten
Zugriff und damit eine vereinfachte Wartung.
Jedes Kommunikationsmodul fordert, wenn es gestartet wird, seine Konfigurationsdaten vom Kommunikationsmanager an. Sämtliche Einstellungen gehören
dazu, wie unter anderem Nutzernamen, Passwörter, Telefonnummern, Adressen
von Servern, Portnummern, Timing- und Tarifinformationen.
39
Die 128 Byte umfassen allerdings den effektiven, zu übertragenden Datenblock inklusive
aller Header und Redundanzen; die Größe des hier gemeinten Datei“-Fragmentes ist entspre”
chend geringer.
26
Diese Konfigurationsdatei wird in Form eines XML-Dokuments im Kommunikationsmanager hinterlegt. Sie kann vom Anwender im laufenden Betrieb der
Station aktualisiert werden. Der Kommunikationsmanager teilt den Kommunikationsmodulen eine solche Änderung mit, woraufhin die Module ihre Konfigurationsdaten erneut anfordern.
3.1.5
Wegewahl / Routing
Es gibt zwei Anwendungsfälle, bei denen eine Wegewahl durchgeführt werden
muss. Einmal, wenn mehrere Kommunikationswege zum Ziel führen, oder wenn
die aktuelle Station eine Art Zwischenstation zum Ziel darstellt. Als Beispiel
hierfür eignet sich der über ein LAN verkoppelte Verbund mehrerer Stationen,
von denen nur eine einzelne über einen Weg nach draußen“, also zur Leitstation,
”
verfügt40 . Aus Sicht einer Nur-LAN-Station“ wird vom Dispatcher die Stations”
adresse der Leitstation als Zieladresse eingetragen, aber der Kommunikationsmanager erkennt, dass er das Paket nicht direkt dem Ziel übergeben kann. Er weiß
aber, welcher Knoten“ näher am Ziel liegt, und kann das Paket an diesen Tele”
”
grammrouter“ weiterleiten. Dazu versendet er in diesem Fall das Telegramm über
das LAN-Modul.
Das Paket wird an die Vermittlungsstation geschickt, wo es ebenfalls von einem LAN-Modul entgegengenommen wird. Dieses reicht das empfangene Paket
nach oben“ zum Kommunikationsmanager weiter. Hier entscheidet sich erneut,
”
welchen Weg das Paket zu gehen hat. In diesem Fall ist die Station über GPRS
mit der Leitstation verbunden, und das Paket wird an das GPRS-Modul weitergeleitet. Beim umgekehrten Weg, für Pakete aus Richtung der Leitstation, ist der
Mechanismus nach dem selben Schema anwendbar.
3.2
3.2.1
Die Kommunikationsmodule
Anpassung an das Übertragungsmedium
Die zu unterstützenden Übertragungsmedien weisen jeweils spezielle Eigenschaften auf, die eigene Herangehensweisen zur Nutzung erfordern. TCP/IP-basierte
Kommunikationswege weisen ein datenstromorientiertes Übertragungsverhalten
auf, Betriebsfunk dagegen hat durch sein Zeitschlitz-basiertes Übertragungsverfahren einen blockorientierten Charakter. Manche Medien benötigen einen Verbindungsaufbau (GPRS benötigt eine Einwahl), andere dagegen nicht (Stationen
in lokalen Netzen). Bei der Nutzung von Betriebsfunk muss sich der Programmierer zusätzlich noch Gedanken um einen eigenen Medienzugriffsmechanismus
machen, da sich mehrere Stationen den Äther teilen.
Zusammenfassend sind in den Kommunikationsmodulen die speziell an ein
Medium anzupassenden Routinen zum Empfang und Versand von Daten an40
Abbildung dieses Sachverhalts auf Seite 15.
3.2 Die Kommunikationsmodule
27
gesiedelt. Jedes Medium weist andere Eigenschaften auf, und benötigt andere
Herangehensweisen bei der Anwendung.
• Medienzugriffskontrolle:
Sie realisiert das Management der zu nutzenden Übertragungstechnik. Bei
Betriebsfunk schließt sie das Warten auf zugewiesene Zeitschlitze sowie eine zentralisierte Verwaltung der Funkressourcen mit ein. Bei den meisten
anderen Übertragungstechniken braucht sich der Programmierer aber keine
Gedanken um diese MAC-Schicht“ (Medium Access Control) zu machen.
”
Sie ist dort bereits mit enthalten.
Auch der Auf- und Abbau von Wählverbindungen kann mit in die Kategorie
der Medienzugriffskontrolle gezählt werden.
• Überwachung:
Aufgebaute Wählverbindungen können durch unerwünschte externe Ereignisse41 getrennt werden. Um dem zu begegnen, wird die Verbindung überwacht. Wird ein unerwünschter Verbindungsabriss registriert, kann das Modul als Reaktion eine sofortige Wiedereinwahl starten.
Auch der umgekehrte Verbindungsaufbau ist denkbar. Dabei stellt die lokale Station einen Einwahlknoten bereit, in den sich anrufende Stationen
einwählen können. Anrufende Stationen müssen sich authentifizieren, um
die Dienste der angerufenen Station nutzen zu dürfen. Die Erkennung und
Behandlung von eingehenden Verbindungswünschen fällt mit in den Aufgabenbereich der Kommunikationsmodule.
• Redundanz/Kanalcodierung:
Betriebsfunk liefert von Haus aus kein integriertes Fehlermanagement mit.
An der Funkschnittstelle auftretende Bitfehler werden von der verwendeten
Hardware weder erkannt noch korrigiert.
Es ist mit die Aufgabe der Kommunikationsmodule, solche Gegebenheiten
zu berücksichtigen. Das Betriebsfunkmodul benötigt hierfür Mechanismen
zur Fehlererkennung und -korrektur. Dafür stehen verschiedene Techniken
zur Auswahl:
– Fehlererkennende Codes:
Sie ermöglichen durch eine Verwendung von Prüfsummen die Erkennung von aufgetretenen Bitfehlern. Praxisrelevante Verfahren sind Paritätsbits oder der Cyclic Redundancy Check“ (CRC). Diese Verfah”
ren erkennen mehr oder weniger gut verfälschte Blöcke. Sie sind nicht
in der Lage den Auftrittsort des Fehlers zu lokalisieren. Eine Korrektur ist nicht möglich. Ein fehlerbehafteter Block wird vom Empfänger
verworfen und erneut angefordert.
41
Beispielsweise aufgrund einer kurzzeitigen Störung im Telefonnetz.
28
– Fehlerkorrigierende Codes:
Fehlerkorrigierende Codes ermöglichen eine Vorwärtsfehlerkorrektur.
Der Empfänger ist damit in der Lage, den Auftrittsort bestimmter
Fehlermuster zu ermitteln. Die auftretenden Fehler sind somit korrigierbar. Die Verfahren benötigen einen hohen Anteil an Redundanz,
und sind auch kein Allheilmittel. Die Restfehlerwahrscheinlichkeit wird
auch mit größtem Codierungsaufwand immer größer Null sein.
– Interleaving (Codespreizung):
Fehlerbursts42 lassen sich alleine durch Codierung nur sehr schwierig
in den Griff bekommen, da gegen eine hohe Bitfehlerzahl pro Block
nur viele Kontrollbits helfen. Fehlerbursts lassen sich aber dadurch
entschärfen, dass die zu einem Burst gehörenden Bits über mehrere
Blöcke gestreut werden. Der Fehlerburst verteilt sich dann gleichmäßig über mehrere Blöcke und kann mit einfacheren Codes korrigiert
werden.
Bei allen TCP/IP-basierten Medien braucht sich der Programmierer um
auftretende Paketverfälschungen keine Sorgen zu machen. Sie treten höchstens bei GPRS verstärkt in den unteren Schichten auf, was aber bereits
durch die in TCP integrierten Mechanismen kompensiert wird.
• Adressumwandlung:
Der Kommunikationsmanager adressiert Datenpakete über so genannte Stationsadressen (dies sind projektinterne Identifikationsnummern). Das zur
Übertragung verwendete Medium verwendet dagegen davon abweichende
Adressierungsschemata. Die notwendige Adressumsetzung zwischen Stationsadressen und medienspezifischen Adressen erledigt das Kommunikationsmodul. Beispielsweise wird bei einer TCP/IP-basierten Anbindung eine Adressumsetzung zwischen Stationsadressen und IP-Adressen durchgeführt.
• Keine weitere Fragentierung!
Die Aufgabe der Fragmentierung übernimmt bereits der Kommunikationsmanager. Ein jedes Kommunikationsmodul kann aber seine Wunsch-Fragmentgröße nachträglich verändern. Wenn sich bei Funknutzung die Übertragungsbedingungen verschlechtern, kann das Betriebsfunkmodul auf eine
Kanalcodierung mit höherer Redundanz umschalten. Das bedeutet aber,
dass die Datenfragmente seitens des Kommunikationsmanagers kleiner werden müssen. Die resultierenden Blöcke weisen eine höhere Redundanz auf,
daher bleibt weniger Platz für Information.
Es ist dabei nicht gesagt, dass alle genannten Schritte auch implementiert
werden müssen. Ein guter Kandidat dafür ist das Betriebsfunkmodul, aber für
42
Fehlerbursts sind mehrfache, eng hintereinander auftretende Verfälschungen.
3.2 Die Kommunikationsmodule
29
die vorliegende Aufgabe (die Umsetzung des GPRS-Moduls) werden keine Fehlerbehandlungsschritte benötigt. Abbildung 10 zeigt die eben genannten Aspekte
in Form eines Ablaufdiagrammes.
Kommunikationsmodul
IDU
Übergabe einer SDU
an das Kommunikationsmodul
SDU
Projektspezifische
Stationsadresse
Verbindungskenner anfügen
Hd
Adress−
Umsetzung
SDU
Vorwärtsfehlerkorrekturcodes
Hd
SDU
FEC
Prüfsumme hinzufügen
Medienspezifische
Stationsadresse
Hd
SDU
FEC CRC
Versandfertige SDU
Sende−
Routinen
IDU
SDU
Hd
FEC
CRC
:
:
:
:
:
Interface Data Unit
Service Data Unit
Header
Forward Error Correction
Cyclic Redundancy Check
Abbildung 10: Datenpaket innerhalb eines Kommunikationsmoduls
Hier werden fehlerkorrigierende Codes (FEC, Forward Error Correction“)
”
in Kombination mit einer Prüfsumme (CRC, Cyclic Redundancy Check“) ver”
wendet. Die Fehlerkorrektur kann geringe43 Fehler korrigieren, versagt aber bei
umfangreicheren Bitfehlerkombinationen. Der Empfänger erhält nach der Korrektur ein falsches Ergebnis, was er aber ohne weitere Hilfsmittel nicht erkennen
kann. Deshalb wird um diesen inneren Fehlerschutz noch ein äusserer Fehlerschutz geschachtelt, der falsch korrigierte Codeworte erkennen soll. Eine solche
Schachtelung wird auch bei GSM und UMTS angewendet.
3.2.2
Telegrammdienst
Die Kommunikationsmodule bieten einen unquittierten Telegrammdienst (Datagramm-Dienst) an. Der Kommunikationsmanager reicht ein Telegramm an eines
seiner Kommunikationsmodule weiter, um es über diese Schnittstelle auf die Rei”
se“ zu schicken. Genauso können aber auch Telegramme von einer Gegenstation
entgegengenommen werden. Die eigentliche Nutzlast“ besteht aus einem binär
”
43
Geringe Anzahl an Bitfehlern pro Block.
30
codierten Datenpaket, das vom Kommunikationsmanager erzeugt (beim Versenden) und ausgewertet wird (beim Empfang).
3.2.3
Quittierungen
Die Kommunikation zwischen zwei Kommunikationsmodulen ist als unquittierter Telegrammdienst darstellbar. Auf der Übertragungsstrecke können Pakete
verlorengehen, je nach Übertragungsmedium mit einer höheren oder niedrigeren
Wahrscheinlichkeit. Darum brauchen sich die Kommunikationsmodule nicht zu
kümmern. Es ist die Aufgabe des darüberliegenden Kommunikationsmanagers,
einen Paketverlust durch geeignete Quittierungsmechanismen zu bemerken und
die Übertragung zu wiederholen.
3.3
3.3.1
Interprozesskommunikation
Kommunikation zwischen den Modulen
Die am Kommunikationsmechanismus beteiligten Module werden als geschichte”
tes Modell“ dargestellt. Eine untergeordnete“ Schicht bietet dabei einer überge” 44
”
ordneten“ Schicht einen Dienst an. Dieser Abschnitt geht auf die Frage ein, wie
die einzelnen Module miteinander kommunizieren. Diese folgenden Mechanismen
erlauben beispielsweise dem Kommunikationsmanager mit seinen Kommunikationsmodulen zu sprechen.
Abbildung 11 zeigt die in beiden Modulen notwendigen Komponenten, die
einen Datenaustausch zwischen Kommunikationsmanager und Kommunikationsmodul ermöglichen.
In beiden Programmen wird jeweils ein Kommunikationsendpunkt benötigt
(IPC_MASTER und IPC_SLAVE). Diese sind miteinander verbunden und halten intern einen Datenkanal vor. Daten, die an einem dieser Kommunikationsendpunkte
abgegeben werden“, fallen“ nach Transport über den Datenkanal am anderen
”
”
Kommunikationsendpunkt wieder heraus“.
”
Es wird bewusst noch keine Aussage über den eigentlichen Datenkanal gemacht, sondern nur die notwendige Funktionalität der beiden Endpunkte genannt.
Später folgt ein Überblick über die Möglichkeiten zur Umsetzung und den im Prototypen verwendeten Ansatz.
Die beiden Kommunikationsendpunkte sind nicht identisch. Sie werden in den
so genannten Master“ und den Slave“ getrennt. Der Grund liegt im unterschied”
”
lichen Verhalten bezüglich des Aufbaus der internen Datenverbindung. Der Master ist derjenige, der zuerst gestartet wird. Er startet anschließend den Slave.
Dieser meldet sich beim Master zurück, um den Aufbau der Datenverbindung
abzuschließen. Bei Erfolg können Daten ausgetauscht werden. Master und Slave
verhalten sich diesbezüglich symmetrisch.
44
Dies wurde bereits in der Einführung zu Schichtenmodellen auf Seite 13 dargestellt.
3.3 Interprozesskommunikation
31
Datentransfer
IPC_MASTER
Aufbau
Datentransfer
IPC_SLAVE
Datentransfer
Einzelnes Kommunikationsmodul
Abbildung 11: Allgemeine Interprozesskommunikation
.send(DATA)
.recv(DATA)
8.
1.
new()
IPC_MASTER
Anker=.init()
2.
6.
connected
5.
.connect(Anker)
3.
Start [Anker]
4.
new()
IPC_SLAVE
8.
7. Vollduplex−Kanal
.send(DATA)
.recv(DATA)
Abbildung 12: Ablauf der allgemeinen Interprozesskommunikation
32
Das Ablaufdiagramm Nr. 12 zeigt diese Schritte im Detail. Der obere Block
symbolisiert den Kommunikationsmanager mit seinem Master-Endpunkt, der untere zeigt ein einzelnes Kommunikationsmodul mit seinem Slave-Endpunkt als
Kommunikationspartner. Dieses Schaubild ist noch unabhängig von einer konkreten Datenübertragungstechnologie.
Zuerst erstellt der Kommunikationsmanager einen eigenen lokalen MasterKommunikationsendpunkt (1) und initialisiert diesen (2). Dabei wird ein An”
ker“ gesetzt, mit Hilfe dessen sich das Kommunikationsmodul später registrieren
kann. Jetzt wird das Kommunikationsmodul gestartet (3), wobei ihm der Anker
als Kommandozeilenparameter übergeben wird. Das Kommunikationsmodul erzeugt ebenfalls einen Kommunikationsendpunkt, allerdings die Slave“-Variante
”
(4). Jetzt kann der eigentliche Datenkanal etabliert werden. Dazu nutzt das Kommunikationsmodul den übergebenen Anker, um sein Slave-Objekt mit dem Master-Objekt zu verbinden (5). Der Master registriert die Rückmeldung (6), so dass
ein vollduplexfähiger Datenkanal ausgehandelt werden kann (7). Die Initialisierung ist komplett. Der Kommunikationsmanager und das Kommunikationsmodul
können sich gegenseitig Daten zuschicken (8).
3.3.2
Mögliche Ansätze zum Datenaustausch
Zur Kommunikation können verschiedene Technologien verwendet werden. Microsoft Windows CE bietet diverse Technologien an, die einen Datenaustausch
im Rahmen von Inter-Prozess-Kommunikation“ (IPC) ermöglichen.
”
Aber nicht alle diese Methoden sind für den Einsatz geeignet. Die folgende
Übersicht betrachtet die untersuchten Mechanismen:
• TCP/IP-Sockets:
Nutzung von TCP/IP zum Datenaustausch zwischen zwei beteiligten Kommunikationspartnern. Nutzt die Netzwerkfähigkeiten des Systems.
• Window Messages:
Plattformabhängiger Mechanismus zum Datenaustausch zwischen einzelnen
Fenstern. Es gibt vom Betriebssystem vordefinierte Nachrichten, die an andere Fenster gesendet und dort von einer Routine empfangen und bearbeitet
werden.
• Microsoft Message Queues:
Die Microsoft Message Queues“ (MMQ’s) sind ein weiterer Mechanismus
”
zum Versenden von Nachrichten an einen Empfänger. Die Nachrichten werden systemintern in Warteschlangen zwischengespeichert.
• Dateien:
Hierbei werden zu übermittelnde Informationen in Form von Dateien in
einem Übergabeverzeichnis abgelegt. Von hier aus werden sie von einem
3.3 Interprozesskommunikation
33
anderen Programm geöffnet und ausgewertet. Erfordert Synchronisationsmechanismen, um einen gleichzeitigen Zugriff auf die Dateien auszuschließen.
• Remote Procedure Calls:
Remote Procedure Calls“ (RPC) basieren auf Sockets, und dienen dum
”
Aufruf entfernter Prozeduren. Sie können aber auch zur Übermittlung von
Nachrichten verwendet werden.
3.3.3
Interprozesskommunikation über Sockets
Der im Rahmen der Studenarbeit erstellte Prototyp verwendet Sockets zur Interprozesskommunikation. Sockets sind eine flexible Lösung. Sie erlauben die Trennung der beiden Schichten in jeweils eigenständige Programme.
Es werden lokale45 Sockets benutzt. Sie werden über den TCP/IP-Mechanismus des Betriebssystems bereitgestellt. Doch warum wurde sich für den Prototyp
für die Verwendung von Sockets entschieden?
• Sockets sind einfach zu benutzen. Es gibt ein übersichtliches und dokumentiertes Application Programming Interface“ (API).
”
• Sockets stellen eine etablierte Technologie dar. Sie sind sehr ausführlich
getestet und Bestandteil aller modernen Betriebssysteme.
• Sockets sind schnell. Andere zur Auswahl stehende Technologien wie RPC46
nutzen intern ebenfalls den Socketmechanismus, und sind daher im Vergleich höchstens genauso schnell.
• Sockets werden als Datenstrom angesprochen. Der Anwender muss sich Gedanken machen, wie Steuer- und Nutzdaten miteinander vereint und innerhalb des Datenstroms codiert werden. Die Lösung dafür liegt in der
Definition eines Datenaustauschformates. Es beschreibt das Aussehen der
zu übermittelnden Nachrichten.
Diese Aufgabe lässt sich mit Hilfe von XML47 -Telegrammen angehen, doch
wird sich aus Gründen der Einfachheit (Prototyp) nur auf einfache, binär
codierte Nachrichten beschränkt. Bei Bedarf kann auf ein anderes Datenformat umgeschwenkt werden.
• Hinzufügen weiterer Kommunikationskanäle: Neue Sockets können jederzeit
vom Betriebssystem angefordert werden. Sie existieren dann nebeneinander
ohne sich gegenseitig zu beeinflussen.
45
Die Sockets verbinden zwei lokale Prozesse miteinander.
Remote Procedure Calls.
47
eXtended Markup Language.
46
34
Die interne Struktur der Master- und Slaveobjekte wird mit Sockets umgesetzt. Die notwendigen Schritte zum Aufbau einer Kommunikationsbeziehung ähneln dabei dem allgemeinen Ansatz zur Interprozesskommunikation.
11.
.send(DATA)
.recv(DATA)
IPC_MASTER
1.
new()
2.
.bind()
TCPIP_LISTENER
3.
TCPIP_ENDPOINT
8.
PortNum
Start [PortNum]
9.
connected
4.
10.
Etablierter Socket
(Vollduplex)
5.
new()
7.
connecting
6.
TCPIP_ENDPOINT
.connect(PortNum)
IPC_SLAVE
11.
.send(DATA)
.recv(DATA)
Abbildung 13: Interprozesskommunikation mit Sockets
Die beiden Kommunikationsendpunkte IPC_MASTER und IPC_SLAVE sind in
Abbildung 13 (Seite 34) weiterhin zu erkennen. Sie werden wie bereits beschrieben verwendet. Intern sind sie jedoch konkret auf die Verwendung von TCP/IPSockets angepasst.
Der Kommunikationsmanager initialisiert den Master-Endpunkt (1). Dieser
bindet intern einen so genannten Listener -Socket TCPIP_LISTENER an einen freien
TCP-Port (2). Dieser Port wird auf eintreffende Verbindungswünsche überwacht,
was für die spätere Rückmeldung des Slaves wichtig ist. Er weist eine eindeutige
Nummer auf (3), die dem anschließend gestarteten Kommunikationsmodul als
Kommandozeilenparameter übergeben wird (4). Das Kommunikationsmodul initialisiert seinen lokalen Verbindungsendpunkt (5), und teilt ihm den Rückrufport
des Masters mit. Intern wird ein lokaler TCP/IP-Endpunkt TCPIP_ENDPOINT erzeugt (6). Er wird mit dem Master verbunden (7). Dort wartet noch der Listener
3.4 Schnittstellen und Protokolle
35
(8). Er nimmt die Verbindung an und erzeugt seinerseits ebenfalls einen TCP/IPEndpunkt (9). Zwischen Master und Slave besteht jetzt eine vollduplexfähige Datenverbindung (10), die durch Nutzung der Methoden des Masters und des Slaves
zum Datentransfer genutzt werden kann (11).
3.4
3.4.1
Schnittstellen und Protokolle
Schnittstelle oberhalb des Kommunikationsmanagers
Kommunikations−
manager
Kommunikations−
manager
Abbildung 14: Dienstschnittstelle des Kommunikationsmanagers
Der Kommunikationsmanager erhält seine zu übertragenden Nachrichten aus
einem Übergabeverzeichnis. Wenn eine Datei versendet werden soll, wird sie vom
Dienstnehmer dort abgelegt. Damit der Kommunikationsmanager die neue Datei
bemerkt, sendet ihm der Dienstnehmer ein so genanntes Event48“. Es enthält alle
”
weiteren, noch notwendigen Informationen: Den vollständigen Pfad der Datei, die
Stationsadresse des Empfängers, eine Priorität und noch weitere Parameter.
Diese Schnittstelle existiert bereits und ist nicht Bestandteil dieser Studienarbeit. Der Mechanismus wurde bereits im Rahmen des bestehenden Funk-Projektes entwickelt und kann für die neue Modulstruktur übernommen und angepasst
werden.
3.4.2
Protokoll zwischen Kommunikationsmanagern
Kommunikations−
manager
Kommunikations−
manager
Abbildung 15: Protokoll zwischen Kommunikationsmanagern
Dieses Protokoll wird an das bereits bestehende Funk-Projekt angelehnt. Es
macht eine Menge an internen Änderungen erforderlich, denn es kann beispielsweise von nun an nicht mehr mit festen Fragmentgrößen gearbeitet werden. Das
48
Über eine Window-Message.
36
zu implementierende Protokoll wird mit variablen Fragmentgrößen49 zurechtkommen müssen.
Die interne Struktur mit der Nutzung von Warteschlangen und dem Mechanismus der Fragmentierung von großen Datenblöcken im Kommunikationsmanager
war die Idee des Autors im Rahmen der Planung der Modulstruktur. Die konkrete Implementierung ist dagegen nicht mehr Bestandteil dieser Studienarbeit
und wird später von jemand anderem übernommen. Dabei müssen die bestehende
Routinen aus dem Funk-Projekt angepasst werden. Die notwendigen Änderungen werden von demjenigen Programmierer umgesetzt, der auch die bestehenden
Funkroutinen entwickelt hatte.
3.4.3
Protokolle des Prototyp
Bei der Erstellung des Prototyp konnten nicht alle genannten Mechanismen implementiert werden. Der Schwerpunkt lag auf der Demonstration des bidirektionalen
Datentransfers.
Es wurden eine Reihe von Nachrichten definiert, die stellvertretend für beliebige Datenblöcke (wie sie im späteren Hauptprojekt auftreten werden) versendet
und empfangen werden. Der Prototyp besteht aus zwei Stationen, dem Echoserver und dem Echoclient. Der Echoserver wird auf dem Beckhoff-PC gestartet. Er
wählt sich per GPRS ins Internet ein und wartet auf Anfragen des Echoclients.
Dieser residiert auf dem Arbeits-PC (Leitstation) und versendet über Ethernet
(Mit einem DSL-Router als Standardgateway) eine Reihe von Ping“-Nachrichten.
”
Der Server empfängt diese und antwortet auf sie mit den entsprechenden Pong“”
Nachrichten.
Sowohl der Server als auch der Client bedienen sich eines Kommunikationsmoduls. Sie müssen es jeweils starten und ihm den Befehl zur Einwahl erteilen.
Nach Aufbau der Verbindung wird das Modul zur Datenübertragung genutzt.
Um es zu beenden (Programmende), schickt ihm der Kommunikationsmanager
(Echoserver, Echoclient) ein halt“-Kommando. Das Modul beendet sich und gibt
”
alle noch belegten Ressourcen frei.
• Kommunikationsmanager an Kommunikationsmodul, Steuerdaten (ICI50 ’s)
– connect
Aufforderung an das Kommunikationsmodul, die Einwahl zu starten.
Dies kann je nach verwendetem Medium eine Weile dauern. Bei GPRS
werden ca. 15 Sekunden zur Einwahl benötigt. Dieser Schritt ist auch
bei Medien ohne Verbindungsaufbau notwendig (Ethernet beispielsweise), denn erst ab diesem Moment nimmt das Modul auch Daten von
49
Wenn die Hauptkommunikationsanbindung über Funk (128 Bytes pro Block) ausfällt, ändert sich beim Umschalten auf eine vorhandene ISDN-Backupleitung (evtl. 1024 Bytes pro
Block) die Fragmentgröße.
50
Interface Control Information.
3.4 Schnittstellen und Protokolle
37
Echoclient
Echoserver
LAN−Modul
Kommunikationsmodul
auf PC (Leitstation)
pong_pdu
killechoserver_pdu
pong_req
ping_ind
killechoserver_ind
halt
disconnected
disconnect
connect
ping_pdu
connected
auf Beckhoff−PC
pong_ind
ping_req
killechoserver_req
halt
disconnected
disconnect
connected
connect
auf PC (Leitstation)
GPRS−Modul
Kommunikationsmodul
auf Beckhoff−PC
Abbildung 16: Protokolle des Prototyp (Echoserver, Echoclient)
anderen Stationen entgegen. Nach Aufbau der Verbindung beginnt das
Kommunikationsmodul auf dem Medium zu lauschen.“
”
– disconnect
Das Kommunikationsmodul soll seine aufgebaute Verbindung beenden.
Sowohl eingehende als auch ausgehende Datenverbindungen werden
gekappt. Es werden keine neuen Verbindungsaufbauwünsche bedient.
– halt
Das Kommunikationsmodul soll sich beenden. Es wird alle belegten
Ressourcen freigeben und sich terminieren.
• Kommunikationsmanager an Kommunikationsmodul, Daten (PDU51 ’s)
– ping_req
Der Echoclient verschickt ein Ping“ an den Echoserver.
”
– pong_req
Der Echoserver antwortet auf ein Ping“ mit einem Pong“. Die Ant”
”
wort geht an die Station, die das Ping gesendet hatte.
– killechoserver_req
Hiermit kann der Echoclient den Echoserver aus der Ferne“ beenden.
”
Da der Echoserver auf dem Beckhoff-PC läuft, wird ein manueller Eingriff am Beckhoff-PC zur Beendigung des Echoservers unnötig.
• Kommunikationsmodul an Kommunikationsmanager, Steuerdaten (ICI’s)
– connected
Das Kommunikationsmodul ist jetzt online. Es ist bereit, Nutzdaten
51
Protocol Data Unit.
38
zu übertragen. Der Kommunikationsmanager kann ab sofort Daten
versenden.
– disconnected
Das Kommunikationsmodul ist nicht mehr online. Dies passiert immer
dann, wenn vorher ein disconnect empfangen wurde oder das Medium
wegen einer Störung zeitweise nicht verwendet werden kann ( Ausfall
”
durch ziehen des Antennensteckers“).
• Kommunikationsmodul an Kommunikationsmanager, Daten (PDU’s)
– ping_ind
Auf Seite des Echoservers ist eine Ping“-Nachricht (Anfrage des Echocli”
ents) eingetroffen.
– pong_ind
Auf Seite des Echoclients ist eine Pong“-Nachricht (Antwort des Echo”
servers) eingetroffen.
– killechoserver_ind
Der Echoserver erhält den Befehl, sich und sein Kommunikationsmodul
zu beenden.
• Kommunikationsmodul an Kommunikationsmodul
– ping_pdu
PDU vom Echoclient zum Echoserver. Sie fordert den Echoserver zu
einer Antwort ( Pong“) auf.
”
– pong_pdu
PDU vom Echoserver zum Echoclient. Enthält die Antwort auf ein
Ping.“
”
– killechoserver_pdu
Eine weitere PDU. Sie befiehlt dem Echoserver, sich und sein Kommunikationsmodul zu beenden.
39
4
Kommunikation über GPRS
4.1
Nutzerschnittstelle des GPRS-Modems
Das GPRS-Modem wird über eine serielle Schnittstelle (RS232) mit dem PC verbunden. Das GPRS-Modem emuliert ein herkömmliches analoges Modem, um
eine maximale Kompatibilität zu existierenden Betriebssystemen zu gewährleisten. Das Betriebssystem greift dabei auf das Point-to-Point Protocol“ (PPP)
”
zurück, um sich mit einem Internetprovider zu verbinden. Der dazu notwendige
PPP-Protokollstapel ist fest im Modem integriert. Das Modem wird über den ATBefehlssatz52 angesprochen. Mit den entsprechenden Befehlen wird die Einwahl
gestartet und per PPP eine Internetverbindung etabliert.
Das folgende Blockschaltbild zeigt die interne Struktur des Modems. Im Vergleich zur bei Analogmodems verwendeten Technik ist hier der PPP-Protokollstapel des Providers in das Modem integriert. Er dient hier lediglich der Kopplung
zwischen Modem und Betriebssystem.
Embedded PC
Einwahl
Terminal
GPRS Modem
Anwendung
PPP
Stapel
Serielle Schnittstelle
GGSN
SGSN
BSS
Modem
Steuerung
IP
IP
AT−Codes
GPRS Provider
AT−Codes
IP
Internet
IP
PPP
Stapel
Serielle Schnittstelle
Serielles Kabel
GPRS
Protokollstapel
GPRS
Protokollstapel
Funkschnittstelle
AT
:
IP
:
PPP :
GPRS :
GGSN :
SGSN :
BSS :
Attention Codes
Internet Protocol
Point to Point Protocol
General Packet Radio Service
Gateway GPRS Support Node
Serving GRPS Support Node
Base Station Subsystem
Abbildung 17: Vereinfachtes Schichtenmodell GPRS-Modem
4.2
4.2.1
Inbetriebnahme des GPRS-Modems
Die Hardware vorbereiten
Zur Inbetriebnahme des Modems wird eine SIM-Karte53 in die dafür vorgesehene
Schublade des Modems eingelegt. Auf dieser sind die Zugangsdaten des Nutzers
und Informationen des verwendeten Mobilfunkprovider gespeichert.
52
53
AT: Attention“-Codes, Hayes-Befehlssatz.
”
Subscriber Identity Module.
40
4 KOMMUNIKATION ÜBER GPRS
Das Modem kommt als kompakte Blackbox und kann direkt in einen Schaltschrank eingebaut werden. Es wird noch eine externe Antenne benötigt, die an
einem Ort installiert werden muss, wo ein ausreichender Empfang gewährleistet
ist. Beim vorliegenden Testaufbau kommt eine Multiband-GSM-Antenne54 der
Firma Hirschmann zum Einsatz. Sie besitzt einen Magnetfuß und weist eine Impedanz von 50 Ω auf, was auch vom Modem verlangt wird.
Abbildung 18: Schema der externen Antenne
Zur Stromversorgung wird ein externes Netzteil mitgeliefert. Das Modem kann
aber auch direkt mit einer Eingangsspannung im Bereich von 8 − 30 V DC betrieben werden.
4.2.2
Testen des AT-Befehlssatzes
Das GPRS-Modem wird über ein serielles Schnittstellenkabel (RS232) mit dem
Rechner verbunden. Die Einbindung in das Betriebssystem gestaltet sich sehr einfach, da das GPRS-Modem das Verhalten eines normalen“ Modems für analoge
”
Telefonleitungen nachahmt. Es wird über AT-Kommandos gesteuert und bringt
einen integrierten PPP-Protokollstapel zur Emulation55 eines Internetproviders
mit sich.
Die folgende Tabelle zeigt diejenigen AT-Kommandos des Modems, die zur
Inbetriebnahme, zum Testen und zum Verbindungsaufbau notwendig sind. Es
gibt noch sehr viele weitere Befehle, welche aber nur für Spezialaufgaben relevant
sind. Sie können bei Bedarf unter [Siem01b] nachgeschlagen werden.
54
Typ Hirschmann MCA 18 90 MH“.
”
Emulation deshalb, weil bei Nutzung eines herkömmlichen Analogmodems der PPP-Protokollstapel der Gegenstation beim Internetprovider liegt. Bei GPRS ist dieser bereits im Modem
integriert. Er dient nur der Kopplung zwischen Betriebssystem und Modem, nicht jedoch als
Schicht 2 Protokoll auf der Übertragungsstrecke.
55
4.2 Inbetriebnahme des GPRS-Modems
AT-Kommando
AT
ATZ
AT +CPIN
=0000
AT +CGDCONT
=1,
ip,
internet.t-d1.de
AT +CGQREQ
=1,
3,
4,
3,
0,
0
ATD *99***1#
ATDP *99***1#
ATDT *99***1#
ATH
+++
ATA
41
Bedeutung
Attention“, liefert OK
”
Rücksetzen des Modems
PIN zur Authentifizierung übermitteln
PDP-Kontext definieren
Context Identity“ (CID)
”
Packet Data Protocol“ (PDP)
”
Access Point Name“ (APN)
”
Quality of Service-Parameter setzen
Context Identity“ (CID)
”
Precedence“ (Priorität)
”
Delay“ (Verzögerung)
”
Reliability“ (Zuverlässigkeit)
”
Peak“ (Spitzenrate)
”
Mean“ (Mittlere Rate)
”
Wahlaufruf, Bezug auf PDP-Kontext CID=1
Alternative Angabe zu ATD (Pulswahl)
Alternative Angabe zu ATD (Tonwahl)
Wird vom Modem nicht unterstützt!
Auflegen
Wechsel vom Datenübertragungsmodus
(PPP) in den AT-Modus
Wechsel vom AT-Modus zu unterbrochenem
Datenübertragungsmodus
Tabelle 1: Wichtige AT-Kommandos
Um den Befehlssatz zu testen, wird ein Terminalprogramm benötigt. Dazu
eignet sich unter Windows das mitgelieferte Terminalprogramm Hyperterminal“
”
bzw. unter GNU/Linux das Programm Minicom“. Als Schnittstelle wird der seri”
elle Port des Modems ausgewählt (eventuell COM1: unter Windows, /dev/ttyS0
unter Linux). Die Standardparameter der Portkonfiguration56 sind bereits korrekt und können beibehalten werden. Auf dem folgenden Bildschirmfoto (Seite
42) sieht man eine Minicom-Sitzung, in der das Modem mit Hilfe von AT-Kommandos dazu gebracht wird sich beim Provider einzubuchen und dem Rechner
über PPP eine Internetverbindung bereitzustellen.
Die Einwahl wird durch mehrere Schritte gestartet:
• ATZ
56
Baudrate, Parität und Anzahl der Stoppbits.
42
Abbildung 19: Konfiguration und Einwahl über AT-Kommandos
Setzt das Modem zurück. Dieser Schritt ist nicht unbedingt erforderlich,
da das Modem in der Regel gerade erst eingeschaltet wurde und noch kein
Rücksetzen notwendig ist.
• AT +CGDCONT=1,ip,internet.t-d1.de
Erzeugung eines PDP-Kontextes (Packet Data Protocol). Mit der ContextID (CID) Nr.1 wird das PDP IP“ und der Access Point Name“ (APN)
”
”
internet.t-d1.de“ verknüpft.
”
• AT +CGQREQ=1,3,4,3,0,0
Festlegung der Quality of Service“ (QoS-) Parameter des PDP-Kontextes.
”
• ATD *99***1#
Start der Einwahl in das Internet. Im Hintergrund wird das Modem jetzt
versuchen, sich in das GPRS-Netz einzubuchen und vom Provider eine IPAdresse zu bekommen. Bei Erfolg initialisiert das Modem seinen integrierten PPP-Protokollstapel, um den angeschlossenen Rechner ins Internet zu
”
leiten“. Die kryptischen Zeichen mit den vielen Klammern in Abbildung 19
auf Seite 42 zeigen den resultierenden PPP-Datenstrom. Da nur ein simples
Terminalprogramm ohne eingebauten PPP-Protokollstapel verwendet wird,
kann der Datenstrom direkt betrachtet werden.
4.2 Inbetriebnahme des GPRS-Modems
43
Bei herkömmlichen Analogmodems gibt es unterschiedliche AT-Einwahlkommandos. Diese reichen von ATDP für eine Einwahl über Pulswahl, ATDT für eine
Einwahl über Tonwahl bis zu ATD für eine Einwahl mit nicht spezifiziertem Wahlverfahren. Bis auf Tonwahl werden alle Kommandos vom Modem unterstützt
(siehe Abbildung 20, Seite 43). Bei der späteren Konfiguration der Interneteinwahl ist unbedingt darauf zu achten, dass Pulswahl verwendet wird. Sonst wird
sich das Modem nicht in das GPRS-Netz einbuchen.
Abbildung 20: Test verschiedener AT-Kommandos zur Einwahl
Bei einen letzten Experiment wird das Modem von einem Festnetztelefon aus
angerufen. Dabei kommt kein GPRS oder IP zum Einsatz. Wie Abbildung 21
zeigt, hat der Anruf geklappt. Im Fenster des Terminalprogrammes tauchen mehrere RING-Nachrichten auf. Der Befehl ATA bringt das Modem zur Annahme der
Verbindung, und man erhält eine bestehende Sprachverbindung. Im Telefonhörer
sind hierbei keinerlei Geräusch zu vernehmen, nur das Freizeichen verschwindet
nach dem Absetzen des Abhebekommandos. Die bestehende Verbindung wird
entweder durch Auflegen des Telefons oder durch Eingabe des Kommandos ATH
im Terminalprogramm beendet.
44
Abbildung 21: Zweimaliger Anruf des Modems aus dem Festnetz
4.2.3
Konfiguration zur Einwahl in das Internet über PPP
Die ersten Tests zur Einwahl ins Internet wurden auf einem SuSE57 Linux 8.2
durchgeführt. Zu diesem Zeitpunkt stand dem Autor nur das GPRS-Modem,
aber noch keine Microsoft Windows-Entwicklungsumgebung und kein BeckhoffPC zur Verfügung.
Das GPRS-Modem wird als herkömmliches Modem erkannt. Anschließend
wird die Interneteinwahl konfiguriert. Die vollständige Konfiguration befindet sich
in Anhang F auf Seite 82, das Logfile zur Einwahl in Anhang G auf Seite 86.
Hier erkennt der interessierte Leser die notwendigen Einstellungen. Das Logfile
zeigt die Reaktion des GPRS-Modem auf die einzelnen AT-Kommandos und die
Aushandlung der PPP-Verbindung.
4.2.4
Test der aufgebauten Verbindung
Die aufgebaute GPRS-Verbindung ist aus Nutzersicht nicht von einer herkömm”
lichen“ Internetverbindung zu unterscheiden. Ein paar Ping“-Kommandos an
”
bekannte Server funktionieren auf Anhieb. Der Browsertest mit URL’s bekannter
Webseiten funktioniert ebenfalls, aber es dauert lange bis eine Webseite komplett
aufgebaut ist. Dies liegt aber nicht an einer langsamen Übertragungsgeschwindigkeit von GPRS, sondern an der Wechselwirkung zwischen TCP/IP und den
57
Homepage unter [SuSE].
4.3 Windows CE .NET 4.1 und GPRS
45
hohen Paketlaufzeiten bei GPRS. Diese Problematik wird in einem eigenen Kapitel (Abschnitt 4.4.2) auf Seite 51 betrachtet.
4.3
4.3.1
Windows CE .NET 4.1 und GPRS
Zur Einwahl notwendige Schritte
Es folgt eine detaillierte Beschreibung wie das verwendete GPRS-Modem Sie”
mens MC35i“ unter Microsoft Windows CE .NET 4.1 ansprochen wird. Es gibt
eine wichtige Randbedingung, die bei der Softwareerstellung eingehalten werden
soll: Der gesamte Konfigurationsprozess muss vollständig per Software auf einem
nackten“ Image durchzuführen sein.
”
Es muss ausreichen, das Programm auf dem Beckhoff-PC abzulegen, das Modem anzuschließen und das Programm zu starten. Es darf keine weiteren Einstellungen geben, die vorher manuell kontrolliert werden müssen.
Die vollautomatische Einwahl58 in das Internet mit Hilfe eines Modems ist unter Windows CE eine sehr aufwendige Angelegenheit. Es stellte sich heraus, dass
ein dafür elementar wichtiger Konfigurationsschritt nirgendwo dokumentiert wurde. Über Google59 konnte aber ein Artikel gefunden werden, der einen inoffiziellen
Registry-Hack“ vorstellt um die Einstellungen manuell60 vorzunehmen.
”
Um die Einwahl auf einem völlig unbedarften Image zu starten, sind die nachfolgend aufgeführten Schritte notwendig. Sie werden im nächsten Unterkapitel
genauer betrachtet. Die Aufzählung richtet sich an den interessierten Entwickler, da es sich um ein programmiertechnisches Problem handelt. Wer noch nie
für Windows CE entwickelt hat, dem werden ein paar der verwendeten Begriffe
nichts sagen. Sie sind aber unter [GrBr01] nachlesbar.
1. Die Unimodem-Einträge in der Registrierdatenbank manuell auf brauchbare
Defaultwerte setzen.
2. Alle defaultmäßig verwendeten Initstrings aus der Registrierdatenbank entfernen.
3. Mit Hilfe von Befehlen der Telephony API“ (TAPI) nach nutzbaren Mo”
dems suchen.
4. Erzeuge in der Registrierdatenbank eine so genannte Location“, um das
”
Wahlverhalten61 zu beeinflussen. Dafür gibt es seitens Microsoft weder APIBefehle, Einstellungsboxen noch Dokumentation.
58
Diese Funktionalität lässt sich mit der von Dialern“ vergleichen. Ein Programm spricht ein
”
Modem vollautomatisch an um eine Einwahl zu starten.
59
Eine Suchmaschine, erreichbar unter http://www.google.de.
60
Da es weder einen API-Aufruf, noch eine Klickbox“ im ControlPanel gibt.
”
61
Verwendung von Tonwahl oder Pulswahl, Länderprefixe in den Rufnummern und die Notwendigkeit von Amtsholungen.
46
5. Schreibe die notwendigen Init-Strings des Modems manuell in die Registrierdatenbank.
6. Fülle eine RASENTRY-Datenstruktur aus und sende sie an das Betriebssystem. Sie enthält Informationen über das beim Verbindungsaufbau zu verwendende Modem und die zu wählende Rufnummer.
7. Fülle eine RASDIALPARAMS-Datenstruktur aus und registriere sie im Betriebssystem. Über sie werden der Loginname und das Passwort zur Authentifizierung am Provider eingestellt.
8. Starte die Einwahl über den API-Aufruf RasDial(). Dieser schlägt beim
Setzen der PIN bei Verwendung eines Siemens MC35I“ immer fehl, da
”
sich das Modem beim PIN-Setzen erst intern initialisiert und für mehrere
Sekunden blockiert. In dieser Zeitspanne läuft RasDial() in einen Timeout
und bricht ab. Mehr dazu auf Seite 49.
9. Überwache die Einwahl und die aufgebaute Verbindung über den Mechanismus der Window-Messages“.
”
10. Nutzung der aufgebauten Verbindung. Die notwendigen Einstellungen zum
Nameserver und zum Standardgateway werden automatisch gesetzt.
11. Beenden der Verbindung über den API-Aufruf RasHangUp().
4.3.2
Die einzelnen Schritte im Detail
Die im vorangegangenen Abschnitt genannten Schritte werden nun im Detail
betrachtet. Es wird speziell auf die Anwendung der Befehle eingegangen.
1. Den Unimodem-Eintrag anpassen
Wenn man unter Microsoft Windows CE. NET 4.1 eine Internetverbindung
über ein Modem aufbauen möchte, wird die Konfiguration dieses Modems
dem so genannten Unimodemeintrag entnommen. Dies ist eine Ansammlung von Parametern, die in der Registrierdatenbank unter dem Schlüssel
HKLM62 \Drivers\Unimodem zu finden sind. Der erste Unterschlüssel unter
\Settings\ enthält eine Reihe von Schlüssel-Werte-Paaren mit AT-Kommandos. Sie werden dazu verwendet das Modem zu resetten (ATZ) oder um
eine Einwahl zu starten (ATD). Der zweite Unterschlüssel \Init\ enthält
eine Reihe von Initstrings, die vor einer Einwahl der Reihe nach an das
Modem gesendet werden. Hier muss sichergestellt werden, dass die geforderten Einträge überhaupt in der Registrierdatenbank existieren und dass
sie auf brauchbare Werte gesetzt sind. Man muss dabei direkt die Regierdatenbank manipulieren, da es keine API-Kommandos zum Zugriff auf den
Unimodem-Eintrag gibt.
62
HKLM ist die gebräuchliche Kurzform für HKEY_LOCAL_MACHINE .
47
2. Alle Initstrings entfernen
Bevor eigene Initstrings in die Registrierdatenbank geschrieben werden, sollten alle bereits existierenden Einträge entfernt werden. Sonst kann es passieren, dass bereits mehrere Einträge exisitieren und diese nicht komplett
von den eigenen Initstrings ersetzt werden. Es ist daher sehr wichtig, in
einem ersten Schritt alle Altlasten unter HKLM\Drivers\Init\ zu entfernen. Um ganz sicher zu gehen, dass das System nicht negativ beeinflusst
wird, hinterlegt man einen leeren“ Initstring. Dafür bietet sich das neu”
trale AT-Kommando AT<CR> an. Wie man sieht, müssen Initstrings in der
Registrierdatenbank um die Zeichenfolge <CR>63 ergänzt werden.
3. Suche nach ansprechbaren Modems
Für die spätere Einwahl benötigt man den Identifikationsstring des Modems. Erst mit seiner Hilfe kann des Betriebssystem erkennen, welches der
angeschlossenen Geräte für die Einwahl benutzt werden soll. Dieser Identifikationsstring muss genau bekannt sein und wird vor der Einwahl ermittelt.
Es gibt mehrere Funktionen in der Telephony API“, die man zur Suche
”
nach verfügbaren Modems nutzen muss. Einer davon lautet LineEnumerate(), welcher die Identifikationsstrings aller verfügbaren Schnittstellen
der Reihe nach zurückliefert. Man muss sich anschließend den richtigen aus
der übergebenen Menge heraussuchen. Es gibt zwei Bedingungen, die der
potentielle Indentifikationsstring gleichzeitig erfüllen muss:
• Der String muss das Schlüsselwort Hayes“ enthalten.
”
• Der String muss die Schnittstelle, an der das Modem angeschlossen
ist, als Teilstring enthalten (Beispielsweise COM1“).
”
Die konkrete Anwendung der TAPI-Funktionen erweist sich als aufwendig. Sie erfordert unter anderem die Nutzung einer so genannten CallbackFunktion. Wenn man dieses ganze Beiwerk“ ignoriert, reduziert sich der
”
Aufwand auf die eben genannten Schritte.
4. Erzeugung einer neuen Location“
”
Dieser Abschnitt befasst sich mit dem schwierigsten Schritt, der zur Einwahl notwenig ist. Wenn man dem Betriebssystem befiehlt, eine bestimmte Telefonnummer anzuwählen, wird anhand noch weiterer Parameter der
Wahlstring für das Modem zusammengesetzt. Wünschenswert ist hierbei
der simple Einwahlbefehl ATDP (Pulswahl) direkt gefolgt von der zu wählenden Rufnummer, was aber in der Praxis leider so nicht funktioniert. Bei
ersten Experimenten wurde der Wahlstring durch mehrere vorangestellte
Nullen komplett unbrauchbar gemacht.
63
CR“ ist die Abkürzung für Carriage Return“, was so viel wie Wagenrücklauf bedeutet.
”
”
48
Die Einstellungen, die das interne Vorbereiten des Wählstrings steuern, sind
in der so genannten Location zusammengefasst. Sie befindet sich in Form
eines REG_MULTI_SZ-Datenfeldes in der Windows-Registrierdatenbank. Sie
ist über den Pfad HKCU64 \ControlPanel\Dial\Locations\ innerhalb der
Registrierdatenbank zu finden. Die einzelnen Parameter müssen nach einem
festgelegten Schema als Stringfeld codiert und in der Registrierdatenbank
abgespeichert werden. Folgende Parameter der Location beeinflussen das
Wahlverhalten:
• Entscheidung zwischen Pulswahl oder Tonwahl
• Wahl eines Länderprefix, der vor die Vorwahl angefügt werden soll
• Wahl einer Vorwahl, die vor die Rufnummer gebastelt werden soll
• Festlegung einer zu verwendenden Amtsholung
Es ist unbedingt sicherzustellen, dass für das Siemens-GPRS-Modem Pulswahl verwendet wird. Sonst wird das Modem nicht anfangen zu wählen.
Weiterhin sind alle anderen Funktionen und Optionen zu deaktivieren, damit der Programmierer die volle Kontrolle über die Bestandteile des Wahlstrings erhält.
Keine dieser Funktionen wurde von Microsoft dokumentiert. Der Autor fand
aber einen einzelnen Beitrag eines Microsoft-MVP65 in den Newsgroups. Er
beschreibt einen inoffiziellen Registry-Hack“. Ohne diesen Hinweis hätte
”
das Modem nicht in Betrieb genommen werden können.
5. Eigene Initstrings setzen
Die komplette Konfiguration des Modems erfolgt über AT-Kommandos,
die vom Betriebssystem in Form der Initstrings an das Modem gesendet
werden. Es sind insgesamt drei Initstrings notwendig, um alle notwendigen
Parameter an das Modem weiterzuleiten:
• Die Freischaltung der SIM-Karte über die PIN im ersten Initstring
• Die Definition des Packet Data Protocols“ (PDP-Kontext) im zweiten
”
Initstring
• Die Wahl der Quality of Service-“ (QoS-) Parameter im dritten Init”
string
Die Initstrings werden direkt in die Registrierdatenbank unter dem Pfad
HKLM\Drivers\Init\ abgelegt. Jeder Eintrag besteht aus einem Schlüssel-
64
HKCU ist die gebräuchliche Kurzform für HKEY_CURRENT_USER.
Microsoft zeichnet in Newsgroups besonders engagierte Privatleute mit dem Titel Most
Valuable Professional aus, um diese als wertvolle Mitglieder der Community“ zu kennzeichnen.
”
65
49
Wertepaar. Der Schlüssel besteht aus einer Zahl, welcher die Bearbeitungsreihenfolge der einzelnen Initstrings vorgibt. Der zugehörige Wert enthält
den Initstring als Zeichenkette.
Es gibt dabei ein Problem mit der Freischaltung des Modems durch die
PIN. Dieses Problem wird im späteren Abschnitt Die Einwahl starten“ auf
”
Seite 49 erläutert.
6. Einen Telefonbucheintrag erstellen
Als nächstes kommt das Ausfüllen einer RASENTRY-Datenstruktur an die
Reihe. Sie enthält Informationen über den Einwahlprozess:
• Die Verwendung von PPP (ISO/OSI-Schicht 2) einstellen
• Die Verwendung von IP (ISO/OSI-Schicht 3) aktivieren
• Auswahl des Modems über seinen Identifikationsstring
• Den Gerätetyp festlegen: Verwende die Konstante RASDT_Modem
• Übergabe der zu wählenden Telefonnummer
Anschließend wird die ausgefüllte Datenstruktur mit Hilfe des API-Kommandos RasSetEntryProperties() an das Betriebssystem gesendet.
7. Einen Providereintrag erstellen
Zur Anmeldung bei einem Provider ist in der Regel eine Authentifizierung
über einen Loginnamen und ein Passwort vorgesehen. Obwohl dies bei einer Einwahl ins Internet über GPRS nicht notwendig ist, muss trotzdem
der vorgesehene Mechanismus des Betriebssystems zur Einwahl beachtet
werden. Die notwenigen Parameter werden über eine so genannte RASDIALPARAMS-Datenstruktur dem Betriebssystem mitgeteilt. Sie enthält:
• Den Loginnamen (bei GPRS eine beliebige Zeichenfolge)
• Das Anmeldepasswort (ebenfalls eine beliebige Zeichenfolge)
• Eine Referenz auf eine gültige RASENTRY-Datenstruktur.
Die Aktivierung der ausgefüllte Struktur geschieht über den API-Befehl
RasSetEntryDialParams().
8. Die Einwahl starten
Der API-Befehl RasDial() startet die Einwahl des Modems und etabliert
eine PPP-Verbindung zum Provider. Als Parameter wird ihm eine Referenz
auf eine gültige RADDIALPARAMS-Datenstruktur übergeben. Danach wird innerhalb des Betriebssystems eine Kette von Ereignissen durchlaufen:
(a) Zurücksetzen des Modems
50
(b) Versendung aller Initstrings der Reihe nach an das Modem. Dazu gehört auch das Setzen der PIN.
(c) Starten der eigentlichen Einwahl
(d) Warten auf erfolgreiches Abschließen der Einwahl
(e) Einrichtung der PPP-Verbindung
(f) Übernahme der zugewiesenen IP-Adresse, der Adresse des zu verwendenden Nameservers und der Adresse des Standardgateways
Es gibt dabei ein Problem mit dem Setzen der PIN, wenn der dazu notwendige Befehl über einen Initstring an das Modem gesendet wird. Die
Bearbeitung des AT CPIN-Befehls durch das Modem dauert sehr lange (bis
zu zehn Sekunden), da hierbei auf eine Antwort des Mobilfunkproviders gewartet wird. Dadurch läuft aber RasDial() in einen Timeout, und bricht
die Einwahl mit einer Fehlermeldung ab. Der selbe Fehler tritt auch auf,
wenn die PIN bereits gesetzt wurde und der betreffende Initstring ein zweites Mal an das Modem gesendet wird. Auch hierbei schlägt die Einwahl mit
RasDial() fehl.
Das Problem wird dadurch gelöst, dass in einem ersten Schitt immer die
PIN in Form eines Initstrings an das Modem gesendet wird und RasDial()
dabei bewusst fehlschlägt. Anschließend wird das Kommando aus der Menge der Initstrings entfernt und die Einwahl ein zweites Mal gestartet. Dabei
wird dann nicht mehr versucht, die PIN zu setzen, sondern sofort mit der
Einwahl begonnen. Das Timeout-Problem tritt hierbei nicht mehr auf.
9. Die Verbindung überwachen
Der RasDial()-Befehl kann so parametriert werden, dass er im Hintergrund den Verbindungsaufbau und die anschließend aufgebaute Verbindung
überwacht. Immer wenn es dabei zu einer Statusänderung kommt, wird
eine so genannte Window-Message generiert und an einen zu spezifizierenden Window-Message-Handler übergeben. Dieser ist so implementiert,
dass er auf zwei spezielle Window-Messages reagiert (RASCS_Connected und
RASCS_Disconnected). Erstere wird immer dann ausgelöst, wenn eine Einwahl ins Internet erfolgreich war, die letztere wenn die Einwahl gescheitert
ist oder eine bereits laufende Sitzung getrennt wurde. Dabei kann nach
Bedarf sofort eine Wiedereinwahl veranlasst werden (über einen erneuten
Aufruf von RasDial()).
10. Die Verbindung auslösen
Der API-Befehl RasHangUp() trennt eine aufgebaute Verbindung. Das Betriebssystem kümmert sich intern um alle notwendigen Schritte, so dass an
dieser Stelle keine weiteren Aufräumkommandos notwendig sind. Der Befehl löst zusätzlich eine RASCS_Disconnected-Meldung aus. Dies muss beim
Entwurf des Window-Message-Handlers“ berücksichtigt werden.
”
4.4 Besonderheiten bei der Nutzung von GPRS
4.4
4.4.1
51
Besonderheiten bei der Nutzung von GPRS
Quality of Service
Der folgende Abschnitt behandelt die mit dem vorliegenden GPRS-Modem erreichbaren Datenraten. Die Leistungsfähigkeit einer Datenübertragungsstrecke
kann dabei durch verschiedene Merkmale charakterisiert werden:
• Datendurchsatz im Downlink
• Datendurchsatz im Uplink
• Paketverlustrate
• Laufzeit
• Laufzeitschwankungen
Es macht ein Unterschied, auf welcher Schicht66 der Tester die Benchmarks
ansetzt. Die Leistungsdaten für die GPRS-Schnittstelle brauchen nicht direkt
gemessen zu werden, denn sie sind schon in den Datenblättern67 zu GPRS aufgeführt68 .
Diese Daten geben aber nur begrenzt Auskunft über die auf höheren Schichten
erreichbaren Datenraten. Das GPRS-Kommunikationsmodul verwendet TCP/IP
als Kommunikationsprotokoll.
4.4.2
Die TCP/IP Problematik
Die in TCP/IP integrierten Mechanismen zur Fluss- und Staukontrolle wurden
ursprünglich für Netze mit kurzen Paketlaufzeiten und sehr geringen Übertragungsfehlerraten entworfen. TCP geht davon aus, dass Pakete nur dann verloren
gehen, wenn im Netz eine Stausituation vorliegt. TCP senkt daraufhin die Rate
der ausgesendeten Pakete, um den Engpass im Netz nicht zu verschärfen. Diese
Mechanismen funktionieren für Festnetze mit festen Endsystemen, jedoch nicht
mehr für das drahtlos arbeitende GPRS. Hier trifft TCP auf Paketlaufzeiten im
Sekundenbereich69 , und je nach gewählten QoS70 -Parametern auf Paketfehlerraten von bis zu 1 : 102 . TCP kann nun nicht mehr unterscheiden, ob die Pakete noch im Netz unterwegs sind oder durch einen Stau verworfen wurden. Viel
66
Schicht im Sinne des ISO/OSI Referenzmodells.
Bei GPRS entscheiden die wählbaren QoS-Parameter (Quality of Service) über die bereitgestellte Qualität des Dienstes. Sie sind unabhängig vom verwendeten Modem und Provider.
68
Siehe [Schi00] und [Siem01b] (Abschnitt QoS-Parameter).
69
Verzögerungsklasse 3: Der Erwartungswert der Übertragungsdauer einer 128 Bytes großen
SDU liegt bei 50 Sekunden. 95% der SDU’s werden innerhalb von 250 Sekunden ausgeliefert.
In der Praxis wird momentan sogar nur Klasse 4, also Best Effort, angeboten.
70
Quality of Service.
67
52
schlimmer ist, dass von Zeit zu Zeit wirklich Pakete verloren gehen. TCP wird
permanent mit einer scheinbar drohenden Stausituation konfrontiert. Es drosselt
die Datenrate, und versendet Paketwiederholungen um die Verluste zu kompensieren.
Ein TCP-Datenstrom benötigt eine gewisse Zeit, bis er die Kapazität eines
Übertragungskanals ausnutzt. TCP tastet sich nach und nach an höhere Datenübertragungsraten heran, bis erste Paketverluste auftreten71 . Die langen Paketlaufzeiten und die im Vergleich zu den Festnetzen hohen Verlustraten kollidieren
mit diesem Mechanismus, und verhindern, dass TCP den gegebenen GPRS-Datenkanal effektiv ausnutzt.
4.4.3
Nutzbare Datenraten
Die direkt mit TCP/IP erreichbaren Datenraten können mit Hilfe von FTP72
bestimmt werden. Dazu eignet sich ein Versuchsaufbau, der aus zwei Rechnern
besteht. Der erste Rechner ist direkt mit dem Internet verbunden73 . Auf ihm läuft
ein FTP-Server, der Dateien sowohl entgegennehmen als auch versenden kann.
Als Gegenstation kommt ein zweiter PC zum Einsatz, der sich über das GPRSModem in das Internet einwählt. Per FTP-Client wird von ihm aus die Datentransferrate zum FTP-Server auf dem ersten Rechner bestimmt. Zur Messung
der Geschwindigkeit eignet sich eine große Datei74 aus Zufallszahlen75 . Sie wird
im ersten Schritt vom Client auf den Server geschoben“, und im zweiten Schritt
”
wieder heruntergeladen. Dabei wird jeweils die Zeitspanne gemessen, die benötigt wird um die Datei komplett zu übertragen. Der im Test verwendete FTPClient zeigt die erreichte Datenübertragungsrate direkt an, was eine manuelle
Berechnung unnötig macht.
Erwartungsgemäß unterscheiden sich die Datentransferraten in beiden Fällen. Der Uplink des GPRS-Modems weist eine geringere Datenübertragungsrate
als der Downlink auf. Der Grund liegt im geplanten Einsatzgebiet des GPRSModems, denn für die normale Internetnutzung ist die Datenrate des Downlinks
wichtiger als der Uplink. Die per FTP gemessenen Raten lauten:
Diese Angaben entsprechen den für das GPRS-Kommunikationsmodul verfügbaren Datenraten. Im Bezug auf das Hochbehälterproblem wäre eine umgekehrte
Verteilung der Datenraten für Up- und Downlink wünschenswert. Die meisten
Daten werden auf der Station erzeugt, und über den Uplink des GPRS-Modems
71
Diese Form der Staukontrolle wird als Slow-Start-Mechanismus“ bezeichnet. Siehe [Schi00].
”
File Transfer Protocol.
73
Dies ist im vorliegenden Fall ein handelsüblicher PC, der sich über ein DSL-Modem mit
dem Internet verbindet.
74
Die Testdatei ist 524288 Bytes groß.
75
Durch die Verwendung von Zufallszahlen wird verhindert, dass an den Übertragungsschnittstellen eine Datenkompression durchgeführt wird. Sie würde zu einem zu optimistischen Ergebnis führen. Die Datei wurde im Test durch den Unixbefehl dd if=/dev/urandom
”
of=./ftp.dat bs=1K count=512“ erzeugt.
72
4.4 Besonderheiten bei der Nutzung von GPRS
53
Datenrichtung der Belastung Dauer
Datenrate
GPRS-Uplink
404 Sekunden 1,3 KB/s
GPRS-Downlink
79 Sekunden 6,5 KB/s
Tabelle 2: Datenraten mit GPRS
an die Leitstation versendet. Da aber bei GPRS ein zeitunabhängiger Tarif zum
Einsatz kommt, entstehen durch die geringe Datenrate im Uplink keine finanziellen Nachteile. Es dauert nur entsprechend lange.
54
5
5.1
5 VERSUCHSAUFBAU UND VERWENDETE HARDWARE
Versuchsaufbau und verwendete Hardware
Aufbau des Netzwerkes
Alle die Studienarbeit umfassenden Aufgaben wurden vom Autor in Heimarbeit
durchgeführt. Daher musste zuerst geprüft werden, welche Komponenten benötigt
werden um jeden Testfall abdecken zu können. Es stellte sich heraus, dass bis auf
die Beckhoff-Station und der GPRS-Anbindung bereits alle notwendige Hardware
vorhanden war.
Als Entwicklungsumgebung kommt ein handelsüblicher PC zum Einsatz. Der
Internetzugang erfolgt über einen weiteren PC, der als Router konfiguriert wurde
und mit einem DSL-Modem ausgestattet ist. Die Beckhoff-Station wird ebenfalls
an den Router angeschlossen und ist somit Bestandteil des lokalen Netzwerkes.
GPRS−Internetzugang
Dyn−IP
Dyn−DNS
192.168.1.3
Embedded PC
Internet
DSL
Dyn−IP
Dyn−DNS
Gateway
Firewall
192.168.1.1
192.168.1.2
Dyn−DNS−Server
Entwicklungsrechner
"Leitstation"
Abbildung 22: Aufbau der Entwicklungs- und Testumgebung
Es müssen gleichzeitig auf dem Beckhoff-PC laufende Programme getestet
werden und eine Verbindung ins Internet bestehen. Die einfachste Lösung für so
etwas sind mehrere Netzwerkkarten im Hauptrechner, aber er wies keine freien
PCI-Steckplätze mehr auf. Also wird diese Aufgabe einem externen Router (der
bereits vorher diese Aufgabe übernahm) übertragen. Das ist keineswegs nur eine
Notlösung, sondern bringt viele Vorteile mit sich. Der Router übernimmt gleichzeitig Aufgaben als Internetzugangspunkt, Firewall und Netzwerkmonitor. Über
den Microsoft Windows 2000-PC hätte man diese Aufgaben nur mit wesentlich
größerem Aufwand hinbekommen können, wenn überhaupt.
Wichtig ist auch die Praxisrelevanz der gewählten Struktur. Im späteren Einsatz wird die Leitstation mit großer Wahrscheinlichkeit über ein Gateway im
5.2 Der embedded PC
55
lokalen Netz ins Internet gelangen. Wird im Testaufbau die Debugging-Verbin”
dung“ (Ethernetstrang) zwischen Router und Beckhoff-Station entfernt, erhält
man genau diese Netzwerkstruktur.
Eine der Hauptaufgaben dieser Studienarbeit bestand darin, ein GPRS-Modem auf dem Beckhoff-PC in Betrieb zu nehmen. Der Datentransfer soll direkt zur
Leitstation erfolgen. Die folgende Abbildung zeigt den Weg, den ein Datenpaket
auf seiner Reise vom Beckhoff-PC zur Leitstation gehen muss:
DSL−Internetprovider
NIC
Entwicklungsumgebung
NIC
NIC
Gateway
Firewall
DSL−Modem
Internet
Dyn−DNS−Server
Embedded PC
Modem
Antenne
BSS
SGSN
GGSN
GPRS−Provider
Abbildung 23: Weg des Datentransfers über GPRS
Das Paket wird über das GPRS-Modem ins Internet geschickt. Sein Ziel ist die
Leitstation, die über den Router ebenfalls mit dem Internet verbunden ist. Das
Paket erreicht den Router, und wird zur Leitstations-Software auf dem ArbeitsPC weitergeleitet.
5.2
Der embedded PC
Als Automatisierungsstation kommt ein embedded PC der Firma Beckhoff zum
Einsatz. Er basiert auf einem Pentium MMX76 kompatiblen Prozessor mit 266
MHz Taktfrequenz. Er wird in der vorliegenden Ausführung77 mit internen 128
MB Arbeitsspeicher geliefert. Als Betriebssystem kommt Microsoft Windows CE
.NET 4.1 zum Einsatz, welches in Form eines Images“ auf einer Compact-Flash”
Karte vorliegen muss. Sie hält 128 MB an nichtflüchtigem Speicher, und bietet
genügend Platz zur persistenten Ablage eigener Daten. Über den integrierten
RJ45 Ethernetanschluss kann direkt mit der Station gearbeitet werden. Das besagte GPRS-Modem, ein Siemens MC35i78 , wird über einen seriellen Anschluss
76
MMX: Multimedia Extensions.
Ein Beckhoff CX1001-0011.
78
Die technischen Daten des Modems befinden sich in Anhang A auf Seite 69.
77
56
(RS232) an den Beckhoff-PC angeschlossen. Des Weiteren war die vorliegende
Station mit diversen analogen und digitalen Eingängen bestückt. Sie waren für
die anstehenden Aufgaben allerdings belanglos. Sie werden bei Bedarf von der
auf der Station laufenden Soft-SPS ausgelesen und weiterverarbeitet. Die SoftSPS konnte nicht getestet werden, da die von der Firma Beckhoff mitgelieferte
Bediensoftware ( TwinCAT“) nicht mit der Hardware des Hauptrechners kom”
patibel war. Die Software benötigt systemnahen Zugriff auf spezielle Timer, was
in der aktuellen Implementierung nur auf Prozessoren ohne Unterstützung für
symmetrisches Multithreading79“ (SMT) möglich ist. Es gibt einen Patch, der
”
die SMT-Routinen des Betriebssystems deaktiviert80 , aber für das vorliegende
Zweiprozessorsystem gibt es überhaupt keine Hoffnungen das Programm zum
Laufen zu bewegen. Es ist nicht bekannt, ob Beckhoff für zukünftige Versionen
von TwinCAT auch die Unterstützung von SMP-Systemen ( Symmetrisches Mul”
tiprozessing“) plant.
5.3
Der PC: Entwicklungsumgebung und Leitstation
Der PC erfüllt eine Vielzahl von Aufgaben. Sein wichtigstes Einsatzgebiet ist die
Softwareentwicklung. Auf ihm laufen sämtliche Entwicklungsumgebungen, sowohl
um Programme für den embedded PC zu schreiben als auch für die Leitstation.
Der PC kann mit dem embedded PC gleichzeitig über LAN (zum Debuggen) und
über das Internet (zum Testen des GPRS-Datentransfers) kommunizieren.
Auch die Aufgabe der Leitstation wird von diesem PC übernommen. Die
dafür notwendige Software wird lokal gestartet und kann über den Router mit
dem sich per GPRS ins Internet einwählenden embedded PC Daten austauschen.
Der Verbindungsaufbau kann dabei sowohl vom embedded PC als auch vom PC
aus erfolgen. Da jeweils verschiedene IP-Adressen für die Adressierung innerhalb
des LAN’s und die Adressierung innerhalb des weltweiten Internet verwendet
werden, kommt es zu keinen Problemen mit der Wegewahl.
Die technischen Daten entsprechen denen eines handelsüblichen PC’s:
• Workstation-PC, Dual Athlon MP 2000+, 512 MB Arbeitsspeicher
• Betriebssystem Microsoft Windows 2000 oder SuSE Linux 8.2
• Embedded Visual Studio .NET mit Embedded Visual C++
• Visual Studio .NET mit C++ .NET
• Visual Studio C++ 6.0
79
Bei Intel-Prozessoren auch unter dem Begriff Hyper Threading“ bekannt.
”
Dies gilt dann allerdings global für alle auf dem System laufenden Anwendungen und macht
den Vorteil vom SMT komplett zu nichte.
80
5.4 Der Router / Gateway
57
• Über den dynamischen DNS-Eintrag powerstation.dyn.l13.de erreichbar.
5.4
Der Router / Gateway
Die genaue Bezeichnung dieser Komponente gestaltet sich schwierig. Es soll sich
hier nicht an Begriffen wie Router oder Gateway festgebissen, sondern die geforderten Funktionen und deren Umsetzung erläutert werden. Dieser Rechner wird
im Folgenden als Router“ bezeichnet, auch wenn dies technisch nicht immer ganz
”
korrekt sein mag.
Als Plattform für den Router fiel die Wahl auf einen seit Jahren ausrangierten
PC, der für die Aufgabe als kombinierter Einwahlserver, Firewall und Router
geeignet ist. Die technischen Daten der verwendeten Hardware lauten:
• Pentium 90 Prozessor, 72 MB RAM
• Drei Fast Ethernet Netzwerkkarten81 vom Typ Intel EtherExpress 100
• Anbindung an das Internet über ein externes DSL Modem
Als Betriebssystem kommt ein minimales Linuxsystem ohne grafische Oberfläche zum Einsatz. Konkret handelt es sich bei der Distribution um ein Debian
Stable Release 1 (siehe [Debi]), mit dem zur Zeit aktuellsten verfügbaren Linuxkernel 2.6.4 (siehe [Linu]).
Embedded PC
NIC
192.168.1.3/24
Router
ETH2
192.168.1.1/24
DSL−
Modem
ETH0
Bridge
BR0
PPP0
192.168.1.1/24
ETH1
192.168.1.2/24
NIC
Arbeits−PC
Abbildung 24: Schaubild des Routers und seiner Umgebung
81
Network Interfaces, im Text kurz als NIC’s bezeichnet.
58
Die erste Netzwerkkarte dient zum Anschluss des DSL-Modems (Internetzugang), die beiden anderen führen jeweils über Crosslinkkabel zum embedded PC
und zum Arbeitsplatz-PC. Damit sich der embedded PC und der PC im Netz
gegenseitig sehen können, müssen sie sich im selben Subnetz befinden. Dieses
Problem wird durch den Mechanismus des Ethernet-Bridgings“ gelöst. Er fügt
”
die beiden Netzwerkkarten zu einem gemeinsamen Subnetz zusammen. Der Router kann von beiden PC’s aus über die interne IP-Adresse 192.168.1.1 erreicht
werden.
Die zweite Aufgabe des Routers ist die Maskierung der nur lokal gültigen IPAdressen beim Zugriff auf Ressourcen des weltweiten Internet. Dieser Mechanismus lautet Masquerading“ (oder NAT für Network Address Translation“), und
”
”
lässt jegliche Anfragen des embedded PC’s oder des PC’s ins Internet so aussehen als würden sie vom Router stammen. Der Router besitzt durch die DSLAnbindung als einziger Rechner eine weltweit gültige IP-Adresse (abgesehen vom
Beckhoff-PC bei aufgebauter GPRS-Verbindung).
Mit den mitgelieferten Werkzeugen wird auch ein Paketfilter realisiert. Ohne dieses Hilfsmittel ist es kaum möglich, mit dem Windows 2000 Rechner si”
cher82“ im Internet zu arbeiten. Wie die jüngste Vergangenheit gezeigt hat, reichen schon wenige Minuten Internetverbindungen aus, um sich Schädlinge wie den
Blasterwurm einzufangen. Durch die aktivierte Firewall können keinerlei Anfragen aus dem Internet den Windows 2000 Rechner erreichen. Wird dieses jedoch
gewünscht, können einzelne Ports selektiv freigegeben und an den PC gefor”
wardet83“ werden. Erst dieser Mechanismus erlaubt es, dass im Testaufbau vom
embedded PC Daten über das GPRS-Modem an den PC versendet werden können. Die Daten werden an die weltweit gültige IP-Adresse des Routers adressiert,
und kommen dann über die DSL-Schnittstelle bei diesem an. Er erkennt anhand
der verwendeten TCP-Portnummer den Verwendungszweck und kann den Datenstrom transparent an den PC im internen Netz weiterleiten ( Portforwarding“).
”
In umgekehrter Richtung funktioniert der Mechanismus genauso.
Das vollständige Script bridge-up, welches die hier vorgestellten Funktionen
auf dem Router aktiviert, befindet sich in Anhang C.2 auf Seite 71.
Sehr hilfreich ist auch die Möglichkeit, einen Traffic-Monitor“ auf dem Router
”
einzusetzen. Sämtliche Datenströme laufen über den Router und können angezeigt werden. Hierfür eignet sich das Programm iptraf (siehe [IPtr02]), welches
dem Benutzer einen genauen Überblick über momentan den Router passierende Datenpakete liefert. Für Tests mit ein- und ausgehenden Verbindungen ins
weltweite Internet (an die über per GPRS erreichbare Station) ist diese Überwachungsmöglichkeit sehr nützlich.
82
Sicherheit ist jedoch keine binäre“ Eigenschaft, sondern vielmehr das Ergebnis einer sehr
”
langen Liste von Dingen, die nicht falsch gemacht werden dürfen.
83
Dieses wird über sogenanntes Destination NAT“, bei dem die Ziel-IP-Adresse umgebogen
”
wird, vom Router realisiert.
5.5 Dynamische DNS-Einträge
5.5
59
Dynamische DNS-Einträge
Sowohl der Router als auch der embedded PC bekommen bei der Einwahl ins
Internet vom Internetprovider eine dynamische IP-Adresse zugewiesen. Sie ändert
sich von Einwahl zu Einwahl. Damit sich die beiden PC’s dennoch finden können,
adressieren sie sich gegenseitig über ihre DNS-Namen und nicht über statische
IP-Adressen.
Es gibt diverse Anbieter, die diesen als Dyn-DNS Eintrag“ bezeichneten Ser”
vice anbieten. Der Autor hatte Glück, denn einer seiner Komilitonen betreibt
einen eigenen Nameserver. Es werden zwei DNS-Namen zur Verfügung gestellt.
Der Router ist über den Namen powerstation.dyn.l13.de und der embedded
PC über den Namen epc.dyn.l13.de erreichbar. Bei einer Verbindungstrennung
mit anschließender Wiedereinwahl übermittelt jede Station ihre neue IP-Adresse
an den Nameserver. Nach einer gewissen Synchronisationsdauer84 ist die neue IPAdresse für die anderen Stationen sichtbar. Die Synchronisationszeit liegt zwischen fünf und 15 Minuten. Danach ist der Datentransfer wieder möglich.
Die Synchronisationdauer kann aber durch einen Trick verkürzt werden. Jede Station kann die Absenderadressen einteffender Pakete auswerten, und einen
lokalen Zwischenspeicher zur Namensauflöung pflegen. Wird eine Station vom
Netz getrennt, schickt sie eine Hallo“-Meldung an alle potentiellen Kommunika”
tionspartner. Diese merken sich die Absenderadresse, und können mit ihr einen
Datentransfer vor Abschluss der Synchronisation der Nameserver (DNS) starten.
84
Jeder DNS-Eintrag hat eine gewisse Gültigkeitsdauer, um wiederkehrende Anfragen durch
topologisch nahe DNS-Server zwischenspeichern zu können.
60
6 SONSTIGE BETRACHTUNGEN
6
Sonstige Betrachtungen
6.1
6.1.1
Sicherheit
Offene Ports
Im Falle der GPRS-Anbindung wählt sich der embedded PC über das GPRSModem mit Hilfe des eingebauten PPP-Protokollstapels ins Internet ein. Der
Provider weist dieser Schnittstelle eine weltweit gültige IP-Adresse zu, und der
embedded PC wird Bestandteil des weltweiten Internet.
Hiermit sind viele Probleme verbunden, denn diese Anbindung ist keine Einbahnstraße. Jeder, der die IP-Adresse der Station kennt, kann ebenso wie jeder
autorisierte Nutzer auf IP-Ebene mit der Station kommunizieren. Daher ist es
unumgänglich, die Anzahl der auf der Station laufenden und global angebotenen
Dienste zu untersuchen und ggf. einzuschränken. Laufende Dienste sind immer
ein Sicherheitsrisiko, und man sollte nicht benötigte Dienste abschalten, um die
Möglichkeiten eines böswilligen Angriffes einzudämmen. Bevor man jedoch gegen eine Schwachstelle vorgehen kann, muss man wissen, ob überhaupt welche
vorhanden sind.
Als Werkzeug der Wahl bietet sich der freie Portscanner nmap85 an. Nmap ist
in der Lage, einen über IP erreichbaren Rechner auf laufende TCP- oder UDPDienste zu prüfen86 .
Die Ergebnisse sind erschreckend. Neben den unsicheren Diensten Telnet“
”
und FTP“ war nach außen hin Netbios (UDP) für jedermann offen und zugäng”
lich. Die Ergebnisse der Testdurchläufe sind in Anhang D, Seite 74, nachlesbar.
6.1.2
Firewall
Nach dem vorangegangenen Abschnitt über offenen Ports bei Windows CE 4.1
stellt sich die Frage was man dagegen tun kann. Es gibt prizipiell zwei Ansätze,
die verfolgt werden sollten:
1. Unbenötigte Dienste sind abzuschalten
2. Alle für das Internet unwichtigen Ports sind nach außen hin durch eine
Firewall zu schützen
Der erste Schritt erscheint logisch, lässt sich aber in der Praxis unter Microsoft Windows CE 4.1 nur schwierig bis gar nicht realisieren. Es geht schon mit
der Frage los, welche Dienste überhaupt als notwendig zu klassifizieren sind und
welche nicht. Telnet und FTP könnte man getrost deaktivieren. Bei ihrem Authentifizierungsmechanismus wandert das Passwort im Klartext über die Leitung,
was nicht tragbar ist. Aber wie deaktiviert man einen solchen Dienst?
85
86
Homepage unter http://www.insecure.org/nmap/ [Inse].
Weitergehende Informationen zu nmap sind in dessen Hilfen (Man-Pages) dokumentiert.
6.1 Sicherheit
61
Es konnte nicht herausgefunden werden, wo verzeichnet ist, welche Dienste
wann und wie in welcher Reihenfolge gestartet werden. Im ungünstigsten Fall ist
ein solcher Eingriff nur über nicht dokumentierte Schlüssel in der Registrierdatenbank möglich. Man erkauft sich einen solchen Schritt mit dem Risiko, dass
andere Dienste von Windows versteckt auf einen solchen Dienst aufbauen und
anschließend nicht mehr funktionieren. Hier ist noch weiteres Testen notwendig!
Der zweite Schritt sollte losgelöst vom ersten Schritt umgesetzt werden. Selbst
wenn alle unwichtigen Dienste deaktiviert werden können, ist ein zusätzlicher Paketfilter zu empfehlen. Er kann nicht nur die Nutzung lokaler Dienste vom externen Internet aus unterbinden, sondern auch den normalen“ Datenverkehr auf
”
gewisse Regeln hin überprüfen. Allerdings gibt es in Windows CE 4.1 keinerlei
eingebaute Möglicheiten eine Firewall oder einen Paketfilter zu aktivieren. Dieses
wichtige Feature steht erst mit der Nachfolgeversion Microsoft Windows CE 4.287
zur Verfügung. Da Version 4.2 noch nicht veröffentlicht wurde, kann hier keine
Aussage über die Leistungsfähigkeit der mitgelieferter Firewall gemacht werden.
Auch hier ist noch einiges zu tun, denn in der jetzigen Version ist es ein Risiko,
die Station über eine längere Zeitspanne am Internet zu betreiben. Die Wahrscheinlichkeit, dass ein Cracker im Internet zufällig über die Station stolpert88
und diese angreift, ist nicht zu vernachlässigen.
6.1.3
Nessus-Scan
Der Nessus-Scan“ ist ein Service, der ein an das Internet angeschlossenes System
”
nach Schwachstellen abklopft. Man kann ihn über ein Webformular (zu finden
unter [Port]) starten und bekommt nach Abschluss des Tests eine EMail mit den
Testergebnissen zugeschickt. Die Verwendung des Tests ist kostenlos. Es gibt drei
Testmodi, schnell, standard und intensiv. Sie unterscheiden sich untereinander in
Aufwand und Laufzeit. Zur Untersuchung des Beckhoff-PC’s wurde der Intensivtest gewählt.
Damit der Test auch mit dem vorliegenden Testaufbau durchführt werden
konnte, war eine Änderung der Konfiguration des Routers notwendig. Nur der
Router hängt per DSL direkt am Internet, und erhält als einziges eine globale
IP-Adresse. Sowohl der embedded PC als auch der PC haben selbst nur eine
lokale IP-Adresse, und können nicht direkt vom Nessus-Server“ gesehen werden.
”
Folgende Änderungen waren nötig:
• Router:
Der Router wird so konfiguriert, dass er sämtliche Anfragen aus dem In87
Laut Featureliste auf der Microsoft-Homepage, siehe Dokument [Micr].
Crackern steht heutzutage eine umfangreiche Sammlung von vollautomatischen und sehr
leistungsfähigen Werkzeugen zur Verfügung, während auf der anderen Seite meist Rechner
mit unsicheren Standardeinstellungen betrieben werden. Nmap ist ein solches Werkzeug, das
in der Lage ist eine ungeschütze Windows CE-Station aus einem gegebenen IP-Adresspool
herauszufischen.
88
62
ternet nicht lokal auswertet, sondern an den embedded PC im lokalen Netz
weiterleitet. Dieser als Port-Forwarding“ bekannte Mechanismus wird über
”
so genanntes Destination NAT89“ realisiert. Das Skript zur Konfiguration
”
der Interfaces und der Filterketten liegt in Anhang E.2 auf Seite 75.
• Embedded PC:
Auf dem embedded PC wird der Router als Standardgateway (hier: IPAdresse 192.168.1.1) eingetragen. So finden die Antworten an den NessusServer wieder den Weg zurück ins Internet (über den Router).
• Arbeitsplatz-PC:
Auf dem Hauptrechner ist keine Konfigurationsänderung notwendig. Er ist
lediglich der Initiator des Scanvorgangs. Der Test wird per Browser über
eine Webseite gestartet. Da alle lokalen IP-Adressen vom Router nach außen
hin maskiert werden, kommt es zu keinen Konflikten zwischen PC und
embedded PC. Der Scan wird vom Hauptrechner gestartet, betrifft aber
nur den embedded PC.
Laut Aussage auf der Homepage kann der Testlauf viele Stunden benötigen. Man
lässt ihn am besten über Nacht laufen. Das per EMail zugesendete Logfile befindet
sich in Anhang E.4 auf Seite 76.
Das Logfile offenbart eine Reihe an Schwachstellen. Genannt wird nochmals
die Unsicherheit von FTP“ und Telnet“, die auch schon vom einfachen Portscan
”
”
feststellt wurde. Andere Schwachstellen dagegen sind fest im Betriebssystemkern
angesiedelt (die vorhersagbaren IP-ID’s90 ) und nicht durch Eigeninitiative in den
Griff zu bekommen. Sie stellen laut der Angaben auf der Nessus-Homepage eine
bekannte Verwundbarkeit gegenüber existierenden Angriffen dar (siehe [Port]).
6.1.4
Fehlende Langzeiterfahrung, versteckte Lücken
Windows CE ist eine sehr junge Produktlinie der Firma Microsoft. Es handelt
sich dabei um eine von Anfang an neu programmierte Plattform für embed”
ded Devices“ und Handhelds“, die mit ihren großen Brüdern“ Windows 2000
”
”
bis Windows XP nur noch den Namen und die Grundprinzipien der grafischen
Oberfläche gemeinsam hat.
Es bleibt abzuwarten, ob hier noch gravierende Sicherheitsprobleme, die sich
erst im Laufe der Zeit durch breiten Praxiseinsatz zeigen, verborgen liegen.
• Die Codebasis von Windows CE ist noch jung und noch nicht im breiten
Einsatz. Noch kann niemand abschätzen (außer Microsoft selbst), welchen
89
Destination NAT: Änderung der Zieladresse eines Pakets beim Passieren des Routers, mit
de-Maskierung“ aller Antwortpakete in Rückrichtung.
” 90
Im Logfile des Nessus-Scan lautet es: The remote host uses non-random IP IDs, that is,
it is possible to predict the next value of the ip id field of the ip packets sent by this host. An
attacker may use this feature to determine traffic patterns within your network. [. . . ].
6.1 Sicherheit
63
Grad an Ausgereiftheit Windows CE besitzt. Fakt ist jedoch, dass Softwareentwicklung ein komplizierter Prozess ist, und sich Fehlerbehebung und
das Integrieren neuer Features gegenseitig ausschließen. Noch sind keine
Angriffspunkte bekannt, aber das liegt daran, dass Windows CE noch so
gut wie nirgends an die große weite Welt des Internet angeschlossen ist. Mit
wachsender Verbreitung wird es auch ein begehrteres Angriffsziel werden.
• Die Stationen lassen sich im späteren Einsatz nur schwierig auf einem aktuellen Stand halten. Dazu muss jedesmal ein Mitarbeiter vor Ort die Speicherkarten mit den Images austauschen. Das Ferneinspielen von Patches ist
nicht möglich.
6.1.5
Kostenpflichtige Luftschnittstelle
In dem Moment, wo sich die Beckhoff-Station über ihr Modem in das Internet
einwählt, erhält sie eine weltweit gültige IP-Adresse. Über diese ist sie in der Lage,
Daten mit Hilfe von IP-Paketen zu versenden und zu empfangen. Alle diese Pakete
bilden das Übertragungsvolumen, das die Station über die Luftschnittstelle überträgt. Da bei dem eingesetzten GPRS-Tarif kein zeitbasiertes Abrechnungsmodell
verwendet wird, dient das effektive Übertragungsvolumen als Abrechnungsgrundlage. Das ist brauchbarer Ansatz, da die Station somit rund um die Uhr im Netz
eingebucht bleiben kann und die Kosten direkt über das emittierte Datenvolumen
beeinflußt werden können.
Dieser Ansatz weist aber ein Problem auf, das den reinen Einwahlbetrieb in
seiner jetzigen Form gefährden kann. Der Grund liegt in der Art und Weise, wie
die Abrechnung bei der GPRS-Nutzung durchgeführt wird.
Alle an das Internet angeschlossenen Rechner sind prinzipiell gleichberechtigt
und können sich gegenseitig Datenpakete zusenden. Die Anbindung über GPRS
macht da keine Ausnahme. Jeder Rechner im Internet kann beliebig Daten an
den embedded PC versenden. Alle diese Daten wandern über die Luftschnittstelle
(den Downlink des embedded PC) und verursachen unerwünschtes und kostenpflichtiges Übertragungsvolumen. Solange der embedded PC online ist, kann er
sich in keiner Weise vor diesen Datenpaketen schützen. Selbst eine Firewall greift
erst auf höherer Ebene, wenn die Datenpakete bereits vollständig empfangen wurden. Im schlimmsten Falle schickt der Angreifer eine große Menge an sinnlosen
IP-Paketen ohne relevanten Inhalt. Sie werden zwar vom embedded PC verworfen, aber erst nachdem sie Kosten verursacht haben. Bereits ein DSL-Anschluss
mit dem geringsten erhältlichen Uplink kann einen Datenstrom erzeugen, der die
Kosten für die GPRS-Anbindung in erschreckende Höhen treibt.
Die folgende, noch optimistische91 Rechnung soll ein Gefühl für die potentielle
Schadenshöhe vermitteln:
91
Die Zahlen wurden abgerundet und können nach oben angepasst werden.
64
1. Der Angreifer verwendet einen gewöhnlichen DSL-Uplink mit 128 Kbit/s
2. Er emittiert einen Datenstrom von 10 KBytes/s
3. Der GPRS-Provider berechnet pro 10 KByte-Datenblock 9 Cent
∧
4. 9 Cent pro Sekunde = 324 EUR pro Stunde
Ein möglicher Lösungsansatz müsste schon vor der Luftschnittstelle auf Providerseite greifen. Wenn man dort eine Art Proxy verwenden könnte, der über
bestimmte Regeln nur valide“ Pakete zur Luftschnittstelle durchreicht, würde
”
man die Kontrolle über den kostenpflichtigen GPRS-Link zurückerlangen können.
Es war sehr zeitintensiv, diese Problematik einem Servicemitarbeiter der deutschen Telekom klarzumachen. Prizipiell gibt es dafür eine Lösung, die auf der Nutzung von so genannten Virtual Private Networks“ (VPN) basiert. Dabei kommt
”
ein Proxy zum Einsatz, der vor der Luftschnittstelle auf Providerseite arbeitet.
Er besitzt die volle Kontrolle über weiterzureichende Datenpakete. Er stellt sicher, dass nur Datenpakete von authentifizierten Absendern an den GPRS-Link
weitergeleitet werden, und niemand anders mehr die dargestellte Kostenexplosion
verursachen kann.
Dieses Feature“ wird als Zusatzoption angeboten, und ist bisher ausschließ”
lich für Businesskunden erhältlich. Privatkunden erhalten noch keinen Zugriff
auf dieses wichtige Hilfsmittel. Da die von der Firma bereitgestellte SIM-Karte
den Businesstarif nutzt, konnten weitere Informationen zu diesem Thema92 gesammelt werden. Es fand sich jedoch weder ein kundiger Mitarbeiter noch eine
Preisliste mit weiteren Aussagen zu diesem Thema. Es soll nur sehr teuer“ sein,
”
und eine spezielle Telekom-eigene VPN-Software voraussetzen. Ob es eine kompatible Client-Software für Microsoft Windows CE gibt, konnte nicht beantwortet
werden.
6.2
Zukunftsaussichten
Wichtig ist, dass baldmöglichst eine Firewall in das System integriert wird. Laut
den Produktankündigungen auf der Homepage von Microsoft wird die nächste
Version von Windows CE.NET, die Version 4.2, eine integrierte Firewall mitliefern. Es ist noch offen, wie leistungsfähig diese sein wird. Sie muss bei Erhalt
eines aktuellen Images getestet werden.
Eine weitere Möglichkeit liegt in der Verwendung eines externen Routers mit
integrierter Firewall. Allerdings wird es ein derart spezialisiertes Gerät nicht geben oder es wird sehr teuer sein. Solche Router“ sind aus der heutigen Fernseh”
werbung nicht mehr wegzudenken93 , erfüllen aber nicht den für das Projekt er92
93
Der Telekom-interne Begriff hierfür lautet IP-VPN“.
”
Sie werden zur Zeit recht günstig in Verbindung mit DSL-Tarifen angeboten.
6.2 Zukunftsaussichten
65
forderlichen Zweck. Er müsste ein externes Modem über eine serielle Schnittstelle
ansprechen können und mit GPRS-verwandten Mechanismen wie PIN-Nummern
zurecht kommen. Weitere Anforderungen sind eine integrierten Firewall und die
Möglichkeit diese auch konfigurieren zu können.
Auch muss sich jemand Gedanken um den Mechanismus des Abschaltens von
Diensten bei Microsoft Windows CE machen. Ein laufender Telnet-Dienst ist
nichts weiter als ein Sicherheitsrisiko94 . Von einer Verwendung über das Internet ist abzuraten. Es ist sinnvoll, wenn dieser Dienst“ abgeschaltet wird. Nur
”
dann kann er auch nicht missbraucht werden oder durch einen Softwarefehler die
Systemstabilität gefährden.
Das im letzten Abschnitt genannte Problem der kostenpflichtigen Luftschnittstelle sollte in Zukunft verfolgt werden. Es ist wahrscheinlich, dass hierfür in Zukunft Lösungen angeboten werden. Dazu muss das Problem aber zuerst in das
Bewusstsein der Anbieter rücken.
94
Es ist verständlich, dass Microsoft nun auch eine Schnittstelle zur Fernwartung anbieten
will. Wieso sich dabei allerdings für Telnet und nicht für das sicherere SSH entschieden wurde,
ist dem Autor ein Rätsel.
66
7
7 ZUSAMMENFASSUNG / ERREICHTE ZIELE
Zusammenfassung / erreichte Ziele
Im Rahmen der vorliegenden Studienarbeit wurden folgende Tätigkeiten durchgeführt:
• Untersuchung und Inbetriebnahme eines GPRS-Modems vom Typ Siemens
MC35i.
• Ansteuerung des Modems unter Windows CE .NET 4.1 mit Hilfe der Programmiersprache embedded Visual C++“.
”
• Entwurf eines modularen Kommunikationsmodells.
• Implementierung eines Kommunikationsmoduls zur Anbindung an GPRS.
• Implementierung eines Kommunikationsmoduls zur Anbindung an Ethernet.
• Entwicklung eines funktionierenden Prototyps. Er sollte mit GPRS arbeiten
und die modulare Kommunikationsstruktur umsetzen.
Untersuchung des GPRS-Modems Das Modem ließ sich mit Hilfe der bei
Analogmodems verbreiteten AT-Kommandos ( Hayes Befehlssatz“) ansprechen.
”
Dies erleichterte die Inbetriebnahme sehr. Es brauchten nur wenige GPRS-spezifische Anpassungen in den Einstellungen des Betriebssystems vorgenommen zu
werden, um eine Internetverbindung aufzubauen. Das Modem wurde komplett
über Initstrings parametriert. Es wurde gezeigt, dass zur Einwahl die selben
Schritte wie bei einer Einwahl mit Analogmodems verwendet werden können.
An manchen Stellen traten aber Probleme auf. Die Freischaltung des Modems
über seine PIN machte Probleme, was aber gelöst werden konnte.
Ansteuerung des Modems aus einem Programm heraus Es wurde ein
Programm geschrieben, welches die zur Einwahl über GRPS notwendigen Schritte komplett umsetzte. Das Programm ist in der Lage, auf einem unbehandelten“
”
System (ein Image im Originalzustand) eine Einwahl zu starten, die Verbindung
zu überwachen und zu nutzen. Die erstellten Klassen wurden modular strukturiert, um eine Wiederverwertung einzelner Bestandteile zu gewährleisten. So
konnte zusätzlich mit wenigen Programmzeilen eine Klasse für Analogmodems
abgeleitet werden. Sie nutzt die selben Komponenten, die vorher für die GPRSKlasse erstellt wurden. Die Datenübertragung nach aufgebauter Verbindung wurde über den Socket-Mechanismus (TCP/IP) des Betriebssystems abgewickelt.
67
Modulares Kommunikationsmodell Die zur Kommunikation notwendige
Funktionalität wurde in zwei Schichten getrennt. Ein Kommunikationsmanager
dient auf jeder Station als Ansprechpartner zur Datenübertragung. Informationen
werden vom ihm in Form von Dateien transparent übertragen. Er bedient sich
hierfür seinen Kommunikationsmodulen. Sie sind jeweils auf ein einzelnes Medium zugeschnitten und verbergen die medienspezifischen Eigenschaften vor dem
Kommunikationsmanager. Dadurch wird ein paralleler Betrieb mehrerer Kommunikationswege ermöglicht. Praxisrelevant war hierbei die Unterscheidung in einen
Haupt- und einen Backuplink.
GPRS-Kommunikationsmodul Ein weiteres Kommunikationsmodul wurde
zur Nutzung von GPRS erstellt. Es war in der Lage, ein Modem vom Typ Sie”
mens MC35i“ anzusprechen. Eine Verbindungsüberwachung mit sofortiger Wiedereinwahl bei Verbindungsabriss wurde integriert. Das Problem der sich bei jeder
Einwahl ändernden IP-Adressen wurde durch Nutzung dynamischer DNS-Einträge gelöst.
Ethernet-Kommunikationsmodul Für die Anbindung der Leitstation wurde
ein Kommunikationsmodul zur Nutzung von Ethernet erstellt. Mit ihm konnte
der Kommunikationsmanager der Leitstation über einen Router mit den verteilten
Stationen sprechen. Ein Datentransfer konnte mit einem anderen Ethernetmodul
oder dem GPRS-Modul erfolgen.
Prototyp Zur Demonstration des Datentransfers wurde ein Prototyp erstellt.
Als Testaufbau kam ein embedded PC der Firma Beckhoff zum Einsatz, der
sich über ein GPRS-Modem ins Internet einwählte. Als Kommunikationspartner
( Leitstation“) kam ein handelsüberlicher PC zum Einsatz. Er war Bestandteil
”
eines lokalen Netzwerkes (LAN) und über einen DSL-Router mit dem Internet
verbunden. Des Weiteren wurde noch ein Dyn-DNS-Server verwendet. Mit seiner
Hilfe konnten sich die beiden Stationen trotz sich bei jeder Einwahl ändernder
IP-Adressen gegenseitig ansprechen.
Die entworfene Modulstruktur diente als Basis für den Prototyp. Die Kommunikationsmanager wurden jedoch nicht vollständig implementiert. Zur Demonstration des Datentransfers wurden hier ein Echoserver und ein Echoclient eingesetzt. Der Echoclient kann über sein“ Kommunikationsmodul (Das GPRS-Modul
”
auf dem embedded PC) eine Ping“-Nachricht an die Leitstation versenden. Diese
”
wird dort vom Ethernet-Modul entgegen genommen und an den dortigen Kommunikationsmanager weiter geleitet. Hier wurde der Echoserver implementiert.
Er wertete das Ping“-Paket aus und verschickte ein Pong“-Paket an den Absen”
”
der. Dieses Paket kam wiederum am GPRS-Kommunikationsmodul des BeckhoffPC’s an und wurde vom dortigen Echoclient entgegen genommen und angezeigt.
68
7 ZUSAMMENFASSUNG / ERREICHTE ZIELE
Am Prototyp konnten Störeinflüsse simuliert werden. Durch ein Abtrennen
der Antenne vom Modem wurde die Verbindung gekappt. Das Programm merkte
dies sofort und unterbrach die Versendung von Datenpaketen. Sie wurde erst nach
erfolgreicher Wiedereinwahl fortgesetzt.
Ergebnis Die gestellten Aufgaben wurden bis zur gewünschten Ausbaustufe
erfüllt. Die Nutzung von GPRS ist mit den erstellten Programmen möglich. Die
dazu erforderlichen Programmteile lassen sich durch ihren modularen Charakter
aus dem Prototyp herauslösen und in das Hauptprojekt integrieren.
Die Datenübertragung über GPRS wurde anhand eines Prototyp gezeigt. Die
Daten gingen hierbei von einer abgesetzten Automatisierungsstation dank deren
GPRS-Anbindung über das Internet an einen per DSL angebundenen Router.
Dieser leitete die Daten an einen PC im lokalen Netzwerk weiter. Die dort laufende
Leitstations-Software nahm die Daten zur Auswertung entgegen und versandte
daraufhin Antwortpakete.
Parallel zur Anfertigung dieser Studienarbeit wurden bereits die Ideen zum
modularen Kommunikationsmodell in das Hauptprogramm integriert. Dabei wurden die nicht im Prototyp enthaltenen Protokolle des Kommunikationsmanagers
und der Kommunikationsmodule entwickelt. Im vorliegenden Beispiel wurde nur
eine Menge selbstdefinierter Testnachrichten versendet. Da gezeigt wurde, dass
die transparente Datenübertragung funktioniert, können selbst entwickelte Protokolle eingesetzt werden.
Das Thema Sicherheit“ muss in Anschluss an diese Studienarbeit genauer
”
verfolgt werden. Mit der nachfolgenden Version von Windows CE soll laut Microsoft erstmalig eine Firewall mitgeliefert werden. Diese muss getestet werden.
Aber auch das Problem der kostenpflichtigen Luftschnittstelle bei der Nutzung
von GPRS konnte noch nicht gelöst werden. Hierfür sind jedoch die Netzprovider
verantwortlich.
69
Anhang
A
Technische Daten: Modem Siemens MC35i
Abbildung 25: Bilder des Modems Siemens MC35i“
”
Detailliertere Daten findet man im Datenblatt unter [Siem03].
• Dual-band EGSM900 and GSM1800
• GPRS multi-slot class 8
• GPRS mobile station class B
• Output Power at EGSM900: 2 W
• Output Power at GSM1800: 1 W
• Control via AT commands
• Supply voltage range: 8 . . . 30 V
• Weight: 18 g
• Ambient temperature: −20◦ C . . . + 55◦ C
• CSD up to 14.4 kbps
• GPRS: max. 85.6 kbps (downlink)
• Coding scheme CS 1,2,3,4
• PPP-stack
• RS232 bi-directional
• 50 Ω antenna connector
70
B
B.1
B TARIFÜBERSICHT GPRS TARIFE
Tarifübersicht GPRS Tarife
T-D1 Tarife
Die Telekom bietet eine Vielzahl von GPRS-Tarifen an. Einige davon sind sogenannte Tarifoptionen, also nur Zusätze zu bereits bestehenden Mobilfunkverträgen. Der Businesstarif“ ein dagegen ein eigenständiger Tarif.
”
Im Laufe der Studienarbeit standen insgesamt zwei verschiedene Tarife zur
Auswahl. Die vielen anderen Tarifoptionen können auf der Telekom-Homepage
(siehe [Deut]) nachgelesen werden.
Die ersten Tests wurden vom Autor mit seiner eigenen SIM-Karte durchgeführt, wobei der T-D1-Tarif T-Mobile Data 1“ zum Einsatz kam. Später stand
”
seitens der Firma eine extra SIM-Karte mit dem BusinessData“-Tarif zur Verfü”
gung. Mit ihr wurden alle Tests mit höherem Transfervolumen durchführt.
Tarif
Tarifart
Monatlicher Grundpreis
(10-Sek.-Takt)
Bereitstellungspreis
T-Mobile Karte
GPRS: Monatliches
Inklusivvolumen
GPRS: Weitere Preise
Abrechnungseinheit
T-Mobile Data 1
Tarifoption
+ 4,95 EUR
(Option)
+ 0 EUR
(Option)
1 MB
BusinessData
Eigenständiger Tarif
12,85 EUR
0,09 EUR/10 KB
10 KB
1,59 EUR/1 MB
1 KB
21,51 EUR
5 MB
Tabelle 3: Tarifinformationen Telekom-D1
B.2
Vodafone Tarife
Die Tarife von Vodafone wurden zwar nicht genutzt, aber mit recherchiert und
eingefügt. Sie ermöglichen einen Vergleich. Auch hier wird eine große Auswahl an
verschiedenen Tarifen geboten, von denen aber nur diejenigen relevant sind die
einen Vergleich mit den T-D1-Tarifen erlauben. Die vollständige Tarifliste ist auf
der Vodafone-Homepage (siehe [Voda]) nachlesbar.
71
Tarif
Tarifart
Monatlicher Grundpreis
Bereitstellungspreis
(Aktivierung)
GPRS: Monatliches
Inklusivvolumen
GPRS: Weitere Preise
Abrechnungseinheit
Vodafone GPRS L Vodafone GPRS XL
Tarifoption
Tarifoption
+ 9,95 EUR
19,95 EUR
(Option)
(Option)
+ 4,95 EUR
4,95 EUR
(Option)
(Option)
1 MB
5 MB
0,29 EUR/100 KB
100 KB
0,255 EUR/100 KB
100 KB
Tabelle 4: Tarifinformationen Vodafone-D2
C
C.1
Konfiguration des Routers
Informationen zum Skript
Die gesamte lokale Netzwerkfunktionalität des verwendeten Testaufbaus wird zentral durch den Router gesteuert. Seine Konfiguration ist in dem folgenden Shellscript hinterlegt. Es wird automatisch nach jeder Einwahl ins Internet aufgerufen,
und konfiguriert alle Netzwerkinterfaces, die Bridge, den Paketfilter, das NAT95
und das Portforwarding.
Die einzelnen Funktionen des Routers werden in Abschnitt 5.4 auf Seite 57
erläutert, daher beschränkt sich der folgende Absatz nur auf das verwendete Konfigurationsskript.
C.2
Das Skript bridge-up
#!/bin/bash
# /etc/ppp/bridge-up
# Letze Aenderung am 09.12.2003
#
# Verwendete IP-Adressen
#
IP_BR0="192.168.1.1"
IP_ETH1="192.168.1.2"
IP_ETH2="192.168.1.3"
IP_NETMASK="255.255.255.0"
IP_BROADCAST="192.168.1.255"
IP_RANGE="192.168.1.0/24"
95
Network Address Translation, Adressumsetzung lokaler IP-Adressen auf eine global gültige
IP-Adresse.
72
C KONFIGURATION DES ROUTERS
#
# Verwendete Programme:
#
IPT=/sbin/iptables
IFC=/sbin/ifconfig
IFD=/sbin/ifdown
BRC=/usr/sbin/brctl
#
# Alles aufraeumen!
#
# Alle iptables-Eintraege zuruecksetzen
/etc/ppp/iptables-reset
# Eventuell bereits vorhandene Bridge entfernen
$IFC br0 down > /dev/null
$BRC delbr br0 >/dev/null
#
# Die Bridge neu aufsetzen
#
$IFD eth1
$IFD eth2
$IFC eth1 0.0.0.0
$IFC eth2 0.0.0.0
$BRC addbr br0
$BRC addif br0 eth1
$BRC addif br0 eth2
$IFC br0 $IP_BR0 broadcast $IP_BROADCAST netmask $IP_NETMASK
#
# Paketweiterleitungen aktivieren
#
# IP-Forwarding aktivieren
echo 1 >/proc/sys/net/ipv4/ip_forward
# Masquerading aktivieren
$IPT -A POSTROUTING -t nat -o ppp0 -j MASQUERADE
#
# Spoofing abwehren
#
# Nur Pakete mit validen Absenderadressen an den
$IPT -A PREROUTING -t mangle -i eth1 -s $IP_ETH1
$IPT -A PREROUTING -t mangle -i eth2 -s $IP_ETH2
# Nur nicht direkt an lokale Rechner adressierte
NIC’s akzeptieren
-j ACCEPT
-j ACCEPT
Pakete akzeptieren
C.2 Das Skript bridge-up
$IPT -A PREROUTING -t mangle -i ppp0 -s ! $IP_RANGE -j ACCEPT
#
# Die Weiterleitung von Paketen beeinflussen:
#
# Prinzipiell alle Pakete verwerfen/sperren!
$IPT -P FORWARD DROP
# Bridging erlauben
$IPT -A FORWARD -i br0 -o br0 -j ACCEPT
# Alle ausgehenden Pakete lokaler Rechner ins Internet akzeptieren
$IPT -A FORWARD -i br0 -o ppp0 -j ACCEPT
# Pakete von Aussen nur dann weiterleiten, wenn Sie Antworten auf
# Anfragen sind. Um dennoch Pakete von Aussen auf manchen Ports zu
# akzeptieren, sind weitere Regeln fuer die FORWARD-Kette notwenig
$IPT -A FORWARD -i ppp0 -o br0 -m state --state ESTABLISHED,RELATED
... -j ACCEPT
# Alle lokalen Dienste nach aussen hin verstecken,
# bis auf wenige Ausnahmen:
# 1.) Bereits aufgebaute Verbindungen
# 2.) Verbindungen an SSH : Port 22 von allen Hosts aus
# 3.) ICMP-Pakete (z.B. fuer Ping)
$IPT -P INPUT DROP
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p tcp --dport 22 -j ACCEPT
# SSH
$IPT -A INPUT -p icmp -j ACCEPT
# ICMP-Pakete
#
# Studienarbeit: Selektives Portforwarding an Beckhoff-Station
#
# TCP-Verbindungen, die aus dem Internet an Localhost:2000 ankommen,
# sollen an den PC an ETH1 (192.168.1.1) weitergereicht werden.
$IPT -A PREROUTING -t nat -i ppp0 -p tcp --dport 2000 -j DNAT
... --to $IP_ETH1
$IPT -A FORWARD -i ppp0 -o br0 -p tcp --dport 2000 -j ACCEPT
#
# Alles was noch uebrig ist...
#
# ICMP erlauben... etwas holprige Loesung
$IPT -A INPUT -j REJECT
# DynDNS-Datenbankeintrag fuer "Powerstation" aktualisieren
/usr/bin/wget -o /dev/null -O /dev/null
... ’http://dyn.l13.de/cgi-bin/dyndns.cgi?name=xxxx&pwd=yyyy&ip=auto’
73
74
D
D PORTSCANS: WINDOWS CE.NET 4.1
Portscans: Windows CE.NET 4.1
Die hier vorgestellten Logfiles sind das Ergebnis des in Abschnitt 6.1.1 auf Seite
60 beschriebenen Portscans. Ziel des Scans war die laufende Beckhoff-Station. Die
hier aufgeführten Ports sind offen“ und stammen vom Betriebssystem (Microsoft
”
Windows CE .NET 4.1) oder zusätzlich darauf laufender Software.
D.1
Ergebnisse des TCP/IP Portscans
# nmap (V. 3.00) scan initiated Sat Dec 20 20:32:53 2003 as:
nmap -v -sS -p 1-65535 -oN nmap_tcp.log 192.168.1.3
Interesting ports on (192.168.1.3):
(The 65528 ports scanned but not shown below are in state: closed)
Port
State
Service
21/tcp
open
ftp
23/tcp
open
telnet
80/tcp
open
http
443/tcp
open
https
987/tcp
open
unknown
5120/tcp
open
unknown
48898/tcp open
unknown
# Nmap run completed at Sat Dec 20 20:33:34 2003 -1 IP address (1 host up) scanned in 40 seconds
D.2
Ergebnisse des UDP/IP Portscans
# nmap (V. 3.00) scan initiated Sat Dec 20 20:33:45 2003 as:
nmap -v -sU -p 1-65535 -oN nmap_udp.log 192.168.1.3
Interesting ports on (192.168.1.3):
(The 65532 ports scanned but not shown below are in state: closed)
Port
State
Service
137/udp
open
netbios-ns
138/udp
open
netbios-dgm
48899/udp open
unknown
# Nmap run completed at Sat Dec 20 20:34:37 2003 -1 IP address (1 host up) scanned in 51 seconds
75
E
E.1
Nessus-Report: Windows CE.NET 4.1
Routerkonfiguration für Nessusscan
Für den im Laufe der Tests durchgeführten Nessus-Scan war die normale Routerkonfiguration aus Anhang C.2, Seite 71, nicht verwendbar. Geprüft werden sollte
der embedded PC, und nicht der direkt aus dem Internet sichtbare Router. Da
der Nessus-Scan von einem Server aus dem Internet durchgeführt wird, müssen
für die Dauer des Tests jegliche Anfragen aus dem Internet unverändert an den
Beckhoff-PC weitergeleitet werden. Des Weiteren müssen für die Dauer des Tests
jegliche Formen von aktiven Filterregeln deaktiviert werden. Sie hätten das Testergebnis verfälscht. Bei der späteren Einwahl ins Internet über GPRS weist der
embedded PC mit der aktuellen Windows CE Version auch keine Firewall auf.
Um die neuen Einstellungen zu aktivieren, braucht lediglich das folgende
Script einmal manuell bei bereits aufgebauter Internetverbindung gestartet zu
werden:
E.2
Das Skript nessus-up
#!/bin/bash
# /etc/ppp/nessus-up
# Letzte Aenderung am 15.01.2004
#
# Verwendete IP-Adressen
#
IP_BR0="192.168.1.1"
IP_ETH1="192.168.1.2"
IP_ETH2="192.168.1.3"
IP_NETMASK="255.255.255.0"
IP_BROADCAST="192.168.1.255"
IP_RANGE="192.168.1.0/24"
#
# Verwendete Programme:
#
IPT=/sbin/iptables
IFC=/sbin/ifconfig
IFD=/sbin/ifdown
BRC=/usr/sbin/brctl
#
# Alles aufraeumen!
#
# Alle iptables-Eintraege zuruecksetzen
76
E NESSUS-REPORT: WINDOWS CE.NET 4.1
/etc/ppp/iptables-reset
# Eventuell vorhandene Bridge entfernen
$IFC br0 down > /dev/null
$BRC delbr br0 >/dev/null
#
# Die Bridge neu aufsetzen
#
$IFD eth1
$IFD eth2
$IFC eth1 0.0.0.0
$IFC eth2 0.0.0.0
$BRC addbr br0
$BRC addif br0 eth1
$BRC addif br0 eth2
$IFC br0 $IP_BR0 broadcast $IP_BROADCAST netmask $IP_NETMASK
#
# Paketweiterleitungen aktivieren
#
# IP-Forwarding aktivieren
echo 1 >/proc/sys/net/ipv4/ip_forward
# Masquerading aktivieren
$IPT -A POSTROUTING -t nat -o ppp0 -j MASQUERADE
# Alle Anfragen aus dem Internet auf das an ETH2 angeschlossene
# Geraet (Dies ist der embedded PC, IP Adresse 192.168.1.3)
# weiterleiten.
$IPT -A PREROUTING -t nat -i ppp0 -j DNAT --to $IP_ETH2
E.3
Mitteilung des Testergebnisses
Da der Test über mehrere Stunden läuft (auf der Homepage des Nessus-Scans ist
je nach Netzanbindung und Firewallkonfiguration von einer maximalen Laufzeit
von 24 Stunden die Rede), wird das Ergebnis nach Ablauf des Tests per EMail
zugestellt. Eine Rückmeldung innerhalb des aufrufenden Browserfensters wäre
unsinnig, da der Nessus-Scan laut Dokumentation in der Lage sein soll ein ungeschütztes Microsoft Windows 98 System in wenigen Minuten zum Absturz zu
bringen.
E.4
Scanergebnis Nessus-Scan
Nessus Scan Report
This report gives details on hosts that were tested and issues that
were found. Please follow the recommended steps and procedures to
E.4 Scanergebnis Nessus-Scan
77
eradicate these threats.
Scan Details
Hosts which were alive and responding during test 1
Number of security holes found
1
Number of security warnings found
6
Host List
Host(s)
80.136.125.42
Possible Issue
Security hole(s) found
Analysis of Host
Address of Host Port/Service
80.136.125.42
ftp (21/tcp)
80.136.125.42
telnet (23/tcp)
80.136.125.42
www (80/tcp)
80.136.125.42
https (443/tcp)
80.136.125.42
unknown (987/tcp)
80.136.125.42
unknown (5120/tcp)
80.136.125.42
unknown (48898/tcp)
80.136.125.42
netbios-ns (137/udp)
80.136.125.42
general/udp
80.136.125.42
general/tcp
80.136.125.42
general/icmp
Issue regarding Port
Security hole found
Security warning(s) found
Security notes found
Security Issues and Fixes: 80.136.125.42
Type Port Issue and Fix
Vulnerability ftp (21/tcp) It is possible to force the FTP server
to connect to third parties hosts, by using the PORT command.
This problem allows intruders to use your network resources to
scan other hosts, making them think the attack comes from your
network, or it can even allow them to go through your firewall.
Solution : Upgrade to the latest version of your FTP server,
or use another FTP server.
Risk factor : Medium/High
CVE : CVE-1999-0017
Nessus ID : 10081
Warning ftp (21/tcp)
This FTP service allows anonymous logins. If you do not want to share
data
with anyone you do not know, then you should deactivate the anonymous
account,
since it may only cause troubles.
Risk factor : Low
CVE : CAN-1999-0497
78
Nessus ID : 10079
Informational ftp (21/tcp) An FTP server is running on this port.
Here is its banner :
220 Service ready for new user.
Nessus ID : 10330
Informational ftp (21/tcp) Remote FTP server banner :
220 Service ready for new user.
Nessus ID : 10092
Warning telnet (23/tcp) The Telnet service is running.
This service is dangerous in the sense that it is not ciphered - that
is,
everyone can sniff the data that passes between the telnet client
and the telnet server. This includes logins and passwords.
Solution:
If you are running a Unix-type system, OpenSSH can be used instead of
telnet.
For Unix systems, you can comment out the ’telnet’ line in
/etc/inetd.conf.
For Unix systems which use xinetd, you will need to modify the telnet
services
file in the /etc/xinetd.d folder. After making any changes to xinetd
or
inetd configuration files, you must restart the service in order for
the
changes to take affect.
In addition, many different router and switch manufacturers support
SSH as a
telnet replacement. You should contact your vendor for a solution
which uses
an encrypted session.
Risk factor : Low
CVE : CAN-1999-0619
Nessus ID : 10280
Informational telnet (23/tcp) A telnet server seems to be running on
this port
Nessus ID : 10330
Informational telnet (23/tcp) Remote telnet banner :
Welcome to the Windows CE Telnet Service on beckhoff
login:
Nessus ID : 10281
Informational www (80/tcp) A web server is running on this port
Nessus ID : 10330
Informational www (80/tcp) The remote web server type is :
Microsoft-WinCE/4.10
Solution : We recommend that you configure (if possible) your web
79
server to return
a bogus Server header in order to not leak information.
Nessus ID : 10107
Informational www (80/tcp) Nessus was not able to reliably identify
this server. It might be:
Zope/(Zope 2.5.1 (OpenBSD package zope-2.5.1p1)
The fingerprint differs from these known signatures on 7 point(s)
Nessus ID : 11919
Informational https (443/tcp) The service closed the connection after
1 seconds without sending any data
It might be protected by some TCP wrapper
Nessus ID : 10330
Informational unknown (987/tcp) This port was detected as being open
by a port scanner but is now closed.
This service might have been crashed by a port scanner or by a plugin
Nessus ID : 10919
Informational unknown (5120/tcp) A web server is running on this port
Nessus ID : 10330
Informational unknown (5120/tcp) The remote web server type is :
Microsoft-WinCE/4.10
Solution : We recommend that you configure (if possible) your web
server to return
a bogus Server header in order to not leak information.
Nessus ID : 10107
Informational unknown (5120/tcp) Nessus was not able to reliably
identify this server. It might be:
Zope/(Zope 2.5.1 (OpenBSD package zope-2.5.1p1)
The fingerprint differs from these known signatures on 7 point(s)
Nessus ID : 11919
Informational unknown (48898/tcp) The service closed the connection
after 0 seconds without sending any data
It might be protected by some TCP wrapper
Nessus ID : 10330
Warning netbios-ns (137/udp) The following 1 NetBIOS names have been
gathered :
BECKHOFF
The remote host has the following MAC address on its adapter :
0x00 0x01 0x05 0x00 0x35 0xc6
If you do not want to allow everyone to find the NetBios name
of your computer, you should filter incoming traffic to this port.
Risk factor : Medium
CVE : CAN-1999-0621
Nessus ID : 10150
Informational general/udp For your information, here is the traceroute
to 80.136.125.42 :
80
217.160.165.173
217.160.165.253
212.227.125.1
212.227.116.231
212.227.112.123
?
62.153.177.54
217.237.154.65
?
80.136.125.42
Nessus ID : 10287
Warning general/tcp
The remote host does not discard TCP SYN packets which
have the FIN flag set.
Depending on the kind of firewall you are using, an
attacker may use this flaw to bypass its rules.
See also :
http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
http://www.kb.cert.org/vuls/id/464113
Solution : Contact your vendor for a patch
Risk factor : Medium
BID : 7487
essus ID : 11618
Warning general/tcp
The remote host uses non-random IP IDs, that is, it is
possible to predict the next value of the ip_id field of
the ip packets sent by this host.
An attacker may use this feature to determine traffic patterns
within your network. A few examples (not at all exhaustive) are:
1. A remote attacker can determine if the remote host sent a packet
in reply to another request. Specifically, an attacker can use your
server as an unwilling participant in a blind portscan of another
network.
2. A remote attacker can roughly determine server requests at certain
times of the day. For instance, if the server is sending much more
traffic after business hours, the server may be a reverse proxy or
other remote access device. An attacker can use this information to
concentrate his/her efforts on the more critical machines.
3. A remote attacker can roughly estimate the number of requests that
a web server processes over a period of time.
Solution : Contact your vendor for a patch
Risk factor : Low
Nessus ID : 10201
Warning general/icmp
The remote host answers to an ICMP timestamp request. This allows an
attacker
to know the date which is set on your machine.
This may help him to defeat all your time based authentication
protocols.
Solution : filter out the ICMP timestamp requests (13), and the
outgoing ICMP
timestamp replies (14).
Risk factor : Low
CVE : CAN-1999-0524
Nessus ID : 10114
_________________________________________________________________
This file was generated by Nessus, the open-sourced security
scanner.
81
82
F KONFIGURATION DES MODEMS UNTER LINUX
F
Konfiguration des Modems unter Linux
F.1
Motivation
Die ersten Versuche mit dem GPRS-Modem wurden unter SuSE Linux 8.2 durchgeführt. Hier standen flexiblere Werkzeuge zum Einrichten und Analysieren von
Netzwerkgeräten zur Verfügung als unter Microsoft Windows 2000. Hierbei ging
es nur um das Herantasten an die Funktionsweise des Modems. Später wird das
Modem in einem Microsoft Windows-Umfeld eingesetzt.
Die Einrichtung des Modems unter SuSE Linux 8.2 war dank des mitgelieferten, grafischen Administrationstools (YaST296 ) problemlos. Jeder einzelne Schritt
wurde mit einem Bildschirmfoto dokumentiert. Im Bereich der Modemkonfiguration kommt der Programmierer mit GPRS-spezifischen Initstrings97 in Kontakt.
Ihre praktische Anwendung wird in Form dieser Bilder dokumentiert.
F.2
Bildschirmfotos von Yast2
1. Auswahl des Modems
Abbildung 26: Auswahl eines noch nicht konfigurierten Modems
96
Yet another Setup Tool.
Eine genaue Beschreibung der Bedeutung von Initstrings findet man in Abschnitt 4.2.2 auf
Seite 40.
97
F.2 Bildschirmfotos von Yast2
83
• Wähle den Eintrag für ein neues Modem“ aus der Liste aus, um dieses
”
nun zu konfigurieren.
2. Zuweisung der seriellen Schnittstelle
Abbildung 27: Zuweisung einer seriellen Schnittstelle
• Nennung die serielle Schnittstelle des Modems (hier: /dev/ttyS0)
• Impulswahl verwenden (ganz wichtig!) da Tonwahl vom GPRS-Modem
nicht unterstützt und damit ignoriert wird
• Lautsprecher aus, da irrelevant bei GPRS
• Kein Warten auf Wählton, da irrelevant bei GPRS
3. Details zu den Modemparametern
Abbildung 28: Konfiguration der Schnittstelle und der Initstrings
• Baudrate der seriellen Schnittstelle auf 115200 Baud setzen
84
F KONFIGURATION DES MODEMS UNTER LINUX
• Mit dem ersten Initstring die PIN übermitteln
• Mit dem zweiten Initstring den PDP-Kontext definieren
• Mit dem dritten Initstring die QoS-Parameter setzen
4. Internet-Service-Provider wählen
Abbildung 29: Auswahl eines neuen ISP’s
• Konfiguriere einen neuen Providereintrag
5. Internetverbindung konfigurieren
Abbildung 30: Konfiguration des Providers
F.2 Bildschirmfotos von Yast2
• Festlegung der Telefonnummer auf *99***1#
• Benutzername ist beliebig (Authentifikation über PIN)
• Passwort ist beliebig (Authentifikation über PIN)
6. Verbindungsparameter und DNS konfigurieren
Abbildung 31: DNS-Konfiguration
•
•
•
•
Dial-On-Demand deaktivieren
Nameserver dynamisch über PPP zuweisen lassen
Firewall deaktivieren
Kein Trennen der Verbindung bei Inaktivität (Bild falsch!)
7. Einstellungen zur IP-Adresse
Abbildung 32: IP-Konfiguration
• IP-Adresse dynamisch über PPP zuweisen lassen
• Automatisch über PPP zugewiesenes Standardgateway verwenden
85
86
G
G LOGFILE: INTERNETEINWAHL GPRS-MODEM
Logfile: Interneteinwahl GPRS-Modem
SuSE Meta pppd (smpppd-ifcfg), Version 1.00 on powerstation.
We are disconnected.
trying to connect to smpppd
connect to smpppd
We are connecting.
pppd: Plugin passwordfd.so loaded.
pppd: --> WvDial: Internet dialer version 1.42
pppd: --> Initializing modem.
pppd: --> Sending: AT+CPIN=xxxx
pppd: AT+CPIN=xxxx
pppd: OK
pppd: --> Sending: AT+CGDCONT=1,ip,internet.t-d1.de
pppd: AT+CGDCONT=1,ip,internet.t-d1.de
pppd: OK
pppd: --> Sending: ATM0
pppd: ATM0
pppd: OK
pppd: --> Sending: ATX3
pppd: ATX3
pppd: OK
pppd: --> Modem initialized.
pppd: --> Sending: ATDP*99***1#
pppd: --> Waiting for carrier.
pppd: ATDP*99***1#
pppd: CONNECT
pppd: ~[7f]}#@!}!}#} }9}"}&} }*} } }’}"}(}"}%}&[11]ew[14]}#}%B#}%5#~
pppd: --> Carrier detected. Waiting for prompt.
pppd: ~[7f]}#@!}!}#} }9}"}&} }*} } }’}"}(}"}%}&[11]ew[14]}#}%B#}%5#~
pppd: --> PPP negotiation detected.
pppd: Serial connection established.
pppd: Using interface ppp0
pppd: Connect: ppp0 <--> /dev/ttyS0
pppd: local IP address 80.187.93.228
pppd: remote IP address 192.168.254.254
pppd: primary
DNS address 193.254.160.1
pppd: Script /etc/ppp/ip-up finished (pid 7827), status = 0x0
We are connected.
We are disconnecting.
pppd: Terminating on signal 15.
We are disconnecting.
pppd: Connection terminated.
pppd: Connect time 5.8 minutes.
87
pppd: Sent 35715 bytes, received 87035 bytes.
pppd: Script /etc/ppp/ip-down finished (pid 7906), status = 0x0
pppd died: pppd received a signal (exit code 5)
88
H ABKÜRZUNGSVERZEICHNIS
H
Abkürzungsverzeichnis
API
Application Programming Interface
APN Access Point Name
AT
Attention, Hayes-Befehlssatz
BSS
Base Station Subsystem
CID
Context ID
COM1 Handle der ersten seriellen Schnittstelle unter Microsoft Windows
CRC Cyclic Redundancy Check
DLL Dynamic Linked Library (Dateiendung)
DNS Domain Name Service
DSL Digital Subscriber Line
EEPROM Electrically Eraseable Programmable Read Only Memory
EXE Executable (Dateiendung)
FEC Forward Error Correction
FTP File Transfer Protocol
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
HKCU HKEY CURRENT USER
HKLM HKEY LOCAL MACHINE
ICI
Interface Control Information
IDU
Interface Data Unit
IP
Internet Protocol
89
IPC
Inter Process Communication
ISDN Integrated Services Digital Network
ISO/OSI International Organization for Standardization / Open Systems Interconnection
ISP
Internet Service Provider
LAN Local Area Network
MAC Medium Access Control
Man-Page ‘Manual Page’, Hilfesystem unter Unix
MMQ Microsoft Message Queue
MMS Multimedia Messaging Service
MMX Multimedia Extensions
MVP Most Valuable Professional
NAT Network Address Translation
NIC
Network Interface
PCI
Peripheral Component Interconnect
PCI
Protocol Control Information
PDP Packet Data Protocol
PDU Protocol Data Unit
PIN
Personal Identification Number
PPP Point-to-Point Protocol
QoS
Quality of Service
RAS Remote Access Service
RegTP Regulierungsbehörde für Telekommunikation und Post
RPC Remote Procedure Call
SDU Service Data Unit
SGSN Serving GPRS Support Node
90
SIM
H ABKÜRZUNGSVERZEICHNIS
Subscriber Identity Module
SMP Symmetric Multiprocessing
SMS Short Message Service
SMT Symmetric Multithreading
SPS
Speicherprogrammierbare Steuerung
SSH
Secure Shell
TAPI Telephony API
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol/Internet Protocol
UDP User Datagram Protocol
URL Uniform Resource Locator
VPN Virtual Private Network
XML eXtended Markup Language
YaST Yet another Setup Tool
LITERATUR
91
Literatur
[Butt97]
Giorgio Buttazzo. Hard Real-Time Computing Systems, Predictable
Scheduling - Algorithms and Applications. Kluwer Academic Publishers. 400 Seiten, 3. Auflage, 1997.
[DAFU]
DAFU - Datenfunk Deutschland, http://www.dafu.de/redir/gprs.
html. GPRS - General Packet Radio Service. Allgemeine Informationen über GPRS, Übertragungstechnik: Verwendbare Coding Sche”
mes“, Zeitschlitze, erreichbare Übertragungsraten im Up- und Downlink.
[Debi]
Debian, http://www.debian.org. Debian GNU/Linux – Das universelle Betriebssystem. Homepage der Debian-Linux Distribution.
[Deut]
Deutsche Telekom AG, http://www.t-mobile.de. T-Mobile, Mobilfunk, Handy, SMS, MMS, GPRS. Homepage von T-Mobile. Tarifinformationen zu GPRS.
[GrBr01] Nick Grattan und Marshall Brain. Windows CE 3.0. Application
Programming. Prentice Hall. 508 Seiten, Microsoft Technologies Series. Auflage, 2001.
[Inse]
Insecure.org, http://www.insecure.org/nmap. Nmap - Free Security
Scanner for Network Exploration and Security Audits. Homepage des
freien Portscanners Nmap.
[IPtr02]
IPtraf, http://cebu.mozcom.com/riker/iptraf. IPTraf - An IP
Network Monitor, 2002. Homepage des IP-Netzwerkmonitors iptraf.
[KrRe02] Gerhard Krüger und Dietrich Reschke. Lehr- und Übungsbuch Telematik. Netze, Dienste, Protokolle. Fachbuchverlag Leipzig. 439 Seiten,
2. Auflage, 2002.
[Linu]
Linux, http://www.kernel.org. The Linux Kernel Archives. This is
the primary site for the Linux kernel source.
[Micr]
Microsoft, http://www.microsoft.com/windows/embedded/ce.net/
evaluation/whatsnew/featurecomp/default.asp. Feature-by-Feature Comparison: Windows CE .NET vs. Windows CE3.0. Vergleich
zwischen den Microsoft Windows CE Versionen 3.0, 4.0, 4.1 und 4.2.
15 Seiten.
[Port]
Port-Scan, http://www.port-scan.de. Port-Scan: Testen Sie Ihr
System bevor es andere tun. Wir wollen Ihnen helfen Ihren PC/ Ihr
”
Netzwerk sicherer zu machen“.
92
[Schi00]
LITERATUR
Jochen Schiller. Mobilkommunikation. Techniken für das allgegenwärtige Internet. Addison Wesley. 557 Seiten, 1. Auflage, 2000.
[Siem01a] Siemens AG, http://www.datek.no/Hardware/SiemensMC35/MC35_
gpr.pdf. MC 35 - Siemens Cellular Engine - GPRS Startup User
Manual, August 2001. Konfiguration des Modems MC 35 unter Windows NT 4.0, Konfiguration über Init-Strings, Einwahl in das Internet
über PPP, Test der Verbindung, QoS-Parameter. 15 Seiten.
[Siem01b] Siemens AG, http://www.datek.no/Hardware/SiemensMC35/AT_
Comma.pdf. MC 35 Siemens Cellular Engine - AT Command Set,
September 2001. Konfiguration eines Siemens GPRS-Modems über
AT-Kommandos. Vollständige Auflistung aller Kommandos und deren
Zweck. 184 Seiten.
[Siem03]
Siemens
AG,
http://www.datek.no/Hardware/SiemensMC35/
Datashee.pdf. Cellular Engine MC35 - The first GPRS module from
Siemens for mobile computing and multimedia, 2003. Technische
Daten zum Siemens MC35 GPRS Modem, 2 Seiten.
[SuSE]
SuSE Linux AG, http://www.suse.de. Willkommen bei SuSE LINUX. Homepage der SuSE-Linux Distribution.
[Voda]
Vodafone, http://www.vodafone.de. Vodafone-Live!, Foto-Handy,
MMS, Spiele, Klingeltöne. Homepage des Mobilfunkproviders Voda”
fone“. Tarifinformationen zu GPRS.
ABBILDUNGSVERZEICHNIS
93
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Eine Leitstation überwacht mehrere verteilte Stationen . . . .
Erreichbarkeit über eine Vermittlungsstation . . . . . . . . . .
Bilder der verwendeten Beckhoff-Station . . . . . . . . . . . .
Interner Aufbau einer Automatisierungsstation . . . . . . . . .
Protokollinformationen und -overhead nach ISO/OSI . . . . .
Versendung von Dateien: Kommunikationsmanager . . . . . .
Nutzung von Kommunikationsmodulen zur Datenübertragung
Vernetzung mehrerer Stationen über mehrere Dienste . . . . .
Priorisierte Warteschlange zum Dateiversand . . . . . . . . . .
Datenpaket innerhalb eines Kommunikationsmoduls . . . . . .
Allgemeine Interprozesskommunikation . . . . . . . . . . . . .
Ablauf der allgemeinen Interprozesskommunikation . . . . . .
Interprozesskommunikation mit Sockets . . . . . . . . . . . . .
Dienstschnittstelle des Kommunikationsmanagers . . . . . . .
Protokoll zwischen Kommunikationsmanagern . . . . . . . . .
Protokolle des Prototyp (Echoserver, Echoclient) . . . . . . . .
Vereinfachtes Schichtenmodell GPRS-Modem . . . . . . . . . .
Schema der externen Antenne . . . . . . . . . . . . . . . . . .
Konfiguration und Einwahl über AT-Kommandos . . . . . . .
Test verschiedener AT-Kommandos zur Einwahl . . . . . . . .
Zweimaliger Anruf des Modems aus dem Festnetz . . . . . . .
Aufbau der Entwicklungs- und Testumgebung . . . . . . . . .
Weg des Datentransfers über GPRS . . . . . . . . . . . . . . .
Schaubild des Routers und seiner Umgebung . . . . . . . . . .
Bilder des Modems Siemens MC35i“ . . . . . . . . . . . . . .
”
Auswahl eines noch nicht konfigurierten Modems . . . . . . .
Zuweisung einer seriellen Schnittstelle . . . . . . . . . . . . . .
Konfiguration der Schnittstelle und der Initstrings . . . . . . .
Auswahl eines neuen ISP’s . . . . . . . . . . . . . . . . . . . .
Konfiguration des Providers . . . . . . . . . . . . . . . . . . .
DNS-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . .
IP-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
8
8
10
13
14
15
15
24
29
31
31
34
35
35
37
39
40
42
43
44
54
55
57
69
82
83
83
84
84
85
85
94
TABELLENVERZEICHNIS
Tabellenverzeichnis
1
2
3
4
Wichtige AT-Kommandos . . .
Datenraten mit GPRS . . . . .
Tarifinformationen Telekom-D1
Tarifinformationen Vodafone-D2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
53
70
71
TABELLENVERZEICHNIS
95
Abschlusserklärung
Die vorliegende Arbeit habe ich selbständig ohne Benutzung anderer als der angegebenen Quellen angefertigt. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten Quellen entnommen wurden, sind als solche kenntlich gemacht. Die
Arbeit ist in gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer
oder anderer Prüfungen noch nicht vorgelegt worden.
Unterschrift

Technische Universität Ilmenau Fakultät für

Transcription

Similar documents

Vertiefungsarbeit - Drahtlose Internetzugänge

hotspot 32 hotspot 100

Architektur für flexible Paketverarbeitung in

Benutzerhandbuch

Software Design Patterns - Ereignisbearbeitung

Prädiktive Regelungen und Wetterprognosen in der

- hitec HANDEL

POWERLINKFacts 02/06

Einbau- und Bedienungsanleitung EB 6610

Installation des maxspot OS - maxspot®