Voilà, réception d'un nouveau téléphone qui cette fois, je l'espère, durera plus que l'ancien. Et comme le dit téléphone est vide de tout, je branche ma "vieille" clef USB- bluetooth qui m'avait tant réussie sous Mandriva 2007.0 pour envoyer dans le petit zin-zin sonneries et autre carnet d'adresses. Et là, l'outil KDE (kbluetooth) qui avait si bien fonctionné à l'époque ne reconnaît plus rien.

Alors ok, l'outil kde_tout_beau ne marche pas. Mais l'avantage de linux reste que si lorsque graphique part en vrille, la ligne de commande, elle, on ne le dira jamais assez, restera éternellement votre amie. Je m'en vais donc vous conter la méthode "Conan", pour importer entre autre un carnet d'adresse, via bluetooth.

Découverte des services

Si tout est correctement installé (paquets bluez et bluez-utils), le chargement de la pile Bluetooth se fait par un la commande suivante :

Si tout c'est bien passé, un ps -edaf vous indique que deux nouveaux démons sont présents : hcid pour Host Controller Interface Daemon, et sdpd pour Service Discovery Protocol Daemon. Le premier est donc chargé de la clef elle-même et l'autre de gérer les services que peut offrir un périphérique bluetooth connecté à la clef.

Alors vérifions déjà si la clef est reconnue dans le système :

Ok, notre adaptateur est donc visible (hci0). Maintenant regardons les périphériques visibles par notre clef :

Parfait, mobile en vue, son adresse bluetooth est donc 00:1D:25:FB:A2:75. Voyons maintenant ce que ce téléphone sait faire. La commande suivante sans le grep donnerait plus d'information, mais là nous cherchons à obtenir la liste des services disponibles, et surtout le canal bluetooth associé à chaque service. En effet en blutooth c'est comme en TCP/IP, à l'adresse IP correspond notre adresse bluetooth, les services du périphériques peuvent être vu comme des serveurs et enfin les ports qu'écouteraient ces serveurs sont appelés des canaux (Channels).

Dans cette liste, pour l'instant, deux services nous intéressent particulièrement : OOP et OBEX File Transfert qui sont respectivement sur les canaux 9 et 3.

OBEX FTP

Le OBEX FileTransfert, disponible ici sur le canal 9, est un protocole permettant l'échange de fichier. A ce titre il est à rapprocher d'un serveur FTP. Il est grâce à lui possible de lire les dossiers présent sur le périphérique, de se déplacer dans l'arborescence, et enfin d'envoyer et recevoir des fichiers.

Et comme OBEX FT est une sorte de serveur FTP, il y existe pour lui un client OBEX FT. Il faut pour cela installer le paquet obexftp. Ceci fait, pour avoir la liste des dossiers à la racine du téléphone il suffit d'invoquer la commande obexftp -b 00:1D:25:FB:A2:75 -l

De la même manière, nous pouvons envoyer ou recevoir un fichier :

Voilà qui va déjà nous permettre d'échanger photos, sonneries, images, etc, avec le mobile. La moitié du boulot est donc réalisée. Mais il nous reste encore à trouver le moyen d'exporter un carnet d'adresse.

Object Push Protocol

OPP ou Object Push Protocol, permet d'envoyer un fichier au mobile comme le permettrait obexftp. Mais contrairement à ce dernier, OOP est conçu pour que le fichier reçu soit interprété par le téléphone et non pas être simple stocké dans sa mémoire. Par exemple, et c'est ce qui va nous servir plus loin, pour la majorité des téléphones, si le fichier poussé est une vCard , il sera directement stocké dans le carnet d'adresses.

Donc comme nous avions un client OBEX TP, il nous faut un client OOP pour pousser nos fichiers. Malheureusement il n'y en a pas d'inclus dans la Mandriva en standard (du moins je n'en ai pas trouvé). La solution est donc de télécharger ussp-push et de le compiler nous-mêmes.

Rien de bien sorcier là dedans, juste décompresser l'archive, aller dans le dossier ./ussp-push/ , vérifier que les paquets de développement de bluez sont installés (libbluez-devel) et lancer un classique make. Au bout de quelques secondes, un exécutable ussp-push est fabriqué, vous pouvez le déplacer en /usr/bin

ussp-push fonctionne, comme obexftp , avec l'adresse bluetooth du téléphone. Par exemple pour envoyer un jpeg dans le téléphone. Et comme nous l'avons vu plus haut, le canal OPP est, pour ce téléphone, le 3. Cela nous donnes pour envoyer une photo dans le téléphone :

Nous retrouvons donc l'adresse bluetooth, le 3 correspondant au canal utilisé par OOP, le fichier à envoyer et le nom du fichier à inscrire dans le téléphone.

Voilà, nous avons maintenant l'outil nous permettant d'envoyer notre carnet d'adresses dans notre téléphone, et ceci grâce à OOP et aux vCards.

Méthode sauvage d'export de carnet d'adresse

Un fichier vCard (extension .vcf) contient une ou plusieurs cartes de visite. C'est même le format qu'utilise kaddressbook pour son stockage. Il s'agit d'un simple fichier texte contenant des suites d'enregistrements composés de champs (nom, adresse, numéros, etc.). Or par chance, nombre de téléphones utilisent justement ce même format pour échanger des cartes de visites via OOP.

L'histoire pourrait donc s'arrêter là en faisant un ussp-push du fichier de stockage de kaddressbook mais malheureusement, mon téléphone ne sait pas analyser un fichier vCard comprenant plus d'une entrée. Il va donc falloir introduire une étape supplémentaire et demander à kaddressbook un export au format vCard 2.1, avec tous les champs, mais en créant un fichier par enregistrement. Ce qui ne lui pose pas plus de problèmes que cela (fonction Fichier/Exporter...).

Une fois sa tache terminée, vous devez avoir un dossier remplis de fichiers vcf. A ce stade, il est sage d'aller configurer son téléphone pour autoriser le PC à communiquer sans confirmation, de sorte à ne pas avoir à valider chaque arrivée dans le carnet d'adresse.

Il ne nous reste plus maintenant qu'à écrire le petit script qui va pousser chaque fichier vcf dans le téléphone :

Ce script perl est simple d'utilisation, vous le lancez par la commande suivante :

Le premier paramètre est le dossier où se trouvent les vCards exportées, le second la combinaison de l'adresse de votre téléphone et du canal utilisé pour OOP. Le script opère un filtrage pour n'envoyer au téléphone que les vCard qui contiennent un nom (FN:). Enfin le 0.50 permet de régler un temps de pose pour que le téléphone ne sature pas (ici .5 correspond à 500ms). Vous pouvez l'augmenter si votre téléphone n'est pas assez véloce.

Conclusion

On ne peut pas dire que cela aura été simple mais comme toujours avec Linux, les épreuves nous en apprennent beaucoup sur le système et son architecture. C'est rarement du temps perdu. Et au moins, nous ne sommes plus dépendant d'outil plus complexes mais plus fragiles.

Commentaires