1. Aufgabenstellung

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.
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. 10-15 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. 1998 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 KurzstreckenNetzwerk-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 2.402 MHz bis 2.480 MHz. In einigen
Ländern z.B. Spanien, Japan und Frankreich (2.446,5 – 2.483,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-Hopping2
Verfahren (FHSS; Frequency Hopping Spread Spectrum) in 79 Schritten mit einem Abstand von je
1 MHz zum Einsatz. Die Frequenzwechsel erfolgen 1.600 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 802.11b) 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)-FrequencyShift-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
2.2 Bluetooth – System
2,4 G Hz
Bluetooth
Radio
Bluetooth
Link
Controller
Bluetooth
Linkm anager
& IO
HCI
Bluetooth Controller
HCI
Host
Layer
Anw endung
Host System
Abbildung 2.2.1: Aufbau eines Bluetooth-Systems (Quelle: /4/ S.57)
2.2.1 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.
2.2.2 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.
2.2.3 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
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.
2.2.4 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 HostSystem 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.
2.2.5 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 2.2.1 bis 2.2.5 aufgeführten Komponenten gehören zu einem vollständigen BluetoothProtokollstack.
5
Auf allen korrespondierenden Hosts (min. 1, max. 7) ist eine vergleichbare Hardware-FirmwareProtokoll-Struktur implementiert.
Host (A)
Host (B)
Anwendung
Bluetooth
Funkstrecke
Bluetooth
Funkstrecke
High-Level-Treiber
High-Level-Treiber
Basisband Controller
HCI-Treiber
HCI
Bus-Treiber
Physik
HCI
Firmware
Link
Manager
Firmware
Basisband Controller
Link
Manager
Firmware
Bus-Firmware
HCI
Firmware
Bus-Firmware
USB, PCI, PCMCIA, UART...
HCI
HCI-Treiber
Physik
Bus-Treiber
USB, PCI, PCMCIA, UART...
Abbildung 2.2.2: Bluetooth Treiber (Quelle: /4/ S.122)
2.2.6 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
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.
Scatter-Netz
Pico-Netz
Stand
by
Slave
Stand
by
Master
Master
Slave
Master
Stand
by
Slave
Slave
Slave
Abbildung 2.3.1: Pico- und Scatter-Netze
7
Slave
Slave
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.
433,9 kBit/s
732,2 kBit/s
Daten
symmetrisch
64 kBit/s
Daten
asymmetrisch
Sprache
64 kBit/s
57,6 kBit/s
433,9 kBit/s
64 kBit/s
Asynchrone Kommunikation
(paketvermittelt)
Synchrone Kommunikation
(leitungsvermittelt)
Abbildung 2.4.1: Bluetooth-Kommunikationsarten (Quelle: /4/ S.58)
2.4.1 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
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.
2.4.2 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.
2.4.3 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 SCOSlots 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
2.5 Bluetooth-Protokollstack
2.5.1 Übersicht Bluetooth-Protokollstack
vCard/vCal
ATBefehle
W AE
SDP
TCS BIN
W AP
OBEX
UDP
TCP
IP
PPP
BNEP
Audio
RFCOM M
L2CAP
Hostcontroller Schnittstelle
LM P
Basisband
Bluetooth-Funk
Abbildung 2.5.1: Bluetooth-Protokollstack
2.5.2 Bluetooth im ISO-OSI-Schichtenmodell
ISO-OSI-Schichtenmodell
7
Bluetooth-Schichtenmodell
Verarbeitung
Application
6
Darstellung
5
Sitzung
TCP
UDP
IP
4
Transport
PPP
BNEP
3
RFCOMM
Vermittlung
L2CAP
LLC
2
Sicherung
LM
MAC
Baseband
1
SDP
Bitübertragung
RF
Abbildung 2.5.2: ISO-OSI-Schichtenmodell vs. Bluetooth-Schichtenmodell
10
Die Bluetooth-Kernprotokolle entsprechen im wesentlichen der Schicht 1 und 2 im ISO-OSIReferenzmodell. Darüber liegende Schichten werden von den anwendungsspezifischen Protokollen,
den angepassten Protokollen (Adopted Protocols), repräsentiert.
2.5.3 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.
2.5.3.1 Basisband
Im Basisband sind fast alle wichtigen Technologien implementiert, wie z.B. der Aufbau von PicoNetzen, 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.
2.5.3.2 Link Manager Protocol (LMP)
Das Link-Manager-Protokoll wickelt ausschließlich die Kommunikation zwischen den LinkManagern 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
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
RFCOMM (Radio Frequency Communication)
Telefonieprotokolle
TCS BIN (Telephony Control Specification Binary)
AT-Befehle
Adaptierte Protokolle
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
2.5.3.3 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
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.
2.5.3.4 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.
2.5.4 Das Kabelersatzprotokoll – Radio Frequency Communication (RFCOMM)
Das RFCOMM-Protokoll ist das erste Protokoll oberhalb der Kernprotokolle. Es ist auf dem HostSystem 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.
2.5.5 Bluetooth Network Encapsulation Protocol (BNEP)
Das BNEP definiert den einheitlichen Transport von Netzwerkpaketen über eine BluetoothVerbindung. 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
Das BNEP wird u.a. für Verbindungen zwischen Bluetooth-Geräten unter Verwendung des PANProfils (Private Area Networking) benötigt. Dies stellt die einzige Möglichkeit dar IP over
Bluetooth in Bluetooth-Adhoc-Netzwerken zu realisieren.
2.5.6 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 BluetoothUmgebung 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.
2.5.6.1 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 PPPRahmens versendet werden. Mit Hilfe des NCP ist z.B. die Zuweisung von dynamischen IPAdressen 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
2.5.6.2 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
1.500 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.
2.5.6.3 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
2.5.6.4 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 LISTIGProjektes 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
2.6.1 Übersicht – grundlegende Bluetooth-Profile
Generic Access
Profile (GAP)
Service Discovery
Application Profile
(SDAP)
Private Area Network
Profile (PAN)
Telephony Profile
Intercom Profile
(IntP)
Cordless
Telephon Profile
(CTP)
Dial Up Network
Profile (DUNP)
LAN Access
Profile (LAP)
Serial Port Profile
(SPP)
FAX Profile
(FaxP)
Headset Profile
(HSP)
Generic Object
Exchange Profile
(GOEP)
File Transfer
Profile (FP)
Object Push
Profile (OPP)
Abbildung 2.6.1: Bluetooth-Profile
16
Synchronisation
Profile (SP)
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.
2.6.2 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
2.6.2.1 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
2.6.2.2 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-PortProfile (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 BluetoothPIN. 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
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/)
2.6.2.3 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
2.6.2.1 und 2.6.2.2 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
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
Stand
by
GN
PANU
PANU
LAN Infrastructure
PANU
NAP
PANU
PANU
PANU
PANU
Abbildung 2.6.3: PAN-Profil, Master als Group Network Controller vs. Network Access Point
21
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
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 TFTDisplays 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
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
3.2.1 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
3.2.1.1 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-BluetoothModul als eine mögliche Realisierung denkbar. Dabei ist aber zu beachten, dass das LISTIGSystem unter Linux läuft und dafür dann entsprechende Treiber sowohl für den PCI-PCMCIAAdapter, 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.
3.2.1.2 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.
3.2.1.3 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.
3.2.2 Software
Auf dem LISTIG-Basisgerät ist standardmäßig als Betriebssystem Debian Linux (Woody) mit einer
Kernelversion 2.4.18 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
zusätzlich zu installierenden Kernel-Patches nötig. In verschiedenen Newsgroups im Internet wird
für eine Bluetooth-Implementation zu einem Kernel 2.4.20 oder höher geraten. Zu Testzwecken
wurde im Laufe der Studienarbeit eine Bluetooth-Schnittstelle auf Basis des 2.4.22 Kernels
realisiert. Dies stellt eine gut funktionierende und sehr stabile Lösungsmöglichkeit dar. Der 2.4.22
Kernel ist eine der letzten Kernelversionen, die für den 2.4.X Kernel-Core entwickelt wurden.
Da für die WLAN-802.11g-Schnittstelle, die ebenfalls im Rahmen des LISTIG-Projektes zu
realisieren war, Mindestvoraussetzung der Kernel 2.6.0 ist, wurde im weiteren Verlauf eine
Implementierung auf Basis des 2.6.4 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-ProfilUnterstü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
3.3.1 Aufbau
IP over Bluetooth via
BNEP and PAN-Profile
Bluetooth Funkstrecke ca. 1-15 m Abstand
LISTIG-Basisgerät
Acer USB Bluetooth Dongle
IP-Adresse: 10.0.0.1
Subnetzmaske: 255.255.255.0
Debian Linux Kernel 2.6.4
Client-Laptop
AVM BlueFRITZ! USB Dongle
IP-Adresse: 10.0.0.2
Subnetzmaske: 255.255.255.0
MS Windows 98 SE
Abbildung 3.3.1a: Aufbau Bluethooth-Testumgebung
26
3.3.2 Inbetriebnahme
Zur Inbetriebnahme wird zu erst das LISTIG-Basisgerät mit dem 2.6.4 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
# 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
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 2.4.22 Kernelversion muss nun noch das Kernel-Modul für den BNEP-Support geladen
werden. Dies geschieht wie folgt:
# modprobe bnep
Bei der Kernelversion 2.6.4 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
(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 BluetoothGerä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
30
mit
Hardware-Adresse
(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
Die Tabelle in Abbildung 3.3.7 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 3.5.2.2). 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
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 (10.0.0.1):
# ifconfig bnep0 10.0.0.1
Und für die Subnetzmaske (255.255.255.0):
# ifconfig bnep0 netmask 255.255.255.0
Ob die Einstellungen korrekt übernommen wurden, kann mit
# ifconfig bnep0
überprüft werden. Dabei sollten folgende Meldungen auf dem Bildschirm erscheinen:
33
Abbildung: 3.3.10: ifconfig bnep0
Zu Testzwecken kann nun sowohl vom Client unter Windows das LISTIG-Basisgerät angepingt
werden:
C:\ping 10.0.0.1
Abbildung 3.3.11: Ping unter MS Windows
Als auch ein Ping vom LISTIG-Basisgerät zum Client erfolgen:
# ping 10.0.0.2
34
Abbildung 3.3.12: 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 3.3.13 ersichtlich, ergänzt
werden.
Abbildung 3.3.13: Die Datei /etc/hosts
Hier wurden die IP-Adressen für das BNEP-Gerät (10.0.0.1) auf dem LISTIG-Basissystem und
dessen Rechnername (listig1), sowie die IP-Adresse des Clients (10.0.0.2) und dessen Rechnername
(schleppi) eingetragen.
Vor dem Starten der IP-Kommunikations-Testapplikation ist noch ein dafür benötigtes DebianPaket (libstdc++2.10_2.95.2-14_i386.deb; siehe auch beiliegende CD) von www.debian.org
herunter zu laden und zu installieren. Dies erfolgt aus dem entsprechenden Unterverzeichnis per:
# dpkg -i libstdc++2.10_2.95.2-14_i386.deb
35
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 listig1 3353
Dabei startet ./listig das Programm. listig1 ist der Rechnername des LISTIG-Basisgerätes
und 3353 ist ein freiwählbarer Port (siehe Abbildung 3.3.1.4 Zeile 1 bis 5).
Die Testapplikation wartet nun auf eine entsprechende Verbindung vom Client:
Abbildung 3.3.14: 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 http://java.sun.com/j2se/1.4.2/download.html zu installieren
bzw. sind beide Programme auf der beiliegenden CD enthalten).
Abbildung 3.3.15: Client-Testapplikation
36
Unter „Hostname or IP“ ist die IP-Adresse des LISTIG-Basisgerätes (10.0.0.1) einzutragen und
unter „Port“ ein beliebiger freier Port z.B. 3353. 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 3.3.16.
Abbildung 3.3.16 Hello world…
Die Funktionsweise der Testsoftware auf dem LISTIG-Gerät wird durch den Bildschirmausdruck in
Abbildung 3.3.17 (unteren 8 Zeilen) deutlich.
Abbildung 3.3.17: 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 3.3.17 zu
entnehmen.
37
3.4
Untersuchung und Bewertung der Bluetooth-Kommunikation
3.4.1 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 3.4.2 gezeigt.
Abbildung 3.4.1: PAN-Verbindung aufbauen
Abbildung 3.4.1: Verbindungsmonitor AVM-Treiber
38
Die Messwerte für unterschiedliche Entfernungen zwischen Client-Laptop und LISTIG-Basisgerät
sind der Tabelle 3.4.1 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.
Host und Client
Sendeleistung
in dBm
Empfangsfeldstärke
in dBm
SNR
in dB
Empfangspaketfehlerrat in %
<1m (direkt gegenüber)
-4
-61 bis -63
16 bis 23
0
ca. 4m Luftlinie
6 bis 9
-68 bis -72
8 bis 14
0 bis 7
ca. 10m Luftline
16
-77 bis -80
0 bis 4
11 bis 52
ca. 5m Luftline
(1 Wand)
12 bis 16
-75 bis -78
3 bis 11
40 bis 60
ca. 10m Luftlinie
(1Wand)
16
-75 bis -79
2 bis 3
0 bis 55
Tabelle 3.4.1: Reichweitenmessung
3.5
Aufgetretene Probleme
3.5.1 Hardware
3.5.1.1 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
3.5.1.2 PCI-Slot
Der innere PCI-Slot des STPC-Mainboard teilt sich grundsätzlich den Interrupt 11 mit dem USBPort, 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 PCIKarte im genannten Slot nicht.
Der Fehler liegt in der Interruptverwaltung und ist eventuell mit einem entsprechenden BIOSUpdate zu beheben (siehe dazu auch nächsten Absatz 3.5.1.3).
3.5.1.3 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 3.5.1.2 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.
3.5.1.4 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
3.5.2 Software
3.5.2.1
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
3.5.2.2
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 3.5.2.1 geschilderten Problem konnte nicht
ausgeschlossen werden.
Bei einer identischen Linux-Installation und –Konfiguration auf einem Laptop traten die unter
3.5.2.1 und unter 3.5.2.2 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.
3.5.2.3
Nutzung des DUN-Profils
Eine zweite Möglichkeit für das Aufsetzen des IP auf eine Bluetooth-Verbindung stellt das DUNProfil dar. Genaue Anleitungen dafür sind im Internet verfügbar, zum Beispiel unter
http://iserver.hta.fhz.ch/~iathalma/projects/bluetooth/Linux_Bluetooth_Lan_Gateway/Linux_Blueto
oth_Lan_Gateway.html oder www.bluez.org .
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 3.5.2.1 und 3.5.2.2 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
3.5.2.4
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
http://bluez.sourceforge.net/contrib/HOWTO-PAN nachzulesen. Für Debian-Linux müsste eine
Portierung erfolgen.
3.5.3 Allgemeine Bemerkungen
Ein Support-Anfrage an den Boardhersteller (Marek Micro; www.marekmicro.com ) 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 2.6.4 und der
installierten Hotplug-Umgebung die verwendete Basishardware bis an ihre Leistungsgrenzen
ausgereizt wird. Beide Features sind allerdings für die Realisierung der WLAN-802.11gSchnittstelle 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.
10-15 min, bis die erste Eingabe erfolgen kann, deutlich zu hoch.
43
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 2.6.4 verbunden mit der HotplugUmgebung eingesetzt werden soll. Der Linux-Kernel 2.4.22 bildet zumindest auf der vorliegenden
Basis-Hardware eine schnellere und stabilere Realisierung. Im weiteren sind zumindest die unter
3.5.2.1 und 3.5.2.2 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 (3.5.2.4) 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 (2.6.2.2; 3.5.2.3) 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
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: 3-936759-00-6
/2/ McCarty, B.: Learning Debian/GNU Linux;
Oreilly & Associates, 1999
ISBN: 1-565-92705-2
/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: 3-8272-5181-8
/4/ Wollert, J.F.: Das Bluetooth Handbuch;
Franzis Verlag, Poing 2002
ISBN: 3-7723-5323-1
Seminararbeiten:
/5/ Grenzendörfer, L.: Untersuchungen zu Bluetooth; TU Ilmenau, Fakultät Elektro- und
Informationstechnik,
Institut
Kommunikationsund
Messtechnik,
Fachgebiet
Kommunikationsnetze, Seminararbeit 2002
Webseiten:
/6/ www.debian.org - Webseite für Debian-Linux
/7/ www.bluez.org - Webseite für den Linux-Bluetooth-Protokollstack
/8/ www.kernel.org - Webseite für Linux-Kernels
/9/ www.avm.de - Webseite für AVM-Produkte (AVM-BlueFRITZ!-Bluetooth-USB-Dongle)
/10/ www.acer.de - Webseite für Acer-Produkte (Acer-Bluetooth-USB-Dongle)
45
6. Verwendete Bluetooth-Hardware
LISTIG-Basisgerät
Client-Laptop
Acer Bluetooth mini
AVM BlueFRITZ! USB
USB Adapter (BT500)
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
Model
Ü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
(v. mitgelieferten
HCI, L2CAP, RFCOMM, SDP, SDP, CMTP, BNEP, L2CAP,
Standard- OBEX
TCS, RFCOMM
treiber)
Unterstützte Profile
(v. mitgelieferten
GAP; SDGP, SPP, LAN, DUN, SDAP, GAP, CIP, PAN, SPP;
Standard- FAX, GOEP, FTP, OPP, SYNC DUN, CTP
treiber)
Tabelle 6.1.1: Bluetooth-Hardware
46
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 PCBereich leiten lassen, sondern die Einstellungen wie folgt beschrieben vornehmen.
Bios-Einstellungen:
Relevanter Eintrag
Zu wählender „Wert“
C
CD Hd/Pri Slave
D
Primary Master
Boot 1st
Drive C
Drive D
IDE 0
Auto, LBA
IDE 1
Auto, phys.
Tabelle 7.1.1 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 7.1.1 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
7.2 Linux-Installation auf dem LISTIG-Basisgerät
Für die Grundinstalltion von Debian-Linux auf dem LISTIG-Basisgerät ist von der „MiniWoodCD“ 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. www.debian.org 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 (141.24.93.159 bzw. 141.24.93.160)
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-2.6.4.tar.bz2) von z.B. www.kernel.org
herunter geladen und am besten im Verzeichnis /usr/src/ abgespeichert werden.
Danach ist die Archiv-Datei mit folgendem Befehl zu entpacken:
# tar xvfj linux-2.6.4.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-2.6.4
Nun geht man mit
48
# 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-2.4.18-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-2.4.18-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
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
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 KernelKompilation 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. 15-20 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
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 PANProfil unter Linux nutzbar ist. Die entsprechenden, gepackten Archive können unter www.bluez.org
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
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 ServiceDiscovery-Protocol
(SDP)
4.
BlueZ-PAN
bluez-pan-1.1.tar.gz
Treiber für das PrivatArea-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 7.4.1 ersichtlich.
Damit die Treiber-Module automatisch geladen werden, sind in der Datei /etc/modules.conf
noch folgende Zeilen zu ergänzen:
53
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-10-250
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 AVMBluetooth-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
7.6.1. 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
Für bestimmte (nicht alle) Befehle sind Manual-Pages hinterlegt und können mit
# man <Befehl>
aufgerufen werden.
Als Beispiel:
# man lsmod
7.6.2. 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-ROMLaufwerk wieder ge-unmountet wird. Dies erfolgt mit:
# umount /cdrom
7.6.3. Midnight Commander installieren
Der Midnight Commader stellt einen intuitiv bedienbaren Dateimanager auf Basis der LinuxKommandozeile 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
7.6.4. 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 www.debian.org herunter geladen und mit folgendem Befehl installiert werden:
# dpkg –i <Packagename>
7.6.5 Packages für Packen und Entpacken
Installieren des Bzip2-Packers mit:
# apt-get install bzip2
7.6.6 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
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
7.6.8 Herunterfahren bzw. Neustarten eines Linux-Systems
Herunterfahren mit:
# shutdown –h now
oder:
# halt
Ein Neustart erfolgt mit:
# reboot
57