2. Bluetooth Eine Einführung

Transkript

1 1. Aufgabenstellung Das vorhandene LAN-Integrierte Steuerungssystem (LISTIG) ist um eine Bluetooth-Schnittstelle zu erweitern. Dabei sind folgende Arbeitsschritte zu erledigen: Einarbeitung in die vorgegebene Architektur des Basisgerätes Konzipierung der Bluetooth-Schnittstelle Inbetriebnahme der Bluetooth-Schnittstelle Untersuchung und Bewertung der Kommunikation über Bluetooth Die Bluetooth-Technik ist dadurch gekennzeichnet, dass Profile die Eigenschaft der Geräte festlegen, sodass Geräte mit unterschiedlichen Profilen nicht mit einander kommunizieren können. Im Rahmen der Studienarbeit ist insbesondere die Profil-Problematik zu lösen. 1

2 2. Bluetooth Eine Einführung 2.1 Bluetooth Grundlagen Bluetooth ist ein mittlerweile etablierter Standard für die Übertragung von Daten und Sprache via Kurzstreckenfunk. Zukünftig soll diese Technologie Kabelverbindungen bei mobilen und stationären Geräten ersetzen. Charakteristische Merkmale dieses Standards sind seine Robustheit gegenüber Störungen, die geringe Komplexität der Geräte, der niedrige Energieverbrauch sowie die geringen Herstellungskosten. Bluetooth-Geräte sind z.z. in 2 Leistungsklassen am Markt verfügbar. Die erste mit einer typischen Sendeleistung von 1 mw (Leistungsklasse 2) und einer Reichweite von ca m, die zweite mit einer typischen Sendeleistung von 100 mw (Leistungsklasse 1) und einer Reichweite von ca. 100 m. Unter Zuhilfenahme von zusätzlichen Leistungsverstärkern, Repeatern und/oder speziellen Antennen lässt sich die Reichweite weiter vergrößern. Der Name Bluetooth (Blauzahn) geht auf den vor rund 1000 Jahren in Dänemark herrschenden König Harald II (dessen Spitzname war Blauzahn) zurück. Wegen seiner fortschrittlichen Denkweise genießt er heute noch einen guten Ruf. Unter seiner Regentschaft wurde der erfolgreiche Zusammenschluss einzelner Gebietsteile zu einem einheitlichen Königreich eingeleitet. Ähnliches ist auch Ziel des Bluetooth-Standards von Firmen wie Ericsson (daher auch der Name), Nokia, IBM, Intel und Toshiba begründet, sind heute mehr als 2000 Elektronik-Firmen weltweit am Einsatz und der Weiterentwicklung dieses Standards beteiligt. Die genannten Firmen haben sich im Rahmen der Bluetooth-SIG (Special Interest Group) zusammengeschlossen, um die Kurzstrecken- Netzwerk-Technologie in eigenen Designs einzusetzen oder Produkte darauf aufbauend zu entwickeln. In aktuellen Bluetooth-Geräten finden sich Chipsätze verschiedenster Hersteller, die alle dem Bluetooth-Standard entsprechen und zumindest grundsätzlich (Stichwort: Profile) mit einander kommunizieren können. Bluetooth-Geräte arbeiten im lizenzfreien 2,4 GHz ISM-Band (Industrial Scientific Medicine). In den meisten Ländern umfasst dies die Bandbreite von MHz bis MHz. In einigen Ländern z.b. Spanien, Japan und Frankreich (2.446, ,5 MHz) ist die zur Verfügung stehende Bandbreite weiter eingeschränkt. Geräte, die dieses reduzierte Frequenzband nutzen, arbeiten nicht mit Geräten zusammen, die für die volle ISM-Bandbreite entwickelt wurden. Eine Lösung dieses Problems ist im Rahmen der Bluetooth-SIG angestrebt. Innerhalb des Frequenzbandes für die Bluetooth-Kommunikation kommt ein Frequenz-Hopping- 2

3 Verfahren (FHSS; Frequency Hopping Spread Spectrum) in 79 Schritten mit einem Abstand von je 1 MHz zum Einsatz. Die Frequenzwechsel erfolgen Mal pro Sekunde (Hops/s). Dieses Verfahren bietet neben der vorhandenen Verschlüsselung einen weiteren Schutz gegen unerlaubtes Abhören und Unterwandern eines Bluetooth-Netzwerkes. Weiter wird dadurch eine gewisse Robustheit gegenüber Störungen im Hochfrequenzbereich (HF) gewährleistet, da bei einer Störung nicht die gesamte Übertragung betroffen ist, sondern im Idealfall nur ein Datenpaket verloren geht, welches dann auf einer anderen Frequenz wiederholt übertragen werden kann. In diesem Zusammenhang sollte nicht vernachlässigt werden, dass das lizenzfreie ISM-Band von zahlreichen Funkdiensten (u.a. WLAN b) genutzt wird und überdies Mikrowellenherde frequenzmäßig eng benachbart sind. Die Reihenfolge, mit der die Frequenzwechsel erfolgen, wird als Hop-Sequenz (FHS; Frequency Hopping Sequence) bezeichnet und vom Master (die Station, über die in einem Pico-Netz alle Verbindungen laufen) festgelegt. Die Geräte innerhalb eines Pico-Netzwerkes lassen sich anhand einer 48 Bit langen unverwechselbaren Seriennummer eindeutig identifizieren. In Pico-Netzwerken mit 2 oder mehr Teilnehmern muss ein Gerät und kann auch nur ein Gerät die Funktion des Masters übernehmen. Bei der Bluetooth-Technologie kommt als Modulationsverfahren Gaussian-(shaped)-Frequency- Shift-Keying (GFSK) zum Einsatz. Eine binäre Eins wird dabei durch einen positiven und eine binäre Null durch einen negativen Frequenzhub dargestellt. Die Datenübertragung in Vorwärts- und Rückwärtsrichtung erfolgt zeitlich getrennt (Time Division Duplex; TDD) im Halbduplex-Betrieb (HDX; Half Duplex). Sender und Empfänger tauschen dabei ihre Daten abwechselnd in festgelegten Zeit-Slots aus. Eine Slot-Länge beträgt 625 µs. Für jeden Slot wird eine andere Frequenz verwendet. Die maximal erreichbare Datenrate inkl. Header ist dabei 1 MBit/s. 3

4 2.2 Bluetooth System 2,4 GHz Bluetooth Radio Bluetooth Link Controller Bluetooth Linkmanager & IO HCI HCI Host Layer Anwendung Bluetooth Controller Host System Abbildung 2.2.1: Aufbau eines Bluetooth-Systems (Quelle: /4/ S.57) Bluetooth-Radio Das Bluetooth-Radio bildet die Sende-Empfangseinheit, ist somit für die HF und die Luftschnittstelle verantwortlich. Der HF-Träger wird innerhalb dieser Baugruppe erzeugt, respektive empfangen und es wird dessen Modulation bzw. Demodulation vorgenommen. Diese Komponente wird meist skalierbar ausgelegt, so dass Sendeleistungen zwischen 0 und 20 dbm zur Verfügung stehen Bluetooth-Link Controller Auf dem Bluetooth-Link Controller sind die Funktionen des Basisbandes implementiert, er stellt somit die Bluetooth-Funktionalität bereit. Er ist u.a. verantwortlich für Datenpakete, Kanalverwaltung (physikalische und logische), Frequenz-Hopping, Adressierung, Sicherheit, Empfangsund Sendetiming und Fehlerkorrektur Bluetooth-Linkmanager & IO Der Bluetooth-Linkmanager verwaltet alle anfallenden Telegramme über virtuelle logische Kanäle und ermöglicht die Definition von Dienstgüten (QoS Quality of Service), Schlüsselverwaltung für die Authentifizierung und Power-Management. Er stellt alle wesentlichen Funktionen zur Verfügung um den höheren Schichten ein einfaches Kommunikationsmodell anbieten zu können. Sämtliche Leistungen zum Verbindungsaufbau, Verbindungsabbau und zur Pico-Netzverwaltung werden von ihm erbracht. Hierzu werden alle Datenpakete, welche durch die Basisband-Schicht den Controller erreichen, gefiltert und die Steuersignale herausgezogen. Bluetooth-Geräte können auf der Link-Manager-Ebene miteinander kommunizieren, ohne dass das Host-System irgendetwas davon mitbekommt. D.h., es wird eine vollkommene Transparenz zu höheren Protokollschichten erreicht. 4

5 Die zuvor genannten Bestandteile eines Bluetooth-Systems entsprechen der Hard- und Firmware eines Bluetooth-Moduls und werden in der Regel als eine fertige Komponente zugekauft. Bluetooth-Module zur Erweiterung eines Host-Systems stehen z.b. für USB-, UART-, PCCardoder PCMCIA-Schnittstellen zur Verfügung. Damit das Host-System und der Bluetooth-Controller miteinander kommunizieren können, muss es eine Zwischenschicht geben, welche die physikalische Ankopplung beider Rechnersysteme ermöglicht. Diese damit verbundenen Aufgaben werden vom Host Controller Interface übernommen Host Controller Interface (HCI) Das Host Controller Interface definiert den Übergang des controllerseitigen Link-Protokolls und des hostseitigen Link-Protokolls über die o.g. Schnittstellen. Auf dem Host-System läuft das Logical Link Control and Adaption Protocol (L2CAP), darauf setzt der Rest des Bluetooth-Protokollstacks auf. Die spezifizierten Bluetooth-Protokolle sind also mehr oder weniger direkt mit der gesamten Hardware verbunden. In der Bluetooth-Spezifikation sind verschiedene HCI-Protokolle für unterschiedliche Schnittstellen definiert. Eine Gliederung ist wie folgt möglich: - in eine allgemeine Beschreibung des Host Controller Interfaces - in eine Beschreibung der schnittstellenspezifischen Transportschicht (z.b. HCI USB, HCI RS232, HCI UART) - in eine zugehörige HCI-Schnittstellen Beschreibung Die spezifische HCI-Schnittstellen Beschreibung betrifft die entsprechende Implementation in einem z.b. USB-Bluetooth-Modul. Bluetooth-Module kommunizieren in jedem Falle über diese Interface mit ihrem Host, dabei ist es nicht von Bedeutung, welche physikalische Schnittstelle die Daten überträgt. (Abbildung 2.2.2) Die Kommunikation erfolgt also völlig transparent. Zum physikalischen Bus existiert auf dem Host- System ein geeigneter Treiber. Oberhalb des Bustreibers setz der HCI-Treiber auf, der die Schnittstellendaten aufnimmt und an die darüber liegenden Host-Layer-Protokolle weiterleitet Host Layer Der Host-Layer stellt schließlich der jeweiligen Anwendung die Daten zur Verfügung. Zu den Host-Layer-Protokollen, also zur Software, die als Treiber auf dem jeweiligen Host implementiert ist, gehören die Bluetooth-Core-Protokolle (L2CAP, SDP), das Kabelersatzprotokoll (RFCOMM) und der Telephony-API. Die unter bis aufgeführten Komponenten gehören zu einem vollständigen Bluetooth- Protokollstack. 5

6 Auf allen korrespondierenden Hosts (min. 1, max. 7) ist eine vergleichbare Hardware-Firmware- Protokoll-Struktur implementiert. Host (A) Anwendung Host (B) Bluetooth Funkstrecke Bluetooth Funkstrecke High-Level-Treiber High-Level-Treiber Basisband Controller Basisband Controller HCI-Treiber HCI HCI Firmware Link Manager Firmware Link Manager Firmware HCI Firmware HCI HCI-Treiber Bus-Treiber Physik Bus-Firmware Bus-Firmware Physik Bus-Treiber USB, PCI, PCMCIA, UART... USB, PCI, PCMCIA, UART... Abbildung 2.2.2: Bluetooth Treiber (Quelle: /4/ S.122) Anwendung Als letzte Stufe eines Bluetooth-Systems folgt schließlich die jeweilige Anwendung. Hierfür sind entsprechende Anwendungsprotokolle, die so genannten Adopted Protocols erforderlich. Sie gewährleisten eine Interoperabilität mit bisherigen Systemen, wurden in der Regel unverändert übernommen und entsprechen damit dem Industriestandard. Wichtige angepasste Protokolle z.b. für mobiles Internet sind IP, TCP, UDP, PPP und WAP. Aber auch Protokolle für den Datei- oder Objektaustausch spielen eine wichtige Rolle. Hier sei beispielhaft das OBEX-Protokoll (Object Exchange Protocol) genannt. Die angepassten Protokolle bilden die Grundlage für die jeweilige Applikation. 2.3 Netztopolgie Der Bluetooth-Standard zeichnet sich dadurch aus, Adhoc-Netzwerke bilden zu können. D.h., es können zwei oder mehr Geräte mit einander kommunizieren ohne vorherige Kenntnis von einander zu haben. Allerdings bedarf es dazu einer ausgezeichneten Station, die den Zugriff auf die Luftschnittstelle regelt. Eine derartige Station wird als Master bezeichnet. Ein Bluetooth-Master ist in der Lage, mit bis zu sieben aktiven Slaves in Kommunikation zu treten. Slaves und Master bilden zusammen ein Pico-Netz. Gehören zu diesem Pico-Netz mehr als sieben Slaves müssen sich diese im so genannten Park-Modus befinden. 6

7 Bezüglich der Netzwerkeigenschaften des Pico-Netzes ist der Master das bestimmende Element. Er legt die Hop-Sequenz (FHS) fest. Alle Slaves im jeweiligen Pico-Netz müssen sich mit dem Master synchronisieren, um an der Kommunikation teilnehmen zu können. Kein Slave darf dem Master unaufgefordert ein Telegramm übermitteln. Nur auf Anfrage des Masters ist er berechtigt, Daten auszutauschen. Durch diesen Mechanismus ist gewährleistet, dass mit verhältnismäßig wenig Aufwand eine Kommunikation zwischen mehreren Teilnehmern störungsfrei erfolgen kann. Dabei ist anzumerken, dass ein Datenaustausch zwischen zwei Slaves immer zwangsläufig über den Master erfolgt, welcher dabei das in erster Linie limitierenden Element bei einem solchen Übertragungsweg darstellt. Eine Besonderheit des Bluetooth-Standard besteht darin, dass ein Bluetooth-Device, wenn es in ein bestehendes System eingebunden wird, gleichzeitig Master und Slave ist. Erst während des Kommunikationsaufbaus, beispielsweise aufgrund einer Anwendung, entscheidet sich, welche Rolle das Gerät einnimmt. Diese Rolle kann auch während der Kommunikation gewechselt werden. Üblicherweise ist bei Bluetooth-Systemen das Gerät Master, welches das Rufverfahren (Paging) einleitet. Der Bluetooth-Standard lässt zu, dass mehrere Pico-Netze innerhalb der Reichweite nebeneinander parallel existieren. Dies ist möglich, da jeder Master die Kommunikation in seinem Pico-Netz durch eine individuelle Hop-Sequenz steuert. Die verschiedenen Hopping-Schemata sind so definiert worden, dass es möglichst zu keinen Überschneidungen und Interferenzen kommt. Besteht eine Kommunikationsbeziehung zwischen zwei Pico-Netzen über z.b. einen gemeinsamen Slave, spricht man von einem Scatter-Netz. Die Bluetooth-Spezifikation sieht vor, dass ein Device in einem Netz Master und in einem anderen gleichzeitig Slave sein kann. Theoretisch ist es möglich, Nachrichten über eine Scatter-Netz-Struktur weiterzuleiten, jedoch gibt es z.z. noch keine Musterapplikationen, die diese Funktionalität implementiert haben. Pico-Netz Scatter-Netz Stand by Slave Master Slave Master Stand by Stand by Master Slave Slave Slave Slave Slave Abbildung 2.3.1: Pico- und Scatter-Netze 7

8 2.4 Verbindungsarten Prinzipiell stellt der Bluetooth-Standard zwei unterschiedliche Datenkanäle zur Verfügung. Für synchrone Übertragung gibt es die so genannte SCO-Verbindung (Synchronous Connection Oriented), für die asynchrone Kommunikation die ACL-Verbindung (Asynchronous Connectionless Link). Erstere stellt eine leitungsvermittelte synchrone Kommunikation, letztere eine paketvermittelte asynchrone Kommunikation dar. 64 kbit/s 732,2 kbit/s 433,9 kbit/s Sprache 64 kbit/s Daten asymmetrisch 57,6 kbit/s Daten symmetrisch 433,9 kbit/s 64 kbit/s Synchrone Kommunikation (leitungsvermittelt) Asynchrone Kommunikation (paketvermittelt) Abbildung 2.4.1: Bluetooth-Kommunikationsarten (Quelle: /4/ S.58) SCO-Verbindung SCO-Verbindungen werden nach der aktuellen Bluetooth-Spezifikation nur für die Übertragung von Sprachdiensten verwendet, da Sprachdaten wirklich synchron, d.h. deterministisch übertragen werden müssen. Abweichungen wie z.b. Laufzeitverzögerungen wären sofort als Hall, Echo oder sonstige Störgeräusche hörbar. Bei der synchronen Kommunikation wird vom Master eine Punkt-zu-Punkt-Verbindung aufgebaut. Es werden eine bestimmte Menge an Zeitslots in einem genau definierten Abstand reserviert und bilden somit einen synchronen Datenkanal. Ist dieser einmal eingerichtet, bleibt bis zum Abbau der Verbindung zwischen Master und Slave die reservierte Bandbreite erhalten, egal ob sie benötigt wird oder nicht. Ein Master ist in der Lage mehrere SCO-Verbindungen gleichzeitig aufzubauen und zu verwalten. Im Rahmen einer Master-Slave-Verbindung können gleichzeitig 3 SCO-Links etabliert werden. Dadurch ist z.b. die Übertragung eines Stereo-Signals und eines weiteren Sprachkanals zeitgleich möglich. SCO-Links sind immer bidirektional, d.h. es können gleichzeitig 3-kanalige Signale mit 8

9 einer Datenrate von 64 kbit/s synchron versendet werden. Synchrone Verbindungen von einem Master zu mehreren Slaves sind ebenfalls möglich. Hierfür stehen allerdings nur maximal zwei parallele SCO-Links zur Verfügung. Ein SCO-Kanal ist immer symmetrisch, für Hin- und Rückkanal ist in jedem Fall die gleiche Bandbreite reserviert ACL-Verbindung Für alle Datenpakete, die keine Sprachdaten enthalten, verwendet Bluetooth einen asynchronen Kommunikationskanal. Eine Datenübertragung ist dabei sowohl symmetrisch, als auch asymmetrisch möglich. Bei einer symmetrischen ACL-Verbindung können zwischen Master und Slave maximal 433,9 kbit/s quasi gleichzeitig übertragen werden, asymmetrische Kommunikation ermöglicht sogar auf dem Hin- oder Rückkanal bis zu 732,2 kbit/s. Für den jeweils anderen stehen dann allerdings nur noch 57,6 kbit/s zur Verfügung. Eine ACL-Verbindung beruht auf Paketvermittlung. Das setzt ein speicherndes Verhalten der Übertragungsgeräte voraus und stellt eine besonders effiziente Möglichkeit der Übermittlung von Daten dar. Allerdings ist dabei zu beachten, dass im Gegensatz zur Leitungsvermittlung keine definierte Zeit angegeben werden kann, innerhalb derer die Daten den Empfänger erreichen. Die Übertragung erfolgt asynchron. Es sei nochmals darauf hingewiesen, dass jedes Bluetooth-Gerät nur genau einen asynchronen Datenkanal besitzt und über diesen alle Dienste, sowohl das Versenden von Nutzpaketen als auch der Austausch von Steuerinformationen erfolgen, was je nach Anzahl der Steuerinformationen zu Einschränkungen führen kann. Auf der Basis von ACL-Datenpaketen ist eine Gruppenkommunikation innerhalb eines Pico-Netzes möglich. Die Adressierung erfolgt durch eindeutige Stationsadressen, die während des Konfigurationsvorgangs ermittelt werden. Der Master ist in der Lage, im Sinne einer Punkt-zu-Multipunkt-Verbindung, jedem Slave eine Nachricht zu zusenden. Dazu müssen die entsprechenden Datenpakte nur seine Masteradresse erhalten Kombination von SCO- und ACL-Verbindungen Ein Bluetooth-Master kann gleichzeitig mehrere unterschiedliche Datenkanäle zu seinen Slaves aufrechterhalten. Die Begrenzung liegt hier bei maximal zwei bzw. drei SCO-Links und der maximal über einen Bluetooth-Kanal übertragbaren Symbolrate. Zwischen den reservierten SCO- Slots wird die übrige Bandbreite nach dem Best-Effort-Prinzip auf die ACL-Datenpakete verteilt, wobei die Steuerpakete wiederum priorisiert übertragen werden. Nicht zuletzt haben die Art der verwendeten Datenpakte und somit die entsprechende Fehlerkodierung und damit wiederum die Nettodatenrate einen ganz wesentlichen Einfluss auf die Menge der möglichen logischen Verbindungen. 9

10 2.5 Bluetooth-Protokollstack Übersicht Bluetooth-Protokollstack vcard/vcal OBEX AT- Befehle WAE WAP TCS BIN SDP UDP TCP IP PPP BNEP RFCOMM Audio L2CAP Hostcontroller Schnittstelle LMP Basisband Bluetooth-Funk Abbildung 2.5.1: Bluetooth-Protokollstack Bluetooth im ISO-OSI-Schichtenmodell ISO-OSI-Schichtenmodell Bluetooth-Schichtenmodell 7 Verarbeitung Application 6 Darstellung 5 Sitzung UDP TCP IP 4 3 Transport Vermittlung BNEP RFCOMM PPP SDP 2 Sicherung LLC MAC L2CAP Baseband LM 1 Bitübertragung RF Abbildung 2.5.2: ISO-OSI-Schichtenmodell vs. Bluetooth-Schichtenmodell 10

11 Die Bluetooth-Kernprotokolle entsprechen im wesentlichen der Schicht 1 und 2 im ISO-OSI- Referenzmodell. Darüber liegende Schichten werden von den anwendungsspezifischen Protokollen, den angepassten Protokollen (Adopted Protocols), repräsentiert Die Kernprotokolle Um eine reibungslose Zusammenarbeit der verschiedenen Bluetooth-Geräte zu gewährleisten, werden von der Bluetooth-Spezifikation die Kernprotokolle und das Protokoll des Bluetooth-Funks vorgeschrieben. Diese Protokolle wurden im Rahmen der Bluetooth-SIG definiert. Teilweise wurde dabei auch auf vorhandene Standards zurückgegriffen und diese an die Bluetooth Umgebung angepasst (z.b. bei RFCOMM und TCS BIN). Die anwendungsspezifischen Protokolle sind kein Muss und können je nach Bedarf und Verwendungszweck implementiert werden Basisband Im Basisband sind fast alle wichtigen Technologien implementiert, wie z.b. der Aufbau von Pico- Netzen, die Verwaltung der Datenkanäle (SCO- und ACL-Verbindungen), das Frequenzhopping, das Time-Division-Duplexing, die Datenpakete, die Adressierung von Bluetooth-Geräten, die Abfrage- und Paging-Mechanismen zur Synchronisation und die Systemsicherheit Link Manager Protocol (LMP) Das Link-Manager-Protokoll wickelt ausschließlich die Kommunikation zwischen den Link- Managern von zwei Bluetooth-Geräten ab. Es umfasst die Mechanismen zum Auf- und Abbau sowie der Kontrolle von Verbindungen zwischen den Geräten und ermöglicht die Definition von Dienstgüten (QoS Quality of Service), die Kontrolle der Betriebszyklen der Funkeinheit, des Verbindungsstatus und der Energiemodi. Außerdem wird die Funktionalität für die Schlüsselgenerierung, -verwaltung und -überprüfung für die Authentifizierung zur Verfügung gestellt. Die LMP-Nachrichten werden auf der Empfängerseite aus den vom Basisband übergebenen Datenpaketen herausgefiltert und vom Link-Manager verarbeitet. Diese Nachrichten haben immer eine höhere Priorität als Benutzerdaten und erreichen niemals höhere Schichten. 11

12 Bluetooth-Protokoll-Schicht Komponenten des Protokollstacks Bluetooth-Kernprotokolle Basisband LMP (Link Manager Protocol) L2CAP (Logical Link Control and Adaption Layer) SDP (Service Discovery Protocol) Bluetooth spezifische Protokolle BNEP (Bluetooth Network Encapsulation Protocol) Kabelersatzprotokoll Telefonieprotokolle Adaptierte Protokolle RFCOMM (Radio Frequency Communication) TCS BIN (Telephony Control Specification Binary) AT-Befehle PPP (Point-to-Point Protocol) UDP (User Datagram Protocol) TCP (Transmission Control Protocol) IP (Internet Protocol) OBEX (Object Exchange Protocol) WAP (Wireless Application Protocol) vcard (Visitenkartenaustausch zw. Bluetooth-Geräten) vcalendar (Terminabgleich über Bluetooth) IrMC (Infrared Mobile Communications) WAE (Wireless Application Environment) Tabelle 2.5.1: Komponenten des Bluetooth-Protokollstacks Logical Link Control and Adaption Layer Protocol (L2CAP) Das L2CAP ist das zweite Linkmanager-Protokoll oberhalb des Basisbandes. Im Gegensatz zum LMP, was sich um die controllerseitige Kommunikation kümmert, bildet das L2CAP die hostseitige Programmierschnittstelle. Die Hauptaufgaben des L2CAP sind: - die zeitgleiche und völlig transparente Übertragung von Datenpaketen verschiedener höherer Protokollschichten - das Segmentieren großer Datenpakete - die Bereitstellung definierter Dienstgüten - die Gruppenverwaltung Obere Protokollschichten können auf ein Kanalkonzept seitens des L2CAP zurückgreifen, welches ermöglicht über eine asynchrone Verbindung quasi zeitgleich mehrere Protokolle zu übertragen. Dabei werden sowohl verbindungsorientierte als auch verbindungslose Datendienste unterstützt. Das L2CAP unterstützt Datenpakete bis zu einer Größe von 64kByte und setzt diese in entsprechende Basisband-Pakte um. Diese Paketgröße ist von besonderer Bedeutung, da sich oberhalb des L2CAP der Network-Layer befindet und 64kByte eine Kompatibilität zu IP-Paketen gewährleisten. Die logische Link-Schicht unterstützt ausschließlich die Kommunikation über den asynchronen Kanal (ACL). Der SCO-Kanal wird nicht unterstützt. Daraus ergeben sich folgende Einschränkungen: Es wird kein Transport von Audiosignalen ermöglicht und auch kein Kanal für 12

13 eine sichere Übertragung zur Verfügung gestellt. Die Kommunikation mit Gruppen ist nur via Broadcast möglich. Eine zuverlässige Multicast-Verbindung ist nicht implementierbar Service Discovery Protocol (SDP) Das SDP ist ein weiteres hostseitiges Bluetooth-Protokoll und verwaltet in einer Service-Datenbank die auf dem Gerät verfügbaren Dienste. Diese können dann von einem dienstsuchenden Gerät abgefragt bzw. genutzt werden. Alle Einträge in der Dienst-Datenbank sind kategorisch hierarchisch gegliedert und mit den notwendigen Informationen versehen, wie der gesuchte Dienst erreicht werden kann. SDP liefert nur die Information über die von einem Bluetooth-Gerät angebotenen Dienste. Eine Vermittlung zwischen den einzelnen Geräten und Diensten erfolgt nicht Das Kabelersatzprotokoll Radio Frequency Communication (RFCOMM) Das RFCOMM-Protokoll ist das erste Protokoll oberhalb der Kernprotokolle. Es ist auf dem Host- System implementiert und stellt dem Betriebsystem die jeweiligen Cabel-Replacement-Dienste zur Verfügung. Wegen seiner RS232-Schnittstellen-Emulation spielt es eine zentrale Rolle im Bluetooth-Protokollstack. Es kann bis zu 60 virtuelle serielle Schnittstellen mit einer maximalen Datenrate von je 115 kbit/s simulieren und basiert auf dem ETSI (European Telecommunication Standard Institute) Standard TS (Technical Standard) 07.10, wobei nur ein Teil der dort beschriebenen Funktionen von Bluetooth verwendet wird. Das RFCOMM-Protokoll wird u.a. für den Aufbau einer PPP-Verbindung über Bluetooth benötigt. Diese Verbindung ist Grundlage für das DUN-Profil (Dial Up Networking), welches eine Möglichkeit darstellt, das IP (Internet Protocol) über Bluetooth zu realisieren Bluetooth Network Encapsulation Protocol (BNEP) Das BNEP definiert den einheitlichen Transport von Netzwerkpaketen über eine Bluetooth- Verbindung. Für Adhoc-Netzwerke ist ein einheitliches Paketformat Grundvoraussetzung. BNEP übernimmt in Bluetooth-Netzwerken bezüglich des Internetprotokolls (IP) dieselbe Funktion, die in lokalen Netzwerken das Netzwerkprotokoll Ethernet ausübt. D.h. es kapselt diverse Netzprotokolle (IPv4, IPv6, IPX) und leitet die Datenpakte direkt an L2CAP weiter. 13

14 Das BNEP wird u.a. für Verbindungen zwischen Bluetooth-Geräten unter Verwendung des PAN- Profils (Private Area Networking) benötigt. Dies stellt die einzige Möglichkeit dar IP over Bluetooth in Bluetooth-Adhoc-Netzwerken zu realisieren Adaptierte Protokolle (Adopted Protocols) Die letzte Stufe des Bluetooth-Protokollstacks umfasst die jeweiligen Anwendungen. Hierfür wurden bereits existierende Protokolle übernommen und gegebenenfalls an die Bluetooth- Umgebung angepasst. Dies sichert eine Zusammenarbeit mit bereits bestehenden Anwendungen, die bisher auf anderen Übertragungsstandards aufsetzen. Eine Kooperation mit zukünftigen Anwendungen ist dadurch einfacher und relativ unproblematisch zu realisieren. Die adopded Protocols wurden zum Großteil unverändert übernommen und entsprechen somit dem Industriestandard Point-to-Point Protocol (PPP) PPP ist das Sicherungsprotokoll im Internet unterhalb vom IP. Es definiert, wie IP-Datagramme über eine serielle Punkt-zu-Punkt-Verbindung übertragen werden. Es kommt beispielsweise zur Anwendung, wenn man sich mit einem Modem ins Internet einwählt. In diesem Fall wird über die serielle Modemverbindung eine Punkt-zu-Punkt-Verbindung aufgebaut. Das PPP bietet im wesentlichen folgende Funktionalitäten: Eine Methode zur Erstellung von Datenrahmen, ein Protokoll zur Verbindungssteuerung (LCP; Link-Control-Protocol) und das Aushandeln von Funktionen der Vermittlungsschicht, unabhängig vom verwendeten Schicht 3 Protokoll (NCP; Network-Control-Protocol). Auf Basis des LCP-Protokolls von PPP werden Verbindungsdaten zwischen den beiden miteinander kommunizierenden Rechnern hinsichtlich Rahmenlänge, Übertragungsgeschwindigkeit und einer Vielzahl weiterer Parameter ausgetauscht. Bei erfolgreichem Verbindungsaufbau wird die Konfiguration der Vermittlungsschicht über NCP-Pakete realisiert, die innerhalb eines PPP- Rahmens versendet werden. Mit Hilfe des NCP ist z.b. die Zuweisung von dynamischen IP- Adressen möglich. Der Verbindungsabbau erfolgt ebenfalls über LCP-Pakete. Der PPP-Rahmen weicht nur unwesentlich vom HDLC-Protokoll-Standard (High-Level Data Link Control Protocol) ab. Er arbeitet allerdings Zeichen- und nicht Bit-orientiert und kommt mit relativ wenig Protokoll-Overhead aus. 14

15 Internet Protocol (IP) Wie der Name schon sagt, ist IP das Protokoll auf dem der Grossteil der Funktionsweise des Internets beruht. Es ist für die richtige Zustellung und Wegewahl der Datenpakte (Routing) verantwortlich und kümmert sich um die Überlastüberwachung (Traffic-Shaping) der Datenkanäle. Ein geeigneter Routing-Algorithmus vorausgesetzt, können alternative Routen für besonders wichtige Daten oder auch bei Überlast bestimmter Kanäle berechnet werden. IP unterstützt einen verbindungslosen Dienst. Die Datagramm-Übertragung erfolgt in IP-Rahmen, die ohne Nutzdaten eine Mindestlänge von 20 Bytes aufweisen. Typische IP-Datagramme haben Größen zwischen Bytes und 64 kbytes. Quell- und Zieladresse müssen weltweit eindeutig definiert sein. Daraus resultieren die IP-Adressen, die durch das NIC (Network Information Center) weltweit verwaltet werden. Der aktuell verwendete Standard IPv4 (IP Version 4) soll zukünftige durch IPv6 (IP Version 6) abgelöst werden Transmission Control Protocol (TCP) Das TCP realisiert einen zuverlässigen, verbindungsorientierten Dienst oberhalb des unzuverlässigen, verbindungslosen Internet Protokolls. Es gehört zur Transportschicht und kümmert sich um den Kommunikationsaufbau, die Flusssteuerung und kontrolle und die Durchnummerierung der Datenpakete. Der Datenaustausch zwischen zwei Geräten erfolgt über TCP-Datagramme. Mit Hilfe des TCP kann gewährleistet werden, dass ein beliebiger Bytestrom von einem Gerät zu einem anderen zuverlässig übertragen wird. Da IP die Datenpakete über beliebige Kanäle mit unterschiedlichen Laufzeiten und Auslastungen versendet, muss das TCP auf der Empfängerseite dafür sorgen, dass die Pakete auch wieder in der richtigen Reihenfolge zusammen gesetzt und eventuell verlorene Daten erneut übertragen werden. Um zu vermeiden das schnelle Sender langsame Empfänger überlasten, wurde eine Flusssteuerung im TCP implementiert. Die Kommunikation zur darüber liegenden Anwendungsschicht erfolgt über Ports (TSAP; Transport Service Access Ports). Dadurch wird es möglich, ein ganzes Spektrum von Diensten auf einem einzigen Host zu verwalten. IP-Adresse + Port ermöglichen eine weltweit eindeutige Adressierung eines Dienstes auf einem Rechner. Eine Vielzahl von so genannten Wellknown Ports sind in den RFC s (Request for Comments) bereits definiert (z.b. FTP; File Transfer Protocol 21, Telnet 23, http; Hyper Text Transfer Protocol 80). Darüber hinaus können weitere Ports vereinbart und individuelle Dienste angesprochen werden. 15

16 User Datagram Protocol (UDP) Das UDP bietet einen unzuverlässigen, verbindungslosen Dienst auf der Grundlage des IP an. Daten werden nach dem Best-Effort-Prinzip über eine Ende-zu-Ende-Verbindung übertragen. UDP bietet keinerlei Garantie für ordnungsgemäße Datenübermittlung. Soll dennoch eine sichere Übertragung realisiert werden, muss eine Telegrammsicherung in der Applikation erfolgen. Wie auch TCP wird UDP ebenfalls über Ports abgewickelt. UDP eignet sich besonders für Client-Server-Anfragen (z.b. Ping), das Versenden von Broadcast-Nachrichten und Telegrammen mit verhältnismäßig wenig Overhead. Auf weitere Protokolle soll an dieser Stelle nicht eingegangen werden, da sie für das Thema der vorliegenden Studienarbeit nur eine untergeordnete Rolle spielen. Im Rahmen des LISTIG- Projektes erfolgt die Datenübertragung mit Hilfe von TCP/IP bzw. UDP, deshalb wurde sich hier auf die möglichen Realisierungen dieser Protokolle beschränkt. 2.6 Bluetooth-Profile Übersicht grundlegende Bluetooth-Profile Generic Access Profile (GAP) Service Discovery Application Profile (SDAP) Private Area Network Profile (PAN) Telephony Profile Serial Port Profile (SPP) Intercom Profile (IntP) Cordless Telephon Profile (CTP) Dial Up Network Profile (DUNP) LAN Access Profile (LAP) FAX Profile (FaxP) Headset Profile (HSP) Generic Object Exchange Profile (GOEP) File Transfer Profile (FP) Object Push Profile (OPP) Synchronisation Profile (SP) Abbildung 2.6.1: Bluetooth-Profile 16

17 Von der Bluetooth-SIG sind verschiedene Einsatzmodelle für Bluetooth-Geräte spezifiziert worden. Jeder Einsatzbereich spiegelt sich in einem Bluetooth-Profil wieder. Ein solches beschreibt, welche Protokolle und Funktionen unterstützt werden müssen, damit ein Gerät dem Einsatzmodell entsprechen. Es beschreibt die vertikale Sicht im Protokollstack. Dabei müssen nicht immer zwingend alle Funktionen einer Schicht implementiert sein. Innerhalb der Profile sind die verschiedenen notwendigen und optionalen Funktionen definiert. Anhand der Profile wird im Qualifizierungsprozess die Interoperabilität von Geräten sicher gestellt. Die Bluetooth-Spezifikation definiert vier grundlegende Profile und mehrere darauf aufbauende Einsatzmodelle. Unterschiedliche Arbeitsgruppen arbeiten im Rahmen der SIG daran diese um weitere Einsatzgebiete zu ergänzen. Die vier grundlegenden Profile sind (Quelle: /4/ S.224): 1. GAP Generic Access Point GAP definiert die allgemeinen Prozeduren für die Erkennung von Geräten, den Verbindungsaufbau sowie das Verbindungsmanagement. 2. SDAP Service Discovery Application Profile Das SDAP beschreibt die grundlegende Funktionalität von Service-Discovery- Anwendungen. Es nutzt das SDP, um Dienste anbieten zu können und einem Gerät mitzuteilen, welche Protokolle bzw. Profile unterstützt werden. 3. SPP Serial Port Profile Das SPP wird immer dann verwendet, wenn Bluetooth als Kabelersatz zum Einsatz kommt. Auf SPP basieren die Profile für Fax- und LAN-Dienste. 4. GOEP Generic Object Exchange Profile Immer dann, wenn komplexe Datenobjekte ausgetauscht werden, kommt das GOEP zum Einsatz. Es definiert die Verwendung des OBEX-Protokolls innerhalb von Bluetooth und hierbei im Besonderen den Dateitransfer, aktives Pushen von Objekten sowie die Synchronisation von Datenobjekten Möglichkeiten eine IP-Verbindung über Bluetooth zu realisieren Lediglich drei Profile sind in der Lage, ein IP-Netzwerk zu realisieren und damit die in der Aufgabenstellung der Studienarbeit geforderte Funktionalität zu liefern. Im folgenden soll nur auf diese drei eingegangen werden. Informationen über weitere Profile sind der Literatur (/4/,/5/) zu entnehmen. 17

18 Local Area Network Access Profile (LAP) Das LAP realisiert einen LAN-Zugriff über das serielle Kabelersatz-Protokoll (RFCOMM). Es definiert die verschiedenen Geräterollen und wie eine PPP-Verbindung in verschiedenen Szenarien verwendet wird. Eine Geräterolle ist die des LAN-Zugriffspunktes (LAP; LAN Access Point). Über ihn erfolgt der Zugriff aus das kabelgebundene Netzwerk. Die zweite Geräterolle ist das Datenterminal (DT), welches die Dienste des LAP nutzt und beispielsweise ein PC, Laptop, PDA oder Mobiltelefon sein kann. Dabei sind 3 verschiedene Szenarien vorgesehen: 1. Ein Datenterminal nutzt einen LAP für den drahtlosen Zugang zu einem bestehenden LAN. Nachdem eine Verbindung erfolgreich aufgebaut wurde, arbeitet das DT so, als wäre es direkt am LAN per Kabelverbindung angeschlossen wurde. 2. Der LAN-Access-Point kann auch als Gateway für mehrere Datenterminals fungieren. In diesem Fall verwaltet der LAP die verschiedenen Datenterminals, gerade so, als wären sie direkt per Kabel mit dem Netzwerk verbunden. Die Datenterminals können dann sowohl mit dem Netzwerk, als auch untereinander über den LAP kommunizieren. 3. Zwei Bluetooth Geräte können auch direkt untereinander über das LAN-Access-Profile verbunden werden. Jeweils ein Gerät muss dabei die Rolle des LAN-Access-Points oder die des Datenterminals übernehmen. Dieses entspricht in etwa einer Kabelverbindung in einem Punkt-zu-Punkt-Netzwerk. Der Verbindungsaufbau wird grundsätzlich durch das Datenterminal initiiert. Das DT sucht nach dem LAP und versucht anhand der Dienstparameter eine Kommunikation aufzubauen. Dabei kann eine Verschlüsselung und Authentifizierung auf der Link-Manager-Ebene erfolgen. Hierzu wird im so genannten Pairing-Prozess eine Bluetooth-PIN für den Verbindungscode ausgetauscht. Oberhalb der Link-Manager-Ebene kann ebenfalls noch mal eine PPP-Authentifizierung erfolgen. Kann sich das DT nicht authentifizieren, wird die PPP-Verbindung abgebaut. Andernfalls wird dem DT durch den LAP eine IP-Adresse zugewiesen. Damit diese Dienste erfolgreich genutzt werden können, ist ein entsprechender Eintrag in der SDP-Datenbank nötig. 18

19 Dial Up Networking Profile (DUNP) Das Dial-Up-Networking Profil beschreibt die Protokolle und Dienste für die Implementierung eines Einwahlzuganges über ein Modem oder Mobiltelefon. Es setzt ebenfalls auf dem Serial-Port- Profile (nutzt RFCOMM) auf und etabliert oberhalb dessen eine PPP-Verbindung als Sicherungsschicht. Datenpakte höherer Protokollschichten werden transparent verarbeitet und der AT-Befehlssatz für die Steuerung der Modem-Befehle ist ebenfalls integriert. Innerhalb des Profils werden zwei verschiedene Geräterollen definiert (Quelle: /4/ S.242): 1. Das Gateway (GW) beschreibt ein Gerät (Mobiltelefon, Modem), das eine Verbindung zu einem öffentlichen Netzwerk aufbauen kann. 2. Das Data-Terminal (DT) verwendet die Dienstleistungen des Gateways. Typische Geräte sind z.b. Laptops, PC und PDAs. In diesem Profil, werden zwei typische Anwendungsszenarien behandelt, zum einen die Verwendung des GW vom DT aus als kabelloses Modem und zum anderen die Verwendung des GW durch ein DT für den Empfang von Datenrufen. Das DUN-Profil bringt folgende generelle Einschränkungen mit sich (Quelle: /4/ S.244): - Das Modem muss nicht in der Lage sein, zwischen unterschiedlichen Anrufarten zu unterscheiden - Nur die Verwendung von 1-Slot-Datenpaketen ist notwendigerweise vorgeschrieben. Hierdurch wird die Datenrate auf 128 kbit/s begrenzt. Optional können höhere Datenraten mit Mehr-Slot-Paketen erreicht werden. - Es wird immer nur ein Anruf verwaltet. - Es gibt keine Möglichkeit zwischen zwei SCO-Kanälen, die von ein und dem selben Gerät stammen, zu unterscheiden. Die Verwaltung der simultanen Sprachkanäle ist nicht standardisiert und wird herstellerspezifisch umgesetzt. - Eine Initialisierung von GW und DT ist vor der ersten Benutzung zwingend nötig. Meist erfolgt dies durch eine manuelle Aktivierung in Verbindung mit der Eingabe der Bluetooth- PIN. Dadurch ist die Realisierung von Adhoc-Netzwerken mit Hilfe des DUN-Profils nur eingeschränkt möglich. - Es werden nicht mehrere Instanzen von diesem Profil auf einem Gerät unterstützt. 19

20 Authentifizierung und Verschlüsselung erfolgen entsprechend den zugrunde liegenden Protokollen. Innerhalb des DUN-Profils sind verschiedene Dienste definiert, wobei z.b. der Fax-Dienst ausschließlich dem Fax-Profil vorenthalten ist und nicht vom Dial-Up-Networking-Profile unterstützt wird. Die unterstützten Dienste müssen auch hier in die SDP-Datenbank auf dem Server eingetragen und somit den Clients zur Verfügung gestellt werden. Abbildung 2.6.2: Realisierung PAN- und DUN-Profil (Quelle: /7/) Privat Area Networking Profile (PAN) Das PAN-Profil nutzt das BNEP und setzt damit direkt auf dem L2CAP auf. Es stellt somit die eleganteste Möglichkeit dar, das IP über Bluetooth zu realisieren. Adhoc-Netzwerk-Funktionalität wird bei Bedarf ebenso bereitgestellt, wie Verschlüsselung und Authentifizierung. Die bei den unter und beschriebenen Profilen benötigten Zwischenprotokolle (RFCOMM, PPP) sind nicht erforderlich. Damit ist der Implementations- und Konfigurationsaufwand deutlich geringer. Im Rahmen des PAN-Profils sind drei mögliche Geräterollen definiert. 1. Der PAN-User (Private Area Network User), ist Client eines Network Access Points (NAP) oder Client Mitglied eines Group Adhoc Networks. 2. Der Group Adhoc Network Controller (GN) ist der zentrale Vermittlungsknoten in einem Peer-to-Peer-Netzwerk (Bluetooth Pico-Netz). Er kann Peer-to-Peer-Netzwerke mit bis zu sieben gleichzeitig aktiven drahtlosen Clients (PANUs) verwalten. 20

21 Dies entspricht in etwa der Infrastruktur, die sich mit Hilfe des DUN-Profils oberhalb von RFCOMM und PPP ebenfalls realisieren lässt. 3. Der Network Access Point (NAP), agiert als Proxy-Server, als Router oder als Bridge zwischen einem existierenden Netzwerk (z.b. LAN) und bis zu sieben gleichzeitig aktiven drahtlosen Clients (PANUs). Dies entspricht in etwa der Infrastruktur, die sich mit Hilfe des LAN-Profils oberhalb von RFCOMM und PPP ebenfalls realisieren lässt. Entweder die Rolle des GN oder die des NAP kann von einem Bluetooth-Gerät, dem Master im entsprechenden Pico-Netz, wahrgenommen werden. Der GN bzw. NAP befindet sich typischerweise im Listen-Mode und wartet auf einen Verbindungsaufbau von Seiten der Clients. Die zur Verfügung stehenden Dienste (GN oder NAP) müssen ebenfalls in der SDP-Datenbank auf dem Master eingetragen werden und sind somit für die Clients erkenn- und nutzbar. PANU PANU PANU LAN Infrastructure PANU GN Stand by NAP PANU PANU PANU PANU PANU PANU Abbildung 2.6.3: PAN-Profil, Master als Group Network Controller vs. Network Access Point 21

22 2.7 Bluetooth Hard- und Software Aktuell sind auf dem Markt Bluetooth-Geräte mit unterschiedlichen Schnittstellen verfügbar. In einigen Laptops (z.b. Sony VAIO PCG-TR1MP) und PDAs (z.b. HP ipaq Pocket-PC h5550) ist Bluetooth bereits serienmäßig integriert. Auch das Nachrüsten eines Rechners ist möglich. Dafür stehen verschiedene Schnittstellen zur Wahl. Zum Ersten die serielle RS232-Schnittstelle, allerdings gibt es hierfür nur sehr wenig Geräte. Am weitesten verbreitet bei den Bluetooth-Geräten ist die zweite Variante, die USB-Schnittstelle. In diesem Zusammenhang spricht man von so genannten USB-Bluetooth-Dongles. Für diese Schnittstelle sind eine Vielzahl von Geräten unterschiedlicher Herstellern (z.b. Acer, AVM Fritz!, Yakumo, Anycom, Epox) verfügbar. Für die Erweiterung von Laptops oder entsprechenden PDAs stehen neben USB weitere Lösungen zur Verfügung, die auf der PCMCIA- oder CF-Card-Schnittstelle aufsetzen. Welche Protokolle, Profile und somit Dienste unterstützt werden ist vom Treiber des jeweiligen Betriebssystems abhängig. Zum Beispiel liefert der Windows-Treiber für das im Rahmen dieser Studienarbeit verwendete Acer BT-500 Bluetooth-Dongel keinen PAN-Support, da das BNEP nicht unterstützt wird. Unter Linux besteht dieses Defizit nicht. Die Linux-Treiber bieten auch in Zusammenarbeit mit dem Acer-Dongel das PAN-Profil an. Die Unterstützung des PAN-Profils unter Windows stellt bei vielen Geräten ein Problem dar. Eines der wenigen Geräte, die dieses unterstützen, ist das AVM BlueFritz! USB-Dongle. Aus diesem Grunde kam dieses Dongle auch auf der Client-Seite im Versuchsaufbau dieser Studienarbeit zum Einsatz. 22

23 3. Bluetooth-Schnittstelle des LISTIG-Systems 3.1 Beschreibung des LISTIG-Systems Abbildung 3.1.1: Hauptplatine des LISTIG-Basisgeräts Den Kern des LISTIG-Basisgerät bildet das 120 mm x 124 mm große Mainbord (Abbildung 3.1.1). Dieses ist bestückt mit einem STPC-Atlas-Prozessor, der passiv gekühlt wird. Der Speicherausbau beläuft sich auf 128 MB SDRAM, 128 kbyte BIOS-Flash-RAM und 8MB Flash-RAM für das Betriebssystem und andere Programme. Als Massenspeicher kann für die Inbetriebnahme und das Debugging eine Standard ATA-Festplatte (IDE) angeschlossen werden. In der verwendeten Ausbaustufe war dies eine 20 GByte Festplatte der Firma Seagate. Als serielle Schnittstelle steht eine COM-Anschluß mit LVTTL-Pegel zur Verfügung. Weitere verwendbare Schnittstellen sind ein PS/2 Anschluss für ein Keyboard, eine 15-polige HDSUB-Buchse für den Anschluss eines VGA-Monitors, ein 18 Bit breites LVTTL-Interface für den digitalen Anschluss eines TFT- Displays und eine 4-polige Stiftleiste für das Nachaußenführen eines USB-Ports. Zusätzliche Erweiterungen sind über zwei PCI-Steckplätze (32 Bit, 5V) möglich. Die Spannungsversorgung kann über ein steckerseitig modifiziertes Standard-PC-Netzteil erfolgen. Das PC-Bios basiert auf dem General Software Embedde BIOS 4.3 und unterstützt das Booten aus einem linearem Flash-Speicher. Als lokales Betriebssystem kommen DOS/Embedded DOS und 23

24 Linux in Frage. Für Debugging Zwecke kann in Verbindung mit der optionalen Festplatte MS Windows 98 oder MS Windows NT 4.0 SP3 oder höher eingesetzt werden. Auf weitere technische Details soll an dieser Stelle verzichtet werden. Diese und noch eine Vielzahl zusätzlicher Informationen sind in der mitgelieferte HFWK STPC-Board Kurzbeschreibung ein zu sehen. Abbildung 3.1.2: Das LISTIG-Versuchssystem 3.2 Konzeption der Bluetooth-Schnittstelle am LISTIG-System Hardware Das LISTIG-Basisgerät bietet folgende infrage kommende Busschnittstellen zur Erweiterung um eine Bluetooth-Schnittstelle: - 2 PCI Slots - 1 serielle RS232-Schnittstelle - 1 USB-Schnittstelle mit nur einem USB-Port 24

25 PCI-Bus: Da aktuell auf dem Markt keine PCI-Karten verfügbar sind, die eine Bluetooth-Schnittstelle direkt aufsetzend auf dem PCI-Bus realisieren, scheidet diese Schnittstelle für die Bluetooth-Erweiterung in erster Näherung aus. Theoretisch wäre aber eine PCI-PCMCIA-Adapterkarte mit entsprechendem PCMCIA-Bluetooth- Modul als eine mögliche Realisierung denkbar. Dabei ist aber zu beachten, dass das LISTIG- System unter Linux läuft und dafür dann entsprechende Treiber sowohl für den PCI-PCMCIA- Adapter, als auch die PCMCIA-Bluetooth-Karte nötig sind. Im Zuge einer ausführlichen Recherche im Internet und entsprechender Literatur stellte sich heraus, dass dafür z.z. unter Linux (noch) kein ausreichender Treiber-Support besteht. Der PCI-Bus scheidet also als mögliche Schnittstelle für eine Bluetooth-Erweiterung aus Serielle Schnittstelle: Die Anzahl der verfügbaren USB-Geräte für die serielle Schnittstelle ist sehr begrenzt. Durch die Treiberunterstützung vor allem unter Linux wird diese Zahl noch weiter eingeschränkt. Für die Infrarot-Schnittstelle, die ebenfalls im Zuge des LISTIG-Projekts realisiert werden soll, stellt die RS232-Schnittstelle den quasi Standard für eine Erweiterung dar. Aus diesen Gründen wurde von einer Bluetooth-Erweiterung auf Basis der seriellen Schnittstelle Abstand genommen USB-Schnittstelle: USB ist die Schnittstelle, für die eine Vielzahl von Bluetooth-Modulen von unterschiedlichen Herstellern aktuell am Markt verfügbar sind. Die Treiberunterstützung ist sowohl unter Windows als auch unter Linux sehr gut. Sie stellt den quasi Standard für eine Bluetooth-Schnittstelle dar. Deshalb wurde bei der Erweiterung des LISTIG-Systems eine USB-Bluetooth-Lösung gewählt. Zum Einsatz kamen dabei auf der Seite des LISTIG-Basis-Gerätes das Acer BT-500 USB-Dongle und auf der Seite des Clients (zu Testzwecken ein Laptop mit MS Windows 98) das AVM BlueFritz! USB-Dongle. Auf das AVM-Dongle wurde deshalb zurückgegriffen, da die mitgelieferten Windows-Treiber ebenfalls das benötigte BNEP und somit das PAN-Profil unterstützen. Dies ist nur bei einer geringen Zahl von Herstellern der Fall Software Auf dem LISTIG-Basisgerät ist standardmäßig als Betriebssystem Debian Linux (Woody) mit einer Kernelversion installiert. Dieser Kernel stellt die niedrigste Version dar, auf dem sich theoretisch eine Bluetooth-Schnittstelle realisieren ließe. Dafür sind allerdings eine Vielzahl von 25

26 zusätzlich zu installierenden Kernel-Patches nötig. In verschiedenen Newsgroups im Internet wird für eine Bluetooth-Implementation zu einem Kernel oder höher geraten. Zu Testzwecken wurde im Laufe der Studienarbeit eine Bluetooth-Schnittstelle auf Basis des Kernels realisiert. Dies stellt eine gut funktionierende und sehr stabile Lösungsmöglichkeit dar. Der Kernel ist eine der letzten Kernelversionen, die für den 2.4.X Kernel-Core entwickelt wurden. Da für die WLAN g-Schnittstelle, die ebenfalls im Rahmen des LISTIG-Projektes zu realisieren war, Mindestvoraussetzung der Kernel ist, wurde im weiteren Verlauf eine Implementierung auf Basis des Kernels vorgenommen. Die Unterschiede zwischen den beiden Kernelversionen hinsichtlich Installation, Konfiguration und Inbetriebnahme der USB-Bluetooth-Schnittstelle sind minimal. Darauf wird an den entsprechenden Stellen dieser Studienarbeit noch einmal gesondert hingewiesen. Als Client für eine Bluetooth-Teststrecke sollte ein Laptop o.ä. mit einem MS Windows Betriebssystem zum Einsatz kommen. Wie bereits erwähnt, ist dabei zu beachten, dass die Windows-Treiber für das entsprechende Bluetooth-Dongle das PAN-Profil unterstützen müssen. Dies ist z.z. nur bei einer sehr geringen Zahl von Bluetooth-USB-Geräten der Fall. Aus diesem Grund wurde für den Client ein USB-Dongle der Firma AVM gewählt. Die beiliegenden Treiber unterstützen das PAN-Profil. Zu Versuchszwecken wurde ebenfalls eine Testverbindung mit einem HP ipaq Pocket-PC h5550 aufgebaut. Die dort integrierte Bluetooth-Schnittstelle in Zusammenarbeit mit dem verwendeten Betriebssystem Windows CE bietet ebenfalls PAN-Profil- Unterstützung. Ein Aufsetzen der clientseitigen Testapplikation war nicht, in erster Linie aufgrund nicht vorhandener Laufwerke oder anderer einfacher Möglichkeiten für Software-Updates, möglich. 3.3 Aufbau und Inbetriebnahme einer Bluetooth Teststrecke Aufbau IP over Bluetooth via BNEP and PAN-Profile Bluetooth Funkstrecke ca m Abstand LISTIG-Basisgerät Acer USB Bluetooth Dongle IP-Adresse: Subnetzmaske: Debian Linux Kernel Client-Laptop AVM BlueFRITZ! USB Dongle IP-Adresse: Subnetzmaske: MS Windows 98 SE Abbildung 3.3.1a: Aufbau Bluethooth-Testumgebung 26

27 3.3.2 Inbetriebnahme Zur Inbetriebnahme wird zu erst das LISTIG-Basisgerät mit dem Kernel gebootet und dann das Acer-USB-Bluetooth-Dongle an den USB-Port angeschlossen. Auf dem Bildschirm sollte nun folgende Meldung zu lesen sein: usb 1-1: new full speed USB device using address 2 D.h. das ein neues USB-Gerät (Version 1.1) gefunden und diesem die Adresse 2 zugewiesen wurde. Wiederholt man den Vorgang, erscheint die gleiche Meldung, lediglich die Adresse erhöht sich jeweils um 1. Danach muss das Kernel-Modul für das USB-Host-Controler-Interface (HCI) geladen werden. Dies erfolgt in der Kommandozeile mit: # modprobe hci_usb Folgende Meldungen sollten nun so oder in ähnlicher Form auf dem Bildschirm erscheinen und damit die Implementierung der HCI-Protokollschicht bestätigen: Bluetooth: HCI device an connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: HCI USB driver ver 2.5 drivers/usb/core/usb.c: registered new driver hci_usb Als nächstes muss das Bluetooth-Dongle in das System eingebunden werden. # hciconfig hci0 up Darauf sollte folgende Ausgabe erscheinen: Kernel driver hci_usb already loaded Ob das Einbinden erfolgreich verlaufen ist, kann man überprüfen, in dem man nochmals 27

28 # hciconfig eingibt. Der folgende Bildschirm sollte in etwa so aussehen: Abbildung 3.3.1b: hciconfig Nun kann nach Bluetooth-Geräten in der Umgebung gescannt werden. Dazu gibt man # hcitool scan ein und erhält folgenden Bildschirm-Ausdruck. Abbildung 3.3.2: hcitool scan Dem kann man nun den Namen der erreichbaren USB-Bluetooth-Devices (hier: AVM BlueFRITZ! USB) und die zugehörige Hardware-Adresse (hier: 00:04:0E:81:F8:D4) entnehmen. Ob auch 28

29 tatsächlich eine Schicht-2-Verbindung besteht, kann man mit einem Layer-2-Ping (l2ping) überprüfen. Dazu gibt man ein: # l2ping 00:04:0E:81:F8:D4 und erhält folgenden Bildschirmausdruck: Abbildung 3.3.3: l2ping Nun muss noch der Daemon für das Service-Discovery-Protocol (SDP) gestartet werden, damit der entsprechende Client auch erkennen kann, welche Services auf dem Master (LISTIG-Basisgerät) zur Verfügung stehen. # sdpd Bei der Kernelversion muss nun noch das Kernel-Modul für den BNEP-Support geladen werden. Dies geschieht wie folgt: # modprobe bnep Bei der Kernelversion erfolgt dies automatisch durch Aufrufen des nächsten Befehls, der gleichzeitig den Daemon für das Privat-Area-Network-Profil (PAN) startet. # pand --listen --role GN Das LISTIG-Basisgerät tritt somit in die Rolle (--role) des Group-Adhoc-Network-Controlers 29

30 (GN) und wartet mit --listen auf einen Verbindungsaufbau von Seiten des Clients. Wird der pand-befehl erfolgreich ausgeführt, erscheinen auf dem Bildschirm folgende Meldungen zur Bestätigung der Implementierung der verschiedenen Protokollschichten. Bluetooth: L2CAP ver 2.1 Bluetooth: L2CAP socket layer initialized Bluetooth: BNEP (Ethernet Emulation) ver 1.0 Bluetooth: BNEP filters: Protocol multicast Der Client-Laptop kann jetzt mit eingestecktem AVM-USB-Bluetooth-Dongle gebootet werden. In der Netzwerkumgebung sind eine entsprechende IP-Adresse und Subnetzmaske einzutragen. Abbildung 3.3.4: Netzwerkumgebung Abbildung 3.3.5: IP-Adresse und Subnetzmaske Mit Doppelklicken auf das AVM-Bluetooth-Symbol neben der Systemuhr öffnet sich das Übersichtsfenster über die Bluetooth-Umgebung. Dort findet man eine Auflistung von Bluetooth- Geräten, mit denen sich schon einmal verbunden wurde (unter: Meine Bluetooth-Umgebung ) und die zugehörige Signalstärke (unter: Verbindung ) für die jeweilige Verbindung bzw. ob gerade eine Verbindung besteht wird angezeigt. Auf der linken Seite des Fensters, unter Eigene Bluetooth-Geräte ist das AVM-BlueFritz!-USB-Dongle mit Hardware-Adresse 30

31 (00:04:0E:81:F8:D4) und Namen aufgeführt. Für das Hinzufügen neuer Bluetooth-Geräte klickt man mit der linken Maustaste auf das Logo des Dongles und im sich öffnenden Menüfenster auf Neue Bluetooth-Geräte suchen (siehe Abbildung 3.3.6). Abbildung 3.3.6: BlueFRITZ! Meine Bluetooth-Umgebung Nun wird automatisch nach, sich in der Nachbarschaft befindlichen, Bluetooth-Geräten gescannt und folgendes Fenster informiert über das Ergebnis: Abbildung 3.3.7: Bluetooth-Geräte suchen und auswählen Um nun mit einem Bluetooth-Gerät in Verbindung zu treten, wird dieses in der Liste ausgewählt und dann auf den Button Bluetooth-Gerät übernehmen geklickt. 31

32 Die Tabelle in Abbildung zeigt den Gerätenamen des HP ipaq Pocket-PC h5550 POCKET_PC und dessen zugehörige Bluetooth-Adresse 08:00:17:1B:53:C6, sowie die zur Verfügung stehenden Services (Networking, Object transfer, Audio ). Die zweite Zeile symbolisiert das Acer-USB-Bluetooth-Dongle des LISTIG-Basisgeräts mit dem Gerätenamen BlueZ (0) (BlueZ ist der Name für den gesamten Bluetooth-Treiber-Stack unter Linux) und der Hardware-Adresse 00:60:57:0B:4F:D8. Zur Verfügung stehende Services werden nicht ausgewiesen, dieses deutet auf Probleme mit dem Service-Discovery-Protocol (SDP) auf dem LISTIG-System hin (Siehe dazu auch ). Der Aufbau einer PAN-Verbindung wird dadurch aber nicht behindert. Der Verbindungsaufbau erfolgt in dem man wieder zurück im Fenster BlueFRITZ! Meine Bluetooth-Umgebung mit der rechten Maustaste auf das Symbol für die entsprechende Verbindung klickt und Verbinden mit und anschließend Netzwerk (PAN) Group Network Service auswählt (Abbildung 3.3.8). Die PAN-Verbindung wird nun aufgebaut und in der Grafik grün hinterlegt (Abbildung 3.3.9). Abbildung 3.3.8: PAN-Verbindung aufbauen 32

33 Abbildung 3.3.9: Aktive PAN-Verbindung Auf dem LISTIG-Basis Gerät erfolgt jetzt eine Bildschirmausgabe, dass eine BNEP-Verbindung aufgebaut und ein neues Netzwerk-Gerät (bnep0) hinzugefügt wurde. Dessen Konfiguartion wird wie folgt vorgenommen. Für die IP-Adresse ( ): # ifconfig bnep Und für die Subnetzmaske ( ): # ifconfig bnep0 netmask Ob die Einstellungen korrekt übernommen wurden, kann mit # ifconfig bnep0 überprüft werden. Dabei sollten folgende Meldungen auf dem Bildschirm erscheinen: 33

34 Abbildung: : ifconfig bnep0 Zu Testzwecken kann nun sowohl vom Client unter Windows das LISTIG-Basisgerät angepingt werden: C:\ping Abbildung : Ping unter MS Windows Als auch ein Ping vom LISTIG-Basisgerät zum Client erfolgen: # ping

35 Abbildung : Ping unter Linux Damit die Testapplikation für die IP-Kommunikation erfolgreich aufgesetzt werden kann muss noch die Datei hosts im Verzeichnis /etc editiert und wie in Abbildung ersichtlich, ergänzt werden. Abbildung : Die Datei /etc/hosts Hier wurden die IP-Adressen für das BNEP-Gerät ( ) auf dem LISTIG-Basissystem und dessen Rechnername (listig1), sowie die IP-Adresse des Clients ( ) und dessen Rechnername (schleppi) eingetragen. Vor dem Starten der IP-Kommunikations-Testapplikation ist noch ein dafür benötigtes Debian- Paket (libstdc++2.10_ _i386.deb; siehe auch beiliegende CD) von herunter zu laden und zu installieren. Dies erfolgt aus dem entsprechenden Unterverzeichnis per: # dpkg -i libstdc++2.10_ _i386.deb 35

36 Nun kann die IP-Kommunikations-Tespapplikation auf dem LISTIG-Basisgerät gestartet werden. Dazu muss ins Verzeichnis /home/ben bzw. dort hin gewechselt werden, wo das Testprogramm (listig) gespeichert wurde. Das Programm listig wird wie folgt gestartet: #./listig listig Dabei startet./listig das Programm. listig1 ist der Rechnername des LISTIG-Basisgerätes und 3353 ist ein freiwählbarer Port (siehe Abbildung Zeile 1 bis 5). Die Testapplikation wartet nun auf eine entsprechende Verbindung vom Client: Abbildung : Testapplikation Nun muss die Testapplikation ( Client_Listig) auf dem Client aufgerufen und konfiguriert werden. Dies geschieht durch Doppelklick auf die Datei listig.jar. (Vorher ist, wenn noch nicht vorhanden, das Java 2 Runtime Environment von zu installieren bzw. sind beide Programme auf der beiliegenden CD enthalten). Abbildung : Client-Testapplikation 36

37 Unter Hostname or IP ist die IP-Adresse des LISTIG-Basisgerätes ( ) einzutragen und unter Port ein beliebiger freier Port z.b Nun kann im Feld Send a message eine beliebige Nachricht an das LISTIG-System geschickt werden. Diese erscheint dann bei erfolgreicher Hinund Rückübermittlung wieder im Feld Receive a message mit voran gestelltem Ausdruck You have sent: Siehe dazu auch Abbildung Abbildung Hello world Die Funktionsweise der Testsoftware auf dem LISTIG-Gerät wird durch den Bildschirmausdruck in Abbildung (unteren 8 Zeilen) deutlich. Abbildung : Requests from Schleppi Die Ausgabe erfolgt zwei mal, da die Daten zuerst vom Server empfangen und dann wieder zurück an den Client verschickt werden. Die Ausdrücke, die dieses quittieren, sind Abbildung zu entnehmen. 37

38 3.4 Untersuchung und Bewertung der Bluetooth-Kommunikation Reichweitenmessung Die Reichweitenmessungen wurden mit dem im AVM-Treiber integrierten Tool Verbindungsmonitor vom Client aus durchgeführt. Diese Tool ruft man auf, in dem man auf die PAN-Verbindung im Fenster BlueFRITZ! Meine Bluetooth-Umgebung mit der rechten Maustaste klickt. (Abbildung 3.4.1) Im sich dann öffnenden Fenster wird Eigenschaften ausgewählt und unter der nun erscheinenden Grafik der Button Details gedrückt. Die sich danach ergebende Darstellung ist in Abbildung gezeigt. Abbildung 3.4.1: PAN-Verbindung aufbauen Abbildung 3.4.1: Verbindungsmonitor AVM-Treiber 38

39 Die Messwerte für unterschiedliche Entfernungen zwischen Client-Laptop und LISTIG-Basisgerät sind der Tabelle zu entnehmen. Dabei war festzustellen, dass die 10 m spezifizierte Reichweite für ein Bluetooth-Gerät der Leistungsklasse 2 (1 mw max. Sendeleistung) relativ gut und zuverlässig erreicht werden. Die Sendeleistung des AVM-Dongles am Client wird der jeweiligen Verbindungsqualität dynamisch zwischen 4 und 16 dbm angepasst. Das lässt den Schluss zu, dass es sich bei dem AVM-Dongle um ein Gerät der Leistungsklasse 1 (100 mw max. Sendeleistung) handelt. Das am LISTIG-Basisgerät verwendete Acer-Dongle gehört der Leistungsklasse 2 an. Distanz zw. Sendeleistung Empfangsfeldstärke SNR Empfangspaket- Host und Client in dbm in dbm in db fehlerrat in % <1m (direkt gegenüber) bis bis 23 0 ca. 4m Luftlinie 6 bis 9-68 bis bis 14 0 bis 7 ca. 10m Luftline bis bis 4 11 bis 52 ca. 5m Luftline 12 bis bis bis bis 60 (1 Wand) ca. 10m Luftlinie bis bis 3 0 bis 55 (1Wand) Tabelle 3.4.1: Reichweitenmessung 3.5 Aufgetretene Probleme Hardware USB-Stiftleiste Auf dem STPC-Mainboard des LISTIG-Basisgerätes liegt ein Layoutfehler innerhalb der vierpoligen Stiftleiste für die Nachaußenführung des USB-Ports vor. Die inneren beiden Pins sind, gegenüber dem standardisierten Pfostenstecker für den Anschluss einer USB-Buchse, vertauscht. D.h. die Daten-Plus- (D+) und die Daten-Minus-Leitung (D-) müssen im Pfostenstecker gedreht werden, damit die USB-Schnittstelle genutzt werden kann. 39

40 PCI-Slot Der innere PCI-Slot des STPC-Mainboard teilt sich grundsätzlich den Interrupt 11 mit dem USB- Port, der ISA-Bridge und dem IDE-Controller. Dies führte dazu, dass keine gleichzeitige Nutzung von diesem Slot durch z.b. eine Ethernetkarte und dem USB-Port möglich war. Wobei dabei der USB-Port Priorität genießt, d.h. im konkreten Fall, USB funktionierte ordnungsgemäß, die PCI- Karte im genannten Slot nicht. Der Fehler liegt in der Interruptverwaltung und ist eventuell mit einem entsprechenden BIOS- Update zu beheben (siehe dazu auch nächsten Absatz ) BIOS Das Bios bietet leider keinerlei Einstellung für die Interruptverwaltung, daraus resultierend werden dem äußeren PCI-Slot immer der IRQ 10 und dem inneren PCI-Slot der IRQ 11 fest zugewiesen. Dies kann führt u.a. zu den unter beschriebenen Problemen. Auch ist sich beim Booten unbedingt an die unter 7.1 beschriebenen Einstellungen zu halten. Es kommt zu Bootproblemen, wenn bereits ein Betriebsystem (Linux) installiert ist und noch eine startfähige CD-ROM beim Starten im Laufwerk liegt. Der Rechner blieb bei solch einer Konfiguration gelegentlich schon während des Initialisierens der Hardware hängen. Abhilfe ist dadurch möglich, vorher ins Bios zu wechseln, mit oder ohne erfolgte Änderungen noch mal zu speichern, dann das Bios wieder zu verlassen und den automatisch eingeleiteten Startvorgang abzuwarten. Diese Verfahrensweise stellt aber nur ein Provisorium dar, eine endgültige Lösung ist dringend erforderlich Netzteil Als Netzteil für das LISTIG-Basisgerät kommt ein steckerseitig modifiziertes Standard-PC-Netzteil zum Einsatz. Im Rahmen der Studienarbeit kam es zu Problemen mit einem der beiden Basisgeräte, die sich auf das dort verwendete Netzteil zurückführen ließen. Obwohl alle Spannungen wie vorgeschrieben anlagen, war in diesem System kein Betreiben einer PCI-Ethernetkarte möglich. Der Wechsel zu einem etwas höherwertigen Standard-PC-Netzteil behob dieses Problem. Es wurden keine Untersuchungen mit einem Oszilloskop durchgeführt, aber die Vermutung liegt nahe, dass das STPC-Board sehr empfindlich gegenüber unsauberen Spannungen (Oberwellen) ist. Dies sollte bei weiteren Versuchen unbedingt beachtet werden. 40

41 3.5.2 Software Probleme beim Aufruf des Host Controller Interface Daemons (hcid) Mir dem Aufruf des hcid könnte der Initialisierungsvorgang des Bluetooth-Dongles auf dem LISTIG-Basisgerät vereinfacht und beschleunigt werden. Die eigentlich nicht vollständige Konfiguration mit dem Befehl # hciconfig hci0 up sollte besser durch den Aufruf von # hcid ersetzt werden. Im Zusammenhang mit dem Start dieses Daemons wird die Datei /etc/bluetooth/hcid.conf eingelesen. Dadurch wird u.a. in dem USB-Dongle der in der Datei hinterlegte Name und die Geräteklasse abgespeichert und noch eine Vielzahl von Authentifizierungs- und Verschlüsselungseinstellungen vorgenommen. Aus nicht geklärten Gründen stürzt der gesamte Bluetooth-Treiber unter Linux auf dem LISTIG-Basisgerät bei diesem Daemonaufruf ab. Die manuelle Initialisierung kann lediglich durch den o.g. hciconfig-aufruf stabil und reproduzierbar erfolgen. Diese Vorgehensweise ist unvollständig, aber für den Aufbau eines PAN ausreichend. Ein manuelles Setzen von z.b. dem Bluetooth-Dongle-Namen (test) mit # hciconfig hci0 name test bringt ebenfalls den Linux-Treiber zum Absturz. Gleiches gilt für das manuelle Setzen der Geräteklasse mit: # hciconfig hci0 class 0x100 Das LISTIG-Basisgerät muss nach Auftreten dieses Fehlers neu gestartet werden um wieder mit der Bluetooth-Schnittstelle arbeiten zu können. 41

42 Probleme beim Aufruf des Service Discovery Protocol Daemons (sdpd) Wird auf dem LISTIG-Basisgerät unter Linux durch Eingabe von # sdpd der Service-Discovery-Protocol-Daemon gestartet, scheint alles problemlos zu funktionieren. Auf der Gegensteite (Client-Laptop oder HP ipaq Pocket-PC h5550) werden allerdings keine angebotenen Dienste Seitens des LISTIG-Systems angezeigt. Dies deutet auf ein unvollständiges Abarbeiten des SDPs hin, ist aber für den Aufbau der PAN-Verbindung nicht zwingend von Bedeutung. Ein Zusammenhang mit dem unter geschilderten Problem konnte nicht ausgeschlossen werden. Bei einer identischen Linux-Installation und Konfiguration auf einem Laptop traten die unter und unter beschriebenen Fehler nicht auf. Es ist deshalb zu vermuten, dass die Ursache entweder in der LISTIG-Hardware selbst zu suchen ist oder dass das Zusammenspiel zwischen Bluetooth-Treiber und LISTIG-Basisgerät noch nicht vollständig funktioniert. Abhilfe hiefür könnten neue Kernel- und/oder Treiberversionen bzw. entsprechende Patches schaffen. Eventuell ist auch der Einsatz eines anderen USB-Dongles am LISTIG-System zu prüfen Nutzung des DUN-Profils Eine zweite Möglichkeit für das Aufsetzen des IP auf eine Bluetooth-Verbindung stellt das DUN- Profil dar. Genaue Anleitungen dafür sind im Internet verfügbar, zum Beispiel unter oth_lan_gateway.html oder Es ist aber nicht gelungen im Rahmen dieser Studienarbeit eine DUN-Verbindung aufzubauen. Spätestens bei der Authentifizierung auf PPP-Ebene traten nicht genau zu lokalisierende Fehler auf und der Verbindungsaufbau wurde abgebrochen. Es ist zu vermuten, dass dies in Zusammenhang mit den unter und geschilderten Problemen steht. Eine einwandfreie Implementierung aller benötigten Protokolle und Funktionen ist für die Nutzung des DUN-Profils dringend notwendig, da dafür zwei Authentifizierungsebenen, eine im Core-Protocol-Stack und eine für die PPP-Verbindung, einwandfrei durchlaufen werden müssen. 42

43 Nutzung einer Adhoc-Netzwerkverbindung Für den bei der Bluetooth-Verbindung angestrebten Funktionsumfang, erscheint es als sinnvoll diese durch eine Adhoc-Netzwerkverbindung aufsetzend auf dem PAN- oder DUN-Profil zu realisieren. Bei Nutzung des PAN-Profils müsste dazu, abweichend von der unter 3.3 beschriebenen Vorgehensweise, nach dem Aufruf von # pand --listen --role GN eine automatische Konfiguration des BNEPs erfolgen. Die IP-Adresse und Subnetzmaske müssten selbständig vom LISTIG-Basisgerät zugewiesen und verwaltet werden. Eine prinzipielle Konfigurationsmöglichkeit für die RedHat- bzw. SuSe-Linux-Distribution ist unter nachzulesen. Für Debian-Linux müsste eine Portierung erfolgen Allgemeine Bemerkungen Ein Support-Anfrage an den Boardhersteller (Marek Micro; ) bezüglich der aufgetretenen Bios- und USB-Probleme, blieb erfolglos. Da, nach Aussage von Marek Micro, das Layout des STPC-Mainboards der Geheimhaltung unterliegt und eine entsprechende Autorisierung von Seiten des Auftraggebers erfolgen muss. Eine ähnliche Anfrage an die am LISTIG-Projekt beteiligte Firma Hör- und Funkwerke Kölleda (HFWK) blieb gänzlich unbeantwortet. Dies ist besonders von Nachteil, weil das bei dem LISTIG-System mitgelieferte Datenblatt starke Abweichung in u.a. dem Layout und weiteren Punkt, zu dem vorliegenden STPC-Mainboard aufweist. Bei hardwarenahen Linux-Treiber-Problemen ist für eine qualifizierte Anfrage in den entsprechenden Foren im Internet eine genau Hardwarebeschreibung nötig. So ein Posting, mit der Aussicht auf kompetente Hilfe, ist aus den genannten Gründen nur sehr schwer bzw. gar nicht möglich. Weiter war auffällig, dass im Zusammenhang mit dem verwendeten Linux-Kernel und der installierten Hotplug-Umgebung die verwendete Basishardware bis an ihre Leistungsgrenzen ausgereizt wird. Beide Features sind allerdings für die Realisierung der WLAN g- Schnittstelle zwingend nötig. Es treten in diesem Zusammenhang teilweise schon merkliche Verzögerungen auf, wenn im normalen Kommandozeilen-Modus eine Taste auf der Tastatur gedrückt wird, bis zur entsprechend Darstellung auf dem Bildschirm. Auch sind Bootzeiten von ca min, bis die erste Eingabe erfolgen kann, deutlich zu hoch. 43

44 4. Fazit Bluetooth ist mittlerweile ein etablierter Standard, der in immer mehr Geräten wie Mobiltelefonen, Laptops, PDAs und PCs bereits ab Werk integriert wird. Aufgrund seiner ständig steigenden Verbreitung stellt er zukünftig eine kostengünstige Variante für Kurzstrecken- Fernsteuerungsdienste dar. Das in der vorliegenden Studienarbeit untersuchte Szenario kann dafür als Beispiel dienen. Das LISTIG-Basisgerät bildet die zentrale Steuereinheit und seine integrierten Standardschnittstellen (LAN, Bluetooth, IrDa, WLAN, GPRS) verbunden mit der einfachen Hardwarearchitektur sowie das verwendet Linux-Betriebsystem zielen auf eine preisgünstige Positionierung am Markt für Hausautomationssysteme ab. Für ein anwenderfreundliches Konzept sind Stabilität und Geschwindigkeit der Anwendung, eine einfache Bedienung und eine ausreichende Fernsteuerungs-Reichweite von zentraler Bedeutung. Um eine akzeptable Stabilität und vor allem Geschwindigkeit auf dem LISTIG-Basisgerät zu erreichen, gilt es zu überdenken, ob zwingend der Linux-Kernel verbunden mit der Hotplug- Umgebung eingesetzt werden soll. Der Linux-Kernel bildet zumindest auf der vorliegenden Basis-Hardware eine schnellere und stabilere Realisierung. Im weiteren sind zumindest die unter und geschilderten Probleme zu lösen. Dabei ist die ständig fortschreitende Treiberund Kernel-Entwicklung unter Linux zu berücksichtigen. Auch ist die Implementierung von Adhoc-Netzwerkfunktionalität ( ) sicherlich im Sinne einfacherer Bedienung anzustreben. Um eine auf allen Schnittstellen einheitliche Kommunikationsebene zu schaffen, wurden die Protokolle TCP/IP im Rahmen des LISTIG-Projektes gewählt. Die effizienteste Realisierung hierfür auf Basis von Bluetooth ist sicherlich das Protokoll BNEP und darauf aufsetzend das PAN-Profil. Für eine größere Kompatibilität, da nicht alle Geräte PAN unterstützen, ist eventuell das weiter verbreitete DUN-Profil ( ; ) mit einzubeziehen. Die bei der unter 3.3 aufgebauten Bluetooth-Teststrecke erzielte Maximalreichweite von ca. 10 m ist sicher im Eigenheimbereich zu gering. Eine deutliche Vergrößerung könnte durch den Einsatz von USB-Geräten der Leistungsklasse 1 mit einer Reichweite von bis zu 100 m erfolgen. 44

45 5. Literaturverzeichnis Lehrbücher: /1/ Bramer, M.; Goerzen, J.; Othman, O.: Debian GNU/Linux Guide; Software in the Public Interest, Inc. and LinuxLand International, München 2002; ISBN: /2/ McCarty, B.: Learning Debian/GNU Linux; Oreilly & Associates, 1999 ISBN: /3/ Tacket, J.; Gunter, D.; Brown, L.: Linux das Kompendium [leichte Installation, alles zur Hardware-Kompatibilität, HTML-Dokumente mit Linux]; Markt & Technik, Buch- und Software-Verlag, Haar bei München 1996 ISBN: /4/ Wollert, J.F.: Das Bluetooth Handbuch; Franzis Verlag, Poing 2002 ISBN: Seminararbeiten: /5/ Grenzendörfer, L.: Untersuchungen zu Bluetooth; TU Ilmenau, Fakultät Elektro- und Informationstechnik, Institut Kommunikations- und Messtechnik, Fachgebiet Kommunikationsnetze, Seminararbeit 2002 Webseiten: /6/ - Webseite für Debian-Linux /7/ - Webseite für den Linux-Bluetooth-Protokollstack /8/ - Webseite für Linux-Kernels /9/ - Webseite für AVM-Produkte (AVM-BlueFRITZ!-Bluetooth-USB-Dongle) /10/ - Webseite für Acer-Produkte (Acer-Bluetooth-USB-Dongle) 45

46 6. Verwendete Bluetooth-Hardware LISTIG-Basisgerät Client-Laptop Model Acer Bluetooth mini USB Adapter (BT500) AVM BlueFRITZ! USB Adapter Host-Schnittstelle USB Ver.1.1 USB Ver.1.1 Eingangsspannung / Strom DC5V / 150 ma (typisch) Keine Angaben Stromverbrauch (typisch) Standby Modus: 30 ma Keine Angaben Übertragungsmodus: 120 ma Datenübertragungsrate 1,0 MBit/s (max.) 1,0 MBit/s (max.) Frequenzbereich 2,402 GHz 2,480 GHz 2,402 GHz 2,480 GHz Kanalabstand 1 MHz 1 MHz Leistungsklasse Klasse 2 Klasse 1 Typische Reichweite 10 m 100 m Tx-Leistung 0 dbm 20 dbm Rx Empfindlichkeit 0,1% BER/PIN: -70dBm Kein Angaben Antennenimpedanz 50 Ohm 50 Ohm Betriebssystemunterstützung MS Windows98SE, ME; MS MS Windows98SE, ME; MS (v. mitgelieferten Standard- WINDOWS 2000, XP WINDOWS 2000, XP treiber) Unterstützte Core Protocols HCI, L2CAP, RFCOMM, SDP, SDP, CMTP, BNEP, L2CAP, (v. mitgelieferten Standard- OBEX TCS, RFCOMM treiber) Unterstützte Profile GAP; SDGP, SPP, LAN, DUN, SDAP, GAP, CIP, PAN, SPP; (v. mitgelieferten Standard- FAX, GOEP, FTP, OPP, SYNC DUN, CTP treiber) Tabelle 6.1.1: Bluetooth-Hardware 46

47 7. Anhang 7.1 Bootkonfiguration des LISTIG-Basisgeräts In der BIOS-Bootkonfiguration sind unbedingt folgende Einstellungen vorzunehmen. Dabei scheint es nicht von Bedeutung zu sein, wie das CD-ROM bzw. die Festplatte an dem einen vorhandenen IDE-Kanal hardware-mäßig gejumpert ist. Im LISTIG-Versuchssystem war die Festplatte als Primary Master gejumpert und das CD-ROM als Primary Slave konfiguriert. Man sollte sich bei der Konfiguration keines Falls von eventuellen Erfahrungen mit den Boot-Einstellungen aus dem PC- Bereich leiten lassen, sondern die Einstellungen wie folgt beschrieben vornehmen. Bios-Einstellungen: Relevanter Eintrag C D Boot 1st IDE 0 IDE 1 Zu wählender Wert CD Hd/Pri Slave Primary Master Drive C Drive D Auto, LBA Auto, phys. Tabelle Bios-Boot-Einstellungen Nach erfolgreicher Installation kann die Boot-Reihenfolge unter Boot 1st auch umgestellt werden. Dann wird zu erst versucht von der Festplatte zu booten, sollte dies aus irgendwelchen Gründen nicht möglich sein, wird auf das CD-ROM zurückgegriffen. Für eine Neuinstallation sollte die Bootkonfiguration, wie in Tabelle beschrieben, vorgenommen werden. Als erstes ist die MiniWood-CD der beiliegenden Debian Linux Distribution einzulegen. Sollt es beim Booten von CD Schwierigkeiten geben, kann es hilfreich sein, vor dem Booten ins Bios zu wechseln, dieses mit oder ohne Änderungen abzuspeichern und wieder zu verlassen.. 47

48 7.2 Linux-Installation auf dem LISTIG-Basisgerät Für die Grundinstalltion von Debian-Linux auf dem LISTIG-Basisgerät ist von der MiniWood- CD zu booten. Danach ist der, sich in weiten Teilen selbsterklärenden, interaktiven Menüführung zu folgen. Bei Unklarheiten kann auf die sehr gute und ausführliche Hilfefunktion zurückgegriffen werden. Eine ausführliche Installationsanleitung für Debian-Linux liefert das Buch Debian Guide GNU/Linux 3.0 (/1/) in seinen ersten Kapiteln. Eine ähnliche Vorgehensweise ist auch im Internet unter z.b. nachzulesen. Die wichtigsten Schritte und Einstellungen sind auch noch mal in der dem LISTIG-Basisgerät beiliegenden HFWK STPC-Board Kurzbeschreibung dokumentiert. Davon abweichend sind für den Testbetrieb ein anderer Rechnername (listig1 bzw. listig2) und eine andere IP-Adresse ( bzw ) für die LAN-Karte vergeben worden. Diese Einstellungen können aber auch noch nachträglich nach der Installation mit Hilfe des Linux-Kommandos ifconfig geändert werden. Es ist unbedingt darauf zu achten, dass während der Installation tasksel (Task select) aufgerufen wird. Dort muss das C/C++-Entwicklungspaket installiert werden. Dieses ist unbedingt notwendig für das Kompilieren anderer Kernel, Kernelpatches oder noch einzubindender Treiber. Auf eine detailliertere Installationsanleitung soll an dieser Stelle verzichtet werden, da diese den Rahmen der Studienarbeit sprengen würde. 7.3 Kernel konfigurieren und installieren Als erstes muss die entsprechende Kernel-Quelldatei (linux tar.bz2) von z.b. herunter geladen und am besten im Verzeichnis /usr/src/ abgespeichert werden. Danach ist die Archiv-Datei mit folgendem Befehl zu entpacken: # tar xvfj linux tar.bz2 Damit die Kernelsource vom Compiler zuverlässig gefunden wird lässt man einen Link von /usr/scr/linux darauf zeigen. Das erreicht man durch folgendes Kommando: # ln s /usr/src/linux /usr/src/linux Nun geht man mit 48

49 # cd linux in das Verzeichnis der entpackten Kernel-Quelldatei. Damit die Konfiguration des Kernels erfolgen kann, ist vorher noch die Bibliothek libncurses dev mit folgender Eingabe zu installieren: # apt-get install libncurses dev Um nicht alle Basis-Hardwareeinstellungen für den Rechner noch einmal neu eingeben zu müssen, kann die Kernel-Module-Konfigurationsdatei /boot/config bf2.4 in das Verzeichnis mit der Kernelsource /usr/src/linux-2.6.4/ kopiert und dort später im menuconfig-menü eingelesen werden. Das stellt sicher, dass alle Grundeinstellungen (z.b. Prozessortyp, Registersatz ), die bei der Linux-Installation automatisch erkannt und vorgenommen wurden, übernommen werden und dort dann keine Konflikte zwischen tatsächlich vorhandener Hardware und eventuell falsch angegebener Hardware auftreten. Solche Konflikte hätten beim ersten Booten des neuen Kernels eine Kernelpanic zur Folge bzw. würde sich das System ohne jegliche Fehlermeldung beim Booten aufhängen. Es sollte also mit # cp /boot/config bf2.4 /usr/src/linux-2.6.4/config.old die Konfigurationsdatei kopiert werden. Als nächstes ist das Programm menuconfig aus dem Verzeichnis mit der Kernelsource zu starten # make menuconfig und die Datei config.old einzulesen. Nun kann die weitere Konfiguration der Kernelmodule erfolgen. Nach dem Starten von menuconfig erhält man folgenden oder ähnlichen Bildschirm: 49

50 Abbildung 7.3.1: menuconfig Main-Fenster In der Sektion USB Support muss der Punkt USB Bluetooth support (EXPERIMENTAL) unbedingt deaktiviert werden, sofern er angezeigt wird. Diese Modul verwendet den nicht mehr aktuellen Axix-Bluetooth-Stack, es ist aber unbedingt der Bluetooth-Stack des Kernels zu verwenden. Das Modul bluetooth.o darf nicht im Modul-Verzeichnis des Kernels auftauchen. In der Sektion Bluetooth Support sollten der Einfachheit halber alle Einträge als Module (M) eingebunden werden, auch die im Untermenü Bluetooth device drivers. So können sie später bei Bedarf mit # modprobe <Modulname> geladen und sich mit # lsmod über schon geladenen Module informiert werden. Sind alle weiteren Einstellungen erfolgt ist die Konfiguration abzuspeichern und menuconfig zu beenden. 50

51 Als nächstes wird der Kernel kompiliert. Das erledigt man unter Debian-Linux am besten über Skripte im kernel-package. Die bei allen Linux-Distributionen mögliche manuelle Kernel- Kompilation ist ebenfalls möglich, wird aber unter Debian explizit nicht empfohlen. Für das Erzeugen eines kompilierten Kernel-Packages geht man wie folgt vor. Die Kernel-Sourcen müssen zu erst gesäubert und die Parameter von kernel-package zurückgesetzt werden. Dazu gibt man im Verzeichnis der Kernelsource folgende Kommandos ein: # make-kpkg clean Das Komplieren wird mit # fakeroot make-kpkg revision=custom.1.0 kernel_image modules_image gestartet. Die Revisionsnummer 1.0 kann natürlich nach Belieben geändert werden. Sie dient nur dazu, die verschiedenen Versionen des kompilierten Kernels zu unterscheiden. Das Komplieren kann eine ganze Weile dauern. Auf dem LISTIG-Basisgerät nahm der Vorgang 4-5 Stunden in Anspruch. Zum Vergleich, auf einer 600 MHz CPU ist mit ca min zu rechnen. Nach dem Ende des Kompiliervorganges liegt der fertige Kernel in der Datei bzimage (ca. 20 MB) im Verzeichnis /usr/src/linux-2.6.4/arch/i386/boot/ und kann nun mit # cp /usr/src/linux-2.6.4/arch/i386/boot/bzimage /boot/2.6.4 ins Standard-Kernelverzeichnis /boot/ kopiert werden. Die nicht fest mit in den Kernel hinein kompilierten Module liegen im Verzeichnis /usr/src/linux-2.6.4/debian/tmp-image/lib/modules/2.6.4/. Das gesamte Verzeichnis muss nun noch in das Standard-Moduleverzeichnis /lib/modules/ kopiert werden. # cp a /usr/src/linux-2.6.4/debian/tmp-image/lib/modules/2.6.4 <Leerzeichen>/lib/modules Jetzt ist noch der Bootmanager LiLo (Linux Loader) zu konfigurieren. Dazu editiert man die Datei /etc/lilo.conf und sucht folgenden Eintrag: 51

52 Image=/vxlinuz Label=Linux read-only Unterhalb ist folgender Code einzutragen: Image=/boot/2.6.4 Label=Linux_2.6.4 read-only Mit default=label kann man den Kernel wählen, der beim Booten nach Ablauf einer Wartezeit automatisch gestartet werden soll. Jetzt ist die Datei lilo.conf abzuspeichern und mit # lilo zu starten. Damit werden die eben gemacht Änderungen übernommen. Nun kann der Rechner mit # shutdown r now neu gebootet werden. Treten keine Fehler auf, kann im LiLo-Bootmenü nun der Eintrag Linux_2.6.4 ausgewählt und damit der neue Kernel gebootet werden. 7.4 Linux-Bluetooth-Treiber installieren und konfigurieren Nach erfolgtem Kernelupdate sind nun noch vier Treiberpakete zu installieren, damit das PAN- Profil unter Linux nutzbar ist. Die entsprechenden, gepackten Archive können unter herunter geladen und in ein beliebiges Verzeichnis gespeichert werden. Standard ist hier für alle Kernel-, Patch- und Treiberquelldateien das Verzeichnis /usr/src/. Dies ist aber nur eine Empfehlung. Folgende Dateien sind nötig (siehe auch beiliegende CD): 52

53 Reihenfolge Paketname Archiv-Dateiname Beschreibung 1. BlueZ-Libs bluez-libs-2.4.tar.gz Bluetooth-Bibliotheken 2. BlueZ-Utils bluez-utils-2.3.tar.gz Bluetooth-Utilities 3. BlueZ-SDP bluez-sdpd-1.1.tar.gz Treiber für das Service- Discovery-Protocol (SDP) 4. BlueZ-PAN bluez-pan-1.1.tar.gz Treiber für das Privat- Area-Network-Profil (PAN) Tabelle 7.4.1: Bluetooth-Treiber Die Installation sollte zwingend in der angegebenen Reihenfolge (Tabelle 7.4.1) erfolgen, da Abhängigkeiten der verschiedenen Treiberpakete untereinander bestehen und diese in der Reihenfolge Berücksichtigung finden. Vor der Installation müssen die Archive noch im gewählten Unterverzeichnis entpackt werden, dies erreicht man durch folgendes Linux-Kommando: # tar xzvf bluez-libs-2.4.tar.gz Danach wechselt man in das eben entstandene Unterverzeichnis # cd bluez-libs-2.4 und führt nacheinander folgende drei Befehle (Reihenfolge beachten!) aus. #./configure # make # make install Dies erfolgt für die anderen drei Treiberpakete analog. Die jeweiligen Datei- bzw. Verzeichnisnamen sind aus der Tabelle ersichtlich. Damit die Treiber-Module automatisch geladen werden, sind in der Datei /etc/modules.conf noch folgende Zeilen zu ergänzen: 53

54 alias net-pf-31 bluez alias bt-proto-0 l2cap alias bt-proto-2 sco alias bt-proto-4 bnep alias tty-ldisc-15 hci_uart alias char-major hci_vhci Nun sollte alle benötigte Software unter Linux installiert sein. 7.5 Installtion der AVM-Bluetooth-Treibersoftware unter MS Windows Die Installation der Treibersoftware für das BlueFRITZ!-USB-Dongle erfolgt wie unter MS Windows üblich. Der Client-Laptop wird gebootet und das Bluetooth-USB-Gerät an einen USB-Port angeschlossen. Die Plug-and-Play-Funktion erkennt ein neues USB-Gerät und fordert auf eine Treiber-CD einzulegen (siehe auch beiliegende CD). Dieser Aufforderung wird nachgekommen und der Rest der Software-Installation läuft automatisch durch. Nun erscheint neben der Systemuhr das AVM- Bluetooth-Icon, durch doppelklicken darauf öffnet sich das Fenster BlueFRITZ! Meine Bluetooth-Umgebung. Die weiterführende Konfiguration ist unter 3.3 beschrieben. 7.6 Nützliche Linux-Befehle und Packages Hilfe zu Linux-Befehlen und Manual Will man mehr über den Funktionsumfang eines bestimmten Linux-Befehls erfahren, ist es sinnvoll die integrierte Hilfefunktion zu nutzen. Dazu gibt man ein: # <Befehl> --help Als Beispiel: # hciconfig --help 54

55 Für bestimmte (nicht alle) Befehle sind Manual-Pages hinterlegt und können mit # man <Befehl> aufgerufen werden. Als Beispiel: # man lsmod Mounten und Unmounten einer CD-ROM Für das Einbinden einer CD-ROM ins Linux-System gibt man folgendes ein: # mount /cdrom Der Inhalt der CD-ROM ist jetzt im Verzeichnis /cdrom/ zu finden, solange bis das CD-ROM- Laufwerk wieder ge-unmountet wird. Dies erfolgt mit: # umount /cdrom Midnight Commander installieren Der Midnight Commader stellt einen intuitiv bedienbaren Dateimanager auf Basis der Linux- Kommandozeile dar und ist dem vom DOS bekannten Norton Commander nachempfunden. Er kann mit folgendem Befehl installiert werden # apt-get install mc und wird dann mit # mc aufgerufen. 55

56 Debian-Packages Für Debian-Distributionen sind eine Vielzahl von Programm-Packages verfügbar um den Funktionsumfang der jeweiligen Linux-Installation zu erweitern bzw. zu aktualisieren. Diese können unter herunter geladen und mit folgendem Befehl installiert werden: # dpkg i <Packagename> Packages für Packen und Entpacken Installieren des Bzip2-Packers mit: # apt-get install bzip Hilfsprogramme zum Einbinden und Verwalten von Packages Zum etwas komfortableren Installieren und Deinstallieren von Programm-Modulen gibt es das Programm dselect. Es ist standardmäßig bei der Linux-Grundinstallation mit installiert und wird mit # dselect aufgerufen. Es hat eine etwas kryptische Bedienung, weißt aber deutlicher auf die verschiedenen Abhängigkeiten der Programmpakete untereinander hin und kann solche Dependencies-Fehler anzeigen und auch mehr oder weniger gut beheben. Den gleichen Funktionsumfang liefert das Programm aptitude. Es lässt sich intuitiver bedienen, wird mit # apt-get install aptitude installiert und mit # aptitude gestartet. 56

57 7.6.7 Laden, Entladen und Auflisten von Kernel-Modulen Das Laden von Kernel-Modulen, die bei der Kernel-Konfiguration als Module mit eingebunden wurden, erfolgt in den laufenden Kernel per: # modprobe <Modulname> Das Entladen mit: # rmmod <Modulname> Eine Auflistung über die aktuell geladenen Module erhält man mit: # lsmod Herunterfahren bzw. Neustarten eines Linux-Systems Herunterfahren mit: # shutdown h now oder: # halt Ein Neustart erfolgt mit: # reboot 57