3    Bluez Protokoll-Stack

3.1 ALLGEMEIN
3.2 INSTALLATION
3.3 QUELLTEXT
3.4 RFCOMM
3.5 BNEP
       3.5.1 Intel
       3.5.2 Inventel
       3.5.3 Sony
3.6 ANWENDUNG
       3.6.1 Group ad-hoc Network
       3.6.2 Network Acces Point

3.1 Allgemein

BlueZ  ist der offizielle Bluetooth Stack für Linux und kann unter http://bluez.sourceforge.net/ heruntergeladen werden.
Er besitzt folgende Eigenschaften:
+ Flexible, effiziente und modulare Architektur
+ Unterstützung für mehrere Bluetooth Geräte
+ Hardwareabstraktion
+ Standard Socketinterface zu allen Protokollschichten
 
Der aktuelle Protokollstack (Vers. 2.0) besteht aus:
+ HCI Core
+ HCI UART, USB und HCI Emulation Treiber
+ L2CAP Protokoll als ladbares Kernel-Modul
+ Konfigurations- und Testprogramme
Abbildung 11 zeigt eine Übersicht des BlueZ Protokoll Stack.
 
 

Abbildung 11


3.2 Installation

Die Installation bzw. die Übersetzung des Protokoll Stacks ist im zugehörigen „HowTo“ nicht immer ganz aktuell beschrieben. Deshalb werde ich an dieser Stelle einige Tips zur grundsätzliche Vorgehensweise geben.
Der Bluez Stack ist ab Version 2.0-pre7 in drei Teile aufgeteilt:
- BlueZ-libs: Enthält die benötigten Bibliotheken
- BlueZ-kernel: Enthält die benötigten Kernel-Module
- BlueZ-utils: Enthält Programme zum Testen bzw. Konfigurieren des Stacks
Das Verzeichnis, in dem sich der zu übersetzende Quelltext befindet, enthält auch das „configure-Script“ welches automatisch alle Informationen, die der Compiler benötigt ermittelt und diese im „Makefile“ ablegt. Leider funktioniert dieses Script besonders beim Cross-Kompilieren nicht immer ohne Probleme. Meist müssen noch weitere Informationen als Übergabeparameter in der Kommandozeile übergeben bzw. bestimmte Umgebungsvariablen gesetzt werden. Sollte auch dies nicht zum gewünschten Erfolg führen, so muss ggf. die Datei „config.in“ editiert werden. In dieser Datei stehen Angaben wie z.B. lib-Verzeichnisse, aus denen mittels „autoconfig“ das „configure-Script“ generiert wird. Wichtig hierbei kann es auch sein, das alte „config.cach“ zu löschen um auf jeden Fall eine aktualisierte Version zu erstellen.
Beim Update auf eine neuere Version von BlueZ ist es wichtig, vorher die alten Module zu löschen, da sich Verzeichnisse ändern können und das alte Modul somit nicht überschrieben wird und es dem Zufall überlassen bleibt, welches Modul geladen wird.
Wenn Probleme auftreten kann es auch hilfreich sein, in der Mailingliste von BlueZ ( http://bluez.sourceforge.net/ ) zu suchen, da man meist nicht der erste ist, der mit solchen Problemen zu kämpfen hat.

Falls aber alles in Ordnung ist können die drei Teile von BlueZ mit

./configure

make
make install
erzeugt und installiert werden. Danach können die fertigen Module geladen werden, z.B. für ein USB-Gerät würde das folgendermaßen aussehen:
modprobe usb-uhci         //Modul für USB
modprobe hci_usb          //Bluez-Modul für USB-Unterstützung
modprobe l2cap            //Modul für L2CAP
modprobe bluez            //Bluez-Kern
Wichtig hierbei ist es zu überprüfen, ob das USB-Modul usb-uhci und nicht etwa uhci verwendet wird, was zu Problemen führen kann, ggf. also das Kernelmodul usb-uhci  z.B. mit xconfig auswählen und installieren. Mit den mitgelieferten Test- bzw. Konfigurationsprogrammen kann nun die korrekte Funktion des Stacks überprüft werden.



3.3 Quelltext

Der Quelltext von BlueZ-2.0 Kern ist in 9 Dateien aufgeteilt:
Ø af_bluetooth.c: Hier steht alles, was mit Sockets zu tun hat (z.B. Socket öffnen/initialisieren/lesen/schreiben/schließen usw.)
Ø hci_conn.c: Darin sind Funktionen enthalten um SCO- bzw. ACL-Verbindungen zu erstellen/hinzuzufügen/beenden/Informationen anzuzeigen usw.
Ø hci_core: Hier findet man Funktionen, die zur Kommunikation mit dem Bluetoothgerät über das Host Controller Interface nötig sind (z.B. Reset  request SCO bzw. ACL Daten senden bzw. empfangen usw.)
Ø hci_event.c: Funktionen zur Auswertung von Ereignissen vom Bluetooth Gerät, die über das Host Controller Interface empfangen werden (z.B.Connect Request/Inquiry usw.)
Ø hci_sock.c: Darin befinden sich Funktionen zur Kommunikation mit dem Host Controller Interface über Sockets (z.B. erstellen/verwalten/hinzufügen von Sockets bzw. senden/empfangen von Daten über Sockets usw.)
Ø l2cap.c: Hier steht die Implementierung von L2CAP und Funktionen zur Kommunikation über das zugehörige Socket Interface.
Ø lib.c: Quelltext einer Bluetooth Kernel Bibliothek enthält z.B. Bluetooth Fehlercodes usw.

Ø sco.c: Stellt ein Socket Interface für SCO-Verbindungen zur Verfügung

Ø syms.c: Enthält Bluetooth Symbole
 

Außerdem findet man im „drivers“-Verzeichnis den Quelltext für die verfügbaren Treiber:

Ø hci_usb: Treiber für USB

Ø hci_uart: Treiber für die serielle Schnittstelle

Ø dtl1_cs: Treiber für PCMCIA-Karten

Ø hci_vhci: Treiber für ein Virtuelles Gerät


3.4 RFCOMM

RFCOMM ist als Dämon realisiert und setzt auf den BlueZ-Stack auf. Um eine Verbindung über RFCOMM erstellen zu können muß ein Server und ein Client definiert werden, die dann z.B. über Point-to-Point Protokoll miteinander kommunizieren können.



3.5 BNEP

Zur Zeit gibt es Implementierungen dreier Firmen des Bluetooth Network Encapsulation Protokoll für BlueZ, die im weiteren kurz vorgestellt werden sollen.

3.5.1 Intel

Die BNEP Implementierung von der Firma Intel ist als Dämon realisiert und wurde im Januar 2002 erstmals veröffentlicht. Leider ist durch den Dämon nur die Serverseite (PANU/NAP) realisiert und es sieht im Moment nicht danach aus, als ob noch weiter an der Implementierung gearbeitet würde, zumal es inzwischen mindestens eine andere relativ stabile Versionen gibt und auch nicht mehr auf dem Sourceforge-Server zu finden ist.

3.5.2 Inventel

Kurz darauf im Februar 2002 erschien erstmals eine Implementierung der französischen Firma Inventel. Inventel realisierte seine Version von BNEP als Kernel-Modul. Der Quellcode ist unter http://developers.inventel.com/pub/pan/ erhältlich, ist aber leider bis jetzt leider nicht über die Version 0.02 hinausgekommen.

3.5.3 Sony

Bei BlueNIC handelt es sich ebenfalls um eine Implementierung in Form eines Kernel-Modules und wurde von der Firma Sony im März 2002 veröffentlicht. BlueNIC steht derzeit in der Version 1.0 unter http://www.sony.co.jp/en/Products/Linux/Download/Bluetooth.html zum Download bereit und wurde inzwischen sogar auch in das Bluez-CVS aufgenommen. Somit ist BlueNIC ab BlueZ-2.1 bereits enthalten und deshalb werde ich etwas genauer auf BlueNIC eingehen.
Die Sony Implementierung ist der von Inventel sehr ähnlich und beruht auf den gleichen Ideen. BlueNIC beinhaltet Programme zum Konfigurieren bzw. zum Testen von BNEP welche nicht zuletzt wegen der recht ausführlichen Dokumentation sehr leicht zu bedienen sind.
Architektur
Die BlueNIC PANU Implementierung registriert für jedes Bluetooth-Gerät ein Linux Netzwerkgerät. Die MAC-Adresse eines jeden Bluetooth/Ethernet Paares ist die Bluetoothadresse des jeweiligen Bluetooth-Gerätes. Diese Funktionalität ist in dem Kernel-Modul „bnep“ implementiert, das von einem Anwendungsprogramm aus gesteuert wird.
Die GN bridging Funktionen sind ebenfalls in dem Modul realisiert und ermöglichen die im PAN-Profile definierten Filterungs- und Komprimierungsfunktionen.
Die Funktionalität des NAP kann durch Routing oder Bridging realisiert werden. Im Unterschied zum Routing, dass auf Layer 3 (NetworkLayer) des OSI Modells erfolgt, bietet eine Bridge eine völlig protokolltransparente Weitergabe von Daten auf Layer 2 (Link Layer). Auf Unixebene kann Routing recht einfach durch Manipulation der statischen Routingtabelle mit iproute bzw. iproute2 oder dynamisch mit routed erfolgen. Eine Bridge kann in Form eines Kernel-Moduls geladen und mit den entsprechenden Programmen konfiguriert werden um die zwei Netzwerke die über verschiedene Interfaces erreichbar sind miteinander zu verbinden.
Abbildung 12 zeigt die generelle Architektur des Protokoll-Stacks für das PAN-Profile.

Abbildung 12

Schnittstellen

BNEP Controller <-> BNEP

- Initialisierung des Gerätes

- Verwaltung von Verbindungen

- Abfrage von Informationen über Verbindungen und Filtereinstellungen via /proc/bnep

- Testschnittstelle

BNEP <-> L2CAP

- Senden und Empfangen von Daten mittels Standard Socket Interface vom Kernel

- Verbinden und Verbindung trennen mittels Standard Socket Interface vom Kernel
 

BNEP <-> Linux Netzwerkinfrastruktur

- Abfrage von Multicast Einstellungen um Netzwerkfilter zu setzen

- Abfrage installierter Netzwerkprotokolle um Multicast-Filter zu setzen


3.6 Anwendung

Die Anwendung des BlueZ-Stacks mit BlueNIC soll nun anhand einiger praktischen Beispiele erläutert werden.

3.6.1 Group ad-hoc Network

Ein Group ad-hoc Netzwerk dient dazu, Daten zwischen zwei PANUs bzw. zwischen PANU und Master auszutauschen. Dieses Netzwerk läßt sich leicht mittels der entsprechenden Hilfsprogramme aufbauen. Dazu werden zunächst zwei PANUs definiert, welchen die entsprechende IP-Adresse (IP) zugewiesen wird. Die Hardware-Adresse ist jeweils die Bluetooth-Adresse des Gerätes, hier als BT bezeichnet. Der GN ist der Master, der zu den beiden Slaves eine Verbindung aufbaut. Würde das Netzwerk nur aus zwei Teilnehmern bestehen, so könnte in diesem Sonderfall auch der PANU als Master fungieren.
 
Szenario
 

Abbildung 13


In diesem Netzwerk können zwischen jedem der Teilnehmern Daten ausgetauscht werden. Wie der Datenaustausch zwischen den beiden PANU 1 und PANU 2 erfolgt soll anhand von Abbildung 14 verdeutlicht werden.
 


Abbildung 14

Die von einer TCP/IP basierenden Netzwerkanwendung gesendeten Daten gelangen über die entsprechenden Protokollschichten und über die Funkstrecke zum GN. Dort gelangen diese wiederum über die entsprechenden Protokollschichten zu BNEP. Wäre nun das Datenpaket an den GN adressiert (BT), so würde es über die Protokollschichten IP/TCP zur Netzwerkanwendung gelangen. Da aber in unserem Fall PANU 2 der Empfänger des Datenpakets sein soll, vertauscht BNEP die Quell- und Zieladresse des Ethernetpaketes und übergibt diese wieder über die niedrigeren Protokollschichten an PANU 2, der die Daten empfängt und die Nutzdaten der entsprechenden Netzwerkanwendung zur Verfügung stellt. Das Packet-Forwarding für den GN ist im BNEP-Kernelmodul implementiert d.h. höhere Protokollschichten als BNEP werden beim GN in diesem Fall nicht benötigt.

Ein konkretes Beispiel für die Funktion eines GN wird anhand von Abbildung 16 erläutert.
 


Abbildung 16

In diesem Beispiel wird ein „ping“ vonPANU 1 auf PANU 2 ausgeführt. Die gesendeten Pakete in Abbildung 16 wurden mit Hilfe eines Protokoll-Analyser aufgezeichnet. Zunächst sendet PANU 1 Ethernetpaket 5, in Form eines „Compressed Ethernet Destination Only BNEP“ Paketes mit Zieladresse PANU 2 (BT-Adresse) an den Master (GN). Der GN wandelt das Paket in ein „Compressed Ethernet Source Only BNEP“ Paket (BNEP 6) mit Quelladresse in Form der BT-Adresse von PANU 1 um und sendet dieses an PANU 2. PANU 2, der das Paket empfangen hat generiert nun seinerseits ein „ComprDest“ Ethernetpaket mit Zieladresse PANU 1 und sendet dieses an den GN, der genau wie vorher wieder Source durch Destination ersetzt und die Antwort von PANU 2 an PANU 1 sendet. Die „ping-Anfrage“ an PANU 2 wurde somit beantwortet. Eine genauere Abbildung des Scans ist als Abbildung A1 im Anhang zu finden.

Datenrate

Beim Down- bzw. Upload einer 2 MB großen Datei mit ftp (File Transfer Protocol) ergaben sich in diesem Bluetooth-Netzwerk die in Tabelle 6 dargestellten Datenraten. Abbildung A2 im Anhang zeigt einen Ausschnitt der Übertragenen Pakete.
 
 

 
PANU 1/2 <-> GN
PANU1 <-> PANU2
Datenrate 
60 kB/s
38 kB/s
Tabelle 6

3.6.2 Network Acces Point

Dieses Szenario zeichnet sich dadurch aus, dass mindestens ein Teilnehmer eines Blutooth-Netzes Zugang zu einem anderen Netzwerk hat und diesen und die damit verbundenen Dienste den übrigen Teilnehmern zur Verfügung stellt. Der Zugang zu dem zweiten Netz kann dabei sowohl durch eine Network-Bridge als auch durch einen Router erfolgen.
Szenario 1

Abbildung 17

In Abbildung 17 ist ein Szenario dargestellt, in dem den NAP Zugang zu zwei verschiedenen Bluetooth-Piconetzen hat, indem er über zwei Bluetooth-Geräte verfügt. In den beiden Piconetzen können wiederum aus bis zu sieben PANUs bestehen, die untereinander oder mit den NAP Daten austauschen können. Der Unterschied zum GN liegt nun darin, dass der NAP den PANUs Zugang zu einem zweiten Piconetz mit NAP und PANUs ermöglicht. Die Weiterleitung von IP-Paketen zwischen die beiden Netzen erfolgt mittels Routing durch Einrichtung von entsprechenden Routing-Tabelle. Die Konfiguration des Netzwerks erfolgt mit „iproute2“, Informationen hierzu findet man unter http://www.linuxguruz.org/iptables/howto/2.4routing.html . Die Routing-Tabellen für speziell dieses Netzwerk, sowie einige weiter Hinweise findet man im Anhang.

Datenrate

Beim Down- bzw. Upload einer 2 MB großen Datei ergaben sich in diesem Bluetooth-Netzwerk die in Tabelle 7 dargestellten Datenraten.
 

 
PANU 1/2 <-> NAP
PANU1 <-> PANU2
Datenrate
68 kB/s
42 kB/s
Tabelle 7

Szenario 2
 



Abbildung 18

Es ist auch möglich, dass die beiden NAPs nicht an einem Rechner angeschlossen sind, sondern an getrennten Rechnern, die z.B. über Ethernet miteinander verbunden sind. Abbildung 18 zeigt ein solches Szenario.Es können über Ethernet beliebig viele NAPs und somit beliebig viele Piconetze miteinander verbunden sein. Aus dem Anhang können wiederum die Routing-Tabellen für dieses Szenario entnommen werden.
 
 

 
[prev]
Inhalt
[next]