A Bluetooth egy olyan vezeték nélküli technológia, amellyel a 2,4 GHz-es frekvenciatartományban tudunk személyi hálózatokat létrehozni 10 méteren belül. Az ilyen típusú hálózatok általában alkalmi jelleggel keletkeznek különféle hordozható eszközök, mint például mobiltelefonok, kézi számítógépek és laptopok között. Eltérően más népszerű vezeték nélküli technológiáktól, például a wi-fitől, a Bluetooth magasabb szintű szolgáltási profilokat is felajánl: FTP-szerű állományszervereket, az állományok áttolását, hang átküldését, soros vonali emulációt és még sok minden mást.
A FreeBSD-ben megvalósított Bluetooth protokollkészlet a Netgraph rendszerre építkezik (lásd netgraph(4)). A Bluetooth alapú USB-s hardverzárak széles körét támogatja az ng_ubt(4) meghajtó. A Broadcom BCM2033 chipre épített Bluetooth eszközöket az ubtbcmfw(4) és az ng_ubt(4) meghajtók támogatják. A 3Com Bluetooth PC Card 3CRWB60-A eszközt az ng_bt3c(4) meghajtó támogatja. A soros és UART alapú Bluetooth eszközöket a sio(4), ng_h4(4) és hcseriald(8) ismeri. Ebben a szakaszban a Bluetooth alapú USB-s hardverzárak használatát mutatjuk be.
Alapértelmezés szerint a Bluetooth eszközmeghajtók modulként érhetőek el. Az eszköz csatlakoztatása előtt a megfelelő meghajtót be kell töltenünk a rendszermagba:
# kldload ng_ubt
Ha a Bluetooth eszköz már a rendszer indításakor is jelen van, akkor a modult az /boot/loader.conf állományon keresztül is betölthetjük:
ng_ubt_load="YES"
Dugjuk be az USB-s hardverzárunkat. Az alábbihoz hasonló kimenet fog keletkezni a konzolon (vagy a rendszernaplóban):
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=294Az /etc/rc.d/bluetooth szkript fogja végezni a Bluetooth használatához szükséges protokollkészlet elindítását és leállítását. Jó ötlet leállítani az eszköz eltávolítása előtt, de ha elhagyjuk, (általában) nem okoz végzetes hibát. Az indításkor a következő kimenetet kapjuk:
# /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
A Host Controller Interface (HCI) egy parancsfelületet nyújt a működési sáv vezérlőjéhez (baseband controller) és az összeköttetések kezelőjéhez (link manager), valamint hozzáférést a hardverállapot és -vezérlő regiszterekhez. Ez a felület egy egységes módszert szolgáltat a Bluetooth működési sávjához tartozó tulajdonságok eléréséhez. Az eszközön üzemelő HCI réteg a Bluetooth hardverben található HCI firmware-rel vált adatokat és parancsokat. A Host Controller Transport Layer (vagyis a fizikai busz) meghajtója mind a két HCI réteget és a kettejük közti információcserét is elérhetővé teszi.
Az egyes Bluetooth eszközökhöz létrejön egy-egy hci típusú Netgraph-beli csomópont. Ez a HCI csomópont általában a Bluetooth eszközmeghajtó csomópontjához (lefelé) és az L2CAP csomóponthoz (felfelé) csatlakozik. Az összes HCI műveletet a HCI csomóponton kell elvégezni és nem az eszközmeghajtóhoz tartozón. A HCI csomópont alapértelmezett neve a “devicehci”. Ezekről többet az ng_hci(4) man oldalán tudhatunk meg.
Az egyik legáltalánosabb feladat a Bluetooth eszközök esetében a közelben levő további eszközök felderítése. Ezt a műveletet tudakozódásnak (“inquiry”) nevezik. A tudakozódást és az összes többi HCI-hez kapcsolódó műveletet a hccontrol(8) segédprogrammal tudjuk elvégezni. A lentebb látható példa azt mutatja meg, hogyan tudunk Bluetooth eszközöket keresni egy adott távolságon belül. Az elérhető eszközök listáját néhány másodpercen alatt megkapjuk. A távoli azonban eszközök csak akkor fognak válaszolni, ha felderíthető (“discoverable”) módban vannak.
% 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]A BD_ADDR a Bluetooth eszköz egyedi címe, hasonló a hálózati kártyák MAC-címéhez. Erre a címre lesz szükség ahhoz, hogy a továbbiakban kommunikálni tudjunk az eszközzel. Emberek számára értelmezhető nevet is hozzá tudunk rendelni a BD_ADDR címhez. Az /etc/bluetooth/hosts állomány tartalmazza a Bluetooth eszközökre vonatkozó információkat. A következő példában azt láthatjuk, hogyan tudunk beszédesebb nevet adni egy távoli eszköznek:
% hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav T39-ese
Amikor tudakozódni kezdünk a távoli Bluetooth eszközök jelenléte felől, a gépünket “sajat.gep.nev (ubt0)” néven fogják látni. Ez a helyi eszközhöz rendelt név bármikor megváltoztatható.
A Bluetooth rendszer lehetőség ad pont-pont (természetesen csak két Bluetooth egység között) vagy pont-multipont típusú kapcsolatok kiépítésére. A pont-multipont kapcsolat esetén a kapcsolaton több Bluetooth eszköz osztozik. A most következő példában megláthatjuk, hogyan kell az aktív működési sávban lekérdezni a helyi eszköz létrejött kapcsolatait:
% 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
A kapcsolat azonosítója (connection handle) akkor hasznos, amikor egy sávbeli kapcsolatot akarunk lezárni. Ezt általában nem kell kézzel megcsinálni. A rendszer magától lezárja az inaktív sávbeli kapcsolatokat.
# hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16]
A hccontrol help paranccsal tudjuk lekérdezni az elérhető HCI parancsokat. A legtöbb HCI parancs végrehajtásához nem kellenek rendszeradminisztrátori jogosultságok.
A Logical Link Control and Adaptation Protocol (L2CAP) a kapcsolat-orientált és a kapcsolat nélküli adatszolgáltatásokért felelős a felsőbb rétegek felé, valamit támogatja a protokollok többszörözését, a darabolást és az összerakást. Az L2CAP a magasabb szintű protokollok és az alkalmazások számára egészen 64 kilobyte méretig lehetővé teszi az adatcsomagok küldését és fogadását.
A L2CAP a csatorna (channel) fogalmára építkezik. A csatorna egy logikai kapcsolatot képvisel a működési sávon belüli kapcsolat felett. Mindegyik csatornához egyetlen protokoll kötődik, egy a többhöz alapon. Több csatorna is tarthozhat ugyanahhoz a protokollhoz, de egy csatornán nem használhatunk több protokollt. A csatornákon keresztül érkező L2CAP csomagok ezután a megfelelő felsőbb rétegbeli protokollokhoz kerülnek. Több csatorna osztozhat ugyanazon a sávbeli kapcsolaton.
Minden Bluetooth eszközhöz létrejön egy l2cap típusú Netgraph-csomópont. Az L2CAP csomópont általában egy Bluetooth HCI csomóponthoz (lefelé) és egy Bluetooth sockethez (felfelé) kapcsolódik. Az L2CAP csomópont alapértelmezett neve “devicel2cap”. Erről részletesebben az ng_l2cap(4) man oldal világosít fel minket.
Ezen a szinten hasznos parancsnak bizonyulhat az l2ping(8), amivel más eszközöket tudunk pingelni. Előfordulhat, hogy egyes Bluetooth implementációk nem válaszolnak semmilyen feléjük küldött adatra, így az alábbi példában is szereplő 0 bytes teljesen normális.
# 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
Az l2control(8) segédprogram használható az L2CAP csomópontok különböző műveleteinek kivitelezésére. Ebben a példában a helyi eszközhöz tartozó logikai kapcsolatokat (csatornák) és sávokat kérdezzük le:
% 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
Másik ugyanilyen diagnosztikai eszköz a btsockstat(1). Ha a viselkedését tekintjük, akkor leginkább a netstat(1) programra hasonlít, de a Bluetooth hálózatban megjelenő adatszerkezetekkel dolgozik. Az alábbi példa az iménti l2control(8) parancs kimenetében szereplő logikai kapcsolatokat mutatja:
% 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
Az RFCOMM protokoll a soros portok emulációját valósítja meg az L2CAP protokollon keresztül. A protokoll az ETSI TS 07.10. RFCOMM szabványán alapszik, és egy egyszerű átviteli protokoll, amelyet a 9 tűs RS-232 (EIATIA-232-E) soros portok emulációjára készítettek fel. Az RFCOMM protokoll legfeljebb 60 kapcsolat (RFCOMM csatorna) párhuzamos használatát támogatja két Bluetooth eszköz között.
Az RFCOMM számára a teljes kommunikációs útvonal két különböző eszközön futó alkalmazást (kommunikációs végpontot) és köztük levő kommunikációs szegments foglalja magában. Az RFCOMM az adott eszközön a soros portot használó alkalmazások részére készült. A kommunikációs szegmens az egyik eszköztől a másikig vezető Bluetooth alapú összeköttetés (közvetlen kapcsolat).
Közvetlen kapcsolat esetén az RFCOMM csak az eszközök közti kapcsolattal foglalkozik, valamint hálózati kapcsolat esetén az eszköz és a modem közti kapcsolattal. Az RFCOMM más konfigurációkat is támogat, például olyan modulokat, amelyek az egyik oldalon a Bluetooth vezeték nélküli technológián keresztül kommunikálnak, míg a másik oldalon egy vonalas felületet nyújtanak.
A FreeBSD-ben az RFCOMM protokollt Bluetooth foglalatok rétegében valósították meg.
Alapértelmezés szerint a Bluetooth kommunikáció nem hitelesítődik és bármelyik eszköz képes bármelyik másikkal felvenni a kapcsolatot. Egy Bluetooth eszköz (például egy mobiltelefon) egy adott szolgáltatáshoz igényelhet hitelesítést (például betárcsázáshoz). A Bluetooth alapú hitelesítés többnyire PIN kódokkal történik. A PIN kód egy legfeljebb 16 karakterből álló ASCII karakterlánc. A felhasználóknak mind a két eszközön ugyanazt a PIN kódot kell megadniuk. Miután megadtuk a PIN kódot, az eszközök létrehoznak hozzájuk egy összekötettésbeli kulcsot (link key). Ezután ezt a kulcsot vagy az eszközökön tároljuk vagy pedig valamilyen tartós tárolón. A következő alkalommal mind a két eszközt ezt a korábban elkészített kulcsot fogja használni. Ezt az eljárást nevezik párosításnak (pairing). Ha valamelyik eszköz elveszti az össszeköttetés kulcsát, akkor a párosítást meg kell ismételni.
A hcsecd(8) démon felelős az összes Bluetooth alapú hitelesítési kérés lekezeléséért. Az alapértelmezett konfigurációs állománya az /etc/bluetooth/hcsecd.conf. Például így tudjuk benne egy mobiltelefonhoz megadni az “1234” PIN kódot:
device {
bdaddr 00:80:37:29:19:a4;
name "Pav T39-ese";
key nokey;
pin "1234";
}Semmilyen korlátozás nincs a PIN
kódokra (a méretüktől eltekintve).
Egyes eszközökbe (például a Bluetooth
fejhallgatók) előre rögzített PIN
kódot építettek bele. A
-d kapcsoló hatására a
hcsecd(8) démont az előtérben lehet
futtatni, így könnyebben láthatjuk mi
történik. A távoli eszközt
állítsuk be a párosítás
elfogadására és kezdeményezzünk
felé egy Bluetooth kapcsolatot. A távoli
eszköznek erre azt kell válaszolnia, hogy elfogadta
a párosítást, majd kérni fogja a PIN
kódot. Adjuk meg ugyanazt a PIN kódot, mint amit
a hcsecd.conf állományba is
beírtunk. Most már a gépünk és
a távoli eszköz párban vannak. A
párosítást a távoli
eszközről is kezdeményezhetjük.
A FreeBSD 5.5, 6.1 és újabb változataiban az /etc/rc.conf állományba a következő sort kell felvenni a hcsecd automatikus indításához:
hcsecd_enable="YES"
Ez pedig a hcsecd démon által generált kimenetre példa:
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
A Service Discovery Protocol (SDP) segítségével a kliens alkalmazások képes felderíteni, hogy a szerver alkalmazások részéről milyen szolgáltatások érhetőek el, valamint ezek a szolgáltatások milyen tulajdonságokkal rendelkeznek. A szolgáltatások tulajdonsági közé soroljuk többek között a felajánlott szolgáltatás típusát vagy osztályát, illetve a szolgáltatás kihasználásához szükséges mechanizmusra vagy protokollra vonatkozó információkat.
Az SDP az SDP szerver és az SDP kliens közti kommunikációt foglalja magában. A szerver karbantart egy listát azokról a szolgáltatási rekordokról, amelyek a szerverhez tartozó szolgáltatások jellemzőit írják le. Mindegyik ilyen szolgáltatási rekord egyetlen szolgáltatás adatait tartalmazza. A kliensek egy SDP kéréssel ezeket a szolgáltatási rekordokat kérhetik el az SDP szervertől. Amennyiben a kliens, vagy a hozzátartozó alkalmazás a szolgáltatás használata mellett dönt, akkor a szolgáltatás használatához a megfelelő szolgáltató felé nyitnia kell egy külön kapcsolatot. Az SDP csak a szolgáltatások és azok tulajdonságainak felderítéséhez ad segítséget, de semmilyen eszközt nem tartalmaz a felhasználásukra.
Általában az SDP kliensek általában valamilyen számunkra kellő tulajdonság alapján keresnek szolgáltatásokat. Ráadásul adódhatnak olyan alkalmak is, amikor a szolgáltatások előzetes ismerete nélkül szeretnénk felderíteni a rendelkezésre álló szolgáltatások típusait. A felajánlott szolgáltatások ilyen típusú feldolgozását nevezzük böngészésnek (browsing).
Az sdpd(8) Bluetooth SDP szerver és a parancssoros sdpcontrol(8) kliens az alap FreeBSD telepítés része. Az alábbi példában egy SDP böngészési kérést adunk ki:
% 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és így tovább. Mindegyik szolgáltatáshoz hozzátartozik a tulajdonságok egy listája (például RFCOMM csatorna). Lehetséges, hogy szolgáltatástól függően bizonyos tulajdonságokat kell figyelnünk. Egyes Bluetooth implementációk nem támogatják a szolgáltatások böngészését és ezért egy üres listát adnak vissza. Ebben az esetben egy konkrét szolgáltatásra tudunk rákeresni. A következő példában az OBEX Object Push (OPUSH) szolgáltatást keressük:
% sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH
FreeBSD alatt az sdpd(8) szerverrel tudunk szolgáltatásokat felajánlani a Bluetooth klienseknek. A FreeBSD 5.5, 6.1 vagy későbbi változataiban ehhez a következő sort kell megadnunk az /etc/rc.conf állományban:
sdpd_enable="YES"
Ezután az sdpd démon így indítható el:
# /etc/rc.d/sdpd start
A távoli kliensek részére Bluetooth szolgáltatásokat felajánlani kívánó helyi szerver alkalmazásoknak regisztrálniuk kell magukat a helyi SDP démonnál. Például az egyik ilyen alkalmazás az rfcomm_pppd(8), és elindítása után regisztrálni fogja a Bluetooth LAN szolgáltatást a helyi SDP démonnál.
A helyi SDP szerveren regisztrált szolgáltatásokat a helyi vezérlési csatornán keresztül egy browse kéréssel tudjuk lekérdezni:
# sdpcontrol -l browse
A betárcsázós hálózati (Dial-Up Networking, DUN) profil leggyakrabban a modemek és mobiltelefonok között tűnik fel. Ez a profil a következő forgatókönyveket dolgozza fel:
A számítógépünkkel egy mobiltelefont vagy modemet vezeték nélküli modemként használunk, amivel az internethez vagy más hálózatokhoz csatlakozunk betárcsázással.
A számítógépünkkel egy mobiltelefonon vagy modemen keresztül fogadunk adathívásokat.
A PPP hálózati hozzáférési (LAN) profil a következő helyezetekben alkalmazható:
LAN hozzáférés egyetlen Bluetooth eszközhöz
LAN hozzáférés több Bluetooth eszközhöz
Két gép összekötése (a soros vonali kapcsolat emulációval PPP-n keresztül)
FreeBSD alatt mind a két profilt a ppp(8) és az rfcomm_pppd(8) valósítja meg -- egy olyan wrapper eszköz, amely az RFCOMM Bluetooth kapcsolatokat a PPP számára is értelmessé alakítja át. Mielőtt még bármelyik profilt elkezdenénk használni, egy új PPP címkét kell létrehozni az /etc/ppp/ppp.conf állományban. Erre példát az rfcomm_pppd(8) man oldalon találhatunk.
A következő példában az rfcomm_pppd(8) programot fogjuk használni arra, hogy egy RFCOMM típusú kapcsolatot nyissunk a 00:80:37:29:19:a4 címmel rendelkező távoli Bluetooth eszköz felé. A tényleges RFCOMM csatorna számát SDP-n keresztül a távoli eszköztől kapjuk. Az RFCOMM csatorna kézzel is megadható, és ilyen esetekben az rfcomm_pppd(8) nem fog SDP kérést küldeni. A sdpcontrol(8) használatával tudjuk lekérdezni a távoli eszközön létrejött RFCOMM csatornát.
# rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup
A PPP hálózati elérés (LAN) szolgáltatás beindításához futni kell a sdpd(8) szervernek. A helyi hálózaton keresztül csatlakozó kliensekhez létre kell hozni egy új bejegyzést az /etc/ppp/ppp.conf állományban. Az rfcomm_pppd(8) man oldalon találhatunk erre példákat. Végezetül indítsuk el az RFCOMM PPP szervert egy érvényes RFCOMM csatornaszámmal. Az RFCOMM PPP szerver ekkor automatikusan regisztrálja a Bluetooth LAN szolgáltatást a helyi SDP démonnál. A következő példában megmutatjuk, hogyan lehet elindítani egy RFCOMM PPP szervert:
# rfcomm_pppd -s -C 7 -l rfcomm-server
Az OBEX egy széles körben alkalmazott protokoll a mobileszközök közti egyszerű állományvitelre. Legfőképpen az infravörös kommunikációban alkalmazzák, ahol a laptopok vagy PDA-k közti általános állományátvitelre használják, illetve névjegykártyák vagy naptárbejegyzések átküldésére mobiltelefonok között és egyéb PIM alkalmazást futtató eszközök esetében.
Az OBEX szervert és klienst egy külső csomag, az obexapp valósítja meg, amelyet az comms/obexapp portból érhetünk el.
Az OBEX kliens használható objektumok áttolására vagy lehúzására az OBEX szerverhez. Ez az objektum lehet például egy névjegykártya vagy egy megbeszélt találkozó. Az OBEX kliens SDP-n keresztül tud magának RFCOMM csatornaszámot szerezni. Ezt úgy tehetjük meg, ha a szolgáltatás neve helyett egy RFCOMM csatorna számát adjuk meg. A támogatott szolgáltatások: IrMC, FTRN és OPUSH. Számként RFCOMM csatorna is megadható. Az alábbi példában egy OBEX munkamenetet láthatunk, ahol az eszköz információs objektumát húzzuk le a mobiltelefonról és egy új objektumot (egy névjegykártyát) tolunk fel a telefon könyvtárába.
% obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get telecom/devinfo.txt devinfo-t39.txt Success, response: OK, Success (0x20) obex> put new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20)
Az OBEX objektumok tologatásának támogatásához az sdpd(8) szervernek kell futnia. Továbbá a beérkező objektumok tárolásához létre kell hoznunk még egy könyvtárat is. Ez az könyvtár alapértelmezés szerint a /var/spool/obex. Végül indítsuk el az OBEX szervert egy érvényes RFCOMM csatorna számának megadásával. Az OBEX szerver ezután automatikusan regisztrálja az “OBEX Object Push” nevű szolgáltatást a helyi SDP démonnál. Ebben a példában láthatjuk az OBEX szerver indítását:
# obexapp -s -C 10
A soros vonali profil (Serial Port Profile, SPP) használatával RS232 (vagy ahhoz hasonló) vonali adatátvitelt tudunk emulálni. Ez a profil a régebben fejlesztett alkalmazásokkal birkózik meg, és a Bluetooth technológiával valódi kábel helyett egy virtuális soros portot képez le.
Az rfcomm_sppd(1) segédprogram ezt a soros vonali profilt valósítja meg. Így egy pszeudo terminált tudunk virtuális soros portként használni. Ha nem adunk meg RFCOMM csatornát, akkor az rfcomm_sppd(1) képes SDP-n keresztül kérni egyet magának a távoli eszköztől. Ha ezt felül kívánjuk bírálni, akkor a parancssorban megadhatunk akár egy konkrét RFCOMM csatornát is.
# rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6...
Miután csatlakoztunk, a pszeudo terminált tudjuk soros portként használni:
# cu -l ttyp6
Egyes Bluetooth eszközök nem támogatják a szerepek cseréjét (role switch). Alapértelmezés szerint amikor a FreeBSD elfogad egy új kapcsolatot, megpróbál rajta szerepet cserélni és mesterré válni. Azok az eszközök, amelyek ezt nem támogatják, nem lesznek képesek emiatt csatlakozni. Ez a szerepváltás az új kapcsolatok felépítése során zajlik le, ezért egy távoli eszköztől nem lehet megtudni, hogy ismeri-e ezt a lehetőséget. A helyi oldalon a következő HCI opcióval lehet kikapcsolni a szerepcserét:
# hccontrol -n ubt0hci write_node_role_switch 0
Persze, igen. Egy külső csomag, a hcidump segítségével, amely a comms/hcidump portból érhető el. A hcidump segédprogram a tcpdump(1) programhoz hasonlítható. Ezzel lehet a Bluetooth csomagok tartalmát megnézni a terminálon vagy elmenteni ezeket egy állományba.
Ha kérdése van a FreeBSD-vel kapcsolatban, a következő
címre írhat (angolul): <freebsd-questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése,
kérjük erre a címre írjon: <gabor@FreeBSD.org>.