32.4 Bluetooth

Written by Pav Lucistnik.

32.4.1 Εισαγωγή

Το Bluetooth είναι μια ασύρματη τεχνολογία για τη δημιουργία προσωπικών δικτύων που λειτουργούν στην 2,4 GHz χωρίς άδεια ζώνη, με μία εκπομπή 10 μέτρων. Τα δίκτυα συνήθως σχηματίζονται ως ad-hocad-hoc από φορητές συσκευές όπως κινητά τηλέφωνα, handhelds και φορητούς υπολογιστές. Σε αντίθεση με τις άλλες δημοφιλείς ασύρματες τεχνολογίες όπως το Wi-Fi, το Bluetooth προσφέρει υψηλότερο επίπεδο υπηρεσιών π.χ. τύπου FTP διακομιστές αρχείων, προώθηση αρχείων, μεταφορά φωνής προσωμοίωση σειριακής γραμμής και άλλα.

Το Bluetooth στο FreeBSD έχει υλοποιηθεί με τη χρήση του Netgraph πλαισίου (δείτε netgraph(4)). Μια ευρεία ποικιλία Bluetooth USB υποδοχών υποστηρίζεται από τον ng_ubt(4) οδηγό. Οι συσκευές Bluetooth βασίζονται στο τσίπ Broadcom BCM2033 και υποστηρίζονται μέσω του ubtbcmfw(4) και ng_ubt(4) οδηγών. Η 3Com Bluetooth PC Card 3CRWB60-A υποστηρίζεται από τον ng_bt3c(4) οδηγό. Οι σειριακές και UART συσκευές βασισμένες στο Bluetooth υποστηρίζονται μέσω του sio(4), ng_h4(4) και hcseriald(8). Αυτή η ενότητα περιγράφει τη χρήση των Bluetooth USB υποδοχών.

32.4.2 Σύνδεση στο μηχάνημα

Εξ ορισμού οι Bluetooth οδηγοί συσκευών είναι διαθέσιμοι ως οδηγοί του πυρήνα. Πριν τοποθετήσετε μια συσκευή, θα χρειαστεί να φορτώσετε τον οδηγό στον πυρήνα:

# kldload ng_ubt

Εάν η συσκευή Bluetooth εμφανίζεται στο σύστημα κατά την διάρκεια της εκκίνησης, φορτώστε τον οδηγό απο το αρχείο /boot/loader.conf:

ng_ubt_load="YES"

Σύνδεση στην USB υποδοχή. Η έξοδος των αποτελεσμάτων που θα μοιάζει με το παρακάτω θα εμφανίζεται στην κονσόλα (ή στο syslog αρχείο):

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

Το /etc/rc.d/bluetooth αρχείο χρησιμοποιείται για την εκκίνηση και τον τερματισμό του Bluetooth. Είναι μία καλή ιδέα για να σταματήσει το Bluetooth πριν αποσυνδέσετε τη συσκευή, αλλά δεν είναι (Συνήθως) καταστροφική. Κατά την έναρξη του Bluetooth, θα λάβετε μια έξοδο των αποτελεσμάτων που θα μοιάζει με το παρακάτω:

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

32.4.3 Host Controller Διεπαφή (HCI)

Η Host Controller Διεπαφή (HCI) παρέχει ένα περιβάλλον εργασίας στον βασικό ελεγχτή και διαχειριστή σύνδεσης, και την πρόσβαση στην κατάσταση του υλικού μέρους και στα μητρώα ελέγχου. Αυτή η διεπαφή παρέχει μια ενιαία μέθοδο πρόσβασης, τις βασικές δυνατότητες του Bluetooth. Το HCI επίπεδο σχετικά με τις ανταλλαγές υποδοχής δεδομένων και τις εντολές με το firmware HCI σχετικά στο υλικό μέρος του Bluetooth. Ο οδηγός του επιπέδου του κεντρικού ελεγχτή μεταφορών (Δηλ. φυσικό κανάλι) προβλέπει δύο στρώματα HCI με την ικανότητα να ανταλλάσσουν πληροφορίες μεταξύ τους.

Ένας Netgraph κόμβος του τύπου hci δημιουργήθηκε για μία μόνο συσκευή Bluetooth. Ο κόμβος HCI είναι κανονικά συνδεδεμένος στη συσκευή - κόμβο του οδηγόυ Bluetooth (downstream) και τον L2CAP κόμβο (upstream). Όλες οι HCI εργασίες πρέπει να εκτελούνται στον κόμβο HCI και όχι στον κόμβο οδήγησης συσκευής. Το προεπιλεγμένο όνομα του κόμβο HCI είναι «devicehci». Για περισσότερες λεπτομέρειες, ανατρέξτε στο ng_hci(4) εγχειρίδιο.

Μία από τις πιο συνήθεις εργασίες είναι η ανακάλυψη των συσκευών Bluetooth στην RF proximity. Αυτή η πράξη καλείται έρευνα. Η Έρευνα και άλλες συναφείς δραστηριότητες HCI γίνονται με το hccontrol(8) εργαλείο. Το παρακάτω παράδειγμα δείχνει τον τρόπο για να μάθετε ποιές συσκευές Bluetooth βρίσκονται εντός εμβέλειας. Θα πρέπει να λάβετε τον κατάλογο των συσκευών μέσα σε λίγα δευτερόλεπτα. Σημειώστε ότι μια απομακρυσμένη συσκευή θα απαντήσει μόνο στην ερώτηση, αν το θέσουμε σε ανακαλύψιμο τύπο.

% 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 είναι η μοναδική διεύθυνση μιάς Bluetooth συσκευής, παρόμοια με τις διευθύνσεις MAC μίας κάρτας δικτύου. Αυτή η διεύθυνση είναι απαραίτητη για την περαιτέρω επικοινωνία με μια συσκευή. Είναι δυνατό να αναθέσουμε ανθρώμινο όνομα στο BD_ADDR. Το /etc/bluetooth/hosts αρχείο περιέχει πληροφορίες σχετικά με τους γνωστούς Bluetooth "οικοδεσπότες". Το ακόλουθο παράδειγμα δείχνει τον τρόπο που θα αποκτήσει ανθρώπινο αναγνώσιμο όνομα που ανατέθηκε στην απομακρυσμένη συσκευή:

% hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4
BD_ADDR: 00:80:37:29:19:a4
Name: Pav's T39

Εάν εκτελέσετε μια έρευνα για μια απομακρυσμένη συσκευή Bluetooth, θα το βρείτε τον υπολογιστή σας ως «your.host.name (ubt0)». Το όνομα που ανατίθεται στην τοπική συσκευή μπορεί να αλλάξει ανά πάσα στιγμή

Το σύστημα Bluetooth παρέχει μία point-to-point σύνδεση (μόνο δύο Bluetooth μονάδες συμμετέχουν), ή μια σύνδεση point-to-multipoint. Στην point-to-multipoint σύνδεση, η σύνδεση μοιράζεται μεταξύ διαφόρων συσκευών Bluetooth. Το ακόλουθο παράδειγμα δείχνει πώς να βρείτε τη λίστα των ενεργών συνδέσεων για την τοπική συσκευή:

% 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

Μια σύνδεση που χειρίζεται είναι χρήσιμη όταν ο τερματισμός της βάσης της σύνδεσης απαιτείται. Σημειώστε, ότι κανονικά δεν είναι υποχρεωτικό να γίνει χειροκίνητα. The stack θα διακόψει αυτόματα ανενεργές συνδέσεις βάσης.

# hccontrol -n ubt0hci disconnect 41
Connection handle: 41
Reason: Connection terminated by local host [0x16]

Ανατρέξτε στην hccontrol βοήθεια για μια πλήρη λίστα με τις διαθέσιμες εντολές HCI. Οι περισσότερες από τις εντολές HCI δεν απαιτούν προνόμια υπερχρήστη.

32.4.4 Ελέγχος Λογικού Συνδέσμου και το Πρωτοκόλλου Προσαρμογής (L2CAP)

Ο Ελέγχος Λογικού Συνδέσμου και το Πρωτοκόλλου Προσαρμογής (L2CAP) προβλέπει προσανατολισμένη σύνδεση και υπηρεσίες δεδομένων συνδεσιμότητας σε πρωτόκολλα ανώτερου επιπέδου με πρωτόκολλο ικανότητας πολυπλεξίας και του κατακερματισμού και την επανασυναρμολόγηση της λειτουργίας. Το L2CAP επιτρέπει πρωτόκολλα υψηλότερου επιπέδου και εφαρμογές για τη μετάδοση και τη λήψη L2CAP πακέτων δεδομένων έως και 64 kilobytes σε μήκος.

Το L2CAP είναι βασισμένο γύρω από την έννοια των καναλιών. Το Κανάλι είναι μια λογική σύνδεση στην κορυφή της βάσης σύνδεσης. Κάθε κανάλι είναι δεσμευμένο σε ένα μοναδικό και κοινό πρωτόκολλο σε μία many-to-one σύνδεση. Πολλαπλά κανάλια μπορούν να συνδεθούν με το ίδιο πρωτόκολλο, αλλά ένα κανάλι δεν μπορεί να δεσμευτεί με πολλαπλά πρωτόκολλα. Κάθε πακέτο L2CAP που λαμβάνεται σε ένα κανάλι απευθύνεται στο αντίστοιχο πρωτόκολλο υψηλού επιπέδου. Πολλαπλά κανάλια μπορούν να μοιράζονται την ίδια σύνδεση βάσης.

Ένας ενιαίος κόμβος του τύπου Netgraph l2cap δημιουργήθηκε για μία μόνο συσκευή Bluetooth. Ο κόμβος L2CAP κανονικά συνδέεται με τον κόμβο Bluetooth HCI (downstream) και τις Bluetooth υποδοχές κόμβων (upstream). Προεπιλεγμένο όνομα για τον κόμβο L2CAP είναι «devicel2cap». Για περισσότερες λεπτομέρειες, ανατρέξτε στο ng_l2cap(4) εγχειρίδιο.

Μια χρήσιμη εντολή είναι l2ping(8), η οποία μπορεί να χρησιμοποιηθεί για ping άλλων συσκευών. Κάποιες εφαρμογές Bluetooth, δεν θα μπορούσαν να επιστρέψουν το σύνολο των δεδομένων που τους στάλθηκε, άρα 0 bytes στο ακόλουθο παράδειγμα είναι φυσιολογικό.

# 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

Το l2control(8) εργαλείο χρησιμοποιείται για να εκτελέσετε διάφορες ενέργειες στους L2CAP κόμβους. Το παράδειγμα αυτό δείχνει τον τρόπο απόκτησης του καταλόγου των λογικών συνδέσεων (κανάλια) και ο κατάλογος των βάσεων συνδέσεων για την τοπική συσκευή:

% 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). Κάνει μια δουλειά παρόμοια με αυτό netstat(1) κάνει, αλλά για τις δομές δεδομένων που σχετίζονται με το δίκτυο Bluetooth. Το παράδειγμα που ακολουθεί δείχνει την ίδια λογική σύνδεση l2control(8)παραπάνω.

% 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

32.4.5 RFCOMM Πρωτόκολλο

Το πρωτόκολλο RFCOMM παρέχει εξωμίωση των σειριακών θυρών πάνω απο το L2CAP πρωτόκολλο. Το πρωτόκολλο βασίζεται στο πρότυπο ETSI TS 07,10. Το RFCOMM είναι ένα απλό πρωτόκολλο μεταφοράς, με πρόσθετες διατάξεις για την προσωμοιώση των 9 κυκλωμώτων των RS-232 (EIATIA-232-E) σειριακών θυρών. Το RFCOMM πρωτόκολλο υποστηρίζει μέχρι 60 ταυτόχρονες συνδέσεις (RFCOMM κανάλια) μεταξύ δύο συσκευών Bluetooth.

Για τους σκοπούς του RFCOMM, ένα πλήρες μονοπάτι επικοινωνίας περιλαμβάνει δύο εφαρμογές που τρέχουν σε διαφορετικές συσκευές (Τα σημεία τέλους της επικοινωνίας) με ένα τμήμα της μεταξύ τους επικοινωνίας. Το RFCOMM προορίζεται για να καλύψει εφαρμογές που κάνουν χρήση των σειριακών θυρών των συσκευών τους. Το τμήμα επικοινωνίας είναι ένας Bluetooth σύνδεσμος από μια συσκευή στην άλλη (απευθείας σύνδεση).

Το RFCOMM ασχολείται μόνον με τη σύνδεση μεταξύ των συσκευών σε άμεση σύνδεση, ή μεταξύ της συσκευής και ενός μόντεμ στην περίπτωση του δικτύου. Το RFCOMM μπορεί να υποστηρίξει άλλες ρυθμίσεις, όπως είναι ενότητες που επικοινωνούν μέσω ασύρματης τεχνολογίας Bluetooth από τη μία πλευρά και παρέχουν ενσύρματη διεπαφή από την άλλη πλευρά.

Το FreeBSD RFCOMM πρωτόκολλο εφαρμόζεται στο στρώμα υποδοχών του Bluetooth.

32.4.6 Αντιστοίχιση των συσκευών

Από προεπιλογή, η επικοινωνία μέσω Bluetooth δεν είναι επικυρωμένη, καθώς και κάθε συσκευή μπορεί να μιλήσει με οποιαδήποτε άλλη συσκευή. Μια συσκευή Bluetooth (για παράδειγμα, κινητού τηλεφώνου) μπορούν να επιλέξει να απαιτεί έλεγχο ταυτότητας για να παρέχει μία συγκεκριμένη υπηρεσία (π.χ. υπηρεσία Dial-Up). Η Bluetooth επικύρωση γίνεται κανονικά με το PIN PIN κωδικοί. Ο κωδικός PIN είναι μια συμβολοσειρά ASCII έως 16 χαρακτήρες στο μήκος. Ο χρήστης απαιτείται να εισάγει τον ίδιο κωδικό PIN και στις δύο συσκευές. Μόλις ο χρήστης έχει εισάγει τον κωδικό PIN, και οι δύο συσκευές θα δημιουργήσουν έναν σύνδεσμο κλειδί. Μετά αυτό το κλειδί - σύνδεσμος μπορεί να αποθηκευτεί είτε στις ίδιες τις συσκευές είτε σε έναν σκληρο δίσκο. Την επόμενη φορά και οι δύο συσκευές θα χρησιμοποιήσουν το προηγουμένως λειτουργικό κλειδί - σύνδεσμος. Η περιγραφόμενη παραπάνω διαδικασία ονομάζεται αντιστοίχιση. Σημειώστε ότι, εάν ο σύνδεσμος - κλειδί χαθεί από οποιαδήποτε συσκευή τότε η αντιστοίχιση πρέπει να επαναληφθεί.

Ο hcsecd(8) δαίμονας είναι υπεύθυνος για το χειρισμό όλων των αιτήσεων ελέγχου ταυτότητας Bluetooth. Η προεπιλεγμένη ρύθμιση του αρχείου είναι /etc/bluetooth/hcsecd.conf. Ένα παράδειγμα είναι όταν ένα κινητό τηλέφωνο με τον κωδικό PIN αυθαιρέτως ορίζεται στο «1234» παρουσιάζεται παρακάτω:

device {
        bdaddr  00:80:37:29:19:a4;
        name    "Pav's T39";
        key     nokey;
        pin     "1234";
      }

Δεν υπάρχει κανένας περιορισμός σχετικά με τους κωδικούς PIN (εκτός από το μήκος). Ορισμένες συσκευές (Π.χ. ακουστικά Bluetooth) μπορεί να έχουν ένα σταθερό κωδικό PIN απο εργοστασιακή προεπιλογή. Η -d αλλάζει δυναμικά τον hcsecd(8) δαίμονα να μείνει στο προσκήνιο, οπότε είναι εύκολο να δείτε τι συμβαίνει. Ρυθμίστε την απομακρυσμένη συσκευή για να λάβετε την αντιστοίχιση και την έναρξη της σύνδεσης Bluetooth με την απομακρυσμένη συσκευή. Η απομακρυσμένη συσκευή θα πρέπει να λέει ότι η αντιστοίχιση ήταν αποδεκτή, και να ζητήσει τον κωδικό PIN. Πληκτρολογήστε τον ίδιο κωδικό PIN που έχετε στο hcsecd.conf. Τώρα το PC σας και η απομακρυσμένη συσκευή είναι συνδεδεμένα. Εναλλακτικά, μπορείτε να ξεκινήσετε την αντιστοίχιση στην απομακρυσμένη συσκευή.

On FreeBSD 5.5, 6.1 and newer, η ακόλουθη γραμμή μπορεί να προστεθεί στο /etc/rc.conf αρχείο για να hcsecd ξεκινάει αυτόματα όταν το σύστημα ξεκινάει:

hcsecd_enable="YES"

Το παρακάτω είναι ένα δείγμα του hcsecd αποτελέσματος του δαίμονα:

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

32.4.7 Το πρωτόκολο ανέυρεσης υπηρεσίας (SDP)

Το πρωτόκολο ανέυρεσης υπηρεσίας (SDP) παρέχει τα μέσα για τις εφαρμογές - πελάτη για να ανακαλύψουν την ύπαρξη των υπηρεσιών που παρέχονται από τις εφαρμογές - διακομιστή, καθώς και τις ιδιότητες των εν λόγω υπηρεσιών. Οι ιδιότητες μιας υπηρεσίας περιλαμβάνουν τον τύπο ή την κατηγορία των προσφερόμενων υπηρεσιών και τον μηχανισμού ή το πρωτόκολλο πληροφοριών που απαιτούνται για να χρησιμοποιήσουν την υπηρεσία.

Ο SDP περιλαμβάνει την επικοινωνία μεταξύ ενός διακομιστή SDP και ένας πελάτης SDP. Ο διακομιστής διατηρεί μια λίστα των εγγραφών των υπηρεσιών που περιγράφουν τα χαρακτηριστικά των υπηρεσιών που συνδέονται με το διακομιστή. Κάθε υπηρεσία εγγραφής περιέχει πληροφορίες σχετικά με μια υπηρεσία. Ένας πελάτης μπορεί να ανακτήσει πληροφορίες από τα επίπεδα εγγραφής των υπηρεσιών που διατηρείται από το διακομιστή SDP από την υποβολή μιας SDP αίτησης. Αν ο πελάτης, ή μία εφαρμογή συσχετισμένη με τον πελάτη, αποφασίζει να χρησιμοποιήσει μια υπηρεσία, θα πρέπει να ανοίξει μία ξεχωριστή σύνδεση με τον πάροχο υπηρεσιών, προκειμένου να χρησιμοποιήσουν την υπηρεσία. Ο SDP παρέχει ένα μηχανισμό για να ανακαλύψει τις υπηρεσίες και τις ιδιότητές τους, αλλά δεν προβλέπει μηχανισμό για τη χρήση των υπηρεσιών αυτών.

Κανονικά, ένας SDP πελάτης ψάχνει για τις υπηρεσίες που βασίζονται σε κάποια επιθυμητά χαρακτηριστικά των υπηρεσιών. Ωστόσο, υπάρχουν φορές που είναι σκόπιμη η ανακάλυψη τον τύπων των υπηρεσιών που περιγράφονται από τις SDP εγγραφές των υπηρεσιών του διακομιστή χωρίς καμία προτερεότητα πληροφοριών σχετικά με τις υπηρεσίες. Αυτή η διαδικασία εξέτασης για τις προσφερόμενες υπηρεσίες καλείται περιήγηση.

Ο Bluetooth SDP διακομιστής sdpd(8) και η γραμμή εντολών - πελάτης sdpcontrol(8) περιλαμβάνονται στην πρότυπη FreeBSD εγκατάσταση. Το ακόλουθο παράδειγμα δείχνει πώς να εκτελέσετε ένα SDP ερώτημα αναζήτησης.

% 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

... και ούτω καθεξής. Σημειώστε ότι κάθε υπηρεσία έχει μια λίστα χαρακτηριστικών (RFCOMM κανάλι για παράδειγμα). Ανάλογα με την υπηρεσία μπορεί να χρειαστεί να σημειώστε μερικές από τις ιδιότητες. Κάποιες εφαρμογές Bluetooth δεν υποστηρίζουν υπηρεσίες προγράμματος περιήγησης και μπορεί να επιστρέψουν έναν άδειο κατάλογο. Στην περίπτωση αυτή είναι δυνατή η αναζήτηση για τη συγκεκριμένη υπηρεσία. Το παρακάτω παράδειγμα δείχνει πώς να ψάξετε για την OBEX Object Push (OPUSH) υπηρεσία:

% sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH

Που προσφέρουν υπηρεσίες στο FreeBSD το Bluetooth πελατών γίνεται με τον sdpd(8) διακομιστή. . Στις FreeBSD 5.5, 6.1 και νεότερες εσκδόσεις,η ακόλουθη γραμμή μπορεί να να προστεθεί στο /etc/rc.conf αρχείο:

sdpd_enable="YES"

Τότε ο sdpd δαίμονας μπορεί να ξεκινήσει με:

# /etc/rc.d/sdpd start

Η τοπική εφαρμογή διακομιστή που θέλει να παρέχει την Bluetooth υπηρεσία προς τους απομακρυσμένους πελάτες θα καταχωρήσει την υπηρεσία με τον τοπικό SDP δαίμονα. Το παράδειγμα η εν λόγω εφαρμογή είναι rfcomm_pppd(8). Μόλις αρχίσει, θα εγγράψει την Bluetooth LAN υπηρεσία με τον SDP δαίμονα.

Ο κατάλογος των υπηρεσιών που καταχωρήθηκε με τον τοπικό SDP διακομιστή μπορεί να ληφθεί από την έκδοση SDP αναζήτησης ερωτημάτων μέσω των τοπικών καναλιών ελέγχου:

# sdpcontrol -l browse

32.4.8 H Dial-Up δυκτίωση (DUN) και πρόσβαση στο δίκτυο με PPP (LAN) προφίλ

Το προφίλ της Dial-Up δυκτίωσης (DUN) χρησιμοποιείται κυρίως με modem και κινητά τηλέφωνα. Τα σενάρια που καλύπτονται από αυτό το προφίλ είναι τα παρακάτω:

Πρόσβαση δυκτίου με PPP (LAN) προφίλ μπορεί να χρησιμοποιηθεί στις ακόλουθες καταστάσεις:

Στο FreeBSD και τα δύο προφίλ υλοποιούνται με το ppp(8) και rfcomm_pppd(8) - ένα κάλλυμα που μετατρέπει η RFCOMM Bluetooth σύνδεση σε PPP με το οποίο μπορεί να λειτουργήσει. Πριν από κάθε προφίλ μπορεί να χρησιμοποιηθεί, μια νέα PPP ετικέτα του/etc/ppp/ppp.conf που θα δημιουργηθεί. Συμβουλευτείτε rfcomm_pppd(8) εγχειρίδιο για παραδείγματα.

Στο παρακάτω παράδειγμα rfcomm_pppd(8) Θα χρησιμοποιηθεί για να ανοίξει την RFCOMM σύνδεση σε απομακρυσμένες συσκευές με BD_ADDR 00:80:37:29:19:a4 στο DUN RFCOMM κανάλι. Θα λαμβάνεται ο πραγματικός αριθμός καναλιού RFCOMM Είναι δυνατόν να δηλώσουμε το RFCOMM κανάλι χειροκίνητα και στη συγκεκριμένη περίπτωση rfcomm_pppd(8) δεν θα εκτελέσει το SDP ερώτημα. Χρησιμοποιείστε sdpcontrol(8) για να μάθετε το RFCOMM κανάλι για την απομακρυσμένη συσκευή.

# rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup

Προκειμένου να παρέχει πρόσβαση δυκτίου με την PPP (LAN) υπηρεσία ο sdpd(8) διακομιστής πρέπει να τρέχει. Μια νέα καταχώρηση για το LAN - πελάτες πρέπει να δημιουργηθεί στο /etc/ppp/ppp.conf αρχείο. Συμβουλευτείτε rfcomm_pppd(8) το εγχειρίδιο για παραδείγματα. Τέλος, ξεκινήστε τον RFCOMM PPP διακομιστή σε ενα έγκυρο RFCOMM αριθμό καναλιού. Ο RFCOMM PPP διακομιστής θα εγγραψει αυτόματα στο μητρώο της Bluetooth LAN υπηρεσίας με τον τοπικό SDP δαίμονα. Το παράδειγμα που ακολουθεί δείχνει πώς να ξεκινήσετε έναν RFCOMM PPP διακομιστή.

# rfcomm_pppd -s -C 7 -l rfcomm-server

32.4.9 OBEX Object Push (OPUSH) Προφίλ

Το OBEX είναι ένα ευρέως χρησιμοποιούμενο πρωτόκολλο για απλές μεταφορές αρχείων μεταξύ κινητών συσκευών. Η κύρια χρήση του είναι η επικοινωνία με υπέρυθρες, που χρησιμοποιούνται για γενικές μεταφορές αρχείων μεταξύ φορητών υπολογιστών ή PDA και για την αποστολή επαγγελματικών καρτών ή καταχωρήσεις ημερολογίου μεταξύ κινητών τηλεφώνων και άλλων συσκευών με PIM εφαρμογές.

Ο διακομιστής OBEX και πελάτη εφαρμόζονται υπό τη μορφή ενός τρίτου πακέτου obexapp, το οποίο είναι διαθέσιμο ως comms/obexapp Θύρα.

Ο OBEX πελάτης χρισημοποιείται για την ώθηση και / ή να τραβήξει αντικείμενα από τον διακομιστή OBEX. Ένα αντικείμενο μπορεί, για παράδειγμα, είναι μια επαγγελματική κάρτα ή ένα ραντεβού. Ο πελάτης μπορεί να αποκτήσει τον OBEX RFCOMM αριθμό καναλιού από την απομακρυσμένη συσκευή μέσω του SDP. Αυτό μπορεί να επιτευχθεί με τον καθορισμό ονόματος της υπηρεσίας αντί τον RFCOMM αριθμό καναλιού. Υποστηριζόμενα ονόματα υπηρεσιών είναι τα εξής: IrMC, FTRN και OPUSH Είναι δυνατόν να προσδιορίσουμε ένα RFCOMM κανάλι ως αριθμό. Παρακάτω είναι ένα παράδειγμα μιας συνόδου OBEX. Το αντικείμενο των πληροφοριών της συσκευής τραβιέται από το κινητό τηλέφωνο καθώς και ένα νέο αντικείμενο (επαγγελματική κάρτα) ωθείται στον κατάλογο του τηλεφώνου.

% 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)

Προκειμένου να παροχηθεί OBEX υπηρεσία ώθησης αντικειμένου, sdpd(8) ο διακομιστής πρέπει να τρέχει. Πρέπει να δημιουργηθεί ένας κατάλογος ρίζα, όπου όλα τα εισερχόμενα αντικείμενα θα αποθηκέυονται. Το προεπιλεγμένο μονοπάτι για τον φάκελο ρίζας είναι /var/spool/obex. Στο τέλος ξεκινάει ο OBEX διακομιστής σε έναΩ διαθέσιμο αριθμό RFCOMM καναλιού. Ο OBEX διακομιστής θα κατωχειρώσει αυτόματα την OBEX υπηρεσία ώθησης αντικειμένου με τον τοπικό SDP δαίμονα. Το παράδειγμα που ακολουθεί δείχνει πώς να ξεκινήσετε τον OBEX διακομιστή.

# obexapp -s -C 10

32.4.10 Προφίλ σειριακής θύρας (SPP)

Το Προφίλ σειριακής θύρας (SPP) αφήνει τις συσκευές Bluetooth να πραγματοποιήσουν την RS232 (ή παρόμοιο) εξομοίωση σειριακού καλωδίου. Το σενάριο που καλύπτεται από το προφίλ, διαπραγματέυεται με πατρογονικές εφαρμογές χρησιμοποιώντας το Bluetooth ως αντικαταστάτη του καλωδίου, μέσω μίας εικονικής σειριακής θύρας.

Το rfcomm_sppd(1) εργαλείο υλοποιεί το προφίλ της Σειριακής Θύρας. Μια ψευδο tty χρησιμοποιείται ως μια εικονική σειριακή θύρα αφαίρεσης. Το παράδειγμα που ακολουθεί, δείχνει πώς να συνδεθείτε σε μια υπηρεία απομακρυσμένης συσκευής Σειριακής Θύρας. Σημειώστε ότι δεν χρειάζεται να καθορίσετε ένα RFCOMM κανάλι rfcomm_sppd(1) μπορούν να την αποκτήσουν από την απομακρυσμένη συσκευή μέσω του SDP. Αν θέλετε να το παρακάμψετε αυτό, καθορίστε ένα RFCOMM κανάλι στην γραμμή εντολών.

# rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6
rfcomm_sppd[94692]: Starting on /dev/ttyp6...

Μόλις συνδεθεί, το ψευδό tty μπορεί να χρησιμοποιηθεί ως σειριακή θύρα:

# cu -l ttyp6

32.4.11 Αντιμετώπιση προβλημάτων

32.4.11.1 Η απομακρυσμένη συσκευή δεν μπορεί να συνδεθεί

Ορισμένες παλαιότερες συσκευές Bluetooth δεν υποστηρίζουν αλλαγή ρόλου. Από προεπιλογή, όταν FreeBSD δέχεται μια νέα σύνδεση, προσπαθεί να εκτελέσει ένα ρόλο διακόπτη και να γίνει κάτοχος. Συσκευές, οι οποίες δεν το υποστηρίζουν αυτό δεν θα είναι σε θέση να συνδεθούν. Σημειώστε ότι η αλλαγή του ρόλου πραγματοποιείται με την καθιέρωσή μιας νέας σύνδεση, έτσι δεν είναι δυνατόν να ζητήσει από την απομακρυσμένη συσκευή, αν υποστηρίζει αλλαγή ρόλου. Υπάρχει μια επιλογή HCI για να απενεργοποιήσετε τον ρόλο ενεργοποίησης στην τοπική πλευρά:

# hccontrol -n ubt0hci write_node_role_switch 0

32.4.11.2 Κάτι πάει στραβά. Μπορώ να δω τι ακριβώς συμβαίνει;

Ναι, μπορείτε. Χρησιμοποιήστε το τρίτο πακέτο hcidump, το οποίο είναι διαθέσιμο ως comms/hcidump θύρα. Το hcidump εργαλείο είναι παρόμοιο με tcpdump(1).Μπορεί να χρησιμοποιηθεί για την απεικόνιση του περιεχομένου των Bluetooth πακέτων στο τερματικό και να απορρίψει τα πακέτα Bluetooth σε ένα αρχείο.

Αυτό το κείμενο, και άλλα κείμενα, μπορεί να βρεθεί στο ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

Για ερωτήσεις σχετικά με το FreeBSD, διαβάστε την τεκμηρίωση πριν να επικοινωνήσετε με την <questions@FreeBSD.org>.
Για ερωτήσεις σχετικά με αυτή την τεκμηρίωση, στείλτε e-mail στην <doc@FreeBSD.org>.