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