Outils pour utilisateurs

Outils du site


brouillon_bluetooth

BlueTooth

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”

gnokii

Installation

# apt-get update
# apt-get install gnokii

configuration

En tant que 'root' et toujours en utilisant une clé Bluetooth.

:!: gnokii ne pourra utiliser le telephone qu'au travers d'un pseudo modem AT
C'est pas plus mal puisque ca fonctionne avec plein de telephone ! hu!

Créé un fichier .gnokiirc à la racine du Home de l'utilisateur.
Ici, c'est root, donc c'est dans /root/.

En pratique, on va s'appuyer sur un exemple de la doc:

# zcat /usr/share/doc/gnokii/Docs/sample/gnokiirc.gz > ~/.gnokiirc

Et puis on change quelques lignes: ( # vi ~/.gnokiirc )

[global]
port = 00:0F:DE:16:E3:5C
model = AT
connection = bluetooth

On ne change pas le reste…

tests

# gnokii --identify
gnokiid Version 0.6.14
LOG: debug mask is 0x1
phone instance config:
model: AT
port_device: 00:0F:DE:16:E3:5C
connection_type: 5
init_length: 0
serial_baudrate: 19200
serial_write_usleep: -1
hardware_handshake: 0
require_dcd: 0
smsc_timeout: 100
connect_script:
disconnect_script:
rfcomm_cn: 1
sm_retry: off
Initializing AT capable mobile phone ...
Serial device: opening device 00:0F:DE:16:E3:5C
Message sent: 0x00 / 0x0004
41 54 5a 0d                                     | ATZ
write: [ATZ<cr>]
read : [ATZ<cr><cr><lf>OK<cr><lf>]
Message received: 0x00 / 0x000a
02 41 54 5a 0d 0d 0a 4f 4b 0d                   |  ATZ   OK
Received message type 00
Message sent: 0x00 / 0x0005
41 54 45 31 0d                                  | ATE1
write: [ATE1<cr>]
read : [ATE1<cr><cr><lf>OK<cr><lf>]
Message received: 0x00 / 0x000b
02 41 54 45 31 0d 0d 0a 4f 4b 0d                |  ATE1   OK
Received message type 00
Message sent: 0x00 / 0x000a
41 54 2b 43 4d 45 45 3d 31 0d                   | AT+CMEE=1

.. <snip> ...

Received message type 06
Message sent: 0x06 / 0x0008
41 54 2b 43 47 53 4e 0d                         | AT+CGSN
write: [AT+CGSN<cr>]
read : [AT+CGSN<cr><cr><lf>353989002606520<cr><lf><cr><lf>OK<cr><lf>]
Message received: 0x06 / 0x0021
02 41 54 2b 43 47 53 4e 0d 0d 0a 33 35 33 39 38 |  AT+CGSN   35398
39 30 30 32 36 30 36 35 32 30 0d 0a 0d 0a 4f 4b | 9002606520    OK
0d                                              |
Received message type 06
IMEI         : XXXXXXXXXXXXXXXXX
Fabricant: SONY ERICSSON
Modele       : AAB-1021011-BV
Product name : AAB-1021011-BV
Revision     : R4C003      CXC1255
Serial device: closing device

Yes !

Mais encore:

# gnokii --monitor once
gnokiid Version 0.6.14
LOG: debug mask is 0x1
phone instance config:
model: AT
port_device: 00:0F:DE:16:E3:5C
connection_type: 5
init_length: 0
serial_baudrate: 19200
serial_write_usleep: -1
hardware_handshake: 0
require_dcd: 0
smsc_timeout: 100
connect_script:
disconnect_script:
rfcomm_cn: 1
sm_retry: off
Initializing AT capable mobile phone ...
Serial device: opening device 00:0F:DE:16:E3:5C
Message sent: 0x00 / 0x0004
41 54 5a 0d                                     | ATZ
write: [ATZ<cr>]
read : [ATZ<cr><cr><lf>OK<cr><lf>]
Message received: 0x00 / 0x000a
02 41 54 5a 0d 0d 0a 4f 4b 0d                   |  ATZ   OK
Received message type 00
Message sent: 0x00 / 0x0005
41 54 45 31 0d                                  | ATE1
write: [ATE1<cr>]
read : [ATE1<cr><cr><lf>OK<cr><lf>]
Message received: 0x00 / 0x000b
02 41 54 45 31 0d 0d 0a 4f 4b 0d                |  ATE1   OK

... <snip> ...

Received message type 14
Message sent: 0x14 / 0x0009
41 54 2b 43 52 45 47 3f 0d                      | AT+CREG?
write: [AT+CREG?<cr>]
read : [AT+CREG?<cr><cr><lf>+CREG: 0,1<cr><lf><cr><lf>OK<cr><lf>]
Message received: 0x14 / 0x001d
02 41 54 2b 43 52 45 47 3f 0d 0d 0a 2b 43 52 45 |  AT+CREG?   +CRE
47 3a 20 30 2c 31 0d 0a 0d 0a 4f 4b 0d          | G: 0,1    OK
Received message type 14
strings[0] = +CREG: 0
strings[1] = 1
strings[2] = (null)
strings[3] = (null)
Appel0: inactif
Appel1: inactif
Sortie du mode surveillance...
Serial device: closing device

Envoi SMS

# echo "Hello Ducon" | gnokii --sendsms +3360721abcd

Yes !

N80/N81

Problème

Problème… gnokii ne fonctionne pas avec… grrr

# sdptool browse 00:12:D2:CC:B8:8B | grep "Service Name"
Service Name: AVRCP Target
Service Name: Hands-Free Audio Gateway
Service Name: Headset Audio Gateway
Service Name: SyncMLClient
Service Name: OBEX File Transfer
Service Name: Nokia OBEX PC Suite Services
Service Name: Nokia SyncML Server
Service Name: OBEX Object Push
Service Name: Dial-Up Networking
Service Name: Imaging

Et pourtant:

$ obexftp -b 00:12:D2:CC:B8:8B -l
Browsing 00:12:D2:CC:B8:8B ...
Channel: 11
Connecting...done
Receiving "(null)"... <?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd"
  [ <!ATTLIST folder mem-type CDATA #IMPLIED>
  <!ATTLIST folder label CDATA #IMPLIED> ]>
<folder-listing version="1.0">
   <folder name="C:" user-perm="RW" mem-type="DEV" label="Mémoire du téléphone"/>
   <folder name="E:" user-perm="RW" mem-type="MMC" label="Carte mém"/>
</folder-listing>done
Disconnecting...done

Soluce ?

Editer le fichier /etc/bluetooth/rfcomm.conf afin d'avoir:

#
# RFCOMM configuration file.
#

rfcomm0 {
      # Automatically bind the device at startup
      bind yes;

      # Bluetooth address of the device
      device 00:12:D2:CC:B8:8B;

      # RFCOMM channel for the connection
      channel 2;

      # Description of the connection
      comment "Example Bluetooth device";
}
:!: “channel 2” et pas autre chose! pourquoi ? mystère! et pas de rapport évident avec “.gnokiirc” …

Et puis:

# /etc/init.d/bluetooth restart
Restarting bluetooth: hcid sdpd rfcomm.

Et là, un device apparait:

/dev/rfcomm0

Parce qu'il a vu le N80 branché ?

Editer .gnokiirc (toujours a la racine de la home de votre user), afin d'avoir:

[global]
port = /dev/rfcomm0
model = AT
connection = serial

rfcomm_channel = 2

(Ne pas toucher le reste)

Et puis ca marche.

brouillon_bluetooth.txt · Dernière modification : 2009/02/01 17:55 de thierry