Add a new translated section (Bluetooth), the translation of this "long"
chapter is over!
This commit is contained in:
Marc Fonvieille
parent
33b1117ee8
commit
e4fbb2c0e2
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=21638
1 changed files with 729 additions and 3 deletions
|
|
@ -1322,10 +1322,736 @@ wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
|
|||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
||||
<sect1 id="network-bluetooth">
|
||||
<title>Bluetooth ** Traduction en Cours **</title>
|
||||
<para></para>
|
||||
<sect1info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Pav</firstname>
|
||||
<surname>Lucistnik</surname>
|
||||
<contrib>Ecrit par </contrib>
|
||||
<affiliation>
|
||||
<address><email>pav@oook.cz</email></address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</sect1info>
|
||||
<title>Bluetooth</title>
|
||||
|
||||
<indexterm><primary>Bluetooth</primary></indexterm>
|
||||
<sect2>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>&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.</para>
|
||||
|
||||
<para>La pile &bluetooth; sous &os; utilise le système
|
||||
Netgraph (voir &man.netgraph.4;). Une large gamme
|
||||
d'adaptateurs USB &bluetooth; sont supportés par le
|
||||
pilote &man.ng.ubt.4;. Les périphériques
|
||||
&bluetooth; basés sur le circuit Broadcom BCM2033 sont
|
||||
supportés par les pilotes &man.ubtbcmfw.4; et
|
||||
&man.ng.ubt.4;. La carte 3Com &bluetooth; PC Card 3CRWB60-A
|
||||
demande le pilote &man.ng.bt3c.4;. Les
|
||||
périphériques &bluetooth; de type série
|
||||
et UART sont supportés via les pilotes &man.sio.4;,
|
||||
&man.ng.h4.4; et &man.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.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Branchement du périphérique</title>
|
||||
|
||||
<para>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:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>kldload ng_ubt</userinput></screen>
|
||||
|
||||
<para>Si le périphérique &bluetooth; est
|
||||
présent au démarrage du système, chargez
|
||||
le module à partir de
|
||||
<filename>/boot/loader.conf</filename>:</para>
|
||||
|
||||
<programlisting>ng_ubt_load="YES"</programlisting>
|
||||
|
||||
<para>Branchez votre clé USB. Une sortie semblable
|
||||
à celle-ci devrait s'afficher sur la console (ou dans
|
||||
les journaux du système):</para>
|
||||
|
||||
<screen>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</screen>
|
||||
|
||||
<para>Copiez
|
||||
<filename>/usr/share/examples/netgraph/bluetooth/rc.bluetooth</filename>
|
||||
à un emplacement adapté, comme
|
||||
<filename>/etc/rc.bluetooth</filename>. 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:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>/etc/rc.bluetooth start ubt0</userinput>
|
||||
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</screen>
|
||||
</sect2>
|
||||
|
||||
<indexterm><primary>HCI</primary></indexterm>
|
||||
<sect2>
|
||||
<title>Interface de contrôle de l'hôte (HCI)</title>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>Un seul noeud Netgraph de type <emphasis>hci</emphasis>
|
||||
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 &man.ng.hci.4;.</para>
|
||||
|
||||
<para>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
|
||||
<emphasis>inquiry</emphasis> (enquête, recherche).
|
||||
Cette recherche et les autres opérations relatives
|
||||
à HCI sont effectuées par l'utilitaire
|
||||
&man.hccontrol.8;. L'exemple ci-dessous montre comment
|
||||
déterminer quels périphériques
|
||||
&bluetooth; sont dans le voisinnage. 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 <emphasis>discoverable</emphasis>.
|
||||
|
||||
<screen>&prompt.user; <userinput>hccontrol -n ubt0hci inquiry</userinput>
|
||||
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]</screen>
|
||||
|
||||
<para><literal>BD_ADDR</literal> 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 <filename>/etc/bluetooth/hosts</filename> 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:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4</userinput>
|
||||
BD_ADDR: 00:80:37:29:19:a4
|
||||
Name: Pav's T39</screen>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>hccontrol -n ubt0hci read_connection_list</userinput>
|
||||
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</screen>
|
||||
|
||||
<para>Une <emphasis>manipulation de la connexion</emphasis> 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.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>hccontrol -n ubt0hci disconnect 41</userinput>
|
||||
Connection handle: 41
|
||||
Reason: Connection terminated by local host [0x16]</screen>
|
||||
|
||||
<para>Référez-vous à la commande
|
||||
<command>hccontrol help</command> pour une liste
|
||||
complète des commandes HCI disponibles. La plupart des
|
||||
commandes HCI ne nécessitent pas les privilèges
|
||||
du super-utilisateur.</para>
|
||||
</sect2>
|
||||
|
||||
<indexterm><primary>L2CAP</primary></indexterm>
|
||||
<sect2>
|
||||
<title>Protocole d'adaptation et de contrôle de lien
|
||||
logique (L2CAP)</title>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>L2CAP est basé sur le concept de
|
||||
<emphasis>canaux</emphasis>. 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.</para>
|
||||
|
||||
<para>Un seul noeud Netgraph de type <emphasis>l2cap</emphasis>
|
||||
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 &man.ng.l2cap.4;.</para>
|
||||
|
||||
<para>Une commande utile est &man.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 <literal>0
|
||||
bytes</literal> dans ce qui suit est normal.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>l2ping -a 00:80:37:29:19:a4</userinput>
|
||||
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</screen>
|
||||
|
||||
<para>L'utilitaire &man.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:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>l2control -a 00:02:72:00:d4:1a read_channel_list</userinput>
|
||||
L2CAP channels:
|
||||
Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State
|
||||
00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN
|
||||
&prompt.user; <userinput>l2control -a 00:02:72:00:d4:1a read_connection_list</userinput>
|
||||
L2CAP connections:
|
||||
Remote BD_ADDR Handle Flags Pending State
|
||||
00:07:e0:00:0b:ca 41 O 0 OPEN</screen>
|
||||
|
||||
<para>Un autre outil de diagnostic est &man.btsockstat.1;. Il
|
||||
effectue un travail similaire à celui de
|
||||
&man.netstat.1;, mais relatif aux structures de données
|
||||
réseau &bluetooth;. L'exemple ci-dessous montre la
|
||||
même connexion logique que &man.l2control.8;
|
||||
ci-dessus.</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>btsockstat</userinput>
|
||||
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</screen>
|
||||
</sect2>
|
||||
|
||||
<indexterm><primary>RFCOMM</primary></indexterm>
|
||||
<sect2>
|
||||
<title>Protocole RFCOMM</title>
|
||||
|
||||
<para>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;.</para>
|
||||
|
||||
<para>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).</para>
|
||||
|
||||
<para>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é.</para>
|
||||
|
||||
<para>Sous &os;, le protocole RFCOMM est
|
||||
implémenté au niveau de la couche des
|
||||
“sockets” &bluetooth;.</para>
|
||||
</sect2>
|
||||
|
||||
<indexterm><primary>couplage</primary></indexterm>
|
||||
<sect2>
|
||||
<title>Couplage des périphériques</title>
|
||||
|
||||
<para>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 <emphasis>codes PIN</emphasis>. 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
|
||||
<emphasis>clé de liaison</emphasis> (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
|
||||
<emphasis>couplage</emphasis>. 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.</para>
|
||||
|
||||
<para>Le “daemon” &man.hcsecd.8; est responsable de
|
||||
la gestion de toutes les requêtes d'authentification
|
||||
&bluetooth;. Le fichier de configuration par défaut
|
||||
est <filename>/etc/bluetooth/hcsecd.conf</filename>. Un
|
||||
exemple de section pour un téléphone portable
|
||||
avec un code PIN arbitraire de “1234” est
|
||||
donné ci-dessous:</para>
|
||||
|
||||
<programlisting>device {
|
||||
bdaddr 00:80:37:29:19:a4;
|
||||
name "Pav's T39";
|
||||
key nokey;
|
||||
pin "1234";
|
||||
}</programlisting>
|
||||
|
||||
<para>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
|
||||
<option>-d</option> force le “daemon”
|
||||
&man.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 dand le fichier <filename>hcsecd.conf</filename>.
|
||||
Maintenant votre PC et le périphérique distant
|
||||
sont couplés. Alternativement, vous pouvez initier le
|
||||
couplage sur le périphérique distant. Ce qui
|
||||
suit est une partie de la sortie du “daemon”
|
||||
<application>hcsecd</application>:</para>
|
||||
|
||||
<programlisting>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</programlisting>
|
||||
</sect2>
|
||||
|
||||
<indexterm><primary>SDP</primary></indexterm>
|
||||
<sect2>
|
||||
<title>Le protocole de découverte de service
|
||||
(SDP)</title>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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é <emphasis>navigation</emphasis>
|
||||
(“browsing”).</para>
|
||||
|
||||
<para>Le serveur SDP &bluetooth; &man.sdpd.8; et le client en
|
||||
ligne de commande &man.sdpcontrol.8; font partie de
|
||||
l'installation &os; standard. L'exemple suivant montre
|
||||
comment effectuer un requête de navigation
|
||||
(“browse”) SDP:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>sdpcontrol -a 00:01:03:fc:6e:ec browse</userinput>
|
||||
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
|
||||
</screen>
|
||||
|
||||
<para>... 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):</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH</userinput></screen>
|
||||
|
||||
<para>Offrir des services sous &os; aux clients &bluetooth; se
|
||||
fait à l'aide du serveur &man.sdpd.8;:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>sdpd</userinput></screen>
|
||||
|
||||
<para>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 &man.rfcomm.pppd.8;.
|
||||
Une fois démarré, il enregistrera un service de
|
||||
réseau local &bluetooth; auprès du serveur SDP
|
||||
local.</para>
|
||||
|
||||
<para>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:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>sdpcontrol -l browse</userinput></screen>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Les profils Dial-Up Networking (DUN) et accès au
|
||||
réseau local avec PPP (LAN)</title>
|
||||
|
||||
<para>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:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>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;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Utilisation d'un téléphone portable ou
|
||||
d'un modem par un ordinateur pour recevoir des appels avec
|
||||
transmission de données.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Le profil d'accès au réseau local avec PPP
|
||||
(LAN) peut être utilisé dans les situations
|
||||
suivantes:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Accès au réseau local pour un
|
||||
périphérique &bluetooth;;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Accès au réseau local pour plusieurs
|
||||
périphériques &bluetooth;;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Liaison PC à PC (en utilisant le protocole PPP
|
||||
sur une émulation de câble
|
||||
série).</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Sous &os; les deux profils sont implémentés
|
||||
par &man.ppp.8; et &man.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
|
||||
<filename>/etc/ppp/ppp.conf</filename>. Consultez la page de
|
||||
manuel &man.rfcomm.pppd.8; pour des exemples.</para>
|
||||
|
||||
<para>Dans l'exemple suivant &man.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 &man.rfcomm.pppd.8;
|
||||
n'émettra pas de requête SDP. Utilisez
|
||||
&man.sdpcontrol.8; pour trouver le canal RFCOMM sur le
|
||||
périphérique distant.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup</userinput></screen>
|
||||
|
||||
<para>Afin de fournir un service d'accès au réseau
|
||||
local avec PPP, le serveur &man.sdpd.8; doit être en
|
||||
fonctionnement. Une nouvelle entrée pour les clients
|
||||
du réseau local doit être créée
|
||||
dans le fichier <filename>/etc/ppp/ppp.conf</filename>.
|
||||
Consultez la page de manuel &man.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:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>rfcomm_pppd -s -C 7 -l rfcomm-server</userinput></screen>
|
||||
</sect2>
|
||||
|
||||
<indexterm><primary>OBEX</primary></indexterm>
|
||||
<sect2>
|
||||
<title>Le profil OBEX Object Push (OPUSH)</title>
|
||||
|
||||
<para>OBEX (échange d'objets) est un protocole
|
||||
très largement utilisé pour les tranferts de
|
||||
fichiers entre périphériques mobiles. Son
|
||||
utilisation principale se trouve dans les communications par
|
||||
infrarouge, où il est utilisé pour le tranfert
|
||||
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).</para>
|
||||
|
||||
<para>Le serveur et le client OBEX sont
|
||||
implémentés dans le logiciel tierce-partie
|
||||
<application>obexapp</application>, qui est disponible sous la
|
||||
forme du logiciel porté <filename
|
||||
role="package">comms/obexapp</filename>.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>obexapp -a 00:80:37:29:19:a4 -C IrMC</userinput>
|
||||
obex> get
|
||||
get: remote file> telecom/devinfo.txt
|
||||
get: local file> devinfo-t39.txt
|
||||
Success, response: OK, Success (0x20)
|
||||
obex> put
|
||||
put: local file> new.vcf
|
||||
put: remote file> new.vcf
|
||||
Success, response: OK, Success (0x20)
|
||||
obex> di
|
||||
Success, response: OK, Success (0x20)</screen>
|
||||
|
||||
<para>Afin de fournir le service OBEX Object Push, le serveur
|
||||
&man.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 <filename
|
||||
role="directory">/var/spool/obex</filename>. 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:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>obexapp -s -C 10</userinput></screen>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Le profil port série (SPP)</title>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>L'utilitaire &man.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 — &man.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.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6</userinput>
|
||||
rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen>
|
||||
|
||||
<para>Une fois connecté, le pseudo-terminal peut
|
||||
être utilisé comme un port série:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cu -l ttyp6</userinput></screen>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Dépannage</title>
|
||||
|
||||
<sect3>
|
||||
<title>Un périphérique distant ne peut pas se
|
||||
connecter</title>
|
||||
|
||||
<para>Certains anciens périphériques &bluetooth;
|
||||
ne supportent pas de changement de rôle. Par
|
||||
défaut, quand &os; 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:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>hccontrol -n ubt0hci write_node_role_switch 0</userinput></screen>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Quelque chose ne va pas, puis-je voir ce qui se passe
|
||||
exactement?</title>
|
||||
|
||||
<para>Bien sûr. Utilisez le logiciel tierce-partie
|
||||
<application>hcidump-1.5</application> qui peut être
|
||||
téléchargé depuis <ulink
|
||||
url="http://www.geocities.com/m_evmenkin/"></ulink>.
|
||||
L'utilitaire <application>hcidump</application> est
|
||||
similaire à &man.tcpdump.1;. Il peut être
|
||||
utilisé pour afficher le contenu des paquets
|
||||
&bluetooth; à l'écran et les sauvegarder dans
|
||||
un fichier.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="network-bridging">
|
||||
|
|
|
|||
Loading…
Reference in a new issue