Bluetooth® est une technologie sans fil pour créer des réseaux personnels sans fils fonctionnant dans la bande 2.4 GHz ne nécessitant pas d'autorisation, avec une portée de 10 mètres. Les réseaux étant généralement composés de périphériques nomades comme les téléphones portables, les assistants personnels et les ordinateurs portables. Contrairement à l'autre technologie sans fil, Wi-Fi, Bluetooth offre un niveau plus élevé de profils de service, par exemple des serveurs de fichiers semblables à FTP, “file pushing”, transport de la voix, émulation de lignes séries, et bien plus.
La pile Bluetooth sous FreeBSD utilise le système Netgraph (voir netgraph(4)). Une large gamme d'adaptateurs USB Bluetooth sont supportés par le pilote ng_ubt(4). Les périphériques Bluetooth basés sur le circuit Broadcom BCM2033 sont supportés par les pilotes ubtbcmfw(4) et ng_ubt(4). La carte 3Com Bluetooth PC Card 3CRWB60-A demande le pilote ng_bt3c(4). Les périphériques Bluetooth de type série et UART sont supportés via les pilotes sio(4), ng_h4(4) et hcseriald(8). Cette section décrit l'utilisation d'un adaptateur USB Bluetooth. Le support Bluetooth est disponible sur les systèmes 5.0 et suivants.
Par défaut les pilotes de périphériques Bluetooth sont disponibles sous la forme de modules du noyau. Avant de brancher le périphérique, vous devrez charger le pilote dans le noyau:
# kldload ng_ubt
Si le périphérique Bluetooth est présent au démarrage du système, chargez le module à partir de /boot/loader.conf:
ng_ubt_load="YES"
Branchez votre clé USB. Une sortie semblable à celle-ci devrait s'afficher sur la console (ou dans les journaux du système):
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
Note : La pile Bluetooth doit être lancée manuellement sous FreeBSD 6.0, et sous les versions 5.0 antérieures à la 5.5. Ce lancement est automatique à partir de devd(8) sous FreeBSD 5.5, 6.1 et versions suivantes.
Copiez /usr/share/examples/netgraph/bluetooth/rc.bluetooth à un emplacement adapté, comme /etc/rc.bluetooth. Cette procédure est utilisée pour démarrer et arrêter la pile Bluetooth. C'est une bonne idée d'arrêter la pile avant de débrancher le périphérique, mais ce n'est pas (généralement) fatal. Quand la pile démarre, vous devriez avoir des messages similaires aux suivants:
# /etc/rc.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
L'interface de contrôle de l'hôte (HCI) fournit une interface de commande pour le contrôleur de la bande de base et le gestionnaire de liaisons, et l'accès à l'état du matériel et aux registres de contrôle. Cette interface offre une méthode uniforme d'accès aux fonctions de la bande de base Bluetooth. La couche HCI de l'hôte échange des données et des commandes avec le firmware HCI du matériel Bluetooth. Le pilote de la couche de transport du contrôleur d'hôte (i.e. le bus physique) fournit aux deux couches HCI la possibilité d'échanger des informations entre elles.
Un seul noeud Netgraph de type hci est créé pour un périphérique Bluetooth. Le noeud HCI est normalement connecté au noeud du pilote Bluetooth (flux descendant) et au noeud L2CAP (flux montant). Toutes les opérations HCI doivent être effectuées sur le noeud HCI et non pas sur le noeud du pilote de périphérique. Le nom par défaut pour le noeud HCI est “devicehci”. Pour plus de détails consultez la page de manuel ng_hci(4).
Une des tâches les plus courantes est la recherche de périphériques Bluetooth dans le voisinage hertzien. Cette opération est appelée inquiry (enquête, recherche). Cette recherche et les autres opérations relatives à HCI sont effectuées par l'utilitaire hccontrol(8). L'exemple ci-dessous montre comment déterminer quels périphériques Bluetooth sont dans le voisinage. Vous devriez obtenir une listes de périphériques au bout de quelques secondes. Notez qu'un périphérique distant ne répondra à la recherche que s'il est placé dans le mode discoverable.
% 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 est l'adresse unique d'un périphérique Bluetooth, similaire à l'adresse MAC d'une carte réseau. Cette adresse est nécessaire pour communiquer avec un périphérique. Il est possible d'assigner un nom humainement compréhensible à l'adresse BD_ADDR. Le fichier /etc/bluetooth/hosts contient des informations concernant les hôtes Bluetooth connus. L'exemple suivant montre comment obtenir le nom qui a été assigné au périphérique distant:
% hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav's T39
Si vous effectuez une recherche sur un périphérique Bluetooth distant, vous devriez trouver votre ordinateur en tant que “votre.machine.nom (ubt0)”. Le nom affecté au périphérique local peut être modifié à tout moment.
Le système Bluetooth fournit une connexion point à point (seules deux matériels Bluetooth sont concernés), ou une connexion point à multipoints. Dans le cas d'une connexion point à multipoints, la connexion est partagés entre plusieurs périphériques Bluetooth. L'exemple suivant montre comment obtenir la liste des connexions en bande de base actives pour le périphérique local:
% 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
Une manipulation de la connexion est utile quand la fin d'une connexion en bande de base est nécessaire. Notez qu'il n'est normalement pas nécessaire de le faire à la main. La pile mettra fin automatiquement aux connexions en bande de base inactives.
# hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16]
Référez-vous à la commande hccontrol help pour une liste complète des commandes HCI disponibles. La plupart des commandes HCI ne nécessitent pas les privilèges du super-utilisateur.
Le protocole d'adaptation et de contrôle de lien logique (L2CAP) fournit des services orientés connexion ou non aux protocoles de niveaux supérieurs, et cela avec des possibilités de multiplexage de protocoles, de segmentation et de réassemblage. L2CAP permet aux applications et aux protocoles de niveaux supérieurs de transmettre et recevoir des paquets L2CAP d'une taille allant jusqu'à 64 Ko.
L2CAP est basé sur le concept de canaux. Un canal est une connexion logique au sommet de la connexion en bande de base. Chaque canal est attaché à un protocole suivant le schéma plusieurs-vers-un. Plusieurs canaux peuvent être attachés au même protocole, mais un canal ne peut être attachés à plusieurs protocoles. Chaque paquet L2CAP reçu sur un canal est dirigé vers le protocole de niveau supérieur approprié. Plusieurs canaux peuvent partager la même connexion en bande de base.
Un seul noeud Netgraph de type l2cap est créé pour un périphérique Bluetooth. Le noeud L2CAP est normalement connecté au noeud HCI Bluetooth (flux descendant) et aux noeuds des “sockets” Bluetooth (flux montant). Le nom par défaut pour le noeud L2CAP est “device2cap”. Pour plus de détails consultez la page de manuel ng_l2cap(4).
Une commande utile est l2ping(8), qui peut être utilisée pour “pinguer” les autres périphériques. Certaines implémentations de Bluetooth peuvent ne pas renvoyer toutes les données qui leur sont envoyées, aussi 0 bytes dans ce qui suit est normal.
# 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
L'utilitaire l2control(8) est employé pour effectuer diverses opérations sur les noeuds L2CAP. Cet exemple montre comment obtenir la liste des connexions logiques (canaux) et la liste des connexions en bande de base pour le périphérique local:
% 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
Un autre outil de diagnostic est btsockstat(1). Il effectue un travail similaire à celui de netstat(1), mais relatif aux structures de données réseau Bluetooth. L'exemple ci-dessous montre la même connexion logique que l2control(8) ci-dessus.
% 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
Le protocole RFCOMM permet l'émulation du port série au-dessus du protocole L2CAP. Le protocole est basé sur la norme ETSI TS 07.10. RFCOMM est un protocole de transport simple, avec les dispositions supplémentaires pour émuler les 9 circuits (signaux) d'un port série RS232 (EIATIA-232-E). Le protocole RFCOMM supporte jusqu'à 60 connexions simultanées (canaux RFCOMM) entre deux périphériques Bluetooth.
Dans le cas de RFCOMM, l'établissement d'une communication implique deux applications tournant sur des périphériques différents (les extrémités de la communication) avec un segment de communication entre eux. RFCOMM est prévu pour couvrir les applications faisant usage des ports séries des périphériques sur lesquels elles résident. Le segment de communication est une liaison Bluetooth d'un périphérique vers un autre (connexion directe).
RFCOMM est seulement concerné par la connexion entre périphériques dans le cas d'un raccordement direct, ou entre le périphérique et un modem dans le cas d'un réseau. RFCOMM peut supporter d'autres configurations, comme les modules qui communiquent par l'intermédiaire de la technologie sans fil Bluetooth d'un côté et utilise une interface câblée de l'autre côté.
Sous FreeBSD, le protocole RFCOMM est implémenté au niveau de la couche des “sockets” Bluetooth.
Par défaut, une communication Bluetooth n'est pas authentifiée, et n'importe quel périphérique peut parler avec n'importe quel autre périphérique. Un périphérique Bluetooth (par exemple un téléphone portable) peut choisir de demander une authentification pour fournir un service particulier (par exemple un service de connexion téléphonique). L'authentification Bluetooth est généralement effectuée avec des codes PIN. Un code PIN est une chaîne ASCII d'une longueur de 16 caractères. L'utilisateur doit entrer le même code PIN sur les deux périphériques. Une fois que l'utilisateur a entré le code PIN, les deux périphériques génèrent une clé de liaison (link key). Ensuite la clé peut être enregistrée soit dans les périphériques eux-mêmes ou sur un moyen de stockage non-volatile. La fois suivante les deux périphériques utiliseront la clé précédemment générée. La procédure décrite est appelée couplage. Si la clé de liaison est perdue par un des périphériques alors l'opération de couplage doit être répétée.
Le “daemon” hcsecd(8) est responsable de la gestion de toutes les requêtes d'authentification Bluetooth. Le fichier de configuration par défaut est /etc/bluetooth/hcsecd.conf. Un exemple de section pour un téléphone portable avec un code PIN arbitraire de “1234” est donné ci-dessous:
device {
bdaddr 00:80:37:29:19:a4;
name "Pav's T39";
key nokey;
pin "1234";
}
Il n'y pas de limitation sur les codes PIN (en dehors de la longueur). Certains
périphériques (comme les casques-micro Bluetooth)
peuvent avoir un code PIN définitivement fixé. Le paramètre -d force le “daemon” hcsecd(8) à rester en
tâche de fond, il est donc aisé de voir ce qu'il se passe. Configurez le
périphérique distant pour recevoir le couplage et initier la connexion Bluetooth vers le périphérique distant. Le
périphérique distant devrait annoncer que le couplage a été accepté, et
demander le code PIN. Entrez le même code PIN que celui que vous avez dans le
fichier hcsecd.conf. Maintenant votre PC et le
périphérique distant sont couplés. Alternativement, vous pouvez initier le
couplage sur le périphérique distant.
Sous FreeBSD 5.5, 6.1 et versions suivantes, la ligne suivante peut être ajoutée au fichier /etc/rc.conf pour obtenir un lancement automatique de hcsecd au démarrage du système:
hcsecd_enable="YES"
Ce qui suit est une partie de la sortie du “daemon” 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
Le protocole de découverte de service (SDP) offre aux applications clientes les moyens de découvrir l'existence des services fournis par les applications serveurs ainsi que les propriétés (attributs) de ces services. Les attributs d'un service comprennent le type ou la classe du service offert et le mécanisme ou l'information sur le protocole nécessaire pour utiliser le service.
Le SDP implique la communication entre un serveur SDP et un client SDP. Le serveur maintient une liste d'enregistrements de services qui décrit les caractéristiques des services associés avec le serveur. Chaque enregistrement de service contient l'information sur un seul serveur. Un client peut récupérer l'information à partir d'un enregistrement de service maintenu par le serveur SDP en émettant une requête SDP. Si le client, ou une application associée avec le client, décide d'utiliser un service, il doit ouvrir une connexion séparée avec le fournisseur du service afin d'utiliser ce service. Le SDP fournit un mécanisme pour découvrir les services et leur attributs, mais n'offre pas de mécanisme pour utiliser ces services.
Généralement, un client SDP recherche les services sur la base de caractéristiques de services désirées. Cependant, il est parfois désirable de découvrir quel type de services sont décrits par les enregistrements de services d'un serveur SDP sans aucune information préalable sur les services. Ce processus de recherche des services offerts est appelé navigation (“browsing”).
Le serveur SDP Bluetooth sdpd(8) et le client en ligne de commande sdpcontrol(8) font partie de l'installation FreeBSD standard. L'exemple suivant montre comment effectuer un requête de navigation (“browse”) 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
... et ainsi de suite. Remarquez que chaque service a une liste d'attributs (canal RFCOMM par exemple). En fonction du service vous pourrez avoir besoin de prendre note de certains de ces attributs. Certaines implémentations Bluetooth ne supportent pas les requêtes de navigation et peuvent renvoyer une liste vide. Dans ce cas il est possible de chercher un service spécifique. L'exemple ci-dessous montre comment chercher le service OBEX Object Push (OPUSH):
% sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH
Offrir des services sous FreeBSD aux clients Bluetooth se fait à l'aide du serveur sdpd(8). Sous les versions de FreeBSD 5.5, 6.1 et plus récentes, la ligne suivante peut être ajoutée au fichier /etc/rc.conf:
sdpd_enable="YES"
Ensuite, le “démon” sdpd peut être démarré avec:
# /etc/rc.d/sdpd start
Sous FreeBSD 6.0, et sous les versions FreeBSD 5.X antérieures à 5.5, sdpd n'est pas intégré aux procédures de démarrage du système. Il doit être lancé manuellement:
# sdpd
L'application serveur locale qui désire offrir un service Bluetooth à des clients distants enregistrera le service auprès du “daemon” SDP local. Un exemple d'une telle application est rfcomm_pppd(8). Une fois démarré, il enregistrera un service de réseau local Bluetooth auprès du serveur SDP local.
La liste des services enregistrés auprès du serveur SDP local peut être obtenue en émettant une requête de navigation (“browse”) SDP par l'intermédiaire du canal de contrôle:
# sdpcontrol -l browse
Le profil Dial-Up Networking (DUN) est principalement utilisé avec les modems et les téléphones portables. Les cas de figure couverts par ce profil sont les suivants:
Utilisation d'un téléphone portable ou d'un modem par un ordinateur comme modem sans fil pour se connecter à un serveur d'accès Internet, ou pour l'utilisation de services accessibles par téléphone;
Utilisation d'un téléphone portable ou d'un modem par un ordinateur pour recevoir des appels avec transmission de données.
Le profil d'accès au réseau local avec PPP (LAN) peut être utilisé dans les situations suivantes:
Accès au réseau local pour un périphérique Bluetooth;
Accès au réseau local pour plusieurs périphériques Bluetooth;
Liaison PC à PC (en utilisant le protocole PPP sur une émulation de câble série).
Sous FreeBSD les deux profils sont implémentés par ppp(8) et rfcomm_pppd(8)—un “wrapper” convertit la connexion Bluetooth RFCOMM en quelque chose d'utilisable par PPP. Avant qu'un profil ne soit utilisable, un nouveau label doit être créé dans le fichier /etc/ppp/ppp.conf. Consultez la page de manuel rfcomm_pppd(8) pour des exemples.
Dans l'exemple suivant rfcomm_pppd(8) sera employé pour ouvrir un connexion RFCOMM avec le périphérique distant avec une adresse BD_ADDR 00:80:37:29:19:a4 sur un canal DUN RFCOMM. Le numéro de canal RFCOMM réel sera obtenu du périphérique distant par l'intermédiaire de SDP. Il est possible de préciser le canal RFCOMM à la main, dans ce cas rfcomm_pppd(8) n'émettra pas de requête SDP. Utilisez sdpcontrol(8) pour trouver le canal RFCOMM sur le périphérique distant.
# rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup
Afin de fournir un service d'accès au réseau local avec PPP, le serveur sdpd(8) doit être en fonctionnement. Une nouvelle entrée pour les clients du réseau local doit être créée dans le fichier /etc/ppp/ppp.conf. Consultez la page de manuel rfcomm_pppd(8) pour des exemples. Enfin, lancez le serveur RFCOMM PPP sur un numéro de canal RFCOMM valide. Le serveur RFCOMM PPP enregistrera automatiquement un service Bluetooth LAN auprès du “daemon” SDP local. L'exemple ci-dessous montre comment démarrer le serveur RFCOMM PPP:
# rfcomm_pppd -s -C 7 -l rfcomm-server
OBEX (échange d'objets) est un protocole très largement utilisé pour les transferts de fichiers entre périphériques mobiles. Son utilisation principale se trouve dans les communications par infrarouge, où il est utilisé pour le transfert des fichiers entre ordinateurs portables ou PDAs, et pour envoyer des cartes de visite électronique ou des éléments d'agenda entre téléphones portables et d'autres périphériques disposant d'applications de gestion d'informations personnelles (PIM).
Le serveur et le client OBEX sont implémentés dans le logiciel tierce-partie obexapp, qui est disponible sous la forme du logiciel porté comms/obexapp.
Le client OBEX est employé pour “pousser” et/ou “tirer” des objets du serveur OBEX. Un objet peut être, par exemple, une carte de visite ou un rendez-vous. Le client OBEX peut obtenir un numéro de canal RFCOMM d'un périphérique distant par l'intermédiaire de SDP. Cela peut être fait en spécifiant le nom du service plutôt que le numéro du canal RFCOMM. Les noms de service supportés sont: IrMC, FTRN et OPUSH. Il est possible de préciser le canal RFCOMM par un nombre. Un exemple de session OBEX est présenté ci-dessous, où l'objet information du périphérique d'un téléphone portable est récupéré, et un nouvel objet (carte de visite) est envoyé dans le répertoire du téléphone.
% 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)
Afin de fournir le service OBEX Object Push, le serveur sdpd(8) doit tourner. Un dossier racine où tous les objets entrant seront stockés doit être créé. Le chemin d'accès par défaut du répertoire racine est /var/spool/obex. Le serveur OBEX enregistrera automatiquement le service OBEX Object Push auprès du “daemon” SDP local. L'exemple ci-dessous montre comment démarrer le serveur OBEX:
# obexapp -s -C 10
Le profil port série (SPP) permet aux périphériques Bluetooth d'émuler un câble série RS232 (ou similaire). Ce profil traite avec les applications classiques en utilisant Bluetooth comme un câble de remplacement, à travers une abstraction de port série virtuel.
L'utilitaire rfcomm_sppd(1) implémente le profil port série. Un pseudo terminal est utilisé comme abstraction de port série virtuel. L'exemple ci-dessous montre comment se connecter à un service port série d'un périphérique distant. Notez que vous n'avez pas besoin d'indiquer un canal RFCOMM — rfcomm_sppd(1) peut l'obtenir auprès du périphérique distant via SDP. Si vous désirez forcer cela, spécifiez un canal RFCOMM sur la ligne de commande.
# rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6...
Une fois connecté, le pseudo-terminal peut être utilisé comme un port série:
# cu -l ttyp6
Certains anciens périphériques Bluetooth ne supportent pas de changement de rôle. Par défaut, quand FreeBSD accepte une nouvelle connexion, il tente d'effectuer un changement de rôle et de devenir maître. Les périphériques qui ne supportent pas cela ne seront pas en mesure de se connecter. Notez qu'un changement de rôle est effectué quand une nouvelle connexion est établie, il n'est donc pas possible de demander au périphérique distant s'il supporte le changement de rôle. Il existe une option HCI pour désactiver le changement de rôle au niveau local:
# hccontrol -n ubt0hci write_node_role_switch 0
Bien sûr. Utilisez le logiciel tierce-partie hcidump qui est disponible sous comms/hcidump dans le catalogue des logiciels portés. L'utilitaire hcidump est similaire à tcpdump(1). Il peut être utilisé pour afficher le contenu des paquets Bluetooth à l'écran et les sauvegarder dans un fichier.
| Précédent | Sommaire | Suivant |
| Réseau sans fil | Niveau supérieur | Bridging |
Ce document, ainsi que d'autres peut être téléchargé sur ftp.FreeBSD.org/pub/FreeBSD/doc/.
Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.