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 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 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-Hopping-

2

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)-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

2.2 Bluetooth – System

Host SystemBluetooth Controller

2,4 GHzBluetooth

Radio

BluetoothLink

Controller

BluetoothLinkmanager

& IOAnwendungHost

LayerHCI HCI

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, Kanal-

verwaltung (physikalische und logische), Frequenz-Hopping, Adressierung, Sicherheit, Empfangs-

und 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-, PCCard-

oder 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 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.

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 Bluetooth-

Protokollstack.

5

Auf allen korrespondierenden Hosts (min. 1, max. 7) ist eine vergleichbare Hardware-Firmware-

Protokoll-Struktur implementiert.

Host (A)

HCI-Treiber

Bus-Treiber

High-Level-Treiber

Bus-Firmware

HCI Firm- ware

HCI Firm- ware

Bus-Firmware

Basisband Controller Basisband Controller

LinkManagerFirmware

Anwendung

HCI

Physik

Host (B)

HCI-Treiber

Bus-Treiber

High-Level-Treiber

HCI

Physik

USB, PCI, PCMCIA, UART... USB, PCI, PCMCIA, UART...

LinkManagerFirmware

BluetoothFunkstrecke

BluetoothFunkstrecke

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.

Master Slave

SlaveSlave

Standby

Master

Slave Slave

Standby

Master

Slave

Slave

Standby

Pico-Netz Scatter-Netz

Abbildung 2.3.1: Pico- und Scatter-Netze

7

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

64 kBit/s

64 kBit/s

732,2 kBit/s

57,6 kBit/s

433,9 kBit/s

433,9 kBit/s

Dat

ensy

mm

etris

ch

Dat

enas

ymm

etris

ch

Spr

ache

Synchrone Kommunikation(leitungsvermittelt)

Asynchrone Kommunikation(paketvermittelt)

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 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

2.5 Bluetooth-Protokollstack

2.5.1 Übersicht Bluetooth-Protokollstack

Bluetooth-Funk

Basisband

LMP

L2CAP

RFCOMM

PPP

Audio

AT-Befehle

UDP TCP

IP

WAE

WAP

vCard/vCal

OBEX

SDPTCS BIN

BNEP

Hostcontroller Schnittstelle

Abbildung 2.5.1: Bluetooth-Protokollstack

2.5.2 Bluetooth im ISO-OSI-Schichtenmodell

Bitübertragung

Vermittlung

Transport

LLC Sicherung MAC

Sitzung

Darstellung

Verarbeitung

RF

Baseband

LM

SDPRFCOMM

BNEPPPP

Application

IP

TCPUDP

L2CAP

ISO-OSI-Schichtenmodell Bluetooth-Schichtenmodell

1

2

3

4

5

6

7

Abbildung 2.5.2: ISO-OSI-Schichtenmodell vs. Bluetooth-Schichtenmodell

10

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.

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 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.

2.5.3.2 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

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 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.

2.5.5 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

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.

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 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.

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 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

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 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

2.6.1 Übersicht – grundlegende Bluetooth-Profile

Generic AccessProfile (GAP)

Service DiscoveryApplication Profile

(SDAP)

Private Area NetworkProfile (PAN)

Telephony Profile

Serial Port Profile(SPP)

Intercom Profile(IntP)

CordlessTelephon Profile

(CTP)

Dial Up NetworkProfile (DUNP)

LAN AccessProfile (LAP)

FAX Profile(FaxP)

Headset Profile(HSP)

Generic ObjectExchange Profile

(GOEP)

Object PushProfile (OPP)

File TransferProfile (FP)

SynchronisationProfile (SP)

Abbildung 2.6.1: Bluetooth-Profile

16

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-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 unter-

scheiden

- 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

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

GN

PANU PANU PANU

PANU Standby NAP

LAN Infrastructure

PANUPANU 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 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

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-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.

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-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

3.3.1 Aufbau

LISTIG-BasisgerätAcer USB Bluetooth Dongle

IP-Adresse: 10.0.0.1Subnetzmaske: 255.255.255.0

Debian Linux Kernel 2.6.4

Client-LaptopAVM BlueFRITZ! USB Dongle

IP-Adresse: 10.0.0.2Subnetzmaske: 255.255.255.0

MS Windows 98 SE

Bluetooth Funkstrecke ca. 1-15 m Abstand

IP over Bluetooth viaBNEP and PAN-Profile

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 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

(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 Debian-

Paket (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

http://www.debian.org/

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

http://www.sun.com/

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 Hin-

und 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. Sendeleistung Empfangsfeldstärke SNR Empfangspaket- Host und Client in dBm in dBm in dB fehlerrat 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 12 bis 16 -75 bis -78 3 bis 11 40 bis 60

(1 Wand)

ca. 10m Luftlinie 16 -75 bis -79 2 bis 3 0 bis 55 (1Wand)

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 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 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 DUN-

Profil 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

http://iserver.hta.fhz.ch/~iathalma/projects/bluetooth/Linux_Bluetooth_Lan_Gateway/Linux_Bluetooth_Lan_Gateway.html

http://iserver.hta.fhz.ch/~iathalma/projects/bluetooth/Linux_Bluetooth_Lan_Gateway/Linux_Bluetooth_Lan_Gateway.html

http://www.bluez.org/

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.11g-

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.

10-15 min, bis die erste Eingabe erfolgen kann, deutlich zu hoch.

43

http://bluez.sourceforge.net/contrib/HOWTO-PAN

http://www.marekmicro.com/

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 Hotplug-

Umgebung 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 Treiber-

und 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 Kommunikations- und 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



http://www.kernel.org/

http://www.avm.de/

http://www.acer.de/

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

Übertragungsmodus: 120 mA

Keine Angaben

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

(v. mitgelieferten Standard-

treiber)

MS Windows98SE, ME; MS

WINDOWS 2000, XP

MS Windows98SE, ME; MS

WINDOWS 2000, XP

Unterstützte Core Protocols


treiber)

HCI, L2CAP, RFCOMM, SDP,

OBEX

SDP, CMTP, BNEP, L2CAP,

TCS, RFCOMM

Unterstützte Profile


treiber)

GAP; SDGP, SPP, LAN, DUN,

FAX, GOEP, FTP, OPP, SYNC

SDAP, GAP, CIP, PAN, SPP;

DUN, CTP

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 PC-

Bereich 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 „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. 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


http://www.kernel.org/

# 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 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. 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 PAN-

Profil 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 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 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 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

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-ROM-

Laufwerk 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 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

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

1. Aufgabenstellung

Documents

Transcript of 1. Aufgabenstellung