Studienarbeit. GPRS-Kommunikationsmodul

Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Studienarbeit GPRS-Kommunikationsmodul vorgelegt von: Florian Evers verteidigt am: 23. 04. 2004 E-Mail Adresse: geboren am: Studiengang: Ingenieurinformatik Studienrichtung: Multimediale Informations- und Kommunikationssysteme Betreuer: Betrieblicher Betreuer: Prof. Dr. rer. nat. habil. Jochen Seitz Dr. Jan Rudorfer, Bei Firma: BN Automation AG Gewerbegebiet Am Wald 5a, 98693 Ilmenau

2 Zusammenfassung In der Wasserversorgungswirtschaft steht als häufiges Problem die kostengünstige Erschließung von räumlich verteilten Objekten (wie Regenüberlaufbecken oder Wasserzählschächten) zum Zweck der Überwachung und Datenerfassung an. Gewünscht wird eine laufende Prozessüberwachung mit der Mö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 später an eine übergeordnete Station übertragen werden. Diese Auswertung umfasst beispielsweise die Erkennung kritischer Systemzustände oder eine Mittelung über mehrere Messwerte im Sinne einer Datenreduktion. Als Übertragungstechnik bietet sich hierbei der mittlerweile quasi flächendeckend verfügbare, drahtlose Datenübertragungsdienst GPRS 1 an. Er kann mit Hilfe von handelsüblicher Hardware genutzt werden. Als erste Teilaufgabe gilt es ein GPRS-Modem 2 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 nächstes soll eine Modulstruktur entworfen und implementiert werden, die eine parallele Verwendung mehrerer verschiedener Kommunikationswege erlaubt. Die einzelnen Module sollen dabei über eine fest definierte Schnittstelle verfügen, damit sie transparent gegeneinander ausgetauscht werden können. Zu lösende Aspekte sind dabei das Verhalten im Fehlerfalle (Verbindungsabriss), die Behandlung von Prioritäten und die Anpassung der zu versendenden Daten an das Ü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 General Packet Radio Service, ein Mobilfunk-Datendienst. 2 Ein Modem vom Typ Siemens MC35i.

INHALTSVERZEICHNIS 3 Inhaltsverzeichnis 1 Vorwort 6 1.1 Über die Firma............................ 6 1.2 Das Hochbehälterproblem..................... 6 1.2.1 Die verteilten Stationen................... 8 1.2.2 Die Leitstation........................ 9 1.2.3 Die Aufgaben der Stationen im Detail........... 9 1.3 Aufgabe................................ 11 1.3.1 Situation vor der Arbeitsaufnahme............. 11 1.3.2 Aufgabenstellung....................... 11 2 Modulares Kommunikationsmodell 13 2.1 Schichtenmodelle........................... 13 2.2 Kommunikationsmodell........................ 14 2.2.1 Beteiligte Komponenten................... 14 2.2.2 Trennung in einzelne Module................ 16 2.2.3 Der Kommunikationsmanager................ 17 2.2.4 Die Kommunikationsmodule................. 19 3 Die einzelnen Module im Detail 22 3.1 Der Kommunikationsmanager.................... 22 3.1.1 Kommunikation über Dateien................ 22 3.1.2 Warteschlangen und Prioritäten............... 23 3.1.3 Fragmentierung / Reassemblierung............. 24 3.1.4 Datenbank für die Kommunikationsmodule......... 25 3.1.5 Wegewahl / Routing..................... 26 3.2 Die Kommunikationsmodule..................... 26 3.2.1 Anpassung an das Übertragungsmedium.......... 26 3.2.2 Telegrammdienst....................... 29 3.2.3 Quittierungen......................... 30 3.3 Interprozesskommunikation...................... 30 3.3.1 Kommunikation zwischen den Modulen........... 30 3.3.2 Mögliche Ansätze zum Datenaustausch........... 32 3.3.3 Interprozesskommunikation über Sockets.......... 33 3.4 Schnittstellen und Protokolle..................... 35 3.4.1 Schnittstelle oberhalb des Kommunikationsmanagers... 35 3.4.2 Protokoll zwischen Kommunikationsmanagern....... 35 3.4.3 Protokolle des Prototyp................... 36 4 Kommunikation über GPRS 39 4.1 Nutzerschnittstelle des GPRS-Modems............... 39 4.2 Inbetriebnahme des GPRS-Modems................. 39

4 INHALTSVERZEICHNIS 4.2.1 Die Hardware vorbereiten.................. 39 4.2.2 Testen des AT-Befehlssatzes................. 40 4.2.3 Konfiguration zur Einwahl in das Internet über PPP... 44 4.2.4 Test der aufgebauten Verbindung.............. 44 4.3 Windows CE.NET 4.1 und GPRS................. 45 4.3.1 Zur Einwahl notwendige Schritte.............. 45 4.3.2 Die einzelnen Schritte im Detail............... 46 4.4 Besonderheiten bei der Nutzung von GPRS............ 51 4.4.1 Quality of Service....................... 51 4.4.2 Die TCP/IP Problematik.................. 51 4.4.3 Nutzbare Datenraten..................... 52 5 Versuchsaufbau und verwendete Hardware 54 5.1 Aufbau des Netzwerkes........................ 54 5.2 Der embedded PC.......................... 55 5.3 Der PC: Entwicklungsumgebung und Leitstation.......... 56 5.4 Der Router / Gateway........................ 57 5.5 Dynamische DNS-Einträge...................... 59 6 Sonstige Betrachtungen 60 6.1 Sicherheit............................... 60 6.1.1 Offene Ports.......................... 60 6.1.2 Firewall............................ 60 6.1.3 Nessus-Scan.......................... 61 6.1.4 Fehlende Langzeiterfahrung, versteckte Lücken....... 62 6.1.5 Kostenpflichtige Luftschnittstelle.............. 63 6.2 Zukunftsaussichten.......................... 64 7 Zusammenfassung / erreichte Ziele 66 A Technische Daten: Modem Siemens MC35i 69 B Tarifübersicht GPRS Tarife 70 B.1 T-D1 Tarife.............................. 70 B.2 Vodafone Tarife............................ 70 C Konfiguration des Routers 71 C.1 Informationen zum Skript...................... 71 C.2 Das Skript bridge-up........................ 71 D Portscans: Windows CE.NET 4.1 74 D.1 Ergebnisse des TCP/IP Portscans.................. 74 D.2 Ergebnisse des UDP/IP Portscans.................. 74

INHALTSVERZEICHNIS 5 E Nessus-Report: Windows CE.NET 4.1 75 E.1 Routerkonfiguration für Nessusscan................. 75 E.2 Das Skript nessus-up........................ 75 E.3 Mitteilung des Testergebnisses.................... 76 E.4 Scanergebnis Nessus-Scan...................... 76 F Konfiguration des Modems unter Linux 82 F.1 Motivation............................... 82 F.2 Bildschirmfotos von Yast2...................... 82 G Logfile: Interneteinwahl GPRS-Modem 86 H Abkürzungsverzeichnis 88 Literaturverzeichnis 91 Abbildungsverzeichnis 93 Tabellenverzeichnis 94 Abschlusserklärung 95

6 1 VORWORT 1 Vorwort 1.1 Über die Firma Die vorliegende Studienarbeit wurde bei der selben Firma absolviert, bei der der Autor auch schon sein Betriebspraktikum im 7. Semester durchgeführt hatte. Die Firma BN Automation AG ist im Bereich der Ver- und Entsorgung von Wasser/Abwasser tätig und hat sich auf die Entwicklung von Gesamtlösungen im Bereich der Automatisierungstechnik spezialisiert. Der zweite Schwerpunkt der Firma liegt im Bereich der Netzwerktechnik. Sie bietet hier als DATEV-Systempartner ein eigenständiges Dienstleistungsangebot an. Hier wurden bereits vielen Steuerberatern und Industriebetrieben die rechentechnischen Einrichtungen eingerichtet und gepflegt. Die Firma BN Automation AG ist ü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 Hochbehälterproblem Sowohl die damalige Praktikumsaufgabe als auch diese Studienarbeit drehen sich um ein Themengebiet, welches innerhalb der Firma unter dem Oberbegriff Das Hochbehälterproblem bekannt ist. Dabei geht es um die Überwachung mehrerer räumlich verteilter Objekte, wie zum Beispiel die genannten Hochbehälter aus der Wasserversorgungswirtschaft. An diesen Hochbehältern sollen laufend Prozessgrößen wie der aktuelle Wasserstand ermittelt werden. Kritische Zustände (Füllstand oder Beobachtung von Alarmkontakten) sollen erkannt und gemeldet werden. Hauptproblem dabei ist die weiträumige Verteilung der einzelnen Stationen. Sie bringt spezielle Anforderungen an die Mechanismen zur Datenübermittlung mit sich. Bei der Anbindung stehen je nach Umfeld mehrere Technologien zur Verfügung. Das Spektrum reicht dabei von klassischen Wählverbindungen über GPRS bis hin zu speziellen Übertragungstechniken wie der Nutzung von Betriebsfunk. Lösungsansatz hierfür soll ein neues Gerät mit einer gewissen Eigenintelligenz sein. Der spätere Anwender installiert es am zu überwachenden Prozess, wo die Station die Aufgabe der Messwerterfassung übernimmt. Gleichzeitig soll sie die Daten vorverdichten 3 und kritische Prozesszustände 4 erkennen können. Zwischen den abgesetzten Stationen und der Leitstation existieren keine dauerhaften 3 Beispielsweise durch Mittelung mehrerer Messwerte. Dies dient der Entfernung von Störeinflüssen und der Reduktion des Datenaufkommens. 4 Zum Beispiel drohende Havarie.

1.2 Das Hochbehälterproblem 7 Standleitungen. Ein Verbindungsmanagement verwaltet hierbei die nur zeitweise genutzten Datenübertragungseinrichtungen. Es soll die anfallenden Übertragungskosten minimieren. Ein Anwendungsbeispiel ist das Sammeln von Daten über den Tag hinweg, um sie einmal täglich über eine Telefonleitung an die Leitstation zu übermitteln. Zusätzlich kann eine Station im Falle eines auftretenden Alarmzustandes eine außerplanmäßige Verbindung aufbauen, um kritische Zustände zu melden. 10 10 Embedded PC Embedded PC 10 10 Embedded PC Embedded PC 10 10 Embedded PC Embedded PC Abbildung 1: Eine Leitstation ü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 können die Stationen beidseitig eine Datenverbindung aufbauen, um die gesammelten Daten zu übermitteln. Dieser sternförmige Aufbau ist dabei nicht die einzige Netztopologie, die in der Praxis vorkommen kann. Einzelne Stationen müssen in bestimmten Einsatzszenarien in der Lage sein, eine Art Wegewahl durchzuführen. Bei der Verwendung von Betriebsfunk kann es vorkommen, dass eine Art Vermittlungsstation auf einem hoch gelegenen Punkt montiert wird. Sie kommuniziert über Funk mit den restlichen Automatisierungsstationen. Die Verbindung mit der Leitstation erfolgt hierbei ausschließlich über die zentrale Vermittlungsstation. Sie ist mit der Leitstation beispielsweise über eine Wählverbindung verbunden. Eine solche Anordnung wird in Abbildung 2 gezeigt.

8 1 VORWORT 10 Funk Embedded PC 10 Embedded PC Berg ISDN Funk Funk 10 10 Embedded PC Embedded PC Abbildung 2: Erreichbarkeit über eine Vermittlungsstation 1.2.1 Die verteilten Stationen Für die verteilten Automatisierungsstationen kommen Industrie-PC s der Firma Beckhoff zum Einsatz. Diese basieren auf eingebetteten 5 PC s, die aufgrund ihrer Bauform 6 direkt mit in den Schaltschränken verbaut werden kö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 verfügt über ein klemmbares Bussystem. Über dieses können weitere Baugruppen 7 hinzugefügt werden. Sie hä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 Eingängen, digitalen Eingängen oder digitalen Ausgängen.

1.2 Das Hochbehälterproblem 9 Auf dem integrierten Rechner läuft als Betriebssystem Microsoft Windows CE.NET 4.1, sowie eine vom Beckhoff ausgelieferte Soft-SPS 8. Sie kümmert sich um die gesamte Messwertaufnahme. Es bleibt noch genügend Rechenkapazität übrig, damit ein Programmierer selbstentwickelte Programme auf der Station betreiben kann. 1.2.2 Die Leitstation Als zentrale Leitstation kommt ein handelsü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 können dann von der Leitstation auf vielfältige Weise weiterverarbeitet werden. Die Verwendungszwecke reichen von einer Speicherung in einem Geschichtsdatenarchiv bis zur sofortigen Weiterleitung an eine übergeordnete Leitwarte. Die Leitstation bietet außerdem eine zentrale Parametrierschnittstelle für das verteilte System. Im Idealfall soll hier der Nutzer einen Zugriff auf alle Datenpunkte erhalten und gegebenfalls Änderungen durchführen können. Die geä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, Speicherprogrammierbare Steuerung (Soft-SPS). Um diese Soft-SPS herum arbeiten diverse Module, die ihr noch weitere Funktionalität hinzufügen. Eine der Hauptaufgaben ist die automatische Aufnahme von Messwerten an einem Prozess und deren Zwischenspeicherung. Je nach Konfiguration übertragen die Stationen diese Daten entweder sofort oder beim nächsten Sammelabruf an die übergeordnete Leitstation. Die Aufgabe dieser Studienarbeit zielt nicht auf die Funktionalität innerhalb der Soft-SPS oder deren nachgeschaltete Bearbeitungsmodule, sondern auf die Ausarbeitung einer modularen Kommunikationsschnittstelle. Sie soll den Datentransfer über mehrere Datenübertragungstechnologien 9 ermöglichen. Die zu Grunde liegenden Kommunikationstechnologien sollen einfach gegeneinander austauschbar sein. Die gesamte Funktionalität zur Kommunikation wird dafür in spezialisierte Kommunikationsmodule gruppiert. Einen Überblick über die interne Struktur einer Station gibt Abbildung Nr. 4 auf Seite 10. Dort befindet sich die Soft-SPS, die für die Prozesskopplung zuständig ist. Sie enthält einen integrierten Timer, um periodische Ereignisse anzustoßen. 8 Eine auf Software basierende, speicherprogrammierbare Steuerung. 9 ISDN, GPRS, Betriebsfunk sowie diverse Weitere und Zukünftige.

10 1 VORWORT Timer Verarbeitungsmodule Soft SPS Dispatcher Spontan Zyklische Meldungen Realtime Grenzwert überwachung archiv 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 können zum Beispiel Filter realisiert werden, die über mehrere gemessene Analogwerte mitteln 10. Die in Abbildung 4 gezeigten Verarbeitungsmodule sind jeweils für einen bestimmten Typ von Datenpunkt zuständig: Spontanarchiv: In diese Kategorie fallen alle Datenpunkte, die von der Station auf Veränderungen überwacht werden sollen. Dies kann ein umspringender Zählerstand oder ein ein Toleranzintervall verlassender, analoger Messwert sein. Ausnahme sind binäre Signale, die so genannten Meldungen. Sie bilden eine eigene Gruppe. Zyklische: Zyklische Messwerte sind Datenpunkte, deren Zustände von der Station periodisch neu gemessen werden. Ein Beispiel ist die minü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 gehören alle binären Datenpunkte. Solche Signale werden von vielen Baugruppen zum Signalisieren von Störungen verwendet ( Störungsmelde-Ausgänge ). Zur Weiterverarbeitung kann das Modul so genannte Totzeiten berücksichtigen. Es meldet dann nur längerfristige Störungen an die Leitstation. 10 Generell: Aufbereitung der Daten und Vorverdichtung.

1.3 Aufgabe 11 Realtime: Das Realtime-Modul hält ein so genanntes Prozessabbild vor. Wenn sich ein entfernter Nutzer sofort über den aktuellen Zustand diverser Datenpunkte informieren möchte, kann er hiermit die aktuellen Messwerte auch unabhängig von eingestellten Messintervallen prüfen. Grenzwertüberwachung: Das Grenzwertmodul überwacht Datenpunkte auf Über- oder Unterschreitung eines Grenzwertes. Es erzeugt immer dann eine Nachricht, wenn ein Datenpunkt ein Gültigkeitsintervall verlä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 fällt dem nachgeschalteten Kommunikationsmanager zu. Um ihn zu nutzen, versehen die Verarbeitungsmodule den zu übertragenden Datenpunkt mit der Stationsadresse des Empfängers 11 und legen die Nachricht als Datei in einem einem stromausfallsicheren Übergabeverzeichnis ab. Der Kommunikationsmanager wird die Nachricht daraufhin an die Zielstation versenden. 1.3 Aufgabe 1.3.1 Situation vor der Arbeitsaufnahme Bei Beginn der Studienarbeit näherte sich bereits eine funktionstüchtige Umsetzung des Gesamtprojektes seiner Fertigstellung. Sie war jedoch sehr spezialisiert und nur mit einer einzigen Datenübertragungsmöglichkeit über Betriebsfunk ausgestattet. Es funktionierte zwar bereits, jedoch war der gesamte kommunikationsbezogene Programmteil ein einziger monolithischer Block. Es wä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 Kommunikationsblock ersetzen soll. Diese Struktur soll mit den unterschiedlichsten Kommuni- kationstechnologien zusammenarbeiten, und eine einfache Erweiterung um neue Kommunikationswege ermöglichen. Die Station soll dann im laufenden Betrieb aus einer gegebenen Anzahl von Kommunikationswegen den günstigsten heraussuchen und hierüber die Daten versenden. Günstig kann dabei Verschiedenes bedeuten. Zielstellung kann eine Kostenminimierung oder eine möglicht hohe Datenübertragungsrate sein. 11 Der Empfä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 Übertragungstechnologie zugeschnittene Kommunikationsmodule erledigen den Zugriff auf die verwendeten Medien, während ein modulübergreifender Kommunikationsmanager die einzelnen Module verwaltet und anspricht. Alle diese Kommunikationsmodule verfügen über eine fest definierte Schnittstelle, damit sie sich später gegeneinander austauschen lassen. Dies vereinfacht die Entwicklung zukünftiger Kommunikationsmodule, die auf jetzt noch nicht verwendeten Kommunikationstechnologien basieren werden. Der Entwickler braucht dann lediglich ein weiteres Kommunikationsmodul zu entwickeln, ohne dass Änderungen an anderen Stellen des Systems notwendig werden. Des Weiteren stand der konkrete Wunsch im Raum, Stationen in zukünftigen Projekten mit GPRS anzusprechen. GPRS ist dank der mittlerweile fast flächendeckenden Verfügbarkeit von GSM 12 ein vielversprechender Ansatz zur Datenü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 für den Beckhoff-PC. Implementierung eines auf Ethernet spezialisierten Prototyps eines Kommunikationsmoduls für die Leitstation, welche über Ethernet 13 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 ermöglicht. Er soll speziell die Modulstruktur umsetzen und GPRS als Kommunikationsmedium nutzen. 12 Global System for Mobile Communication. 13 Die Leitstation ist Bestandteil eines lokalen Netwerkes. Die Internetverbindung wird über einen Router bereitgestellt.

13 2 Modulares Kommunikationsmodell 2.1 Schichtenmodelle Bevor die einzelnen Modelle beschrieben werden, müssen die verwendeten Begrifflichkeiten geklärt werden. Die folgenden Abschnitte enthalten diverse Fachbegriffe aus dem Themenbereich Schichtenmodelle nach ISO/OSI 14, 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 Protokolls zusammenfasst. Die einzelnen Module stehen untereinander in einer Abhängigkeitsbeziehung, und unterscheiden sich in ihrer Funktion als Dienstnehmer und Diensterbringer. Bei der Spezifikation von Protokollen und Diensten trifft man unweigerlich auf eine Ansammlung an dreibuchstabigen Abkürzungen, wie in Schema 5 dargestellt. (N+1) PCI (N+1) SDU (N+1) PDU Schicht N+1 Schicht N (N) IDU (N) ICI (N) PCI (N) SDU (N) ICI Schicht N Schicht N 1 (N) PCI (N) PDU (N) SDU (N 1) IDU (N 1) ICI IDU PCI SDU ICI PDU : Interface Data Unit : Protocol Control Information : Service Data Unit : Interface Control Information : Protocol Data Unit (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 dafür sind Fachbücher zum Thema Kommunikationsnetze (siehe [KrRe02]) besser geeignet. Eine solche Wiederholung wü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 MODULARES KOMMUNIKATIONSMODELL 2.2 Kommunikationsmodell 2.2.1 Beteiligte Komponenten Die gewünschte Infrastruktur soll Daten in Form einzelner Dateien zwischen zwei beteiligten Stationen übertragen. Diese Dateien kö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 selbständiges Programm, welches auf allen Stationen des verteilten Verbundes läuft und sich um die Zustellung zur Zielstation kümmert. Dort angekommen, werden die Daten vom lokalen Kommunikationsmanager wieder in Form von Dateien im Dateisystem (Übergabeverzeichnis) abgelegt. Wenn man den gesamten Kommunikationsmechanismus als Black-Box ansieht, dann verdeutlicht Abbildung 6 diesen Ansatz der Dateienübertragung. VM Station1 Station 2 Archiv Datei Datei Kommunikationsmanager Kommunikationsmanager Ü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 Verfügung stehenden Kommunikationsanbindungen bieten. Verschiedene Anbindungen erfordern verschiedene Strategien zum Datentransfer. Die Kommunikationsmodule fassen die für ein spezielles Medium notwendigen Funktionen zu spezialisierten Blöcken zusammen. Die zu übertragenden Dateien werden vom Kommunikationsmanager aufbereitet 15 und an ein passendes 16 Kommunikationsmodul übergeben. Dieses überträgt die Daten an die nächste Station, auf der wiederum ein Kommunikationsmodul 15 Die Dateien werden nach Prioritäten sortiert und in kleinere Fragmente zerteilt. 16 Diese Auswahl erfolgt nach verschiedenen Kriterien (Erreichbarkeit, Kosten,... ), die noch genauer betrachtet werden.

2.2 Kommunikationsmodell 15 arbeitet welches die Daten entgegennimmt. Das Zusammenspiel ist in Schema 7 erkennbar. Station1 Station 2 Datei Datei Kommunikationsmanager Kommunikationsmanager GPRS Modul Sonstiges Modul LAN Modul GSM Internet DSL LAN DSL Einwahlrouter Abbildung 7: Nutzung von Kommunikationsmodulen zur Datenübertragung Eine einzelne Station kann dabei über mehrere Anbindungen verfügen. In bestimmten Szenarien werden einzelne Stationen als so genannte Relaisstationen 17 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 erhält für den Fall des Ausfalles von GPRS noch eine Ersatz-Anbindung (Backup-Link) über ISDN. Embedded PC Nr. 1 Embedded PC Nr. 2 Leitstation Übergabeverzeichnis Übergabeverzeichnis Ü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 über mehrere Dienste 17 Veranschaulicht im Funkszenario auf Abbildung 2 (Seite 8), wo eine Station die Aufgabe einer Vermittlungseinrichtung übernimmt.

16 2 MODULARES KOMMUNIKATIONSMODELL 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 Funktionalitä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 eigenständige Programme (.exe-dateien). Beide Ansätze haben speziellen Eigenheiten. Unabhängig davon fiel die Wahl zur Erstellung des Prototyps auf die Trennung in eigenständige Programme 18. Der Prototyp sollte mö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 eigenständige Programme modelliert werden. In Bezug auf die Ausführungsgeschwindigkeit wird das DLL-Konzept dem EXE- Konzept allerdings überlegen sein. Bevor später die Produktivversion implementiert wird, sollte der Entwickler das DLL-Konzept genauer untersuchen 19. Die folgende Liste fasst die Konsequenzen zusammen, die sich aus der Gruppierung der Funktionen in einzelne Module ergeben: Austausch von Komponenten: Möglichkeit des Austausches veralteter Programmkomponenten gegen aktualisierte Versionen. Der Austausch eines einzelnen Moduls kann beispielsweise ü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 durchgeführt. Nachträgliche Erweiterung: Einfache Erweiterung um weitere Kommunikationsschnittstellen: Anschluss der Hardware, Platzierung des zugehörigen Kommunikationsmoduls (evtl. über FTP) und abschließende Anmeldung des neuen Moduls beim Kommunikationsmanager. Das Modul wird jetzt vom Kommunikationsmanager gestartet und in den Prozess der Datenübertragung mit eingebunden. Mehrere Module gleichzeitig: Parallel vorhandene Kommunikationswege: Ein Gerät kann mehr als eine 18 Bei dem Kommunikationsmanager und den Kommunikationsmodulen handelt es sich um eigenständige.exe-dateien. 19 Dies geschah parallel zu dieser Studienarbeit.

2.2 Kommunikationsmodell 17 einzelne Anbindung aufweisen. Zusätzlich zu einer GPRS-Anbindung könnte ein ISDN-Anschluss fü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 über ein LAN) wird nur eine einzige Station am Tor zur Welt hängen. Dies zeigt Abbildung 8 auf Seite 15. In diesem Falle startet der Kommunikationsmanager drei Kommunikationsmodule 20. Übersichtliche Schnittstellen: Die Kommunikation zwischen dem Kommunikationsmanager und den einzelnen Kommunikationsmodulen erfolgt über eine festgelegte und einheitliche Schnittstelle. Diese ist idealerweise unabhängig von den Möglichkeiten und Erfordernissen der den Modulen zugrundeliegenden Übertragungstechnologien, denn erst dies ermöglicht einen transparenten Austausch der Module untereinander. Wartbarkeit: Der Programmierer erhält durch die strikte Trennung der Schichten als eigenständige Programme einen modularen Quellcode. Jeder Block weist spezialisierte Fähigkeiten auf. Dadurch werden die Programme kleiner und übersichtlicher, was sich positiv auf die Pflege der Programme auswirkt. Sicherheit durch Trennung Ein abstürzendes Modul reißt nicht den gesamten Kommunikationsmanager mit in den Tod. Ein Modul bleibt schlimmstenfalls hängen, was aber vom darüberliegenden Kommunikationsmanager erkannt werden kann 21. 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 möglich. 2.2.3 Der Kommunikationsmanager Dieses Modul ist ein eigenständiges Programm, welches beim Hochfahren der Station vom System mitgestartet wird und dann immer läuft. Der Kommunikationsmanager hat einen Überblick über sämtliche verfügbaren Kommunikationswege sowie deren Eigenschaften. Da sich die einzelnen Kommunikationswege sehr stark voneinander in ihrer Benutzung unterscheiden 22, werden alle auf die Medien zugeschnittenen Routinen in spezialisierte Kommunikationsmodule ausgelagert. 20 Eines für ISDN, eines für GPRS und ein drittes für Ethernet. 21 Zum Beispiel über Timeouts. 22 Bei ISDN muss eine nach Zeittakten abgerechnete Wählverbindung aufgebaut werden, GPRS dagegen benötigt lediglich einen einzelnen Verbindungsaufbau, bei dem keine weiteren Zeitkosten anfallen.

18 2 MODULARES KOMMUNIKATIONSMODELL Fü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 unterstützen, ohne Rücksicht auf bestimmte Eigenheiten des konkret genutzten Übertragungsmediums nehmen zu müssen. Der Kommunikationsmanager enthält die Menge an Funktionen, die unabhängig von denen der Übertragungsmedien zur Kommunikation gebraucht werden. Dazu gehören die folgenden Aufgaben: Versenden von Dateien: Zu übertragende Daten werden vom Dispatcher 23 und seinen nachgeschalteten Verarbeitungsmodulen 24 in einem Übergabeverzeichnis im Dateisystem abgelegt. Danach ist die Datei unter der Kontrolle des Kommunikationsmanagers, und wird von diesem erst nach vollständigem Versand gelöscht. Auf der Gegenstation läuft der Mechanismus genauso ab, nur in umgekehrter Richtung. Die einzelnen Datenpakete wandern ü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 Ü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 über ISDN zu ermöglichen, startet der Manager das ISDN-Kommunikationsmodul. Ist zusätzlich noch eine GPRS-Anbindung vorhanden 25, lädt er parallel zum ISDN-Modul noch das GPRS- Modul. Wegewahl: Eine Zielstation kann gleichzeitig über mehrere Kommunikationswege erreichbar sein. Dann muss der Kommunikationsmanager eine Entscheidung treffen. Er wä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. 24 Siehe Diagramm 4 auf Seite 10. 25 diese Information steht in der Konfigurationsdatenbank des Kommunikationsmanagers.

2.2 Kommunikationsmodell 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 gewünschten Zielrechner ermöglichen? Kosten für die Datenübermittlung: Eine momentan aufgebaute ISDN-Verbindung könnte billiger sein als der alternative Versand über GPRS. Zustand einzelner Kommunikationsmodule: Wenn sich ein Modul zeitweise als nicht benutzbar meldet, kann das mehrere Ursachen haben. Eine Möglichkeit ist ein Hardwaredefekt, aber auch eine momentan gestörte oder besetzte Leitung führen dazu. Damit der Kommunikationsmanager diese Entscheidung fällen kann, benötigt er eine Datenbank. Sie speichert alle verfügbaren Eigenschaften der vorhandenen Kommunikationsmodule und ermöglicht eine Auswahl des gerade am geeignetesten Weges. Übergabe von Datenströmen: Was passiert, wenn während einer laufenden Datenübertragung eine Datenverbindung wegstirbt? Das betroffende Kommunikationsmodul wird diesen Zustand erkennen und ihn sofort dem darüberliegenden Kommunikationsmanager mitteilen. Dieser wird von nun an seine Wegewahl anders gestalten, und die zu versendenden Datenpakete über eine eventuell vorhandene Ersatzleitung schicken (Handover von Datenströmen). 2.2.4 Die Kommunikationsmodule Die Kommunikationmodule sind unterhalb des Kommunikationsmanagers angesiedelt. Sie werden vom Programmierer jeweils für ein spezielles Ü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 Übertragungsmedien. Sie enthalten jeweils speziell an das Medium angepasste Routinen um Daten zu versenden oder zu empfangen. Es lassen sich Kommunikationsmodule für alle denkbaren Übertragungsmedien entwickeln. Dank ihrer einheitlichen Schnittstelle kann sie der Anwender auch nachträglich in ein älteres System integrieren. Relevante Kommunikationstechniken sind bisher:

20 2 MODULARES KOMMUNIKATIONSMODELL Betriebsfunk: Eine bereits in der Firma verwendete Übertragungstechnik ist Betriebsfunk. Hierbei weist einem die RegTP (Regulierungsbehörde für Telekommunikation und Post) eine feste Frequenz und einen Zeitschlitz zu. Man kann dann mit Hilfe eines entsprechenden Modems einmal pro Minute für ein fünfsekündiges Zeitintervall mit 9600Bit/s Daten versenden. Da sich alle Stationen diesen Zeitschlitz teilen müssen, sind umfassende Synchronisationsmechanismen notwendig. ISDN: Es gibt bei ISDN zwei Möglichkeiten: Einmal die Einwahl bei einem Internetprovider mit anschließender Kommunikation über das Internet, oder die direkte Punkt-zu-Punkt-Verbindung zu einer Zielstation. In beiden Fällen kommen PPP 26 und TCP/IP zur Anwendung. GPRS: GPRS ist Bestandteil von GSM und fast flächendeckend verfügbar. Ein Schwerpunkt dieser Studienarbeit ist die Erstellung eines funktionierenden Prototyps 27 zur Nutzung von GPRS. Analoge Modems: Die Anbindung über Analogmodems ist mit der bereits genannten Anbindung über ISDN vergleichbar. Die beiden Module werden sich nur in wenigen Details 28 unterscheiden. Direkte Anbindung über IP: Diese Kategorie behandelt alle Stationen, die eine bereits vor Modulstart verfügbare IP-Anbindung nutzen. Im Moment sind dies alle Formen von IPbasierten lokalen Netzen 29. Die angeschlossenen Stationen kommunizieren direkt ü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 Beschränkung auf 160 Zeichen 30 pro Nachricht aus. Beim 26 Point-to-Point-Protocol: Wird als Schicht-2-Protokoll beim Datentransfer ü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 eingeschränktem Zeichenvorrat. Pro Zeichen können ca. 6 Bit codiert werden, was einem Informationsgehalt von 120 Bytes pro SMS entspricht.

2.2 Kommunikationsmodell 21 Nachfolger MMS sind im Vergleich zur SMS größere Datenblöcke mit den vollen 8 Bit an Information pro Symbol handhabbar. Sonstige Techniken: Eine Anpassung an zukünftige Übertragungsmedien wird keine Anpassungen an anderen Stellen im System notwendig machen. Es genügt, wenn der Programmierer ein weiteres Kommunikationsmodul erstellt. Er kann es dank der einheitlichen Schnittstelle ohne Ä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 erläutert. Es ging dort um die folgenden Punkte: Versendung von Dateien ( Informationscontainer ) Start- und Stopp von einzelnen Kommunikationsmodulen Wegewahl Übergabe von Datenströmen (Handover) 3.1.1 Kommunikation über Dateien Jede zu versendende Datei liegt in einem stromausfallsicheren Übergabeverzeichnis oberhalb des Kommunikationsmanagers. Dort können die einzelnen Dateien auch eine längere Zeit sicher verweilen. Im vorliegenden Fall dient dazu ein Verzeichnis, welches auf einem stromausfallsicheren Medium 31 liegt. Damit der Kommunikationsmanager mit der Übertragung beginnen kann, schickt ihm der Dienstnehmer ein so genanntes Event 32 (Ereignis) als Anstoß. Es enthält den Dateinamen und noch weitere Parameter 33, die dem Kommunikationsmanager mitgeteilt werden müssen. Die Datei steht jetzt unter der Kontrolle des Kommunikationsmanagers, und wird erst nach ihrer vollständigen Versendung von ihm gelöscht. Der Ersteller der Datei erhält keine weitere Rückmeldung, wenn seine Datei vollständig am Ziel angekommen ist 34. Für die Versendung der Dateien werden noch weitere Informationen benötigt als ihr bloßer Inhalt ( Die Nachricht ). Hier kommen die bereits angsprochenen Parameter ins Spiel, denn sie geben Auskunft über die weitere Behandlung der Datei: Adressierung: Zum erfolgreichen Versand wird der Name oder eine Adresse des Empfängers benötigt: Der Kommunikationsmanager muss wissen, wohin er die Datei zustellen soll. Auch die Angabe einer Absenderadresse ist sinnvoll. Sie ermöglich dem Empfänger zu erkennen woher die Datei gekommen ist. 31 Hier: Ein Compact-Flash Modul. 32 Dazu wird der Mechanismus der Window Messages verwendet. 33 Unter anderem die Priorität der Nachricht und die Stationsadresse der Zielstation. 34 Auf dieser höchsten Ebene gibt es keine Ende-zu-Ende Quittierungen.

3.1 Der Kommunikationsmanager 23 Dringlichkeiten: Es gibt unwichtigere Daten ( niedrige Priorität ). Sie dürfen vom Kommunikationsmanager mit Blick auf eine Kostenersparnis verzö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 Priorität fä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 übertragen werden. Es ist irrelevant, wie der Inhalt der Nachricht aussieht. Sie kann in Form gepackter Binärdaten 35 oder als strukturiertes XML-Telegramm 36 ( extended Markup Language ) vorliegen. Das, was vom Dispatcher und seinen Modulen als Datei im Übergabeverzeichnis abgelegt wird, taucht so auch wieder im Übergabeverzeichnis des Kommunikationspartners auf. 3.1.2 Warteschlangen und Prioritäten Während des Betriebes kö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 übertragenden Logfile wird beispielsweise eine geringere Priorität zugewiesen als einer ausgelösten Alarmmeldung. Der Kommunikationsmanager fällt anhand der Prioritäten eine Entscheidung über die Bearbeitungsreihenfolge. Er achtet darauf, dass Dateien mit hoher Priorität bevorzugt übertragen werden. Für diese Aufgabe wurde vom Autor ein Warteschlangenmechanismus entworfen. Er wird in Abbildung 9 gezeigt. Die interne Warteschlange erlaubt eine Trennung in 256 verschiedene Prioritäten, und hält für jede dieser Prioritä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 gehören: Der vollständige Dateiname mit Pfad im Verzeichnisbaum der Station Die Absenderadresse, die besagt wo die Datei ursprünglich 37 herkommt Die Stationsadresse der Zielstation 35 Falls nur wenig Übertragungskapazität zur Verfügung steht. 36 XML ist ein Hilfsmittel zur Darstellung von Daten, das aber sehr aufgeblasene Telegramme erzeugt. 37 Wichtig für ein Netzwerk mit Relais-Knoten.

24 3 DIE EINZELNEN MODULE IM DETAIL Übergabeverzeichnis Datei 1 Datei 2 Datei 3 Kommunikationsmanager steigende Priorität 0 1 2 3 4 5 6 252 253 254 255 IB 2 Sendewarteschlange (256 Prioritäten) IB 1 IB 3 Scheduler Wegewahl Fragmentierung Sendeprotokoll Infoblock: IB "x" Dateiname mit vollem Pfad Ankunftszeit Absenderadresse Zieladresse Dateilänge Offset in Datei Quittierungsinformationen nächstes Listenelement Kommunikationsmodule Hauptlink Backuplink Abbildung 9: Priorisierte Warteschlange zum Dateiversand Die Dateilänge in Bytes Der Dateizeiger (Offset), der auf den nächsten zu versendenden Bereich zeigt Quittierungsinformationen. Mit ihnen wird überwacht, welche Dateibereiche bereits fehlerfrei vom nächsten Knoten empfangen wurden Die Ankunftszeit am Kommunikationsmanager, zur Bestimmung von Timeouts Mit Hilfe dieser Informationen kann der Kommunikationsmanager die nächste zu versendende Datei auswählen. Die Dateien werden dabei nicht als Ganzes versendet, sondern in Form kleinerer Fragmente. Es käme sonst zu Planungsproblemen, wenn eine hochpriore Meldung auf einen sehr umfangreichen, niederprioren Datentransfer treffen würde. Die Meldung müsste entweder warten 38, 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 können, muss der Kommunikationsmanager sicherstellen, dass eine Datei eine Übertragungsstecke nicht für lange Zeit 38 Dieser Effekt wird als Prioritätsumkehr bezeichnet [Butt97].

3.1 Der Kommunikationsmanager 25 blockieren kann. Später eintreffende aber höher priorisierte Dateien müssen weiterhin bevorzugt versendet werden. Ein solches Verhalten wird durch die Fragmentierung ermöglicht. Hierbei werden die zu versendenden Dateien in kleinere Datenblöcke zerteilt. Solche Datenblöcke sind hinreichend klein, und blockieren das Medium nicht, wenn ein höher priorisierter Datenstrom verzögert eintrifft. Die Fragmentierung hat noch einen weiteren Vorteil: Sie ermöglicht, dass Paketverluste behandelt werden können. Einzelne Fragmente lassen sich effizienter wiederholen als eine komplette Datei. Die Kommunikationsmodule erwarten ihre Nutzlasten in Form von Fragmenten mit einer maximalen Größe. Beim Funkmodul zum Beispiel ist jedes Paket zwingend 128 Byte groß 39, bei IP-basierten Medien werden größere Fragmente verwendet. Diese Fragmentierung wird in Absprache mit den Kommunikationsmodulen vom Kommunikationsmanager durchgeführt. Diese Technik erfordert einen Protokolloverhead, damit der Empfänger die einzelnen Fragmente wieder demultiplexen (trennen) und reassemblieren (zusammenfügen) kann. Um nicht für jedes Paket alle notwendigen Informationen (Dateiname, Absender,... ) erneut zu versenden, kommunizieren die Kommunikationsmanager über einen verbindungsorientierten Mechanismus miteinander. Wenn eine Datei versendet wird, handeln beide Stationen einen logischer Kanal aus. Sie verknüpfen jeweils alle zur Ü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 Empfänger kann das Paket eindeutig zuordnen. 3.1.4 Datenbank für die Kommunikationsmodule Jedes dem Kommunikationsmanager bekannte Kommunikationsmodul weist spezielle Eigenschaften auf, die die vom ihm bereitgestellten Dienste beschreiben. Dazu gehö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 wäre eine Speicherung der Konfigurationsdaten in jedem Kommunikationsmodul denkbar, jedoch ermö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. Sämtliche Einstellungen gehören dazu, wie unter anderem Nutzernamen, Passwörter, Telefonnummern, Adressen von Servern, Portnummern, Timing- und Tarifinformationen. 39 Die 128 Byte umfassen allerdings den effektiven, zu übertragenden Datenblock inklusive aller Header und Redundanzen; die Größe des hier gemeinten Datei -Fragmentes ist entsprechend geringer.

26 3 DIE EINZELNEN MODULE IM DETAIL 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 Änderung mit, woraufhin die Module ihre Konfigurationsdaten erneut anfordern. 3.1.5 Wegewahl / Routing Es gibt zwei Anwendungsfälle, bei denen eine Wegewahl durchgeführt werden muss. Einmal, wenn mehrere Kommunikationswege zum Ziel führen, oder wenn die aktuelle Station eine Art Zwischenstation zum Ziel darstellt. Als Beispiel hierfür eignet sich der über ein LAN verkoppelte Verbund mehrerer Stationen, von denen nur eine einzelne über einen Weg nach draußen, also zur Leitstation, verfügt 40. Aus Sicht einer Nur-LAN-Station wird vom Dispatcher die Stationsadresse der Leitstation als Zieladresse eingetragen, aber der Kommunikationsma- nager erkennt, dass er das Paket nicht direkt dem Ziel übergeben kann. Er weiß aber, welcher Knoten näher am Ziel liegt, und kann das Paket an diesen Telegrammrouter weiterleiten. Dazu versendet er in diesem Fall das Telegramm ü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 über GPRS mit der Leitstation verbunden, und das Paket wird an das GPRS-Modul weitergeleitet. Beim umgekehrten Weg, für Pakete aus Richtung der Leitstation, ist der Mechanismus nach dem selben Schema anwendbar. 3.2 Die Kommunikationsmodule 3.2.1 Anpassung an das Übertragungsmedium Die zu unterstützenden Übertragungsmedien weisen jeweils spezielle Eigenschaften auf, die eigene Herangehensweisen zur Nutzung erfordern. TCP/IP-basierte Kommunikationswege weisen ein datenstromorientiertes Übertragungsverhalten auf, Betriebsfunk dagegen hat durch sein Zeitschlitz-basiertes Übertragungsverfahren einen blockorientierten Charakter. Manche Medien benötigen einen Verbindungsaufbau (GPRS benötigt eine Einwahl), andere dagegen nicht (Stationen in lokalen Netzen). Bei der Nutzung von Betriebsfunk muss sich der Programmierer zusätzlich noch Gedanken um einen eigenen Medienzugriffsmechanismus machen, da sich mehrere Stationen den Äther teilen. Zusammenfassend sind in den Kommunikationsmodulen die speziell an ein Medium anzupassenden Routinen zum Empfang und Versand von Daten an- 40 Abbildung dieses Sachverhalts auf Seite 15.

3.2 Die Kommunikationsmodule 27 gesiedelt. Jedes Medium weist andere Eigenschaften auf, und benötigt andere Herangehensweisen bei der Anwendung. Medienzugriffskontrolle: Sie realisiert das Management der zu nutzenden Übertragungstechnik. Bei Betriebsfunk schließt sie das Warten auf zugewiesene Zeitschlitze sowie eine zentralisierte Verwaltung der Funkressourcen mit ein. Bei den meisten anderen Ü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 Wählverbindungen kann mit in die Kategorie der Medienzugriffskontrolle gezählt werden. Überwachung: Aufgebaute Wählverbindungen können durch unerwünschte externe Ereignisse 41 getrennt werden. Um dem zu begegnen, wird die Verbindung überwacht. Wird ein unerwü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 einwählen können. Anrufende Stationen müssen sich authentifizieren, um die Dienste der angerufenen Station nutzen zu dürfen. Die Erkennung und Behandlung von eingehenden Verbindungswünschen fä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 berücksichtigen. Das Betriebsfunkmodul benötigt hierfür Mechanismen zur Fehlererkennung und -korrektur. Dafür stehen verschiedene Techniken zur Auswahl: Fehlererkennende Codes: Sie ermöglichen durch eine Verwendung von Prüfsummen die Erkennung von aufgetretenen Bitfehlern. Praxisrelevante Verfahren sind Paritätsbits oder der Cyclic Redundancy Check (CRC). Diese Verfahren erkennen mehr oder weniger gut verfälschte Blöcke. Sie sind nicht in der Lage den Auftrittsort des Fehlers zu lokalisieren. Eine Korrektur ist nicht möglich. Ein fehlerbehafteter Block wird vom Empfänger verworfen und erneut angefordert. 41 Beispielsweise aufgrund einer kurzzeitigen Störung im Telefonnetz.

28 3 DIE EINZELNEN MODULE IM DETAIL Fehlerkorrigierende Codes: Fehlerkorrigierende Codes ermöglichen eine Vorwärtsfehlerkorrektur. Der Empfänger ist damit in der Lage, den Auftrittsort bestimmter Fehlermuster zu ermitteln. Die auftretenden Fehler sind somit korrigierbar. Die Verfahren benötigen einen hohen Anteil an Redundanz, und sind auch kein Allheilmittel. Die Restfehlerwahrscheinlichkeit wird auch mit größtem Codierungsaufwand immer größer Null sein. Interleaving (Codespreizung): Fehlerbursts 42 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 entschärfen, dass die zu einem Burst gehörenden Bits über mehrere Blöcke gestreut werden. Der Fehlerburst verteilt sich dann gleichmäßig über mehrere Blöcke und kann mit einfacheren Codes korrigiert werden. Bei allen TCP/IP-basierten Medien braucht sich der Programmierer um auftretende Paketverfälschungen keine Sorgen zu machen. Sie treten höchstens bei GPRS verstärkt in den unteren Schichten auf, was aber bereits durch die in TCP integrierten Mechanismen kompensiert wird. Adressumwandlung: Der Kommunikationsmanager adressiert Datenpakete über so genannte Stationsadressen (dies sind projektinterne Identifikationsnummern). Das zur Ü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 durchgeführt. Keine weitere Fragentierung! Die Aufgabe der Fragmentierung übernimmt bereits der Kommunikationsmanager. Ein jedes Kommunikationsmodul kann aber seine Wunsch-Fragmentgröße nachträglich verändern. Wenn sich bei Funknutzung die Übertragungsbedingungen verschlechtern, kann das Betriebsfunkmodul auf eine Kanalcodierung mit höherer Redundanz umschalten. Das bedeutet aber, dass die Datenfragmente seitens des Kommunikationsmanagers kleiner werden müssen. Die resultierenden Blöcke weisen eine höhere Redundanz auf, daher bleibt weniger Platz für Information. Es ist dabei nicht gesagt, dass alle genannten Schritte auch implementiert werden müssen. Ein guter Kandidat dafür ist das Betriebsfunkmodul, aber für 42 Fehlerbursts sind mehrfache, eng hintereinander auftretende Verfälschungen.

3.2 Die Kommunikationsmodule 29 die vorliegende Aufgabe (die Umsetzung des GPRS-Moduls) werden keine Fehlerbehandlungsschritte benötigt. Abbildung 10 zeigt die eben genannten Aspekte in Form eines Ablaufdiagrammes. Kommunikationsmanager Kommunikationsmodul Projektspezifische Stationsadresse IDU SDU Übergabe einer SDU an das Kommunikationsmodul Verbindungskenner anfügen Adress Umsetzung Hd SDU Vorwärtsfehlerkorrekturcodes Hd SDU FEC Prüfsumme hinzufügen Medienspezifische Stationsadresse Hd SDU FEC CRC Versandfertige SDU Sende Routinen IDU : Interface Data Unit SDU : Service Data Unit Hd : Header FEC : Forward Error Correction CRC : Cyclic Redundancy Check Abbildung 10: Datenpaket innerhalb eines Kommunikationsmoduls Hier werden fehlerkorrigierende Codes (FEC, Forward Error Correction ) in Kombination mit einer Prüfsumme (CRC, Cyclic Redundancy Check ) verwendet. Die Fehlerkorrektur kann geringe 43 Fehler korrigieren, versagt aber bei umfangreicheren Bitfehlerkombinationen. Der Empfänger erhält nach der Korrektur ein falsches Ergebnis, was er aber ohne weitere Hilfsmittel nicht erkennen kann. Deshalb wird um diesen inneren Fehlerschutz noch ein ä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 über diese Schnittstelle auf die Reise zu schicken. Genauso können aber auch Telegramme von einer Gegenstation entgegengenommen werden. Die eigentliche Nutzlast besteht aus einem binär 43 Geringe Anzahl an Bitfehlern pro Block.

30 3 DIE EINZELNEN MODULE IM DETAIL 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 Übertragungsstrecke können Pakete verlorengehen, je nach Übertragungsmedium mit einer höheren oder niedrigeren Wahrscheinlichkeit. Darum brauchen sich die Kommunikationsmodule nicht zu kümmern. Es ist die Aufgabe des darüberliegenden Kommunikationsmanagers, einen Paketverlust durch geeignete Quittierungsmechanismen zu bemerken und die Übertragung zu wiederholen. 3.3 Interprozesskommunikation 3.3.1 Kommunikation zwischen den Modulen Die am Kommunikationsmechanismus beteiligten Module werden als geschichtetes Modell dargestellt. Eine untergeordnete Schicht bietet dabei einer überge- ordneten Schicht einen Dienst 44 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 ermöglichen. In beiden Programmen wird jeweils ein Kommunikationsendpunkt benö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 über den Datenkanal am anderen Kommunikationsendpunkt wieder heraus. Es wird bewusst noch keine Aussage über den eigentlichen Datenkanal gemacht, sondern nur die notwendige Funktionalität der beiden Endpunkte genannt. Später folgt ein Überblick über die Mö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 unterschiedlichen Verhalten bezüglich des Aufbaus der internen Datenverbindung. Der Ma- ster ist derjenige, der zuerst gestartet wird. Er startet anschließend den Slave. Dieser meldet sich beim Master zurück, um den Aufbau der Datenverbindung abzuschließen. Bei Erfolg können Daten ausgetauscht werden. Master und Slave verhalten sich diesbezüglich symmetrisch. 44 Dies wurde bereits in der Einführung zu Schichtenmodellen auf Seite 13 dargestellt.

3.3 Interprozesskommunikation 31 Kommunikationsmanager Datentransfer IPC_MASTER Aufbau Datentransfer IPC_SLAVE Datentransfer Einzelnes Kommunikationsmodul Abbildung 11: Allgemeine Interprozesskommunikation Kommunikationsmanager 1. new().send(data).recv(data) 8. IPC_MASTER 6. connected Anker=.init() 2. 3. Start [Anker] 5..connect(Anker) 4. IPC_SLAVE new() 7. Vollduplex Kanal 8..send(DATA).recv(DATA) Einzelnes Kommunikationsmodul Abbildung 12: Ablauf der allgemeinen Interprozesskommunikation

32 3 DIE EINZELNEN MODULE IM DETAIL 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 unabhängig von einer konkreten Datenübertragungstechnologie. Zuerst erstellt der Kommunikationsmanager einen eigenen lokalen Master- Kommunikationsendpunkt (1) und initialisiert diesen (2). Dabei wird ein Anker gesetzt, mit Hilfe dessen sich das Kommunikationsmodul später registrieren kann. Jetzt wird das Kommunikationsmodul gestartet (3), wobei ihm der Anker als Kommandozeilenparameter ü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 übergebenen Anker, um sein Slave-Objekt mit dem Master-Objekt zu verbinden (5). Der Master registriert die Rückmeldung (6), so dass ein vollduplexfähiger Datenkanal ausgehandelt werden kann (7). Die Initialisierung ist komplett. Der Kommunikationsmanager und das Kommunikationsmodul können sich gegenseitig Daten zuschicken (8). 3.3.2 Mögliche Ansätze zum Datenaustausch Zur Kommunikation können verschiedene Technologien verwendet werden. Microsoft Windows CE bietet diverse Technologien an, die einen Datenaustausch im Rahmen von Inter-Prozess-Kommunikation (IPC) ermöglichen. Aber nicht alle diese Methoden sind für den Einsatz geeignet. Die folgende Übersicht betrachtet die untersuchten Mechanismen: TCP/IP-Sockets: Nutzung von TCP/IP zum Datenaustausch zwischen zwei beteiligten Kommunikationspartnern. Nutzt die Netzwerkfähigkeiten des Systems. Window Messages: Plattformabhä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 Empfänger. Die Nachrichten werden systemintern in Warteschlangen zwischengespeichert. Dateien: Hierbei werden zu übermittelnde Informationen in Form von Dateien in einem Übergabeverzeichnis abgelegt. Von hier aus werden sie von einem

3.3 Interprozesskommunikation 33 anderen Programm geö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 können aber auch zur Übermittlung von Nachrichten verwendet werden. 3.3.3 Interprozesskommunikation über Sockets Der im Rahmen der Studenarbeit erstellte Prototyp verwendet Sockets zur Interprozesskommunikation. Sockets sind eine flexible Lösung. Sie erlauben die Trennung der beiden Schichten in jeweils eigenständige Programme. Es werden lokale 45 Sockets benutzt. Sie werden über den TCP/IP-Mechanismus des Betriebssystems bereitgestellt. Doch warum wurde sich für den Prototyp für die Verwendung von Sockets entschieden? Sockets sind einfach zu benutzen. Es gibt ein übersichtliches und dokumentiertes Application Programming Interface (API). Sockets stellen eine etablierte Technologie dar. Sie sind sehr ausführlich getestet und Bestandteil aller modernen Betriebssysteme. Sockets sind schnell. Andere zur Auswahl stehende Technologien wie RPC 46 nutzen intern ebenfalls den Socketmechanismus, und sind daher im Vergleich hö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 Lösung dafür liegt in der Definition eines Datenaustauschformates. Es beschreibt das Aussehen der zu übermittelnden Nachrichten. Diese Aufgabe lässt sich mit Hilfe von XML 47 -Telegrammen angehen, doch wird sich aus Gründen der Einfachheit (Prototyp) nur auf einfache, binär codierte Nachrichten beschränkt. Bei Bedarf kann auf ein anderes Datenformat umgeschwenkt werden. Hinzufügen weiterer Kommunikationskanäle: Neue Sockets können jederzeit vom Betriebssystem angefordert werden. Sie existieren dann nebeneinander ohne sich gegenseitig zu beeinflussen. 45 Die Sockets verbinden zwei lokale Prozesse miteinander. 46 Remote Procedure Calls. 47 extended Markup Language.

34 3 DIE EINZELNEN MODULE IM DETAIL Die interne Struktur der Master- und Slaveobjekte wird mit Sockets umgesetzt. Die notwendigen Schritte zum Aufbau einer Kommunikationsbeziehung ähneln dabei dem allgemeinen Ansatz zur Interprozesskommunikation. Kommunikationsmanager IPC_MASTER 11..send(DATA).recv(DATA) 1. new() 2..bind() TCPIP_LISTENER 3. PortNum 9. 8. connected TCPIP_ENDPOINT Start [PortNum] 4. 10. Etablierter Socket (Vollduplex) 5. new() 7. connecting 6..connect(PortNum) TCPIP_ENDPOINT IPC_SLAVE 11..send(DATA).recv(DATA) Einzelnes Kommunikationsmodul 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/IP- Sockets 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 Verbindungswünsche überwacht, was für die spätere Rückmeldung des Slaves wichtig ist. Er weist eine eindeutige Nummer auf (3), die dem anschließend gestarteten Kommunikationsmodul als Kommandozeilenparameter übergeben wird (4). Das Kommunikationsmodul initialisiert seinen lokalen Verbindungsendpunkt (5), und teilt ihm den Rü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/IP- Endpunkt (9). Zwischen Master und Slave besteht jetzt eine vollduplexfähige Datenverbindung (10), die durch Nutzung der Methoden des Masters und des Slaves zum Datentransfer genutzt werden kann (11). 3.4 Schnittstellen und Protokolle 3.4.1 Schnittstelle oberhalb des Kommunikationsmanagers Kommunikations manager Kommunikations manager Abbildung 14: Dienstschnittstelle des Kommunikationsmanagers Der Kommunikationsmanager erhält seine zu übertragenden Nachrichten aus einem Ü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 Event 48. Es enthält alle weiteren, noch notwendigen Informationen: Den vollständigen Pfad der Datei, die Stationsadresse des Empfängers, eine Prioritä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 für die neue Modulstruktur ü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 Änderungen erforderlich, denn es kann beispielsweise von nun an nicht mehr mit festen Fragmentgrößen gearbeitet werden. Das 48 Über eine Window-Message.

36 3 DIE EINZELNEN MODULE IM DETAIL zu implementierende Protokoll wird mit variablen Fragmentgrößen 49 zurechtkommen müssen. Die interne Struktur mit der Nutzung von Warteschlangen und dem Mechanismus der Fragmentierung von großen Datenblö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 später von jemand anderem übernommen. Dabei müssen die bestehende Routinen aus dem Funk-Projekt angepasst werden. Die notwendigen Ä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 für beliebige Datenblöcke (wie sie im spä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 wählt sich per GPRS ins Internet ein und wartet auf Anfragen des Echoclients. Dieser residiert auf dem Arbeits-PC (Leitstation) und versendet über Ethernet (Mit einem DSL-Router als Standardgateway) eine Reihe von Ping -Nachrichten. Der Server empfängt diese und antwortet auf sie mit den entsprechenden Pong - Nachrichten. Sowohl der Server als auch der Client bedienen sich eines Kommunikationsmoduls. Sie müssen es jeweils starten und ihm den Befehl zur Einwahl erteilen. Nach Aufbau der Verbindung wird das Modul zur Datenü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 (ICI 50 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 benö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 über Funk (128 Bytes pro Block) ausfällt, ändert sich beim Umschalten auf eine vorhandene ISDN-Backupleitung (evtl. 1024 Bytes pro Block) die Fragmentgröße. 50 Interface Control Information.

3.4 Schnittstellen und Protokolle 37 Echoclient Kommunikationsmanager auf PC (Leitstation) Echoserver Kommunikationsmanager auf Beckhoff PC connect connected disconnect disconnected halt killechoserver_req ping_req pong_ind connect connected disconnect disconnected halt killechoserver_ind ping_ind pong_req LAN Modul Kommunikationsmodul auf PC (Leitstation) ping_pdu pong_pdu killechoserver_pdu 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 Verbindungsaufbauwünsche bedient. halt Das Kommunikationsmodul soll sich beenden. Es wird alle belegten Ressourcen freigeben und sich terminieren. Kommunikationsmanager an Kommunikationsmodul, Daten (PDU 51 s) ping_req Der Echoclient verschickt ein Ping an den Echoserver. pong_req Der Echoserver antwortet auf ein Ping mit einem Pong. Die Antwort 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 läuft, wird ein manueller Eingriff am Beckhoff-PC zur Beendigung des Echoservers unnötig. Kommunikationsmodul an Kommunikationsmanager, Steuerdaten (ICI s) connected Das Kommunikationsmodul ist jetzt online. Es ist bereit, Nutzdaten 51 Protocol Data Unit.

38 3 DIE EINZELNEN MODULE IM DETAIL zu ü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 Stö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 Echoclients) eingetroffen. pong_ind Auf Seite des Echoclients ist eine Pong -Nachricht (Antwort des Echoservers) eingetroffen. killechoserver_ind Der Echoserver erhä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. Enthält die Antwort auf ein Ping. killechoserver_pdu Eine weitere PDU. Sie befiehlt dem Echoserver, sich und sein Kommunikationsmodul zu beenden.

39 4 Kommunikation über GPRS 4.1 Nutzerschnittstelle des GPRS-Modems Das GPRS-Modem wird über eine serielle Schnittstelle (RS232) mit dem PC verbunden. Das GPRS-Modem emuliert ein herkömmliches analoges Modem, um eine maximale Kompatibilität zu existierenden Betriebssystemen zu gewährleisten. Das Betriebssystem greift dabei auf das Point-to-Point Protocol (PPP) zurück, um sich mit einem Internetprovider zu verbinden. Der dazu notwendige PPP-Protokollstapel ist fest im Modem integriert. Das Modem wird über den AT- Befehlssatz 52 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 GPRS Modem GPRS Provider Einwahl Terminal Anwendung Modem Steuerung GGSN SGSN BSS IP IP IP IP Internet AT Codes PPP Stapel AT Codes PPP Stapel Serielle Schnittstelle Serielle Schnittstelle GPRS Protokollstapel GPRS Protokollstapel Serielles Kabel Funkschnittstelle AT : Attention Codes IP : Internet Protocol PPP : Point to Point Protocol GPRS : General Packet Radio Service GGSN : Gateway GPRS Support Node SGSN : Serving GRPS Support Node BSS : Base Station Subsystem Abbildung 17: Vereinfachtes Schichtenmodell GPRS-Modem 4.2 Inbetriebnahme des GPRS-Modems 4.2.1 Die Hardware vorbereiten Zur Inbetriebnahme des Modems wird eine SIM-Karte 53 in die dafür vorgesehene Schublade des Modems eingelegt. Auf dieser sind die Zugangsdaten des Nutzers und Informationen des verwendeten Mobilfunkprovider gespeichert. 52 AT: Attention -Codes, Hayes-Befehlssatz. 53 Subscriber Identity Module.

40 4 KOMMUNIKATION ÜBER GPRS Das Modem kommt als kompakte Blackbox und kann direkt in einen Schaltschrank eingebaut werden. Es wird noch eine externe Antenne benötigt, die an einem Ort installiert werden muss, wo ein ausreichender Empfang gewährleistet ist. Beim vorliegenden Testaufbau kommt eine Multiband-GSM-Antenne 54 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 ü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 für analoge Telefonleitungen nachahmt. Es wird über AT-Kommandos gesteuert und bringt einen integrierten PPP-Protokollstapel zur Emulation 55 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 für Spezialaufgaben relevant sind. Sie können bei Bedarf unter [Siem01b] nachgeschlagen werden. 54 Typ Hirschmann MCA 18 90 MH. 55 Emulation deshalb, weil bei Nutzung eines herkö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 Übertragungsstrecke.

4.2 Inbetriebnahme des GPRS-Modems 41 AT-Kommando Bedeutung AT Attention, liefert OK ATZ Rücksetzen des Modems AT +CPIN PIN zur Authentifizierung übermitteln =0000 AT +CGDCONT PDP-Kontext definieren =1, Context Identity (CID) ip, Packet Data Protocol (PDP) internet.t-d1.de Access Point Name (APN) AT +CGQREQ Quality of Service-Parameter setzen =1, Context Identity (CID) 3, Precedence (Priorität) 4, Delay (Verzögerung) 3, Reliability (Zuverlässigkeit) 0, Peak (Spitzenrate) 0 Mean (Mittlere Rate) ATD *99***1# Wahlaufruf, Bezug auf PDP-Kontext CID=1 ATDP *99***1# Alternative Angabe zu ATD (Pulswahl) ATDT *99***1# Alternative Angabe zu ATD (Tonwahl) Wird vom Modem nicht unterstützt! ATH Auflegen +++ Wechsel vom Datenübertragungsmodus (PPP) in den AT-Modus ATA Wechsel vom AT-Modus zu unterbrochenem Datenübertragungsmodus Tabelle 1: Wichtige AT-Kommandos Um den Befehlssatz zu testen, wird ein Terminalprogramm benötigt. Dazu eignet sich unter Windows das mitgelieferte Terminalprogramm Hyperterminal bzw. unter GNU/Linux das Programm Minicom. Als Schnittstelle wird der serielle Port des Modems ausgewählt (eventuell COM1: unter Windows, /dev/ttys0 unter Linux). Die Standardparameter der Portkonfiguration 56 sind bereits korrekt und kö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 über PPP eine Internetverbindung bereitzustellen. Die Einwahl wird durch mehrere Schritte gestartet: ATZ 56 Baudrate, Parität und Anzahl der Stoppbits.

42 4 KOMMUNIKATION ÜBER GPRS Abbildung 19: Konfiguration und Einwahl über AT-Kommandos Setzt das Modem zurück. Dieser Schritt ist nicht unbedingt erforderlich, da das Modem in der Regel gerade erst eingeschaltet wurde und noch kein Rücksetzen notwendig ist. AT +CGDCONT=1,ip,internet.t-d1.de Erzeugung eines PDP-Kontextes (Packet Data Protocol). Mit der Context- ID (CID) Nr.1 wird das PDP IP und der Access Point Name (APN) internet.t-d1.de verknü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 IP- Adresse 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 herkömmlichen Analogmodems gibt es unterschiedliche AT-Einwahlkommandos. Diese reichen von ATDP für eine Einwahl über Pulswahl, ATDT für eine Einwahl über Tonwahl bis zu ATD für eine Einwahl mit nicht spezifiziertem Wahlverfahren. Bis auf Tonwahl werden alle Kommandos vom Modem unterstützt (siehe Abbildung 20, Seite 43). Bei der spä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 erhält eine bestehende Sprachverbindung. Im Telefonhörer sind hierbei keinerlei Gerä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 4 KOMMUNIKATION ÜBER GPRS Abbildung 21: Zweimaliger Anruf des Modems aus dem Festnetz 4.2.3 Konfiguration zur Einwahl in das Internet über PPP Die ersten Tests zur Einwahl ins Internet wurden auf einem SuSE 57 Linux 8.2 durchgeführt. Zu diesem Zeitpunkt stand dem Autor nur das GPRS-Modem, aber noch keine Microsoft Windows-Entwicklungsumgebung und kein Beckhoff- PC zur Verfügung. Das GPRS-Modem wird als herkömmliches Modem erkannt. Anschließend wird die Interneteinwahl konfiguriert. Die vollstä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 herkömmlichen 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 Ü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 Windows CE.NET 4.1 und GPRS 4.3.1 Zur Einwahl notwendige Schritte Es folgt eine detaillierte Beschreibung wie das verwendete GPRS-Modem Siemens 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 vollständig per Software auf einem nackten Image durchzufü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 müssen. Die vollautomatische Einwahl 58 in das Internet mit Hilfe eines Modems ist unter Windows CE eine sehr aufwendige Angelegenheit. Es stellte sich heraus, dass ein dafür elementar wichtiger Konfigurationsschritt nirgendwo dokumentiert wurde. Über Google 59 konnte aber ein Artikel gefunden werden, der einen inoffiziellen Registry-Hack vorstellt um die Einstellungen manuell60 vorzunehmen. Um die Einwahl auf einem völlig unbedarften Image zu starten, sind die nachfolgend aufgeführten Schritte notwendig. Sie werden im nächsten Unterkapitel genauer betrachtet. Die Aufzählung richtet sich an den interessierten Entwickler, da es sich um ein programmiertechnisches Problem handelt. Wer noch nie für Windows CE entwickelt hat, dem werden ein paar der verwendeten Begriffe nichts sagen. Sie sind aber unter [GrBr01] nachlesbar. 1. Die Unimodem-Einträge in der Registrierdatenbank manuell auf brauchbare Defaultwerte setzen. 2. Alle defaultmäßig verwendeten Initstrings aus der Registrierdatenbank entfernen. 3. Mit Hilfe von Befehlen der Telephony API (TAPI) nach nutzbaren Modems suchen. 4. Erzeuge in der Registrierdatenbank eine so genannte Location, um das Wahlverhalten 61 zu beeinflussen. Dafür gibt es seitens Microsoft weder API- Befehle, Einstellungsboxen noch Dokumentation. 58 Diese Funktionalität lä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, Länderprefixe in den Rufnummern und die Notwendigkeit von Amtsholungen.

46 4 KOMMUNIKATION ÜBER GPRS 5. Schreibe die notwendigen Init-Strings des Modems manuell in die Registrierdatenbank. 6. Fülle eine RASENTRY-Datenstruktur aus und sende sie an das Betriebssystem. Sie enthält Informationen über das beim Verbindungsaufbau zu verwendende Modem und die zu wählende Rufnummer. 7. Fülle eine RASDIALPARAMS-Datenstruktur aus und registriere sie im Betriebssystem. Über sie werden der Loginname und das Passwort zur Authentifizierung am Provider eingestellt. 8. Starte die Einwahl über den API-Aufruf RasDial(). Dieser schlägt beim Setzen der PIN bei Verwendung eines Siemens MC35I immer fehl, da sich das Modem beim PIN-Setzen erst intern initialisiert und für mehrere Sekunden blockiert. In dieser Zeitspanne läuft RasDial() in einen Timeout und bricht ab. Mehr dazu auf Seite 49. 9. Überwache die Einwahl und die aufgebaute Verbindung ü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 ü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 über ein Modem aufbauen möchte, wird die Konfiguration dieses Modems dem so genannten Unimodemeintrag entnommen. Dies ist eine Ansammlung von Parametern, die in der Registrierdatenbank unter dem Schlüssel HKLM 62 \Drivers\Unimodem zu finden sind. Der erste Unterschlüssel unter \Settings\ enthält eine Reihe von Schlüssel-Werte-Paaren mit AT-Kommandos. Sie werden dazu verwendet das Modem zu resetten (ATZ) oder um eine Einwahl zu starten (ATD). Der zweite Unterschlüssel \Init\ enthält eine Reihe von Initstrings, die vor einer Einwahl der Reihe nach an das Modem gesendet werden. Hier muss sichergestellt werden, dass die geforderten Einträge ü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 gebräuchliche Kurzform für HKEY_LOCAL_MACHINE.

4.3 Windows CE.NET 4.1 und GPRS 47 2. Alle Initstrings entfernen Bevor eigene Initstrings in die Registrierdatenbank geschrieben werden, sollten alle bereits existierenden Einträge entfernt werden. Sonst kann es passieren, dass bereits mehrere Einträ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. Dafür bietet sich das neutrale AT-Kommando AT<CR> an. Wie man sieht, müssen Initstrings in der Registrierdatenbank um die Zeichenfolge <CR> 63 ergänzt werden. 3. Suche nach ansprechbaren Modems Für die spätere Einwahl benötigt man den Identifikationsstring des Modems. Erst mit seiner Hilfe kann des Betriebssystem erkennen, welches der angeschlossenen Geräte fü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 verfügbaren Modems nutzen muss. Einer davon lautet LineEnumerate(), welcher die Identifikationsstrings aller verfügbaren Schnittstellen der Reihe nach zurückliefert. Man muss sich anschließend den richtigen aus der übergebenen Menge heraussuchen. Es gibt zwei Bedingungen, die der potentielle Indentifikationsstring gleichzeitig erfüllen muss: Der String muss das Schlü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 Callback- Funktion. 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 anzuwählen, wird anhand noch weiterer Parameter der Wahlstring für das Modem zusammengesetzt. Wünschenswert ist hierbei der simple Einwahlbefehl ATDP (Pulswahl) direkt gefolgt von der zu wä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 Abkürzung für Carriage Return, was so viel wie Wagenrücklauf bedeutet.

48 4 KOMMUNIKATION ÜBER GPRS Die Einstellungen, die das interne Vorbereiten des Wä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 über den Pfad HKCU 64 \ControlPanel\Dial\Locations\ innerhalb der Registrierdatenbank zu finden. Die einzelnen Parameter mü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 Länderprefix, der vor die Vorwahl angefügt werden soll Wahl einer Vorwahl, die vor die Rufnummer gebastelt werden soll Festlegung einer zu verwendenden Amtsholung Es ist unbedingt sicherzustellen, dass für das Siemens-GPRS-Modem Pulswahl verwendet wird. Sonst wird das Modem nicht anfangen zu wählen. Weiterhin sind alle anderen Funktionen und Optionen zu deaktivieren, damit der Programmierer die volle Kontrolle über die Bestandteile des Wahlstrings erhält. Keine dieser Funktionen wurde von Microsoft dokumentiert. Der Autor fand aber einen einzelnen Beitrag eines Microsoft-MVP 65 in den Newsgroups. Er beschreibt einen inoffiziellen Registry-Hack. Ohne diesen Hinweis hätte das Modem nicht in Betrieb genommen werden können. 5. Eigene Initstrings setzen Die komplette Konfiguration des Modems erfolgt ü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 ü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 Initstring Die Initstrings werden direkt in die Registrierdatenbank unter dem Pfad HKLM\Drivers\Init\ abgelegt. Jeder Eintrag besteht aus einem Schlüssel- 64 HKCU ist die gebräuchliche Kurzform für HKEY_CURRENT_USER. 65 Microsoft zeichnet in Newsgroups besonders engagierte Privatleute mit dem Titel Most Valuable Professional aus, um diese als wertvolle Mitglieder der Community zu kennzeichnen.

4.3 Windows CE.NET 4.1 und GPRS 49 Wertepaar. Der Schlüssel besteht aus einer Zahl, welcher die Bearbeitungsreihenfolge der einzelnen Initstrings vorgibt. Der zugehörige Wert enthält den Initstring als Zeichenkette. Es gibt dabei ein Problem mit der Freischaltung des Modems durch die PIN. Dieses Problem wird im späteren Abschnitt Die Einwahl starten auf Seite 49 erläutert. 6. Einen Telefonbucheintrag erstellen Als nächstes kommt das Ausfüllen einer RASENTRY-Datenstruktur an die Reihe. Sie enthält Informationen über den Einwahlprozess: Die Verwendung von PPP (ISO/OSI-Schicht 2) einstellen Die Verwendung von IP (ISO/OSI-Schicht 3) aktivieren Auswahl des Modems über seinen Identifikationsstring Den Gerätetyp festlegen: Verwende die Konstante RASDT_Modem Übergabe der zu wählenden Telefonnummer Anschließend wird die ausgefü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 über einen Loginnamen und ein Passwort vorgesehen. Obwohl dies bei einer Einwahl ins Internet über GPRS nicht notwendig ist, muss trotzdem der vorgesehene Mechanismus des Betriebssystems zur Einwahl beachtet werden. Die notwenigen Parameter werden über eine so genannte RASDI- ALPARAMS-Datenstruktur dem Betriebssystem mitgeteilt. Sie enthält: Den Loginnamen (bei GPRS eine beliebige Zeichenfolge) Das Anmeldepasswort (ebenfalls eine beliebige Zeichenfolge) Eine Referenz auf eine gültige RASENTRY-Datenstruktur. Die Aktivierung der ausgefüllte Struktur geschieht ü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 gültige RADDIALPARAMS-Datenstruktur übergeben. Danach wird innerhalb des Betriebssystems eine Kette von Ereignissen durchlaufen: (a) Zurücksetzen des Modems

50 4 KOMMUNIKATION ÜBER GPRS (b) Versendung aller Initstrings der Reihe nach an das Modem. Dazu gehö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) Ü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 ü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 lä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 schlägt die Einwahl mit RasDial() fehl. Das Problem wird dadurch gelöst, dass in einem ersten Schitt immer die PIN in Form eines Initstrings an das Modem gesendet wird und RasDial() dabei bewusst fehlschlä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 überwachen Der RasDial()-Befehl kann so parametriert werden, dass er im Hintergrund den Verbindungsaufbau und die anschließend aufgebaute Verbindung überwacht. Immer wenn es dabei zu einer Statusänderung kommt, wird eine so genannte Window-Message generiert und an einen zu spezifizierenden Window-Message-Handler übergeben. Dieser ist so implementiert, dass er auf zwei spezielle Window-Messages reagiert (RASCS_Connected und RASCS_Disconnected). Erstere wird immer dann ausgelö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 (über einen erneuten Aufruf von RasDial()). 10. Die Verbindung auslösen Der API-Befehl RasHangUp() trennt eine aufgebaute Verbindung. Das Betriebssystem kümmert sich intern um alle notwendigen Schritte, so dass an dieser Stelle keine weiteren Aufräumkommandos notwendig sind. Der Befehl löst zusätzlich eine RASCS_Disconnected-Meldung aus. Dies muss beim Entwurf des Window-Message-Handlers berücksichtigt werden.

4.4 Besonderheiten bei der Nutzung von GPRS 51 4.4 Besonderheiten bei der Nutzung von GPRS 4.4.1 Quality of Service Der folgende Abschnitt behandelt die mit dem vorliegenden GPRS-Modem erreichbaren Datenraten. Die Leistungsfähigkeit einer Datenübertragungsstrecke kann dabei durch verschiedene Merkmale charakterisiert werden: Datendurchsatz im Downlink Datendurchsatz im Uplink Paketverlustrate Laufzeit Laufzeitschwankungen Es macht ein Unterschied, auf welcher Schicht 66 der Tester die Benchmarks ansetzt. Die Leistungsdaten für die GPRS-Schnittstelle brauchen nicht direkt gemessen zu werden, denn sie sind schon in den Datenblättern 67 zu GPRS aufgeführt 68. Diese Daten geben aber nur begrenzt Auskunft über die auf hö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 ursprünglich für Netze mit kurzen Paketlaufzeiten und sehr geringen Ü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 verschärfen. Diese Mechanismen funktionieren für Festnetze mit festen Endsystemen, jedoch nicht mehr für das drahtlos arbeitende GPRS. Hier trifft TCP auf Paketlaufzeiten im Sekundenbereich 69, und je nach gewählten QoS 70 -Parametern auf Paketfehlerraten von bis zu 1 : 10 2. 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. 67 Bei GPRS entscheiden die wählbaren QoS-Parameter (Quality of Service) über die bereitgestellte Qualität des Dienstes. Sie sind unabhängig vom verwendeten Modem und Provider. 68 Siehe [Schi00] und [Siem01b] (Abschnitt QoS-Parameter). 69 Verzögerungsklasse 3: Der Erwartungswert der Ü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.

52 4 KOMMUNIKATION ÜBER GPRS 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 benötigt eine gewisse Zeit, bis er die Kapazität eines Übertragungskanals ausnutzt. TCP tastet sich nach und nach an höhere Datenübertragungsraten heran, bis erste Paketverluste auftreten 71. 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 können mit Hilfe von FTP 72 bestimmt werden. Dazu eignet sich ein Versuchsaufbau, der aus zwei Rechnern besteht. Der erste Rechner ist direkt mit dem Internet verbunden 73. Auf ihm läuft ein FTP-Server, der Dateien sowohl entgegennehmen als auch versenden kann. Als Gegenstation kommt ein zweiter PC zum Einsatz, der sich über das GPRS- Modem in das Internet einwä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 Datei 74 aus Zufallszahlen 75. Sie wird im ersten Schritt vom Client auf den Server geschoben, und im zweiten Schritt wieder heruntergeladen. Dabei wird jeweils die Zeitspanne gemessen, die benötigt wird um die Datei komplett zu übertragen. Der im Test verwendete FTP- Client zeigt die erreichte Datenübertragungsrate direkt an, was eine manuelle Berechnung unnötig macht. Erwartungsgemäß unterscheiden sich die Datentransferraten in beiden Fällen. Der Uplink des GPRS-Modems weist eine geringere Datenübertragungsrate als der Downlink auf. Der Grund liegt im geplanten Einsatzgebiet des GPRS- Modems, denn für die normale Internetnutzung ist die Datenrate des Downlinks wichtiger als der Uplink. Die per FTP gemessenen Raten lauten: Diese Angaben entsprechen den für das GPRS-Kommunikationsmodul verfügbaren Datenraten. Im Bezug auf das Hochbehälterproblem wäre eine umgekehrte Verteilung der Datenraten für Up- und Downlink wünschenswert. Die meisten Daten werden auf der Station erzeugt, und über den Uplink des GPRS-Modems 71 Diese Form der Staukontrolle wird als Slow-Start-Mechanismus bezeichnet. Siehe [Schi00]. 72 File Transfer Protocol. 73 Dies ist im vorliegenden Fall ein handelsüblicher PC, der sich ü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 Übertragungsschnittstellen eine Datenkompression durchgeführt wird. Sie würde zu einem zu optimistischen Ergebnis führen. Die Datei wurde im Test durch den Unixbefehl dd if=/dev/urandom of=./ftp.dat bs=1k count=512 erzeugt.

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 zeitunabhängiger Tarif zum Einsatz kommt, entstehen durch die geringe Datenrate im Uplink keine finanziellen Nachteile. Es dauert nur entsprechend lange.

54 5 VERSUCHSAUFBAU UND VERWENDETE HARDWARE 5 Versuchsaufbau und verwendete Hardware 5.1 Aufbau des Netzwerkes Alle die Studienarbeit umfassenden Aufgaben wurden vom Autor in Heimarbeit durchgeführt. Daher musste zuerst geprüft werden, welche Komponenten benötigt werden um jeden Testfall abdecken zu kö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 handelsüblicher PC zum Einsatz. Der Internetzugang erfolgt ü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 Internet DSL Dyn IP Dyn DNS Gateway Firewall 192.168.1.1 Embedded PC 192.168.1.2 Dyn DNS Server Entwicklungsrechner "Leitstation" Abbildung 22: Aufbau der Entwicklungs- und Testumgebung Es müssen gleichzeitig auf dem Beckhoff-PC laufende Programme getestet werden und eine Verbindung ins Internet bestehen. Die einfachste Lösung für so etwas sind mehrere Netzwerkkarten im Hauptrechner, aber er wies keine freien PCI-Steckplätze mehr auf. Also wird diese Aufgabe einem externen Router (der bereits vorher diese Aufgabe übernahm) übertragen. Das ist keineswegs nur eine Notlösung, sondern bringt viele Vorteile mit sich. Der Router übernimmt gleichzeitig Aufgaben als Internetzugangspunkt, Firewall und Netzwerkmonitor. Über den Microsoft Windows 2000-PC hätte man diese Aufgaben nur mit wesentlich größerem Aufwand hinbekommen können, wenn überhaupt. Wichtig ist auch die Praxisrelevanz der gewählten Struktur. Im späteren Einsatz wird die Leitstation mit großer Wahrscheinlichkeit über ein Gateway im

5.2 Der embedded PC 55 lokalen Netz ins Internet gelangen. Wird im Testaufbau die Debugging-Verbindung (Ethernetstrang) zwischen Router und Beckhoff-Station entfernt, erhä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: NIC NIC NIC DSL Internetprovider Entwicklungsumgebung Gateway Firewall DSL Modem Internet Dyn DNS Server Embedded PC Modem Antenne BSS SGSN GGSN GPRS Provider Abbildung 23: Weg des Datentransfers über GPRS Das Paket wird über das GPRS-Modem ins Internet geschickt. Sein Ziel ist die Leitstation, die über den Router ebenfalls mit dem Internet verbunden ist. Das Paket erreicht den Router, und wird zur Leitstations-Software auf dem Arbeits- PC weitergeleitet. 5.2 Der embedded PC Als Automatisierungsstation kommt ein embedded PC der Firma Beckhoff zum Einsatz. Er basiert auf einem Pentium MMX 76 kompatiblen Prozessor mit 266 MHz Taktfrequenz. Er wird in der vorliegenden Ausführung 77 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 hält 128 MB an nichtflüchtigem Speicher, und bietet genügend Platz zur persistenten Ablage eigener Daten. Über den integrierten RJ45 Ethernetanschluss kann direkt mit der Station gearbeitet werden. Das besagte GPRS-Modem, ein Siemens MC35i 78, wird über einen seriellen Anschluss 76 MMX: Multimedia Extensions. 77 Ein Beckhoff CX1001-0011. 78 Die technischen Daten des Modems befinden sich in Anhang A auf Seite 69.

56 5 VERSUCHSAUFBAU UND VERWENDETE HARDWARE (RS232) an den Beckhoff-PC angeschlossen. Des Weiteren war die vorliegende Station mit diversen analogen und digitalen Eingängen bestückt. Sie waren für die anstehenden Aufgaben allerdings belanglos. Sie werden bei Bedarf von der auf der Station laufenden Soft-SPS ausgelesen und weiterverarbeitet. Die Soft- SPS konnte nicht getestet werden, da die von der Firma Beckhoff mitgelieferte Bediensoftware ( TwinCAT ) nicht mit der Hardware des Hauptrechners kompatibel war. Die Software benötigt systemnahen Zugriff auf spezielle Timer, was in der aktuellen Implementierung nur auf Prozessoren ohne Unterstützung für symmetrisches Multithreading79 (SMT) möglich ist. Es gibt einen Patch, der die SMT-Routinen des Betriebssystems deaktiviert 80, aber für das vorliegende Zweiprozessorsystem gibt es überhaupt keine Hoffnungen das Programm zum Laufen zu bewegen. Es ist nicht bekannt, ob Beckhoff für zukünftige Versionen von TwinCAT auch die Unterstützung von SMP-Systemen ( Symmetrisches Multiprozessing ) plant. 5.3 Der PC: Entwicklungsumgebung und Leitstation Der PC erfüllt eine Vielzahl von Aufgaben. Sein wichtigstes Einsatzgebiet ist die Softwareentwicklung. Auf ihm laufen sämtliche Entwicklungsumgebungen, sowohl um Programme für den embedded PC zu schreiben als auch für die Leitstation. Der PC kann mit dem embedded PC gleichzeitig über LAN (zum Debuggen) und über das Internet (zum Testen des GPRS-Datentransfers) kommunizieren. Auch die Aufgabe der Leitstation wird von diesem PC übernommen. Die dafür notwendige Software wird lokal gestartet und kann über den Router mit dem sich per GPRS ins Internet einwählenden embedded PC Daten austauschen. Der Verbindungsaufbau kann dabei sowohl vom embedded PC als auch vom PC aus erfolgen. Da jeweils verschiedene IP-Adressen fü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 handelsü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. 80 Dies gilt dann allerdings global für alle auf dem System laufenden Anwendungen und macht den Vorteil vom SMT komplett zu nichte.

5.4 Der Router / Gateway 57 Ü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 erläutert werden. Dieser Rechner wird im Folgenden als Router bezeichnet, auch wenn dies technisch nicht immer ganz korrekt sein mag. Als Plattform für den Router fiel die Wahl auf einen seit Jahren ausrangierten PC, der fü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 Netzwerkkarten 81 vom Typ Intel EtherExpress 100 Anbindung an das Internet über ein externes DSL Modem Als Betriebssystem kommt ein minimales Linuxsystem ohne grafische Oberfläche zum Einsatz. Konkret handelt es sich bei der Distribution um ein Debian Stable Release 1 (siehe [Debi]), mit dem zur Zeit aktuellsten verfügbaren Linuxkernel 2.6.4 (siehe [Linu]). Embedded PC NIC 192.168.1.3/24 Router 192.168.1.1/24 ETH2 DSL Modem ETH0 PPP0 Bridge BR0 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 5 VERSUCHSAUFBAU UND VERWENDETE HARDWARE Die erste Netzwerkkarte dient zum Anschluss des DSL-Modems (Internetzugang), die beiden anderen führen jeweils über Crosslinkkabel zum embedded PC und zum Arbeitsplatz-PC. Damit sich der embedded PC und der PC im Netz gegenseitig sehen können, müssen sie sich im selben Subnetz befinden. Dieses Problem wird durch den Mechanismus des Ethernet-Bridgings gelöst. Er fügt die beiden Netzwerkkarten zu einem gemeinsamen Subnetz zusammen. Der Router kann von beiden PC s aus über die interne IP-Adresse 192.168.1.1 erreicht werden. Die zweite Aufgabe des Routers ist die Maskierung der nur lokal gültigen IP- Adressen beim Zugriff auf Ressourcen des weltweiten Internet. Dieser Mechanismus lautet Masquerading (oder NAT für Network Address Translation ), und lässt jegliche Anfragen des embedded PC s oder des PC s ins Internet so aussehen als würden sie vom Router stammen. Der Router besitzt durch die DSL- Anbindung als einziger Rechner eine weltweit gü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 möglich, mit dem Windows 2000 Rechner sicher 82 im Internet zu arbeiten. Wie die jüngste Vergangenheit gezeigt hat, reichen schon wenige Minuten Internetverbindungen aus, um sich Schädlinge wie den Blasterwurm einzufangen. Durch die aktivierte Firewall können keinerlei Anfragen aus dem Internet den Windows 2000 Rechner erreichen. Wird dieses jedoch gewünscht, können einzelne Ports selektiv freigegeben und an den PC geforwardet 83 werden. Erst dieser Mechanismus erlaubt es, dass im Testaufbau vom embedded PC Daten über das GPRS-Modem an den PC versendet werden können. Die Daten werden an die weltweit gültige IP-Adresse des Routers adressiert, und kommen dann ü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 vollstä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 Möglichkeit, einen Traffic-Monitor auf dem Router einzusetzen. Sämtliche Datenströme laufen über den Router und können angezeigt werden. Hierfür eignet sich das Programm iptraf (siehe [IPtr02]), welches dem Benutzer einen genauen Überblick über momentan den Router passierende Datenpakete liefert. Für Tests mit ein- und ausgehenden Verbindungen ins weltweite Internet (an die über per GPRS erreichbare Station) ist diese Überwachungsmöglichkeit sehr nützlich. 82 Sicherheit ist jedoch keine binäre Eigenschaft, sondern vielmehr das Ergebnis einer sehr langen Liste von Dingen, die nicht falsch gemacht werden dürfen. 83 Dieses wird über sogenanntes Destination NAT, bei dem die Ziel-IP-Adresse umgebogen wird, vom Router realisiert.

5.5 Dynamische DNS-Einträge 59 5.5 Dynamische DNS-Einträge Sowohl der Router als auch der embedded PC bekommen bei der Einwahl ins Internet vom Internetprovider eine dynamische IP-Adresse zugewiesen. Sie ändert sich von Einwahl zu Einwahl. Damit sich die beiden PC s dennoch finden können, adressieren sie sich gegenseitig über ihre DNS-Namen und nicht über statische IP-Adressen. Es gibt diverse Anbieter, die diesen als Dyn-DNS Eintrag bezeichneten Service anbieten. Der Autor hatte Glück, denn einer seiner Komilitonen betreibt einen eigenen Nameserver. Es werden zwei DNS-Namen zur Verfügung gestellt. Der Router ist über den Namen powerstation.dyn.l13.de und der embedded PC über den Namen epc.dyn.l13.de erreichbar. Bei einer Verbindungstrennung mit anschließender Wiedereinwahl übermittelt jede Station ihre neue IP-Adresse an den Nameserver. Nach einer gewissen Synchronisationsdauer 84 ist die neue IP- Adresse für die anderen Stationen sichtbar. Die Synchronisationszeit liegt zwischen fünf und 15 Minuten. Danach ist der Datentransfer wieder möglich. Die Synchronisationdauer kann aber durch einen Trick verkürzt werden. Jede Station kann die Absenderadressen einteffender Pakete auswerten, und einen lokalen Zwischenspeicher zur Namensauflöung pflegen. Wird eine Station vom Netz getrennt, schickt sie eine Hallo -Meldung an alle potentiellen Kommunikationspartner. Diese merken sich die Absenderadresse, und können mit ihr einen Datentransfer vor Abschluss der Synchronisation der Nameserver (DNS) starten. 84 Jeder DNS-Eintrag hat eine gewisse Gültigkeitsdauer, um wiederkehrende Anfragen durch topologisch nahe DNS-Server zwischenspeichern zu können.

60 6 SONSTIGE BETRACHTUNGEN 6 Sonstige Betrachtungen 6.1 Sicherheit 6.1.1 Offene Ports Im Falle der GPRS-Anbindung wählt sich der embedded PC über das GPRS- Modem mit Hilfe des eingebauten PPP-Protokollstapels ins Internet ein. Der Provider weist dieser Schnittstelle eine weltweit gü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 unumgänglich, die Anzahl der auf der Station laufenden und global angebotenen Dienste zu untersuchen und ggf. einzuschränken. Laufende Dienste sind immer ein Sicherheitsrisiko, und man sollte nicht benötigte Dienste abschalten, um die Möglichkeiten eines böswilligen Angriffes einzudämmen. Bevor man jedoch gegen eine Schwachstelle vorgehen kann, muss man wissen, ob überhaupt welche vorhanden sind. Als Werkzeug der Wahl bietet sich der freie Portscanner nmap 85 an. Nmap ist in der Lage, einen über IP erreichbaren Rechner auf laufende TCP- oder UDP- Dienste zu prüfen 86. Die Ergebnisse sind erschreckend. Neben den unsicheren Diensten Telnet und FTP war nach außen hin Netbios (UDP) für jedermann offen und zugänglich. Die Ergebnisse der Testdurchläufe sind in Anhang D, Seite 74, nachlesbar. 6.1.2 Firewall Nach dem vorangegangenen Abschnitt über offenen Ports bei Windows CE 4.1 stellt sich die Frage was man dagegen tun kann. Es gibt prizipiell zwei Ansätze, die verfolgt werden sollten: 1. Unbenötigte Dienste sind abzuschalten 2. Alle für das Internet unwichtigen Ports sind nach außen hin durch eine Firewall zu schützen Der erste Schritt erscheint logisch, lä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 überhaupt als notwendig zu klassifizieren sind und welche nicht. Telnet und FTP könnte man getrost deaktivieren. Bei ihrem Authentifizierungsmechanismus wandert das Passwort im Klartext über die Leitung, was nicht tragbar ist. Aber wie deaktiviert man einen solchen Dienst? 85 Homepage unter http://www.insecure.org/nmap/ [Inse]. 86 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 ungünstigsten Fall ist ein solcher Eingriff nur über nicht dokumentierte Schlüssel in der Registrierdatenbank mö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 losgelöst vom ersten Schritt umgesetzt werden. Selbst wenn alle unwichtigen Dienste deaktiviert werden können, ist ein zusä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 überprüfen. Allerdings gibt es in Windows CE 4.1 keinerlei eingebaute Möglicheiten eine Firewall oder einen Paketfilter zu aktivieren. Dieses wichtige Feature steht erst mit der Nachfolgeversion Microsoft Windows CE 4.2 87 zur Verfügung. Da Version 4.2 noch nicht veröffentlicht wurde, kann hier keine Aussage über die Leistungsfähigkeit der mitgelieferter Firewall gemacht werden. Auch hier ist noch einiges zu tun, denn in der jetzigen Version ist es ein Risiko, die Station über eine längere Zeitspanne am Internet zu betreiben. Die Wahrscheinlichkeit, dass ein Cracker im Internet zufällig über die Station stolpert 88 und diese angreift, ist nicht zu vernachlä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 ü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 gewählt. Damit der Test auch mit dem vorliegenden Testaufbau durchführt werden konnte, war eine Änderung der Konfiguration des Routers notwendig. Nur der Router hängt per DSL direkt am Internet, und erhält als einziges eine globale IP-Adresse. Sowohl der embedded PC als auch der PC haben selbst nur eine lokale IP-Adresse, und können nicht direkt vom Nessus-Server gesehen werden. Folgende Änderungen waren nötig: Router: Der Router wird so konfiguriert, dass er sämtliche Anfragen aus dem In- 87 Laut Featureliste auf der Microsoft-Homepage, siehe Dokument [Micr]. 88 Crackern steht heutzutage eine umfangreiche Sammlung von vollautomatischen und sehr leistungsfähigen Werkzeugen zur Verfügung, während auf der anderen Seite meist Rechner mit unsicheren Standardeinstellungen betrieben werden. Nmap ist ein solches Werkzeug, das in der Lage ist eine ungeschütze Windows CE-Station aus einem gegebenen IP-Adresspool herauszufischen.

62 6 SONSTIGE BETRACHTUNGEN ternet nicht lokal auswertet, sondern an den embedded PC im lokalen Netz weiterleitet. Dieser als Port-Forwarding bekannte Mechanismus wird über so genanntes Destination NAT 89 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: IP- Adresse 192.168.1.1) eingetragen. So finden die Antworten an den Nessus- Server wieder den Weg zurück ins Internet (über den Router). Arbeitsplatz-PC: Auf dem Hauptrechner ist keine Konfigurationsänderung notwendig. Er ist lediglich der Initiator des Scanvorgangs. Der Test wird per Browser ü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 benötigen. Man lässt ihn am besten ü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 s 90 ) und nicht durch Eigeninitiative in den Griff zu bekommen. Sie stellen laut der Angaben auf der Nessus-Homepage eine bekannte Verwundbarkeit gegenüber existierenden Angriffen dar (siehe [Port]). 6.1.4 Fehlende Langzeiterfahrung, versteckte Lücken Windows CE ist eine sehr junge Produktlinie der Firma Microsoft. Es handelt sich dabei um eine von Anfang an neu programmierte Plattform für embedded Devices und Handhelds, die mit ihren großen Brüdern Windows 2000 bis Windows XP nur noch den Namen und die Grundprinzipien der grafischen Oberflä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 abschätzen (außer Microsoft selbst), welchen 89 Destination NAT: Änderung der Zieladresse eines Pakets beim Passieren des Routers, mit de-maskierung aller Antwortpakete in Rü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 spä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 möglich. 6.1.5 Kostenpflichtige Luftschnittstelle In dem Moment, wo sich die Beckhoff-Station über ihr Modem in das Internet einwählt, erhält sie eine weltweit gültige IP-Adresse. Über diese ist sie in der Lage, Daten mit Hilfe von IP-Paketen zu versenden und zu empfangen. Alle diese Pakete bilden das Übertragungsvolumen, das die Station über die Luftschnittstelle überträgt. Da bei dem eingesetzten GPRS-Tarif kein zeitbasiertes Abrechnungsmodell verwendet wird, dient das effektive Übertragungsvolumen als Abrechnungsgrundlage. Das ist brauchbarer Ansatz, da die Station somit rund um die Uhr im Netz eingebucht bleiben kann und die Kosten direkt über das emittierte Datenvolumen beeinflußt werden können. Dieser Ansatz weist aber ein Problem auf, das den reinen Einwahlbetrieb in seiner jetzigen Form gefährden kann. Der Grund liegt in der Art und Weise, wie die Abrechnung bei der GPRS-Nutzung durchgeführt wird. Alle an das Internet angeschlossenen Rechner sind prinzipiell gleichberechtigt und können sich gegenseitig Datenpakete zusenden. Die Anbindung über GPRS macht da keine Ausnahme. Jeder Rechner im Internet kann beliebig Daten an den embedded PC versenden. Alle diese Daten wandern über die Luftschnittstelle (den Downlink des embedded PC) und verursachen unerwünschtes und kostenpflichtiges Übertragungsvolumen. Solange der embedded PC online ist, kann er sich in keiner Weise vor diesen Datenpaketen schützen. Selbst eine Firewall greift erst auf höherer Ebene, wenn die Datenpakete bereits vollstä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 erhältlichen Uplink kann einen Datenstrom erzeugen, der die Kosten für die GPRS-Anbindung in erschreckende Höhen treibt. Die folgende, noch optimistische 91 Rechnung soll ein Gefühl für die potentielle Schadenshöhe vermitteln: 91 Die Zahlen wurden abgerundet und können nach oben angepasst werden.

64 6 SONSTIGE BETRACHTUNGEN 1. Der Angreifer verwendet einen gewö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 möglicher Lösungsansatz müsste schon vor der Luftschnittstelle auf Providerseite greifen. Wenn man dort eine Art Proxy verwenden könnte, der über bestimmte Regeln nur valide Pakete zur Luftschnittstelle durchreicht, würde man die Kontrolle über den kostenpflichtigen GPRS-Link zurückerlangen können. Es war sehr zeitintensiv, diese Problematik einem Servicemitarbeiter der deutschen Telekom klarzumachen. Prizipiell gibt es dafür eine Lö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 ü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 für Businesskunden erhä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 Thema 92 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 für Microsoft Windows CE gibt, konnte nicht beantwortet werden. 6.2 Zukunftsaussichten Wichtig ist, dass baldmöglichst eine Firewall in das System integriert wird. Laut den Produktankündigungen auf der Homepage von Microsoft wird die nächste Version von Windows CE.NET, die Version 4.2, eine integrierte Firewall mitliefern. Es ist noch offen, wie leistungsfähig diese sein wird. Sie muss bei Erhalt eines aktuellen Images getestet werden. Eine weitere Möglichkeit liegt in der Verwendung eines externen Routers mit integrierter Firewall. Allerdings wird es ein derart spezialisiertes Gerät nicht geben oder es wird sehr teuer sein. Solche Router sind aus der heutigen Fernsehwerbung nicht mehr wegzudenken 93, erfüllen aber nicht den für das Projekt er- 92 Der Telekom-interne Begriff hierfür lautet IP-VPN. 93 Sie werden zur Zeit recht günstig in Verbindung mit DSL-Tarifen angeboten.

6.2 Zukunftsaussichten 65 forderlichen Zweck. Er müsste ein externes Modem über eine serielle Schnittstelle ansprechen können und mit GPRS-verwandten Mechanismen wie PIN-Nummern zurecht kommen. Weitere Anforderungen sind eine integrierten Firewall und die Möglichkeit diese auch konfigurieren zu kö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 Sicherheitsrisiko 94. Von einer Verwendung ü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 Systemstabilität gefährden. Das im letzten Abschnitt genannte Problem der kostenpflichtigen Luftschnittstelle sollte in Zukunft verfolgt werden. Es ist wahrscheinlich, dass hierfür in Zukunft Lösungen angeboten werden. Dazu muss das Problem aber zuerst in das Bewusstsein der Anbieter rücken. 94 Es ist verständlich, dass Microsoft nun auch eine Schnittstelle zur Fernwartung anbieten will. Wieso sich dabei allerdings für Telnet und nicht für das sicherere SSH entschieden wurde, ist dem Autor ein Rätsel.

66 7 ZUSAMMENFASSUNG / ERREICHTE ZIELE 7 Zusammenfassung / erreichte Ziele Im Rahmen der vorliegenden Studienarbeit wurden folgende Tätigkeiten durchgefü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 über Initstrings parametriert. Es wurde gezeigt, dass zur Einwahl die selben Schritte wie bei einer Einwahl mit Analogmodems verwendet werden können. An manchen Stellen traten aber Probleme auf. Die Freischaltung des Modems über seine PIN machte Probleme, was aber gelöst werden konnte. Ansteuerung des Modems aus einem Programm heraus Es wurde ein Programm geschrieben, welches die zur Einwahl ü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 überwachen und zu nutzen. Die erstellten Klassen wurden modular strukturiert, um eine Wiederverwertung einzelner Bestandteile zu gewährleisten. So konnte zusätzlich mit wenigen Programmzeilen eine Klasse für Analogmodems abgeleitet werden. Sie nutzt die selben Komponenten, die vorher für die GPRS- Klasse erstellt wurden. Die Datenübertragung nach aufgebauter Verbindung wurde über den Socket-Mechanismus (TCP/IP) des Betriebssystems abgewickelt.

67 Modulares Kommunikationsmodell Die zur Kommunikation notwendige Funktionalität wurde in zwei Schichten getrennt. Ein Kommunikationsmanager dient auf jeder Station als Ansprechpartner zur Datenübertragung. Informationen werden vom ihm in Form von Dateien transparent übertragen. Er bedient sich hierfü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 ermö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 Siemens MC35i anzusprechen. Eine Verbindungsüberwachung mit sofortiger Wie- dereinwahl bei Verbindungsabriss wurde integriert. Das Problem der sich bei jeder Einwahl ändernden IP-Adressen wurde durch Nutzung dynamischer DNS-Einträge gelöst. Ethernet-Kommunikationsmodul Für die Anbindung der Leitstation wurde ein Kommunikationsmodul zur Nutzung von Ethernet erstellt. Mit ihm konnte der Kommunikationsmanager der Leitstation ü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 über ein GPRS-Modem ins Internet einwählte. Als Kommunikationspartner ( Leitstation ) kam ein handelsüberlicher PC zum Einsatz. Er war Bestandteil eines lokalen Netzwerkes (LAN) und ü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 ändernder IP-Adressen gegenseitig ansprechen. Die entworfene Modulstruktur diente als Basis für den Prototyp. Die Kommunikationsmanager wurden jedoch nicht vollständig implementiert. Zur Demonstration des Datentransfers wurden hier ein Echoserver und ein Echoclient eingesetzt. Der Echoclient kann ü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 Absender. Dieses Paket kam wiederum am GPRS-Kommunikationsmodul des Beckhoff- PC s an und wurde vom dortigen Echoclient entgegen genommen und angezeigt.

68 7 ZUSAMMENFASSUNG / ERREICHTE ZIELE Am Prototyp konnten Störeinflü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 gewünschten Ausbaustufe erfüllt. Die Nutzung von GPRS ist mit den erstellten Programmen möglich. Die dazu erforderlichen Programmteile lassen sich durch ihren modularen Charakter aus dem Prototyp herauslösen und in das Hauptprojekt integrieren. Die Datenübertragung über GPRS wurde anhand eines Prototyp gezeigt. Die Daten gingen hierbei von einer abgesetzten Automatisierungsstation dank deren GPRS-Anbindung ü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 Datenübertragung funktioniert, kö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 gelöst werden. Hierfü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 TARIFÜBERSICHT GPRS TARIFE B Tarifübersicht GPRS Tarife B.1 T-D1 Tarife Die Telekom bietet eine Vielzahl von GPRS-Tarifen an. Einige davon sind sogenannte Tarifoptionen, also nur Zusätze zu bereits bestehenden Mobilfunkverträgen. Der Businesstarif ein dagegen ein eigenständiger Tarif. Im Laufe der Studienarbeit standen insgesamt zwei verschiedene Tarife zur Auswahl. Die vielen anderen Tarifoptionen können auf der Telekom-Homepage (siehe [Deut]) nachgelesen werden. Die ersten Tests wurden vom Autor mit seiner eigenen SIM-Karte durchgeführt, wobei der T-D1-Tarif T-Mobile Data 1 zum Einsatz kam. Später stand seitens der Firma eine extra SIM-Karte mit dem BusinessData -Tarif zur Verfügung. Mit ihr wurden alle Tests mit höherem Transfervolumen durchführt. Tarif T-Mobile Data 1 BusinessData Tarifart Tarifoption Eigenständiger Tarif Monatlicher Grundpreis + 4,95 EUR 12,85 EUR (10-Sek.-Takt) (Option) Bereitstellungspreis + 0 EUR 21,51 EUR T-Mobile Karte (Option) GPRS: Monatliches 1 MB 5 MB Inklusivvolumen GPRS: Weitere Preise 0,09 EUR/10 KB 1,59 EUR/1 MB Abrechnungseinheit 10 KB 1 KB Tabelle 3: Tarifinformationen Telekom-D1 B.2 Vodafone Tarife Die Tarife von Vodafone wurden zwar nicht genutzt, aber mit recherchiert und eingefügt. Sie ermö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 vollständige Tarifliste ist auf der Vodafone-Homepage (siehe [Voda]) nachlesbar.

71 Tarif Vodafone GPRS L Vodafone GPRS XL Tarifart Tarifoption Tarifoption Monatlicher Grundpreis + 9,95 EUR 19,95 EUR (Option) (Option) Bereitstellungspreis + 4,95 EUR 4,95 EUR (Aktivierung) (Option) (Option) GPRS: Monatliches 1 MB 5 MB Inklusivvolumen GPRS: Weitere Preise 0,29 EUR/100 KB 0,255 EUR/100 KB Abrechnungseinheit 100 KB 100 KB Tabelle 4: Tarifinformationen Vodafone-D2 C Konfiguration des Routers C.1 Informationen zum Skript Die gesamte lokale Netzwerkfunktionalitä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 NAT 95 und das Portforwarding. Die einzelnen Funktionen des Routers werden in Abschnitt 5.4 auf Seite 57 erläutert, daher beschrä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 gü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 NIC s akzeptieren $IPT -A PREROUTING -t mangle -i eth1 -s $IP_ETH1 -j ACCEPT $IPT -A PREROUTING -t mangle -i eth2 -s $IP_ETH2 -j ACCEPT # Nur nicht direkt an lokale Rechner adressierte Pakete akzeptieren

C.2 Das Skript bridge-up 73 $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

74 D PORTSCANS: WINDOWS CE.NET 4.1 D 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 aufgeführten Ports sind offen und stammen vom Betriebssystem (Microsoft Windows CE.NET 4.1) oder zusä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 Nessus-Report: Windows CE.NET 4.1 E.1 Routerkonfiguration für Nessusscan Für den im Laufe der Tests durchgeführten Nessus-Scan war die normale Routerkonfiguration aus Anhang C.2, Seite 71, nicht verwendbar. Geprü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 durchgeführt wird, müssen für die Dauer des Tests jegliche Anfragen aus dem Internet unverändert an den Beckhoff-PC weitergeleitet werden. Des Weiteren müssen für die Dauer des Tests jegliche Formen von aktiven Filterregeln deaktiviert werden. Sie hätten das Testergebnis verfälscht. Bei der späteren Einwahl ins Internet ü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 über mehrere Stunden lä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 Rückmeldung innerhalb des aufrufenden Browserfensters wäre unsinnig, da der Nessus-Scan laut Dokumentation in der Lage sein soll ein ungeschü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) Possible Issue 80.136.125.42 Security hole(s) found Analysis of Host Address of Host Port/Service Issue regarding Port 80.136.125.42 ftp (21/tcp) Security hole found 80.136.125.42 telnet (23/tcp) Security warning(s) found 80.136.125.42 www (80/tcp) Security notes found 80.136.125.42 https (443/tcp) Security notes found 80.136.125.42 unknown (987/tcp) Security notes found 80.136.125.42 unknown (5120/tcp) Security notes found 80.136.125.42 unknown (48898/tcp) Security notes found 80.136.125.42 netbios-ns (137/udp) Security warning(s) found 80.136.125.42 general/udp Security notes found 80.136.125.42 general/tcp Security warning(s) found 80.136.125.42 general/icmp Security warning(s) 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 E NESSUS-REPORT: WINDOWS CE.NET 4.1 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

E.4 Scanergebnis Nessus-Scan 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 E NESSUS-REPORT: WINDOWS CE.NET 4.1 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

E.4 Scanergebnis Nessus-Scan 81 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.

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 durchgeführt. Hier standen flexiblere Werkzeuge zum Einrichten und Analysieren von Netzwerkgeräten zur Verfügung als unter Microsoft Windows 2000. Hierbei ging es nur um das Herantasten an die Funktionsweise des Modems. Spä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 (YaST2 96 ) problemlos. Jeder einzelne Schritt wurde mit einem Bildschirmfoto dokumentiert. Im Bereich der Modemkonfiguration kommt der Programmierer mit GPRS-spezifischen Initstrings 97 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. 97 Eine genaue Beschreibung der Bedeutung von Initstrings findet man in Abschnitt 4.2.2 auf Seite 40.

F.2 Bildschirmfotos von Yast2 83 Wähle den Eintrag fü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 unterstützt und damit ignoriert wird Lautsprecher aus, da irrelevant bei GPRS Kein Warten auf Wä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 übermitteln Mit dem zweiten Initstring den PDP-Kontext definieren Mit dem dritten Initstring die QoS-Parameter setzen 4. Internet-Service-Provider wä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 85 Festlegung der Telefonnummer auf *99***1# Benutzername ist beliebig (Authentifikation über PIN) Passwort ist beliebig (Authentifikation über PIN) 6. Verbindungsparameter und DNS konfigurieren Abbildung 31: DNS-Konfiguration Dial-On-Demand deaktivieren Nameserver dynamisch über PPP zuweisen lassen Firewall deaktivieren Kein Trennen der Verbindung bei Inaktivität (Bild falsch!) 7. Einstellungen zur IP-Adresse Abbildung 32: IP-Konfiguration IP-Adresse dynamisch über PPP zuweisen lassen Automatisch über PPP zugewiesenes Standardgateway verwenden