Lien:

• http://www.meeus-d.be/linux/bluetooth.html
• http://www.nerux.org/index.php/Bluetooth_irda
• http://www.developershome.com/sms/
• http://www.michaelwood.me.uk/wordpress/2007/03/

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 ???

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.

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 !

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;

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 !

A un certain moment…

# /etc/init.d/bluetooth restart

Normalement le telephone doit se joindre avec le serveur “nin-0”

# apt-get update
# apt-get install gnokii

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…

# 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

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

Yes !

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

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.