Dominique Meeùs
Dernière modification le
retour au sommaire Linux
Depuis Ubuntu 8.10, tout ça a cessé de fonctionner. Voir le bug #289836 sur Launchpad. Voir là en date 2008-11-07 ma solution provisoire.
Dans l’état actuel (mars 2009) d’Ubuntu 9.04, ça fonctionne de moins en moins et ma solution provisoire du 7-11-2008 implique l’installation de paquets trop éloignés du reste pour encore être compatibles. Donc plus de solution du tout ! Pas mieux en juin et ça ne change pas avec le noyau 2.6.29. Par contre, ça remarche avec Bluez 4.40-2. Bingo !
Quelques commandes :
/etc/init.d/bluetooth (un script de lancement du
démon bluetoothd) start, status,
stop.
modprobe btusb, rmmod btusb.
Il semble qu’on ait remplacé le démon hcid par
bluetoothd à partir de Bluez 4.xx et le driver hci_usb par
btusb à partir du noyau 2.6.27. L’un ou l’autre de ces changements, ou les
deux, étaient incompatibles avec certains dispositifs Bluetooth, dont mon D-Link
DBT-122. Launchpad est noyé de plaintes de gens qui ont divers ennuis, plus ou moins
graves, qui rendent leur Bluetooth pratiquement inutilisable, dans deux versions
successives d’Ubuntu, 8.10 et 9.04. Cependant ça marche en installant les paquets
bluetooth, bluez et libbluetooth3 en version
4.40-2. Il reste à espérer qu'ils seront bientôt intégrés à la distribution.
J’ai installé un adaptateur D-Link DBT-122. Comme dispositif USB il est listé par
~$ lsusb | grep Bluetooth
Bus 001 Device 003: ID 2001:f111 D-Link Corp. [hex] DBT-122 Bluetooth
adapter
et en Bluetooth
# hcitool dev
Devices:
hci0 00:13:46:00:55:A0
Donc mon adaptateur est reconnu et j’ai son adresse MAC.
Si on édite /etc/bluetooth/hcid.conf, pour que
le démon hcid en tienne compte, il faut le relancer: hcid
restart. Comme les choses commencent par ne pas marcher, on veut éditer les
fichiers de configuration pour voir ce que ça change mais il est probable que le
fichier par défaut est assez bon et que le problème venait d’ailleurs (voir par exemple
la « visibilité » ci-dessous à propos de hcitool scan).
# hciconfig donne l’état du dispositif
Bluetooth local, par exemple
hci0: Type: USB
BD Address: 00:13:46:00:55:A0 ACL MTU: 377:10 SCO MTU: 16:0
UP RUNNING PSCAN ISCAN
RX bytes:4876 acl:64 sco:0 events:236 errors:0
TX bytes:2267 acl:65 sco:0 commands:77 errors:0
On peut arrêter et redémarrer hci0 par
hciconfig hci0 down et hciconfig hci0 up.
On peut chercher un dispositif Bluetooth voisin par
hcitool scan. Par exemple, avec mon gsm, ça donne :
Scanning ...
00:13:70:0E:8A:77 Nokia 6021
Attention, ceci ne marche que si le téléphone est « visible ». Pour des raisons de sécurité, le téléphone peut être masqué. Cherchez cette option de visibilité dans les paramètres Bluetooth du téléphone et changez-la le cas échéant.
Avec hcitool inq, on obtient quelques détails
plus techniques comme la classe :
Inquiring ...
00:13:70:0E:8A:77 clock offset: 0x61ca class: 0x520204
La connaissance de l’adresse MAC (plus exactement BD
Address) du dispositif voisin permet de tester une liaison de bas niveau et de demander
encore plus de renseignements. On peut lancer un ping par l2ping
00:13:70:0E:8A:77 (Ctrl-C pour arrêter). En demandant hcitool
info 00:13:70:0E:8A:77, j’obtiens
Requesting information ...
BD Address: 00:13:70:0E:8A:77
Device Name: Nokia 6021
LMP Version: 1.2 (0x2) LMP Subversion: 0x4db
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xbf 0xee 0x0f 0x40 0x18 0x18 0x00 0x00
<3-slot packets> <5-slot packets> <encryption>
<slot offset>
<timing accuracy> <role switch> <sniff mode>
<RSSI>
<channel quality> <SCO link> <HV3 packets> <u-law
log>
<A-law log> <CVSD> <paging scheme> <power
control>
<transparent SCO> <inquiry with RSSI> <AFH cap.
slave>
<AFH class. slave> <AFH cap. master> <AFH class.
master>
Bien sûr, je ne prétends pas que je comprends le détail de la réponse. Ça m’encourage de voir qu’une certaine communication est possible entre l’ordinateur et le téléphone. (Étape suivante : pouvoir lire et écrire des données sur mon téléphone, comme les adresses et les rendez-vous.)
Les deux dispositifs doivent (avec l’option security
user dans /etc/bluetooth/hcid.conf) s’échanger un code PIN
(personal identification number). (C’est ce qu’on appelle le pairing.) Il faut
et il suffit qu’ils s’échangent la même série de chiffres. (Il n’y a pas de raison que
ce soit le PIN du téléphone. Ce qui compte c’est qu’on utilise le même PIN des deux
côtés lors de l’établissement de la liaison.)
J’ai suivi les indications du Gammu Wiki sur la connexion
Bluetooth avec le téléphone. J’ai écrit alors dans /etc/bluetooth un
nouveau PIN helper que j’appelle echopin et qui contient les deux
lignes
#!/bin/bash
echo "PIN:1234"
Dans /etc/bluetooth/hcid.conf, je remplace le
PIN helper par pin_helper /etc/bluetooth/echopin. Je relance hcid
restart. J’ai demandé au téléphone de chercher des équipements audio. Il a
trouvé l’ordinateur (en réalité le dispositif Bluetooth, on pourrait le déménager sur
un autre ordinateur). Dans Wammu (ci-dessous), j’ai demandé de se connecter au
téléphone. Le téléphone a demandé le PIN, j’ai donné 1234 et la connexion a réussi.
Maintenant, l’ordinateur et le gsm se connaissent et ne demandent plus de PIN pour se
connecter. (Par défaut, le téléphone demande l’autorisation de se connecter et ne se
déconnecte pas de lui-même – ce qui empêche Wammu de se reconnecter. Il vaut mieux
autoriser du côté du téléphone les connexions automatiques avec l’ordinateur.)
Avec Ubuntu 8.04, mon fichier hcid.conf a changé mais je
n’ai pas dû refaire le pairing. Avec 8.10, quand j’ai résolu les problèmes hardware,
j’ai du refaire le pairing et en chipotant un peu, j’y suis arrivé, je ne sais plus
comment.
Affiche une fenêtre Bluetooth devices. La commande Devices/Scan affiche mon Nokia 6021. La commande Edit/Properties ne donne rien.
Affiche une icone d’activité. Semble attendre qu’on (le téléphone) lui envoie des fichiers. J’ai aussi réussi à envoyer à mon téléphone une nouvelle sonnerie mais je ne me rappelle plus si c’est par ceci ou par Wammu.
Wammu est l’interface graphique d’une application en lignes de commandes Gammu. À en juger par des articles et leurs images d’écran, c’est juste ce qu’il faut : gestion des adresses, des tâches et de l’agenda, avec possibilité de backup du téléphone. À partir d’Ubuntu 7.04, il y a une version de Wammu qui fonctionne.
Les paquets deb proposés avaient des dépendances incomptatibles avec Ubuntu. J’ai trouvé sur le Wiki de Gammu.org un script que j’ai appelé insgw pour installer Gammu et Wammu dans Ubuntu 6.06. Je l’ai exécuté comme root. J’ai eu ainsi dans le menu Accessoires un Wammu qui fonctionnait (et qui me parlait en français sans que je le lui aie demandé).
Il faut encore pour la relation avec le téléphone des fichiers de configuration corrects qui sont ~/.gammurc et ~/.Wammu avec surtout l’adresse MAC du gsm. Et voilà, je demande à Wammu de récupérer Calendrier ; Appels sortant, manqué, reçu (sic pour le singulier) ; Contacts téléphone, carte SIM ; Messages Lu, Envoyé, Non lu, Non envoyé ; Choses à faire, et j’ai tout sur un écran de 17", — sensiblement plus grand que celui du gsm — et je peux en prendre un backup. Wow !
On peut éditer. L’édition se fait en temps réel dans le téléphone. Je peux aussi mettre le téléphone à l’heure sur l’horloge de l’ordinateur. Si je veux accéder aux messages, Wammu se plante.
Si j’édite ou je crée un item dans le calendrier, j’ai un message disant que « It was not possible to read saved entry! It might be different that the one saved in phone until you reread all entries. » mais ça marche quand même. Par contre, on ne peut pas éditer un item existant. On peut en effacer. L’interface est fruste : une liste. De même pour les contacts.
Le format et le contenu des fichiers enregistrés dépend de
l’extension. Un fichier .vcf donne un fichier texte des contacts en format
VCard. Un fichier .ldif donne un fichier texte des contacts en format
d’importation LDAP. (On pourrait aussi sauver les contacts dans un format
.lmb de Nokia mais cela plante Wammu.) Un fichier .vcs donne
un fichier texte de l’agenda en format VCalendar. Un fichier .ics donne un
fichier texte de l’agenda en format iCal. Toute autre extension (.backup par défaut si
on n’en met pas) donne un backup Gammu. On peut écrire l’extension ou la sélectionner
comme type de fichier dans la boîte de dialogue étendue de sauvegarde. Ce devrait être
un fichier texte mais gedit refuse de l’ouvrir et bluefish donne seulement deux
caractères spéciaux.
Les fichiers iCal peuvent être importés dans l’extension calendrier Lightning de Thunderbird. Voir ici la solution d’un problème de caractères accentués.
Gnokii est une autre application de gestion des données du téléphone, qui se trouve dans les dépôts de paquets d’Ubuntu et de Debian. Synaptic installe dans le menu Accessoires l’interface graphique xGnokii. La fenêtre de base de xnokii est une horreur qui rappelle certains media players. Par contre, les contacts sauvés le sont en format texte genre CSV (avec point-virgule), contrairement au format propriétaire de Gammu. Chez moi, xGnokii se plantait d’abord en accédant à l’agenda. (Contrairement à Wammu, Gnokii se déconnecte en se plantant.) Il est vrai que Wammu fait des difficultés aussi avec cet agenda : ça marche, mais avec un message d’erreur. L’interface calendrier est à peine moins fruste que celle de Wammu. On a la liste en dessous du calendrier. Si on sélectionne une note, le jour est mis en évidence dans l’agenda mais cliquer sur un autre jour de l’agenda ne fait pas naviguer dans la liste. Gnokii ne veut pas enregistrer mon agenda (pas de message d’erreur, il ne fait ni ne dit rien).
Le paquet gnokii contient (et Synaptic installe
du même coup) l’interface xgnokii. Il existe aussi une autre interface,
Gnocky, à télécharger séparément, que je n’ai pas essayée parce que les copies d’écran montrent qu’elle ne gère
pas l’agenda.
Devrait permettre de synchroniser Evolution avec un gsm (ou d’autres PIMs, Personal Information Managers). Utilise IrMC que mon Nokia 6021 ne supporte pas.