Bluetooth ermöglicht die Bildung von persönlichen Netzwerken über drahtlose Verbindungen bei einer maximalen Reichweite von 10 Metern und operiert im unlizensierten 2,4-GHz-Band. Solche Netzwerke werden normalerweise spontan gebildet, wenn sich mobile Geräte, wie Mobiltelefone, Handhelds oder Notebooks miteinander verbinden. Im Gegensatz zu Wireless LAN ermöglicht Bluetooth auch höherwertige Dienste, wie FTP-ähnliche Dateiserver, Filepushing, Sprachübertragung, Emulation von seriellen Verbindungen und andere mehr.
Der Bluetooth-Stack von FreeBSD verwendet das Netgraph-Framework (netgraph(4)). Viele Bluetooth-USB-Adapter werden durch den ng_ubt(4)-Treiber unterstützt. Auf dem Chip BCM2033 von Broadcom basierende Bluetooth-Geräte werden von den Treibern ubtbcmfw(4) sowie ng_ubt(4) unterstützt. Die Bluetooth-PC-Card 3CRWB60-A von 3Com verwendet den ng_bt3c(4)-Treiber. Serielle sowie auf UART basierende Bluetooth-Geräte werden von sio(4), ng_h4(4) sowie hcseriald(8) unterstützt. Dieses Kapitel beschreibt die Verwendung von USB-Bluetooth-Adaptern.
Bluetooth-Unterstützung ist in der Regel als Kernelmodul verfügbar. Damit ein Gerät funktioniert, muss der entsprechende Treiber im Kernel geladen werden:
# kldload ng_ubt
Ist das Bluetooth-Gerät beim Systemstart angeschlossen, kann das entsprechende Modul auch von /boot/loader.conf geladen werden:
ng_ubt_load="YES"
Schließen Sie Ihren USB-Adapter an, sollte eine Meldung ähnlich der folgenden auf der Konsole (oder in syslog) erscheinen:
ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3,
wMaxPacketSize=49, nframes=6, buffer size=294
Zum Starten und Beenden des Bluetooth-Stacks verwenden Sie das Skript /etc/rc.d/bluetooth. Es ist empfehlenswert, den Bluetooth-Stack zu beenden, bevor Sie den Adapter entfernen. Selbst wenn Sie dies nicht tun, kommt es (normalerweise) zu keinem fatalen Fehler. Wenn Sie den Bluetooth-Stack starten, erhalten Sie eine Meldung ähnlich der folgenden:
# /etc/rc.d/bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a Features: 0xff 0xff 0xf 00 00 00 00 00 <3-Slot> <5-Slot> <Encryption> <Slot offset> <Timing accuracy> <Switch> <Hold mode> <Sniff mode> <Park mode> <RSSI> <Channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <Paging scheme> <Power control> <Transparent SCO data> Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8
Das Host Controller Interface (HCI) bietet eine Befehlsschnittstelle zum Basisbandcontroller und Linkmanager, sowie Zugriff auf den Hardwarestatus und die Kontrollregister. Dadurch wird ein einheitlicher Zugriff auf die Fähigkeiten des Bluetooth-Basisbands möglich. Die HCI-Layer des Rechners tauschen Daten und Befehle mit der HCI-Firmware der Bluetooth-Geräte aus. Über den Host Controller Transport Layer-Treiber (also den physikalischen Bus) können beide HCI-Layer miteinander kommunizieren.
Eine einzelne Netgraph-Gerätedatei vom Typ hci wird für ein einzelnes Bluetooth-Gerät erzeugt. Die HCI-Gerätedatei ist normalerweise mit der Bluetooth-Gerätetreiberdatei (downstream) sowie der L2CAP-Gerätedatei (upstream) verbunden. Alle HCI-Operationen müssen über die HCI-Gerätedatei und nicht über die Treiberdatei erfolgen. Der Standardname für die HCI-Gerätedatei (die in ng_hci(4) beschrieben wird) lautet “devicehci”.
Eine der wichtigsten Aufgaben ist das Auffinden von sich in Reichweite befindenden Bluetooth-Geräten. Diese Funktion wird als inquiry bezeichnet. Inquiry sowie andere mit HCI in Verbindung stehende Funktionen werden von hccontrol(8) zur Verfügung gestellt. Das folgende Beispiel zeigt, wie man herausfindet, welche Bluetooth-Geräte sich in Reichweite befinden. Eine solche Abfrage dauert nur wenige Sekunden. Beachten Sie, dass ein Gerät nur dann antwortet, wenn es sich im Modus discoverable befindet.
% hccontrol -n ubt0hci inquiry
Inquiry result, num_responses=1
Inquiry result #0
BD_ADDR: 00:80:37:29:19:a4
Page Scan Rep. Mode: 0x1
Page Scan Period Mode: 00
Page Scan Mode: 00
Class: 52:02:04
Clock offset: 0x78ef
Inquiry complete. Status: No error [00]
BD_ADDR stellt, ähnlich der MAC-Adresse einer Netzwerkkarte, die eindeutige Adresse eines Bluetooth-Gerätes dar. Diese Adresse ist für die Kommunikation mit dem Gerät nötig. Es ist aber auch möglich, BD_ADDR einen Klartextnamen zuzuweisen. Die Datei /etc/bluetooth/hosts enthält Informationen über die bekannten Bluetooth-Rechner. Das folgende Beispiel zeigt, wie man den Klartextnamen eines entfernten Geräts in Erfahrung bringen kann:
% hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav's T39
Wenn Sie ein entferntes Bluetooth-Gerät abfragen, wird dieses Ihren Rechner unter dem Namen “your.host.name (ubt0)” finden. Dieser Name kann aber jederzeit geändert werden.
Bluetooth ermöglicht Punkt-zu-Punkt-Verbindungen (an denen nur zwei Bluetooth-Geräte beteiligt sind), aber auch Punkt-zu-Multipunkt-Verbindungen, bei denen eine Verbindung von mehreren Bluetooth-Geräten gemeinsam genutzt wird. Das folgende Beispiel zeigt, wie man die aktiven Basisbandverbindungen des lokalen Gerätes anzeigen kann:
% hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN
Ein connection handle ist für die Beendigung einer Basisbandverbindung nützlich. Im Normalfall werden inaktive Verbindungen aber automatisch vom Bluetooth-Stack getrennt.
# hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16]
Rufen Sie hccontrol help auf, wenn Sie eine komplette Liste aller verfügbaren HCI-Befehle benötigen. Die meisten dieser Befehle müssen nicht als root ausgeführt werden.
Das Logical Link Control and Adaptation Protocol (L2CAP) bietet höherwertigen Protokollen verbindungsorientierte und verbindungslose Datendienste an. Dazu gehören auch Protokollmultiplexing, Segmentierung und Reassemblierung. L2CAP erlaubt höherwertigen Protokollen und Programmen den Versand und Empfang von L2CAP-Datenpaketen mit einer Länge von bis zu 64 Kilobytes.
L2CAP arbeitet kanalbasiert. Ein Kanal ist eine logische Verbindung innerhalb einer Basisbandverbindung. Jeder Kanal ist dabei an ein einziges Protokoll gebunden. Mehrere Geräte können an das gleiche Protokoll gebunden sein, es ist aber nicht möglich, einen Kanal an mehrere Protokolle zu binden. Jedes über einen Kanal ankommende L2CAP-Paket wird an das entsprechende höherwertige Protokoll weitergeleitet. Mehrere Kanäle können sich die gleiche Basisbandverbindung teilen.
Eine einzelne Netgraph-Gerätedatei vom Typ l2cap wird für ein einzelnes Bluetooth-Gerät erzeugt. Die L2CAP-Gerätedatei ist normalerweise mit der Bluetooth-HCI-Gerätedatei (downstream) sowie der Bluetooth-Socket-Gerätedatei (upstream) verbunden. Der Standardname für die L2CAP-Gerätedatei, die in ng_l2cap(4) beschrieben wird, lautet “devicel2cap”.
Ein nützlicher Befehl zum Anpingen von anderen Geräten ist l2ping(8). Einige Bluetooth-Geräte senden allerdings nicht alle erhaltenen Daten zurück. Die Ausgabe 0 bytes ist also kein Fehler:
# l2ping -a 00:80:37:29:19:a4 0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0
Das Programm l2control(8) liefert Informationen über L2CAP-Dateien. Das folgende Beispiel zeigt, wie man die Liste der logischen Verbindungen (Kanäle) sowie die Liste der Basisbandverbindungen abfragen kann:
% l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State 00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN % l2control -a 00:02:72:00:d4:1a read_connection_list L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN
btsockstat(1) ist ein weiteres Diagnoseprogramm. Es funktioniert analog zu netstat(1), arbeitet aber mit Bluetooth-Datenstrukturen. Das folgende Beispiel zeigt die gleiche Liste der logischen Verbindungen wie l2control(8) im vorherigen Beispiel.
% btsockstat Active L2CAP sockets PCB Recv-Q Send-Q Local address/PSM Foreign address CID State c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN Active RFCOMM sessions L2PCB PCB Flag MTU Out-Q DLCs State c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN
Das RFCOMM-Protokoll emuliert serielle Verbindungen über das L2CAP-Protokoll. Es basiert auf dem ETSI-Standard TS 07.10. Bei RFCOMM handelt es sich um ein einfaches Transportprotokoll, das um Funktionen zur Emulation der 9poligen Schaltkreise von mit RS-232 (EIATIA-232-E) kompatiblen seriellen Ports ergänzt wurde. RFCOMM erlaubt bis zu 60 simultane Verbindungen (RFCOMM-Kanäe) zwischen zwei Bluetooth-Geräten.
Eine RFCOMM-Kommunikation besteht aus zwei Anwendungen (den Kommunikationsendpunkten), die über das Kommunikationssegment miteinander verbunden sind. RFCOMM unterstützt Anwendungen, die auf serielle Ports angewiesen sind. Das Kommunikationssegment entspricht der (direkten) Bluetooth-Verbindung zwischen den beiden Geräten.
RFCOMM kümmert sich um die direkte Verbindung von zwei Geräten, oder um die Verbindung zwischen einem Gerät und einem Modem (Netzwerkverbindung). RFCOMM unterstützt auch andere Konfigurationen. Ein Beispiel dafür sind Module, die drahtlose Bluetooth-Geräte mit einer verkabelten Schnittstelle verbinden können.
Unter FreeBSD wurde das RFCOMM-Protokoll im Bluetooth Socket-Layer implementiert.
In der Voreinstellung nutzt Bluetooth keine Authentifizierung, daher kann sich jedes Bluetoothgerät mit jedem anderen Gerät verbinden. Ein Bluetoothgerät (beispielsweise ein Mobiltelefon) kann jedoch für einen bestimmten Dienst (etwa eine Einwählverbindung) eine Authentifizierung anfordern. Bluetooth verwendet zu diesem Zweck PIN-Codes. Ein PIN-Code ist ein maximal 16 Zeichen langer ASCII-String. Damit eine Verbindung zustande kommt, muss auf beiden Geräten der gleiche PIN-Code verwendet werden. Nachdem der Code eingegeben wurde, erzeugen beide Geräte einen link key, der auf den Geräten gespeichert wird. Beim nächsten Verbindungsaufbau wird der zuvor erzeugte Link Key verwendet. Diesen Vorgang bezeichnet man als Pairing. Geht der Link Key auf einem Gerät verloren, muss das Pairing wiederholt werden.
Der hcsecd(8)-Daemon verarbeitet alle Bluetooth-Authentifzierungsanforderungen und wird über die Datei /etc/bluetooth/hcsecd.conf konfiguriert. Der folgende Ausschnitt dieser Datei zeigt die Konfiguration für ein Mobiltelefon, das den PIN-Code “1234” verwendet:
device {
bdaddr 00:80:37:29:19:a4;
name "Pav's T39";
key nokey;
pin "1234";
}
Von der Länge abgesehen, unterliegen PIN-Codes keinen Einschränkungen. Einige
Geräte, beispielsweise Bluetooth-Headsets, haben einen festen PIN-Code eingebaut.
Die Option -d sorgt dafür, dass der hcsecd(8)-Daemon im
Vordergrund läuft. Dadurch kann der Ablauf einfach verfolgt werden. Stellen Sie das
entfernte Gerät auf receive pairing und initiieren
Sie die Bluetoothverbindung auf dem entfernten Gerät. Sie erhalten die Meldung, dass
Pairing akzeptiert wurde und der PIN-Code benötigt wird. Geben Sie den gleichen
PIN-Code ein, den Sie in hcsecd.conf festgelegt haben. Ihr
Computer und das entfernte Gerät sind nun miteinander verbunden. Alternativ
können Sie das Pairing auch auf dem entfernten Gerät initiieren.
hcsecd kann durch das Einfügen der folgenden Zeile in /etc/rc.conf beim Systemstart automatisch aktiviert werden:
hcsecd_enable="YES"
Es folgt nun eine beispielhafte Ausgabe des hcsecd-Daemons:
hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4
Das Service Discovery Protocol (SDP) erlaubt es Clientanwendungen, von Serveranwendungen angebotene Dienste sowie deren Eigenschaften abzufragen. Zu diesen Eigenschaften gehören die Art oder die Klasse der angebotenen Dienste sowie der Mechanismus oder das Protokoll, die zur Nutzung des Dienstes notwendig sind.
SDP ermöglicht Verbindungen zwischen einem SDP-Server und einem SDP-Client. Der Server enthält eine Liste mit den Eigenschaften der vom Server angebotenen Dienste. Jeder Eintrag beschreibt jeweils einen einzigen Serverdienst. Ein Client kann diese Informationen durch eine SDP-Anforderung vom SDP-Server beziehen. Wenn der Client oder eine Anwendung des Clients einen Dienst nutzen will, muss eine seperate Verbindung mit dem Dienstanbieter aufgebaut werden. SDP bietet einen Mechanismus zum Auffinden von Diensten und deren Eigenschaften an, es bietet aber keine Mechanismen zur Verwendung dieser Dienste.
Normalerweise sucht ein SDP-Client nur nach Diensten, die bestimmte geforderte Eigenschaften erfüllen. Es ist aber auch möglich, anhand der Dienstbeschreibungen eine allgemeine Suche nach den von einem Server angebotenen Diensten durchzuführen. Diesen Vorgang bezeichnet man als Browsing.
Der Bluetooth-SDP-Server sdpd(8) und der Kommandozeilenclient sdpcontrol(8) sind bereits in der Standardinstallation von FreeBSD enthalten. Das folgende Beispiel zeigt, wie eine SDP-Abfrage durchgeführt wird:
% sdpcontrol -a 00:01:03:fc:6e:ec browse
Record Handle: 00000000
Service Class ID List:
Service Discovery Server (0x1000)
Protocol Descriptor List:
L2CAP (0x0100)
Protocol specific parameter #1: u/int/uuid16 1
Protocol specific parameter #2: u/int/uuid16 1
Record Handle: 0x00000001
Service Class ID List:
Browse Group Descriptor (0x1001)
Record Handle: 0x00000002
Service Class ID List:
LAN Access Using PPP (0x1102)
Protocol Descriptor List:
L2CAP (0x0100)
RFCOMM (0x0003)
Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
LAN Access Using PPP (0x1102) ver. 1.0
... und so weiter. Beachten Sie, dass jeder Dienst eine Liste seiner Eigenschaften (etwa den RFCOMM-Kanal) zurückgibt. Je nach dem, welche Dienste Sie benötigen, sollten Sie sich einige dieser Eigenschaften notieren. Einige Bluetooth-Implementationen unterstützen kein Service Browsing und geben daher eine leere Liste zurück. Ist dies der Fall, ist es dennoch möglich, nach einem bestimmten Dienst zu suchen. Das folgende Beispiel demonstriert die Suche nach dem OBEX Object Push (OPUSH) Dienst:
% sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH
Unter FreeBSD ist es die Aufgabe des sdpd(8)-Servers, Bluetooth-Clients verschiedene Dienste anzubieten. Sie können diesen Server durch das Einfügen der folgenden Zeile in die Datei /etc/rc.conf aktivieren:
sdpd_enable="YES"
Nun kann der sdpd-Daemon durch folgene Eingabe gestartet werden:
# /etc/rc.d/sdpd start
Der lokale Server, der den entfernten Clients Bluetooth-Dienste anbieten soll, bindet diese Dienste an den lokalen SDP-Daemon. Ein Beispiel für eine solche Anwendung ist rfcomm_pppd(8). Einmal gestartet, wird der Bluetooth-LAN-Dienst an den lokalen SDP-Daemon gebunden.
Die Liste der vorhandenen Dienste, die am lokalen SDP-Server registriert sind, lässt sich durch eine SDP-Abfrage über einen lokalen Kontrollkanal abfragen:
# sdpcontrol -l browse
Das Dial-Up Networking (DUN)-Profil wird vor allem für Modems und Mobiltelefone verwendet. Dieses Profil ermöglicht folgende Szenarien:
Die Verwendung eines Mobiltelefons oder eines Modems durch einen Computer als drahtloses Modem, um sich über einen Einwahlprovider mit dem Internet zu verbinden oder andere Einwahldienste zu benutzen.
Die Verwendung eines Mobiltelefons oder eines Modems durch einen Computers, um auf Datenabfragen zu reagieren.
Der Zugriff auf ein Netzwerk über das PPP (LAN)-Profil kann in folgenden Situationen verwendet werden:
Den LAN-Zugriff für ein einzelnes Bluetooth-Gerät
Den LAN-Zugriff für mehrere Bluetooth-Geräte
Eine PC-zu-PC-Verbindung (unter Verwendung einer PPP-Verbindung über eine emulierte serielle Verbindung)
Beide Profile werden unter FreeBSD durch ppp(8) sowie rfcomm_pppd(8) implementiert - einem Wrapper, der RFCOMM Bluetooth-Verbindungen unter PPP nutzbar macht. Bevor ein Profil verwendet werden kann, muss ein neuer PPP-Abschnitt in /etc/ppp/ppp.conf erzeugt werden. Beispielkonfigurationen zu diesem Thema finden Sie in rfcomm_pppd(8).
Im folgenden Beispiel verwenden wir rfcomm_pppd(8), um eine RFCOMM-Verbindung zu einem entfernten Gerät mit der BD_ADDR 00:80:37:29:19:a4 auf dem RFCOMM-Kanal DUN aufzubauen. Die aktuelle RFCOMM-Kanalnummer erhalten Sie vom entfernten Gerät über SDP. Es ist auch möglich, manuell einen RFCOMM-Kanal festzulegen. In diesem Fall führt rfcomm_pppd(8) keine SDP-Abfrage durch. Verwenden Sie sdpcontrol(8), um die RFCOMM-Kanäle des entfernten Geräts herauszufinden.
# rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup
Der sdpd(8)-Server muss laufen, damit ein Netzzugriff mit dem PPP (LAN)-Profil möglich ist. Außerdem muss für den LAN-Client ein neuer Eintrag in /etc/ppp/ppp.conf erzeugt werden. Beispielkonfigurationen zu diesem Thema finden Sie in rfcomm_pppd(8). Danach starten Sie den RFCOMM PPP-Server über eine gültige RFCOMM-Kanalnummer. Der RFCOMM PPP-Server bindet dadurch den Bluetooth-LAN-Dienst an den lokalen SDP-Daemon. Das folgende Beispiel zeigt Ihnen, wie man den RFCOMM PPP-Server startet.
# rfcomm_pppd -s -C 7 -l rfcomm-server
OBEX ist ein häufig verwendetes Protokoll für den Dateitransfer zwischen Mobilgeräten. Sein Hauptzweck ist die Kommunikation über die Infrarotschnittstelle. Es dient daher zum Datentransfer zwischen Notebooks oder PDAs sowie zum Austausch von Visitenkarten oder Kalendereinträgen zwischen Mobiltelefonen und anderen Geräten mit PIM-Funktionen.
Server und Client von OBEX werden durch das Softwarepaket obexapp bereitgestellt, das als Port comms/obexapp verfügbar ist.
Mit dem OBEX-Client werden Objekte zum OBEX-Server geschickt oder angefordert. Ein Objekt kann etwa eine Visitenkarte oder ein Termin sein. Der OBEX-Client fordert über SDP die Nummer des RFCOMM-Kanals vom entfernten Gerät an. Dies kann auch durch die Verwendung des Servicenamens anstelle der RFCOMM-Kanalnummer erfolgen. Folgende Dienste werden unterstützt: IrMC, FTRN und OPUSH. Es ist möglich, den RFCOMM-Kanal als Nummer anzugeben. Es folgt nun ein Beispiel für eine OBEX-Sitzung, bei der ein Informationsobjekt vom Mobiltelefon angefordert und ein neues Objekt (hier eine Visitenkarte) an das Telefonbuch des Mobiltelefons geschickt wird:
% obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get telecom/devinfo.txt Success, response: OK, Success (0x20) obex> put new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20)
Um OBEX-Push-Dienste anbieten zu können, muss der sdpd-Server gestartet sein. Ein Wurzelverzeichnis, in dem alle ankommenden Objekt gespeichert werden, muss zusätzlich angelegt werden. In der Voreinstellung ist dies /var/spool/obex. Starten Sie den OBEX-Server mit einer gültigen Kanalnummer. Der OBEX-Server registriert nun den OBEX-Push-Dienst mit dem lokalen SDP-Daemon. Um den OBEX-Server zu starten, geben Sie Folgendes ein:
# obexapp -s -C 10
Durch dieses Profil können Bluetooth-Geräte RS232- (oder damit kompatible) serielle Kabelverbindungen emulieren. Anwendungen sind dadurch in der Lage, über eine virtuelle serielle Verbindung Bluetooth als Ersatz für eine Kabelverbindung zu nutzen.
Das Profil Serial-Port wird durch rfcomm_sppd(1) verwirklicht. Pseudo-tty wird hier als virtuelle serielle Verbindung verwendet. Das folgende Beispiel zeigt, wie man sich mit einem entfernten Serial-Port-Dienst verbindet. Beachten Sie, dass Sie den RFCOMM-Kanal nicht angeben müssen, da rfcomm_sppd(1) diesen über SDP vom entfernten Gerät abfragen kann. Wenn Sie dies nicht wollen, können Sie einen RFCOMM-Kanal auch manuell festlegen.
# rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6...
Sobald die Verbindung hergestellt ist, kann pseudo-tty als serieller Port verwenden werden.
# cu -l ttyp6
Einige ältere Bluetooth-Geräte unterstützen keinen Rollentausch. Wenn FreeBSD eine neue Verbindung akzeptiert, wird versucht, die Rolle zu tauschen, um zum Master zu werden. Geräte, die dies nicht unterstützen, können keine Verbindung aufbauen. Beachten Sie, dass der Rollentausch ausgeführt wird, sobald eine neue Verbindung aufgebaut wird, daher ist es nicht möglich, das entfernte Gerät zu fragen, ob es den Rollentausch unterstützt. Dieses Verhalten von FreeBSD kann aber durch eine HCI-Option geändert werden:
# hccontrol -n ubt0hci write_node_role_switch 0
Verwenden Sie hcidump, das Sie über den Port comms/hcidump installieren können. hcidump hat Ähnlichkeiten mit tcpdump(1). Es dient zur Anzeige der Bluetooth-Pakete in einem Terminal oder zur Speicherung der Pakete in einer Datei (Dump).
| Zurück | Zum Anfang | Weiter |
| Drahtlose Netzwerke | Nach oben | LAN-Kopplung mit einer Bridge |
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.