31.4. Bluetooth

Írta: Lucistnik, Pav.

31.4.1. Bevezetés

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.

31.4.2. Az eszköz csatlakoztatása

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

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

31.4.3. Host Controller Interface (HCI)

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.

31.4.4. Logical Link Control and Adaptation Protocol (L2CAP)

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

31.4.5. Az RFCOMM protokoll

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.

31.4.6. Az eszközök párosítása

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

31.4.7. Service Discovery Protocol (SDP)

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

31.4.8. A betárcsázós hálózati és a PPP hálózati hozzáférési (LAN) profilok

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

31.4.9. Az OBEX Object Push (OPUSH) profil

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

31.4.10. Soros vonali profil (SPP)

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

31.4.11. Hibaelhárítás

31.4.11.1. Nem tudunk csatlakozni a távoli eszközzel

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

31.4.11.2. Valami nem megy. Lehet látni valahogy, pontosan mi is történik?

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): <questions@FreeBSD.org>.

Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon: <gabor@FreeBSD.org>.