brouillon_bluetooth
Ceci est une ancienne révision du document !
BlueTooth
Lien:
bases
Brancher
Au départ, il n'y a rien:
# hcitool dev Devices:
On branche la clé USB-Bluetooth en reluquant dans le syslog:
Oct 28 11:06:15 nin kernel: usb 2-7.1.4: new full speed USB device using ehci_hcd and address 13 Oct 28 11:06:25 nin kernel: usb 2-7.1.4: configuration #1 chosen from 1 choice Oct 28 11:06:25 nin hcid[21933]: HCI dev 0 registered Oct 28 11:06:25 nin hcid[21933]: Register path:/org/bluez/hci0 fallback:0 Oct 28 11:06:25 nin hcid[21933]: HCI dev 0 up Oct 28 11:06:25 nin hcid[21933]: Device hci0 has been added Oct 28 11:06:25 nin hcid[21933]: Starting security manager 0 Oct 28 11:06:25 nin hcid[21933]: Device hci0 has been activated
Notons le “lag” de 10 secondes entre le branchement et les logs.
Et alors:
# hcitool dev
Devices:
hci0 00:11:67:36:52:EF
La “config” de la clé Bluetooth:
# hciconfig
hci0: Type: USB
BD Address: 00:11:67:36:52:EF ACL MTU: 678:8 SCO MTU: 48:10
UP RUNNING PSCAN
RX bytes:401 acl:0 sco:0 events:18 errors:0
TX bytes:320 acl:0 sco:0 commands:18 errors:0
Plus d'info:
# hciconfig hci0 -a
hci0: Type: USB
BD Address: 00:11:67:36:52:EF ACL MTU: 678:8 SCO MTU: 48:10
UP RUNNING PSCAN
RX bytes:3362 acl:4 sco:0 events:137 errors:0
TX bytes:1268 acl:4 sco:0 commands:78 errors:0
Features: 0xbf 0xfe 0x8d 0x78 0x08 0x18 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'nin-0'
Class: 0x3e0100
Service Classes: Networking, Rendering, Capturing, Object Transfer, Audio
Device Class: Computer, Uncategorized
HCI Ver: 1.2 (0x2) HCI Rev: 0x1fe LMP Ver: 1.2 (0x2) LMP Subver: 0x1fe
Manufacturer: Integrated System Solution Corp. (57)
Rendons cette clé visible:
# hciconfig hci0 up piscan
Verifions:
# hciconfig hci0 -a
hci0: Type: USB
BD Address: 00:11:67:36:52:EF ACL MTU: 678:8 SCO MTU: 48:10
UP RUNNING PSCAN ISCAN
...
“ISCAN” ⇒ visible ???
Scan
MacBookPro
Y a t'il des equipements qui emettent sur le réseau “Bluethooth” (prévoir une attente d'une dizaine de secondes)
# hcitool scan
Scanning ...
00:1B:63:aa:bb:cc MacBookPro_de_XXXXXX
On en veut plus:
# hcitool inq
Inquiring ...
00:1B:63:43:B4:EE clock offset: 0x32a5 class: 0x30210c
La “class” donne le type d'equipement… ici, ce n'est pas un téléphone.
On peut pinguer:
# l2ping 00:1B:63:aa:bb:cc Ping: 00:1B:63:aa:bb:cc from 00:11:67:36:52:EF (data size 44) ... 44 bytes from 00:1B:63:aa:bb:cc id 0 time 195.02ms 44 bytes from 00:1B:63:aa:bb:cc id 1 time 35.50ms 44 bytes from 00:1B:63:aa:bb:cc id 2 time 35.15ms 3 sent, 3 received, 0% loss
On en veut encore plus:
# hcitool info 00:1B:63:aa:bb:cc
Requesting information ...
BD Address: 00:1B:63:aa:bb:cc
Device Name: MacBookPro_de_XXXXXX
LMP Version: 2.0 (0x3) LMP Subversion: 0x7ad
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
<HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
<power control> <transparent SCO> <broadcast encrypt>
<EDR ACL 2 Mbps> <EDR ACL 3 Mbps> <enhanced iscan>
<interlaced iscan> <interlaced pscan> <inquiry with RSSI>
<extended SCO> <EV4 packets> <EV5 packets> <AFH cap. slave>
<AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL>
<AFH cap. master> <AFH class. master> <EDR eSCO 2 Mbps>
<EDR eSCO 3 Mbps> <3-slot EDR eSCO> <extended features>
Comprend rien… normal.
Téléphone
Activons le “Bluetooth” sur un téléphone.
# hcitool scan
Scanning ...
00:17:B0:aa:bb:cc XXXXXX
00:0F:DE:16:E3:5C Benouze
00:1B:63:aa:bb:cc MacBookPro_de_XXXXXX
Mon téléphone est “Benouze”.
# hcitool inq
Inquiring ...
...
00:0F:DE:16:E3:5C clock offset: 0x678c class: 0x520204
...
D'aprés linux mag:
- 5(2) ⇒ Object Transfert
- 02 ⇒ Téléphone
- 04 ⇒ Cellulaire
A verifier!
Plus:
# hcitool info 00:0F:DE:16:E3:5C
Requesting information ...
BD Address: 00:0F:DE:16:E3:5C
Device Name: Benouze
LMP Version: 1.1 (0x1) LMP Subversion: 0x503
Manufacturer: Ericsson Technology Licensing (0)
Features: 0x04 0xca 0x31 0x00 0x00 0x00 0x00 0x00
<encryption> <RSSI> <SCO link> <u-law log> <A-law log> <CVSD>
Il ne fait pas grand chose…
Verifions les services disponibles:
# sdptool browse 00:0F:DE:16:E3:5C | grep "Service Name" Service Name: Dial-up Networking Service Name: Voice gateway Service Name: Serial Port 1 Service Name: Serial Port 2 Service Name: OBEX Object Push Service Name: IrMC Synchronization Service Name: HF Voice gateway Service Name: OBEX Basic Imaging Service Name: OBEX File Transfer
Parfait !
Pairing
hcid.conf
Aprés avoir rendu la clé Bluetooth visible… Le telephone cherche…
| Le nom affiché peut être un nom préalablement mémorisé |
Le téléphone trouve “nin-0” se qui correspond bien a la config.
La config /etc/bluetooth/hcid.conf :
# cat hcid.conf | grep -v "^[[:space:]]*#"
options {
autoinit yes;
security auto;
pairing multi;
passkey "1234";
pin_helper /etc/bluetooth/echopin;
}
device {
name "%h-%d";
class 0x3e0100;
iscan enable; pscan enable;
lm accept,master;
lp rswitch,hold,sniff,park;
}
Ce qui a été modifié:
# security user security auto
#dbus_pin_helper; pin_helper /etc/bluetooth/echopin;
#lm accept; lm accept,master;
pin_helper
Contient le code PIN echangé.
# cd /etc/bluetooth # cat echopin #!/bin/sh echo "PIN:1234"
# chmod a+x echopin
Si ca ne fonctionne pas !
... nin hcid[26678]: pin_code_request (sba=00:11:67:36:52:EF, dba=00:0F:DE:16:E3:5C) ... nin hcid[26678]: call_passkey_agent(): no agent registered
Vérifier le code PIN !
et puis
A un certain moment…
# /etc/init.d/bluetooth restart
pairing
Normalement le telephone doit se joindre avec le serveur “nin-0”
brouillon_bluetooth.1225199423.txt.gz · Dernière modification : 2008/10/28 13:10 de thierry