Leur interface d’administration Web, nommée « Frontview » est accessible en HTTPS, ce qui, au premier abord, semble être une très bonne chose… Oui, mais voilà, le petit processeur « infrant » - architecture sparc -, qu’ils intègrent, est aussi efficace pour les traitements arithmétiques (et donc les fonctions de chiffrement SSL),  qu’un moteur de mobylette sur un Airbus A380. Résultat, même avec un pot polini  et un carbu 14, rien à faire, ça ne décolle pas.  C’est mou…c’est très mou, c’est très très mou !  J’ai résisté tant que j’ai pu, n’effectuant en somme que très peu de manipulations via cette interface, mais aujourd’hui, trop c’est trop, j’ai craqué ! Et quand je m’énerve, je change de couleur, mes proéminents muscles verts déchirent ma chemise et je casse tout sur mon passage.

J’ai donc commencé par m’attaquer à un pauvre crayon à papier et quant il a eu son sort (3 morceaux quand même !), je suis passé au serveur WEB de mon ReadyNAS. Mais, reprenant peu à peu ma raison, une couleur humaine et une chemise piquée sur un étendoir voisin, je me suis résigné à juste désactiver la couche SSL du serveur Apache.

Si comme moi, vous ragez, pestez et vociférez contre ce mollasson de Frontview, voici comment lui redonner un peu de peps, au détriment d’une bonne dose de sécurité, bien malheureusement. Qu’on se le dise, tout de même, si il avance beaucoup mieux après, il ne décolle quand même pas… Un moteur de mobylette reste un moteur de mobylette.

La première chose à faire, si ce n’est pas déjà fait, est d’installer de quoi se connecter en ssh sur la bête (enfin, le veau, pour être plus précis). Il faut pour cela le plugin : Enable Root SSH Access (version Sparc dans mon cas).

Le plugin s’installe par la voie normale : Menu système, Mise à jour – Installation, Image Locale – Module.

Ce module installé et le Nas redémarré, l’accès SSH est ouvert et le mot de passe root synchronisé avec celui du compte « Admin » utilisé pour se connecter à Frontview.

 Il suffit ensuite de se connecter, par ssh donc, pour modifier la configuration d’Apache.

Le fichier de configuration en question est :

/etc/frontview/apache/httpd.conf

• Rechercher la ligne « Listen 443  » , la commenter, ainsi que tout le bloc de configuration SSL suivant,
• Rechercher la ligne « include /etc/frontview/apache/Virtual.conf »  et la commenter (le fichier virtual.conf contient juste une directive de réécriture d’URL pour rediriger les requêtes http vers du https).

 Extrait :

...
 
# Listen 443
# SSLEngine On
# SSLSessionCache dbm:/ramfs/gcache.db
# SSLSessionCacheTimeout 600
# SSLCACertificatePath /etc/frontview/apache
# SSLCertificateFile /etc/frontview/apache/apache.pem
 
...
 
Include /etc/frontview/apache/Ports.conf
# Include /etc/frontview/apache/Virtual.conf
Include /etc/frontview/apache/addons/*.conf
Include /etc/frontview/apache/Shares.conf

Un petit reboot du NAS et l’interface devrait être accessible en http. (si quelqu’un peut m’expliquer comment redémarrer Apache/Frontview sans redémarrer tout le NAS, je suis preneur, j’avoue ne pas avoir cherché et n’ai pas trop étudié les scripts de démarrage sur ce type de machine).

Pour conclure, la manipulation telle que décrite, doit fonctionner sur tous les ReadyNAS; mais je n’ai pas testé d’autres modèles.

Bien évidemment, désactiver https si vous utilisez le NAS depuis Internet ou ailleurs qu’à la maison n’est vraiment pas une bonne idée.

Le but, ici, n’est pas de fournir un dossier détaillé, mais plutôt de faire un témoignage ou donner un retour d’expérience sur ce que peut-être l’amusante mise en place d’une petite solution de domotique.

L’idée de départ était de pouvoir faire des choses relativement simples, telles que :

• Fermer les volets, couper l’alimentation de certains appareils au lieu de les laisser en veille ( TV, ampli, moniteurs, imprimantes) et éteindre les lumières lorsque l’alarme est activée,
• Faire l’opération inverse lorsque l’alarme est désactivée,
• Allumer automatiquement certaines lumières à la tombée du jour,
• Ouvrir automatiquement les volets le matin en guise de réveil,
• Mettre automatiquement en marche mon serveur de sauvegardes chaque nuit et l’éteindre une fois les backups terminés,
• etc…

Cette installation, en plus du respect évident des trois lois de la robotique, se devait de ne pas négliger le WAF (Woman Acceptance Factor). En bref, une simplicité maximale d’utilisation et le moins d’aléas possible – Hors de question, pour la pérennité du projet,  que la TV s’éteigne par « accident » en plein dénouement d’un épisode des « Experts » , la série préférée de Maman…

1 – Une norme et du matériel,

Pour mener à bien ce projet, j’ai utilisé la technologie courant porteur X10… Un système qui n’est plus tout jeune (1975), mais qui a le mérite d’être simple à mettre en oeuvre, toujours fonctionnel et pas trop cher (enfin… tout est relatif).

Il existe deux principaux types de modules : les  contrôleurs et les récepteurs. Le système X10 utilise le réseau électrique existant pour diffuser des trames aux différents modules. Les trames sont structurées avec une partie adresse et une partie commande (ou ordre).

Une adresse X10 est composée :

• d’un code maison, sur 4 bits, de A à P,
• et d’un code appareil, sur 4 bits également,  de 1 à 16.

Comme nous sommes sur un principe de diffusion, nous pouvons configurer plusieurs modules avec la même adresse – tous les récepteurs voient passer les trames, mais n’exécutent l’ordre que si l’adresse leur correspond.

Ci-dessous, la liste non exhaustive des  ordres qui peuvent être transmis :

• Marche (ON), Arrêt (OFF),
• Variation croissante (BRIGHT + Valeur), variation décroissante (DIM + Valeur),
• Toutes les lumières allumées (ALL LIGHTS ON) ou éteintes (ALL LIGHTS OFF),
• Tout allumé, sans distinction du type d’appareil (ALL ON) ou tout éteint (ALL OFF).

Récepteurs (exemples) :

Les récepteurs, comme leur nom l’indique, vont être réceptifs aux ordres X10 pour effectuer l’action commandée. Le tableau ci-dessous présente quelques exemples de matériels :

	Module Appareil : Se connecte entre la prise et l'appareil. Est capable d'interpréter des ordres ON et OFF.
	Module lampe : Identique au module appareil, mais ne supporte pas des intensités élevées. Il est toutefois capable de gérer des commandes supplémentaires (DIM / BRIGHT) .
	Module lampe (douille) : S'insère entre l'ampoule et la douille d'origine.
	Module mural : remplace un interrupteur. Existe en version variateur ou 3 positions pour volets roulants ou stores.
	Micro module : se positionne derrière un interrupteur existant (dans la boite d'encastrement).
	Module rackable : Prend place directement au niveau du tableau électrique.

Contrôleurs (exemples) :

Les contrôleurs sont capables de générer des trames X10 sur le réseau.

	Le CM11 est le module indispensable. Connecté au port série ou usb d'un ordinateur, il va nous permettre de communiquer avec le réseau X10. Il est capable de recevoir ou d'envoyer des trames X10. Il est programmable, pour un fonctionnement ordinateur éteint. Ce modèle est apparemment obsolète et remplacé par le CM15.
	Le module radio permet de transformer des ordres RF, émis depuis une télécommande ou un capteur sans fil en ordre X10.
	Un exemple de détecteur sans fil. Il joue le rôle de détecteur de présence, mais aussi d'obscurité.
	Centrale d'alarme X10 capable de générer des ordres X10 en fonction d'évènements : Armement, désarmement, déclenchement, etc... Elle peut également servir de console de commande X10.

2 – Des logiciels,

MisterHouse

MisterHouse est probablement le projet le plus complet de domotique libre.

• Il supporte des matériels allant bien au-delà du X10,
• Est capable d’exécuter des actions basées sur de la reconnaissance vocale, des évènements horaires, réseaux, matériels, etc…,
• Dispose d’une interface web,
• Couplé à un magnétoscope numérique (VCR), permet la programmation d’enregistrements,
• S’interface avec les mails, le téléphone,
• Gère des caméras de surveillance,
• Produit de la synthèse vocale,
• etc…etc…etc…

Bref, du lourd, du trop lourd pour un démarrage en douceur… Je voulais bricoler avec mes petites mimines et là, c’était vraiment trop d’un coup…

ControlX1O::CM11

ControlX10::CM11 est la librairie Perl MisterHouse utilise pour la gestion du X10. Elle est relativement facile à utiliser.  Je m’en suis servi pour coder un petit utilitaire, « TuX10« , qui permettait de gérer des modules X10, d’envoyer et recevoir des trames, le tout en ligne de commandes. Après avoir « pissé » un bon nombre de lignes et mon programme quasi finalisé, j’ai découvert « Heyu« , qui fait la même chose….Mais en mieux… Ce n’est pas grave, un peu de code aide souvent à comprendre pas mal de choses…

Heyu

Heyu est donc un utilitaire, qui fait la même chose que TuX10, mais en mieux

Ils s’utilise, dans un usage courant, de la façon suivante :

# heyu <Commande> <Module>

Par exemple, dans l’hypothèse ou la lumière de mon salon est adressé « A1″,

Pour l’allumer :

# heyu ON A1

Pour l’éteindre :

# heyu OFF A1

Pour l’allumer avec un variation à 50% (le niveau doit être donné entre 1 et 22) :

# heyu DIMB A1 11

C’est très pratique pour allumer un appareil à heure fixe à l’aide d’un simple cron…

Exemple : allumage de mon serveur de sauvegardes, qui porte l’adresse « C1″, tous les jours à 23H00 :

# CRONTAB
00   23   *    *    *   /usr/local/bin/heyu ON C1

Heyu dispose d’une multitude de commandes et d’options. Nous en verrons quelques unes dans la suite, pour le reste :

# heyu help

ou de façon plus classique :

# man heyu

3 – Un scénario,

Les modes de fonctionnement

J’ai imaginé trois modes de fonctionnement , en fonction de ma présence et de mon activité dans la maison : Les modes « présence », « sommeil » et « absence ».

Le mode « Présence »

C’est le mode de fonctionnement normal, quand je suis à la maison.

• Il est déclenché par l’arrêt de l’alarme ou un signal de réveil,
• Tous les appareils sont sous tension (TV, Hifi, matériel informatique, etc…),
• Les volets sont ouverts,
• La lumière du séjour s’allume automatiquement quand la nuit tombe et s’éteint quand le jour se lève – classe !

Le mode « Sommeil »

Ce mode est actif pendant la nuit, quand je dors…

• Activé manuellement via une télécommande ou la console (Signal Réveil OFF),
• Les appareils ne sont plus alimentés,
• Les volets fermés,
• Les lumières éteintes,
• La lumière du séjour/cuisine s’allume à 50% quand une présence est détectée :  Juste ce qu’il faut pour y voir suffisamment lors des excursions nocturnes près du frigo. Cette attention permet de ne pas être éblouis et de reprendre tranquillement sa nuit après le casse-croute… c’est important !
• Ce mode peut-être désactivé par un signal de réveil manuel ou automatique, pour passer en mode « Présence » (Signal Réveil ON).
• Le passage en mode « présence » est déclenché automatiquement tous les jours de la semaine à 6h30, pour bénéficier d’un doux réveil à la lumière du jour. ( Nda : Penser à ajouter un mode « vacances »…c’est tôt 6h30 quand on est en RTT !)

Le mode « Absence »

• Déclenché par la mise en marche de l’alarme,
• Identique au mode précédent, mais le seul ordre X10 pris en compte est l’arrêt de l’alarme pour le passage en mode « Présence ».

En clair, on attend juste que l’alarme soit désactivée.

4 – Et du bricolage…

Cher lecteur, si tu as tenu jusque là, c’est le moment où nous allons mettre les mains dans le cambouis… L’expression est d’usage, mais c’est plutôt dans le placo que se logent les petits bidules X10… Mais ne nous égarons pas….

Commençons par un petit état de ces différents bidules équipant la maison.

Les éléments X10 utilisés et leur adresse :

Configuration générale :

Ma première idée était de charger la totalité des règles et des macros dans le CM11, pour que le système puisse fonctionner de façon autonome, y compris quand l’ordinateur est éteint. Cependant, j’ai vite changé d’avis… La rom du CM11 est d’une taille plutôt limité et on s’arrache vite les cheveux à gérer des tests qui disparaissent en segmentant un peu les choses. Comme de toute façon, l’ordinateur n’est jamais éteint, j’ai fini par utiliser un fichier de macros par mode. Le bon fichier est uploadé lors d’un changement d’état.

Attaquons la configuration de base de heyu. Le fichier /etc/heyu/x10.conf permet de spécifier le port à utiliser pour l’accès au CM11, un code maison par défaut, de déclarer des alias pour les modules (ce n’est pas obligatoire) et enfin d’affecter l’exécution de scripts à des évènements.

# /etc/heyu/x10.conf - Fichier de configuration HEYU
 
# Port série à utiliser :
TTY  /dev/ttyS0
 
# Code maison par défaut
HOUSECODE A
 
# Fichier de LOGs
LOG_DIR /var/log/
 
# Nom du fichier contenant les macros à uploader
SCHEDULE_FILE x10.sched

Le système est capable de calculer les heures de couché et de levé du soleil en fonction de la date et de la position géographique.

# Nombre de jours à calculer
PROGRAM_DAYS           366
 
# Position Géographique
LONGITUDE   E1:30
LATITUDE     N43:30
 
# Mode de calcul
DAWN_OPTION FIRST
DUSK_OPTION  FIRST

Il est également possible de définir des alias…

# ALIAS
 
ALIAS  lampe_sejour       A1   StdLM
ALIAS  halogene           A2   StdLM
ALIAS  test1              A3   StdAM
ALIAS  test2              A4   StdAM
ALIAS  hifi               A5   StdAM
 
ALIAS  vr_jour            A7   shutter
ALIAS  vr_nuit            A8   shutter
ALIAS  vr                 A7,8
 
ALIAS  inter_reveil       A9
 
ALIAS  mvt_bureau         A10
ALIAS  obs_bureau         A11
ALIAS  mvt_sejour         A12
ALIAS  obs_sejour         A13
 
ALIAS   nuit              B1
ALIAS   alarme            B3
 
ALIAS  sauvegarde         C1    StdAM
 
ALIAS   mode_nuit         D1

Exécution de scripts sur évènement X10.

Quand l’ordre « D1 ON », qui signale la tombé de la nuit est détecté sur le réseau, on crée un fichier sur le système, qui permettra de détecter simplement s’il fait nuit ou pas… Ce flag est positionné quelque-soit le mode de fonctionnement.

# Gestion du mode nuit
SCRIPT D1 on anysrc ::  touch /var/tux10/NUIT
SCRIPT D1 off anysrc ::  rm -f /var/tux10/NUIT

De la même façon, l’ordre « A9 OFF » indique que l’on souhaite passer en mode « sommeil », « B3 ON » en mode « Absence » et « B3 OFF » ou « A9 ON » en mode présence.

# Gestion du mode sommeil
SCRIPT A9 off anysrc :: /home/heyu/mode_sommeil.sh
SCRIPT A9 on anysrc :: /home/heyu/mode_presence.sh
 
# Gestion du mode absence (alarme)
SCRIPT B3 on anysrc :: /home/heyu/mode_absence.sh
SCRIPT B3 off anysrc :: /home/heyu/mode_presence.sh

Toujours à l’heure…

Pour que tout fonctionne parfaitement, il faut s’assurer que l’horloge du CM11 est bien à l’heure… Une nouvelle entrée dans la crontab va effectuer une remise à l’heure régulière grâce à la commande « setclock » d’heyu

# CRONTAB
 
00   23   *    *    *   /usr/local/bin/heyu ON C1
00  */6   *    *    *  /usr/local/bin/heyu setclock

Le mode « présence »

Comme nous l’avons vu, ce mode est déclenché soit par désactivation de l’alarme (B3 OFF), soit par un signal de réveil (A9 ON).

Sur l’un de ces évènements, Heyu a été précédemment configuré pour lancer le script « mode_presence.sh« .
Ce dernier envoie les ordres d’ouverture des volets, de mise sous tension des appareils, allume la lumière s’il fait nuit et charge les macros de présence dans la rom du CM11.

mode_presence.sh

#!/bin/bash
# mode_presence.sh
 
# Ouverture des volets, mise sous tensions des appareils
/usr/local/bin/heyu on A4,5,7,8
 
# Allumer la lumière, si necessaire
if [ -e /var/tux10/NUIT ]; then
   /usr/local/bin/heyu on A1
fi
 
# Upload des macros si nécessaire
cmp -s /etc/heyu/x10.sched.presence /etc/heyu/x10.sched
if [ !$? -eq 0 ]; then
    cp /etc/heyu/x10.sched.presence /etc/heyu.x10.sched
    /usr/local/bin/heyu upload
fi

Au niveau des macros, on va juste définir un timer qui gère l’allumage et l’extinction automatique des lumières en fonction du jour et de la nuit.

/etc/heyu/x10.sched.presence

# x10.sched.presence
 
# Définition d'un timer tous les jours.
# Lance la macro lum_off à l'aurore,
# La macro lum_on 10 minutes avant le crépuscule.
timer smtwtfs 01/01-12/31 dawn dusk-10 lum_off lum_on
 
# Macro lum_on - Envoie les ordres A1 ON et D1 ON
macro lum_on 0 on a1; on d1
 
# Macro lum_off - Envoie les ordres A1 OFF et D1 OFF
macro lum_off 0 off a1; off d1

Le mode « absence »

Ce mode est déclenché par l’activation de l’alarme uniquement (B3 ON)

Heyu est configuré pour exécuter  le script « mode_absence.sh » lorsque le mode est activé.
Le script envoi les ordres de fermeture des volets, de mise hors tension des appareils, éteint les lumières et charge les macros d’absence.

mode_absence.sh

#!/bin/bash
# mode_absence.sh
 
# Fermeture des volets, mise hors tensions des appareils et de l'éclairage
/usr/local/bin/heyu on A1,2,4,5,7,8
 
# Upload des macros si nécessaire
cmp -s /etc/heyu/x10.sched.absence /etc/heyu/x10.sched
if [ !$? -eq 0 ]; then
    cp /etc/heyu/x10.sched.absence /etc/heyu.x10.sched
    /usr/local/bin/heyu upload
fi

Les macros et timers sont  sensiblement identiques à l’étape précédente. Nous n’allons gérer que le « flag » D1 indiquant au système s’il fait jour ou nuit – Inutile d’allumer les lumières s’il n’y a personne à la maison.

/etc/heyu/x10.sched.absence

# x10.sched.presence
 
# Définition d'un timer tous les jours.
# Lance la macro lum_off à l'aurore,
# La macro lum_on 10 minutes avant le crépuscule.
timer smtwtfs 01/01-12/31 dawn dusk-10 lum_off lum_on
 
# Macro lum_on - Envoi l'ordre D1 ON
macro lum_on 0 on d1
 
# Macro lum_off - Envoi l'ordre D1 OFF
macro lum_off 0 off d1

Le mode « sommeil »

Ce mode est déclenché par l’envoi de « A9 OFF« .

Heyu est configuré pour exécuter « mode_sommeil.sh » lors de l’entrée dans ce mode.

Le script ferme les volets roulants, coupe l’alimentation des divers appareils et éteint les lumières. Les macros « embarqués » s’occupent de l’éclairage interactif du séjour (présence près du frigo) et du réveil.

mode_sommeil.sh

# mode_sommeil.sh
 
# Fermeture des volets, mise hors tensions des appareils et de l'éclairage
/usr/local/bin/heyu on A1,2,4,5,7,8
 
# Upload des macros si nécessaire
cmp -s /etc/heyu/x10.sched.sommeil /etc/heyu/x10.sched
if [ !$? -eq 0 ]; then
    cp /etc/heyu/x10.sched.sommeil /etc/heyu.x10.sched
    /usr/local/bin/heyu upload
fi

/etc/heyu/x10.sched.sommeil

# x10.sched.sommeil
 
# Le fameux Timer qui réveille...
# Du lundi au vendredi à 6h30
# passage en mode présence
timer .mtwtf. 01/01-12/31 6:30 00:00 reveil null
# Macro réveil
macro reveil 0 on a9
 
# Ici aussi, on trace la tombée de la nuit
# et le levé du jour
timer smtwtfs 01/01-12/31 dawn dusk-10 night_off night_on
macro night_on 0 on d1
macro night_off 0 off d1
 
# Enfin, la lumière pour le casse croute..
# A12 ON : Détection d'une présence
# A12 OFF : Tout est à nouveau calme
trigger a12 on lum_on
trigger a12 off lum_off
 
# Macro lum_off
macro lum_off 0 off a1
 
# Macro lum_on : Allume la lumière à 50 %
macro lum_on 0 dimb a1 11

5 – En conclusion

Le système tel qui est décrit est fonctionnel depuis quelques années. Il faut savoir que la technologie X10 n’est pas très réactive – il peut se passer quelques secondes avant qu’un appareil réagisse à un ordre, en particulier quand l’installation prend de l’importance et que plusieurs ordres sont transmis à la suite…

J’espère que ce billet apportera des informations utiles à tous ceux qui voudraient se lancer dans une aventure « domotique ».

Liens :

• X10 sur wikipedia,
• Intellihome.be : Fournisseur de modules X10,
• MisterHouse (sourceforge),
• ControlX10::CM11 (librairie Perl),
• Heyu

Pour reprendre la définition de « Wikipedia » :

Le code QR ou QR Code (en anglais) est un code-barres en 2 dimensions (code matrice) pouvant stocker jusqu’à 7089 caractères numériques, 4296 caractères alphanumériques (contrairement au code-barre « traditionnel » qui lui ne peut stocker que de 10 à 13 caractères) ou 2953 octets . Il a l’avantage de pouvoir stocker beaucoup d’informations tout en étant petit et rapide à scanner. Ainsi, le sigle « QR » dérive de « Quick Response » car le contenu peut être décodé rapidement.

Ce type de code, par sa capacité, permet de « stocker » un petit texte, une adresse e-mail, une url, un numéro de téléphone ou encore une vcard complète. Il présente l’intérêt de pouvoir être interprété rapidement à partir d’un PDA ou d’un téléphone, bien sûr munis d’un appareil photo et d’une petite application permettant le décodage. Le contenu, en fonction de son type, peut être, ensuite, traité directement par l’appareil : pointage du navigateur vers l’url, création d’un nouvel email,  import de la vcard dans le carnet d’adresses, etc… Un concept qui ravie les adeptes de gadgets mobiles, en permettant, en un shoot, la saisie d’adresses ou d’url, pas toujours très pratique, voir fastidieuse sur ce genre d’appareil.

Application "Barcode scanner" sur un téléphone Androïd (HTC Hero)

Pour créer son propre QR Code, il existe de nombreux générateurs en ligne, en voici quelques uns, la liste est loin d’être exhaustive :

• http://qrcode.kaywa.com,
• http://www.snapmaze.com,
• http://zxing.appspot.com/generator.

Comme pour les codes barres classiques (1 dimension), ce qui va m’intéresser, c’est bien entendu de pouvoir les générer en local… et si possible en lignes de commandes ( eh oui ! Encore !).

Il existe un petit programme qui fait ça très bien et qui se nomme judicieusement : qrencode.

qrencode est intégré dans la majeure partie des distributions, si ce n’était pas votre cas, vous pouvez toujours télécharger les sources sur le site officiel.

Ce petit outil permet de générer une image au format png, à partir d’une ou plusieurs chaînes de caractères.

$ qrencode --help
qrencode version 3.0.3
Copyright (C) 2006, 2007, 2008 Kentaro Fukuchi
Usage: qrencode [OPTION]... [STRING]
Encode input data in a QR Code and save as a PNG image.
 
-h           display this message.
--help       display the usage of long options.
-o FILENAME  write PNG image to FILENAME. If '-' is specified, the result
will be output to standard output. If -S is given, structured
symbols are written to FILENAME-01.png, FILENAME-02.png, ...;
if specified, remove a trailing '.png' from FILENAME.
-s NUMBER    specify the size of dot (pixel). (default=3)
-l {LMQH}    specify error collectin level from L (lowest) to H (highest).
(default=L)
-v NUMBER    specify the version of the symbol. (default=auto)
-m NUMBER    specify the width of margin. (default=4)
-S           make structured symbols. Version must be specified.
-k           assume that the input text contains kanji (shift-jis).
-c           encode lower-case alphabet characters in 8-bit mode. (default)
-i           ignore case distinctions and use only upper-case characters.
-8           encode entire data in 8-bit mode. -k, -c and -i will be ignored.
-V           display the version number and copyrights of the qrencode.
[STRING]     input data. If it is not specified, data will be taken from
standard input.

La plupart des paramètres disposent d’une valeur par défaut, ce qui simplifie la mise en œuvre pour une utilisation « classique ». Il suffit de préciser le nom de fichier en sortie et le contenu à encoder.

$ qrencode -o test1.png « http://www.jopa.fr »
$ qrencore -o test2.png < test.txt

Pour en savoir plus :

• QR-code ? Clovis Darrigan répond,
• Wikipedia,
• QrEncode,

Sur ce site, tu vas apprendre à construire une borne d’arcade en 6 mois. Les esprits chagrins diront que 6 mois, c’est très long.
Effectivement, c’est très long, surtout qu’on peut construire une borne d’arcade en 24 heures.
Seulement voilà, je suis assez mauvais en bricolage, d’où les 6 mois
Je remercie au passage l’auteur du site ci-dessus, sur lequel je me suis basé pour construire la borne.
Ce site est donc fait pour toi, qui possèdes à peu près le même niveau que moi en bricolage, c’est à dire un niveau 0 sur une échelle de 10.

Pour la leçon de bricolage, c’est par là !

]]> http://www.jopa.fr/index.php/2009/08/17/construire-sa-borne-darcade-en-6-mois/feed/ 3 http://www.jopa.fr/index.php/2009/07/16/linux-pam-et-mirror-une-authentification-rfid/ http://www.jopa.fr/index.php/2009/07/16/linux-pam-et-mirror-une-authentification-rfid/#comments Wed, 15 Jul 2009 23:10:03 +0000 Jopa http://www.jopa.fr/?p=1461 Cette pluvieuse journée du 14 juillet m’a permis de poursuivre mes petits travaux sur le lecteur rfid « Mir:ror ». Dans les articles précédents, je me suis surtout intéressé au déclenchement d’événements en fonction des puces rfid détectées (ou pas) par le lecteur, oubliant l’essence même du RFID : l’authentification. J’ai donc profité de ce temps à ne pas mettre mon chat dehors pour écrire un module PAM (Pluggable Authentification Module) permettant d’authentifier un utilisateur via le Mir:ror.

L’idée est simple : si mon Mir:ror est connecté à l’ordinateur et qu’un fichier contenant mon rfid est présent dans mon répertoire, je veux pouvoir ouvrir ma session à l’aide d’une puce RFID (carte, badge, ztamp:s, laaaaapin…) à la place de saisir mon mot de passe.

Je ne vais pas m’attarder ici à décrire la manière dont est codé le module, je vous laisse le soin de lire les sources… Je vais me contenter d’expliquer son installation et son utilisation.

Mise en garde :

Pour plusieurs raisons dont la simplification du module et mes piètres talents de développeur, il va sans dire que ce petit programme ne doit pas être utilisé en environnement sécurisé. Par contre, pour la maison, c’est plutôt fun !

Nous touchons ici à une partie sensible du système : l’authentification. Les manipulations ci-dessous sont donc à réaliser avec prudence.

Compilation :

Pour pouvoir compiler pam_mir-ror, il nous faut installer un version récente de la librairie de développement pam (libpam-dev). J’ai utilisé la version 1.0.1 proposée par défaut sous Debian Lenny.

$ sudo aptitude install libpam-dev

L’archive contenant les sources est téléchargeable ci-dessous :

• pam_mir-ror.0.2.tar.gz

Une fois téléchargée, il faut la décompresser et tout simplement lancer la commande « make ».

$ tar -xvzf pam_mir-ror.0.2.tar.gz
$ cd pam_mir-ror.0.2
$ make

Si tout se passe bien, nous devrions obtenir deux binaires :

• read_mir-ror : Un petit outil permettant la lecture à partir du Mir:ror,
• pam_mir-ror.so : Le module pam.

read_mir-ror

Le petit outil read_mir-ror va nous permettre de tester le lecteur. Il suffit de l’exécuter et d’approcher une puce rfid.

$ sudo ./read_mirror
0000D0081A025303420200D2

La série de chiffres affichée n’est rien d’autre que l’ID de l’objet détecté.

Il est préférable d’utiliser read_mirror avec les droits root, au moins la première fois, pour l’accès au périphérique mir:ror. Par défaut, le mir:ror n’est accessible que par root. Les droits du handler sont changés à la première utilisation de la fonction de détection (inclue dans l’outil et le module). Il serait certainement plus propre de coder un petit outil qui serait automatiquement lancé par udev ou hotplug au branchement du Mir:ror, mais pour un module PAM, ce n’est pas très important.

Génération du fichier utilisateur

Le même outil (read_mir-ror), va nous permettre de générer le fichier .authtag contenant le rfid propre à chaque utilisateur :

Pour l’utilisateur courant :

$ sudo ./read_mirror > ~/.authtag
$ sudo chmod 400 ~/.authtag

Pour un autre utilisateur  (toto):

$ sudo ./read_mirror > /home/toto/.authtag
$ sudo chmod 400 /home/toto/.authtag

Il faut bien entendu présenter la puce au lecteur juste après la commande ./read_mirror.
Le fichier .authtag doit maintenant contenir le tag :

$ cat ~/.authtag
0000D0081A025303420200D2

Module PAM  :  pam_mir:ror.so

Pour qu’il soit utilisable par PAM, il faut que pam_mir:ror.so soit présent dans /lib/security (lib64/security pour une architecture 64 bits)

$ sudo cp pam_mir-ror.so /lib/security

ou pour un module 64 bits :

$ sudo cp pam_mir-ror.so /lib64/security

La dernière étape va être l’ajout du module à PAM. Pour cela, il nous faut éditer le fichier :
/etc/pam.d/common-auth pour y ajouter, avant les modules pam_unix.so ou pam_unix2.so :

auth             sufficient         pam_mir-ror.so

/etc/pam.d/common-auth

#
# /etc/pam.d/common-auth - authentication settings common to all services
...
auth    sufficient                      pam_mir-ror.so
# here are the per-package modules (the "Primary" block)
auth    [success=1 default=ignore]      pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

Avant de rebooter frénétiquement la machine pour voir ce que ça peut donner avec gdm,  je conseille vivement de tester sur une console (crtl-alt-F1 par exemple)… Comme expliqué en début d’article, nous touchons ici à une partie sensible du système et c’est mieux de garder la main pour éviter des pirouettes telles qu’un redémarrage en single user ou à partir d’un liveCD pour réparer.

J’ai fait en sorte que le module loggue un minimum. En fonction du système, ces logs sont visibles dans /var/log/auth.log ou /var/log/syslog.

Dernière version des sources : pam_mir-ror.0.2.tar.gz

]]> http://www.jopa.fr/index.php/2009/07/16/linux-pam-et-mirror-une-authentification-rfid/feed/ 11 http://www.jopa.fr/index.php/2009/07/12/violet-mirror-acces-device-c/ http://www.jopa.fr/index.php/2009/07/12/violet-mirror-acces-device-c/#comments Sun, 12 Jul 2009 00:22:12 +0000 Jopa http://www.jopa.fr/?p=1415 Dans mon précédent article, je présentais mir:ror, le petit lecteur RFID commercialisé par la société Violet.  Après avoir survolé leur application « Mirware » et mis en évidence les limites de son utilisation, je vais mettre « les mains dans le cambouis » pour essayer de comprendre comment communiquer avec Mir:ror.  L’idée étant de pouvoir coder de petits outils capables de réagir à des tags RFID.

D’un point de vu système, Mir:ror est directement reconnu sous Linux et accessible via le handler de périphérique /dev/hidrawX (où X est le numéro de périphérique, normalement « 0″ si c’est le premier appareil du genre connecté).

La petite application « discover-device« , fournie avec Mirware, permet de le détecter automatiquement :

Attention tout de même aux droits, le périphérique n’est par défaut accessible que par root, il faudra lui changer les droits ou utiliser le script « installer.sh » pour le faire, avant de pouvoir l’exploiter avec un utilisateur standard.

Commençons par voir ce qu’il se passe avec un simple « cat » du fichier :

Des hiéroglyphes s’affichent lorsque nous approchons ou retirons un tag… C’est plutôt bon signe, et visiblement c’est binaire ! Nous devrions y voir plus clair avec un affichage en hexadécimal.  Hexdump est idéal pour ça !

La première ligne (0000 0000 0000 0000 0000 0000 0000 0000 *) nous indique que tant qu’il ne se passe rien, on lit des zéros… Où…Qu’on lit des zéros tant qu’il ne se passe rien ! (c’est plutôt normal).
Les deux lignes suivantes (0102 0000 d008 1a02 5303 4202 00d2 0000 – 0000 0000 0000 0000 0000 0000 0000 0000) s’affichent lorsqu’un tag est approché, les deux dernières ( 0202 0000 d008 1a02 5303 4202 00d2 0000 – 0000 0000 0000 0000 0000 0000 0000 0000 ) lorsqu’on éloigne le tag.

Après plusieurs tests, j’en déduis assez facilement que les deux premiers octets (0102 ou 0202) codent l’évènement. J’en ai repéré 4 types :

• 0×0102 : Tag rfid détecté,
• 0×0202 : Tag rfid retiré,
• 0×0501 : Le mir:ror est mis à l’envert,
• 0×0401 : Le mir:ror est remis à l’endroit.

Les 12 octets suivants semblent identifier la puce RFID.

A titre de test, écrivons rapidement un petit bout de code C, prenant le device en paramètre et affichant les évènements et le tag associé :

// Jopa - Petit test du Mir:ror : test_mirror.c
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[]) {
  FILE *mirror;
  short unsigned int block;
  short unsigned int event;
  char tag[25];
  int i;
 
  //Vérification du paramètre (device)
  if (argc!=2) {
        printf ("Usage : %s mirror_device \n\n",argv[0]);
        exit(-1);
  }
 
  // Ouverture du fichier device
  mirror = fopen(argv[1],"rb");
  if (!mirror) {
        printf("Accès à  %s impossible !\n",argv[1]);
        exit(-1);
  }
 
  // Boucle en lecture
  while (1) {
     fread(&event,2,1,mirror);
     if (event!=0) {
        // Evenement detecté, lecture de l'ID
        for (i=0;i<6;i++) {
            fread(&block,2,1,mirror);
            sprintf(&tag[i*4],"%04X",block);
        }
 
 //Affichage en fonction de l'événement
        switch (event) {
            // Tag On
            case 0x102 :
                printf("%s : ON\n",tag);
                break;
 
             //Tag Off
             case 0x202 :
                 printf("%s : OFF\n",tag);
                 break;
 
             //Mirror envers
             case 0x501 :
                 printf("MIR:ROR ENVERS\n");
                 break;
 
             //Mirror endroit
             case 0x401 :
                   printf("MIR:ROR ENDROIT\n");
                    break;
 
             //Default
             default :
                   printf("Evénement inconnu\n");
        } //switch
      } //if (event
   } //while (1)
} // main()

En quelques lignes, nous ouvrons le périphérique dont le handler est passé en paramètre et bouclons sur sa lecture, 2 octets par 2 octets.
Quand autre chose que « 0″ est détecté, c’est forcément un changement d’état. Nous lisons ensuite l’identifiant de la puce RFID.
La dernière partie affiche un message en fonction de l’évènement détecté.

Il ne reste plus qu’à le compiler et le tester :
$ gcc test_mirror.c -o test_mirror
$ ./test_mirror

Pour compléter l’exemple, nous pouvons rajouter l’exécution d’un script associé au tag et à son approche ou son éloignement. Les scripts pourraient être stockés dans le répertoire de l’utilisateur et porter l’<id>-on.sh ou l’<id>-off.sh comme nom. Pour l’exemple :

• 0000D0081A025303420200D2-on.sh : Lancement de Firefox sur le blog de Jopa

#!/bin/sh
firefox http://www.jopa.fr

• 0000D0081A025303420200D2-off.sh : Lancement de Thunderbird

#!/bin/sh
thunderbird

$ chmod +x ~/0000D0081A025303420200D2-*.sh

Adaptons un peu le code en ajoutant une variable pour le nom du script et une commande « system » dans le « switch/case ».

   // Jopa - Test Mir:ror
 
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[]) {
  FILE *mirror;
  short unsigned int block;
  short unsigned int event;
  char tag[25];
  // Ajout d'un variable script
  char script[256];
  int i;
 
  //Vérification du paramètre (device)
  if (argc!=2) {
        printf ("Usage : %s mirror_device \n\n",argv[0]);
        exit(-1);
  }
 
  // Ouverture du fichier device
  mirror = fopen(argv[1],"rb");
  if (!mirror) {
        printf("Accès à  %s impossible !\n",argv[1]);
        exit(-1);
  }
 
  // Boucle en lecture
  while (1) {
     fread(&event,2,1,mirror);
     if (event!=0) {
        // Evenement detecté, lecture de l'ID
        for (i=0;i<6;i++) {
            fread(&block,2,1,mirror);
            sprintf(&tag[i*4],"%04X",block);
        }
 
 //Affichage en fonction de l'événement
        switch (event) {
            // Tag On
            case 0x102 :
                printf("%s : ON\n",tag);
                //Construction du nom de script et exécution
                sprintf(script,"./%s-on.sh",tag);
                system(script);
                break;
 
             //Tag Off
             case 0x202 :
                 printf("%s : OFF\n",tag);
                 //Construction du nom de script et exécution
                 sprintf(script,"./%s-off.sh",tag);
                 system(script);
                 break;
 
             //Mirror envers
             case 0x501 :
                 printf("MIR:ROR ENVERS\n");
                 break;
 
             //Mirror endroit
             case 0x401 :
                   printf("MIR:ROR ENDROIT\n");
                    break;
 
             //Default
             default :
                   printf("Evénement inconnu");
        } //switch
      } //if (event
   } //while (1)
} // main()

Ceci n’est bien entendu qu’un exemple, écrit rapidement et pas forcément très propre. Mais il permet de mettre en évidence la simplicité avec laquelle il est possible d’accéder à des informations RFID et ouvre la porte sur des développements qui peuvent être rapidement prometteurs.

Question coût, le mir:ror se trouve un peu partout pour un 50ène d’euros. J’ai déniché le mien en solde pour moins de 30 € – Tu vois chérie, moi aussi le fais les soldes  !!! – Dans un joli coffret, sont rangés le lecteur usb, 3 « timbres » autocollants (Ztamp:s) et 2 petits lapins (Nano:Ztag), tous munis d’une puce RFID.

Le lecteur fonctionne biensûr avec les objets commercialisés par Violet, mais aussi avec n’importe quel tags RFID, pourvu qu’il  respecte la norme ISO 14443 A ou B – La carte de bus/métro de Toulouse fonctionne parfaitement par exemple.

En utilisation standard, moyennant l’installation d’un petit logiciel (Mirware) et la création d’un compte (gratuit) sur le site de Violet, nous pourrons enregistrer nos objets RFID et associer une action à leur approche ou leur éloignement du lecteur.

Après tout ce vocabulaire « Nabaztanique« , il faut bien que j’avoue que ce n’est pas pour son utilisation standard que j’ai craqué, mais pour  les  perspectives prometteuses  offertes en terme de bidouillage : Authentification pam, évènements domotiques (X10), clef de chiffrement, on peut imaginer énormément d’usages « non-officiels » … et c’est ça qui est bon !

Néanmoins, dans la suite du billet, je vais balayer une installation classique du « Mirware » sous Linux. Il faut bien commencer par là ! Cette manipulation ne présente pas de difficulté particulière, à part peut-être pour les architectures 64 bits. Dans un prochain article, je m’intéresserai au développements possibles autour du joujou !

Mirware mon beau Mirware…

J’ai réalisé ce test sur deux machines sous Ubuntu (9.04 « Jaunty jackalope » ), l’une en 32 bits, l’autre en 64. Mais Mirware devrait fonctionner sous n’importe quelle distribution, le tout étant de bien installer les librairies nécessaires.

Dans les pré-requis, il faut bien entendu une machine sous Linux, disposant d’une interface graphique et connectée à Internet. En effet, Mirware fonctionne grâce au serveur Violet.net, sur lequel seront enregistrés les tags et les actions qui leurs sont associées.  C’est un peu limitant, mais comment dire….c’est comme ça ! Domage !

L’application est disponible ici en version alpha… On regrettera l’absence des sources, mis à part pour la partie concernant la détection du périphérique, ce qui va sauver l’installation sur une distribution 64 bits.

Je parlais de librairies, il nous faudra satisfaire quelques dépendances à ce sujet et en installer 3 principales :

• Qt 4.4 avec le module webkit,
• QCA 2.0.1,
• SDL 1.2

(cf le README pour plus d’infos)

$ sudo apt-get install   libqt4-webkit   libqca2   libsdl1.2debian

Nous pouvons à présent télécharger et installer le Mirware :

$ wget -c http://broad.violet.net/mirror/mirware.tar.gz
$ tar -xvzf mirware.tar.gz
$ cd mirware-0.9.9-1724
$ sudo ./installer.sh

Le script installer.sh, présent dans l’archive de Mirware, va juste caler les droits pour la détection du périphérique :

installer.sh ( pour information uniquement)

#!/bin/bash
[ "$(id -u)" -eq 0 ] || { echo "This script needs root credentials" ; exit 1 ; }
chown root discover-device || { echo "Could not change owner of discover-device to root. Do you have root credentials ?" ; exit 1 ; }
chmod a+s discover-device || exit 1
touch detected_device
 
echo "All done ! You can now plug a mir:ror and launch mirware-launcher.sh !"

Il ne reste plus qu’à connecter le mir:ror et  lancer mirware :

$ ./mirware-launcher.sh

Une icône dans la barre de notification indique que tout se passe bien. En approchant un objet du capteur, une fenêtre de connexion devrait apparaître, suivie d’un interface permettant d’enregistrer l’objet et de lui associer des actions (applications).

32 bits…C’est bien…mais 64 ?

Si vous utilisez une distribution 64 bits, il vous faudra recompiler le petit programme de détection du mir:ror : discover-device et installer les librairies utilisées par Mirware dans leur version 32 bits. Sans les sources et en l’abscence de version 64 bits, pas le choix…

Concernant la compilation de discover-device, rien de bien sorcier, il faut juste ne pas oublier de lui redonner les bons droits…
$ sudo rm discover-device
$ gcc discover-device.c -o discover-device
$ sudo ./installer.sh

Pour les librairies 32 bits, après avoir pas mal joué de l’apt-get, je suis tombé sur un script qui simplifie bien les choses (merci Cappy). Getlibs prend en paramètre un binaire et télécharge les librairies dépendantes dans leurs versions 32 et 64 bits… Le pied !

$ wget -c http://frozenfox.freehostia.com/cappy/getlibs
$ ./getlibs mirware

Pour clore ce chapitre…

…sur une utilisation classique du mir:ror, je peux ajouter qu’une grande majorité des actions proposées par le serveur sont fonctionnelles sous Linux… L’ouverture d’un dossier, le chargement d’une url, l’accès à la messagerie, à un podcast ou une webradio, la lecture d’un texte en texttospeech et j’en passe…

J’ai tout de même noté un problème gênant sur l’application permettant le lancement de scripts;  En effet, cette dernière ne sait gérer que des scripts Windows/Dos batch (.bat) ou des AppleScripts(MacOsx). Ce n’est pas très gênant pour l’utilisation que je compte en faire et comme promis, je détaillerai, dans le prochain article comment s’affranchir des contraintes du serveur Violet.net pour passer de l’autre côté du mirroir.

]]> http://www.jopa.fr/index.php/2009/07/07/violet-mirror-linux/feed/ 9 http://www.jopa.fr/index.php/2009/05/26/airserv-aircrack-ng-fonera/ http://www.jopa.fr/index.php/2009/05/26/airserv-aircrack-ng-fonera/#comments Tue, 26 May 2009 20:30:54 +0000 Jopa http://www.jopa.fr/?p=1315  

Avec son chipset wifi Atheros supportant le mode monitor et l’injection de packets, sans oublier son connecteur SMA permettant de raccorder une antenne extérieure, la Fonera semble toute indiquée pour tester la sécurité de son réseau Wifi (j’ai bien dit « son » !).  D’autant plus que la suite aircrack-ng est disponible en paquet sous Kamikaze. Ce qui va inévitablement pêcher, c’est la puissance du CPU (Atheros AR2315) avec ses pauvres 183.5 BogoMIPS et éventuellement un léger problème de stockage – Quoique, la Fonéra 2 et son port usb permettent de facilement palier à ce manque de place.

Nous pouvons, bien sûr, bricoler une solution pour contourner le problème en enregistrant les dumps sur une partition réseau (nfs, smb, etc…) ou un  quelconque support usb. Le tout étant de faire tourner les outils gourmands en ressources  sur une autre machine. Ca fonctionne, mais ça reste du bon vieux bricolage…

Heureusement, les supermans et spidermans de la team aircrack-ng ont prévu une solution bien plus élégante… Dans ce cas précis, c’est par airserv-ng qu’ils vont briller de mille éclats.

- Au passage, merci à eux pour tous leurs outils robustes et fonctionnels ! -

Airserv-ng est un serveur de cartes wifi qui va permettre à de nombreuses applications (au moins celles de la suite aircrack-ng) d’utiliser la carte via une connexion TCP client-serveur.

Son utilisation est assez triviale, nous allons le voir dans un petit exemple.

1 – Pré-requis

Pour notre exemple, nous utiliserons :

• Une Fonera
  • installée sous OpenWrt Kamikaze (version 8.09),
  • aircrack-ng installé  (version 1.0 rc1 r1142 : opkg update && opkg install aircrack-ng),
  • l’interface ethernet configurée (192.168.1.1) :
  ^?View Code INI

  # /etc/config/network # Copyright (C) 2006 OpenWrt.org   config interface loopback option ifname lo option proto static option ipaddr 127.0.0.1 option netmask 255.0.0.0   config interface lan option ifname eth0 option proto static option ipaddr 192.168.1.1 option netmask 255.255.255.0

• l’interface wifi activée (/etc/config/wireless) :

# /etc/config/wireless
config wifi-device       wifi0
   option disabled           0
   option diversity          0
   option type           atheros
   option channel          auto
   option txantenna         1
   option rxantenna         1

• Un PC sous Debian Lenny
  • aircrack-ng installé ( apt-get update && apt-get install aircrack-ng ),
  • L’interface ethernet configurée (192.168.1.2) et connectée à la Fonera.

2 – Sur la fonera (le serveur)

Commençons par passer la carte en mode monitor :

root@OpenWrt:~# airmon-ng start wifi0

Interface       Chipset         Driver

wifi0           Atheros         madwifi-ng
ath0            Atheros         madwifi-ng VAP (parent: wifi0) (monitor mode enabled)

Et lançons airserv-ng :

root@OpenWrt:~# airserv-ng -d ath0
Opening card ath0
Setting chan 1
Opening sock port 666
Serving ath0 chan 1 on port 666

Par défaut, le port utilisé est le 666 et la carte wifi est positionnée sur le channel 1. Ces paramètres peuvent respectivement être changés par les options -p et -c.

3 – Sur la station (le client)

L’utilisation des outils sur le PC ne change que par le nom de l’interface wifi à utiliser. Il suffit tout simplement de préciser l’adresse IP du serveur, suivi du numéro de port TCP à la place du nom de l’interface :

192.168.1.1:666

Par exemple pour airodump-ng :

# airodump-ng 192.168.1.1:666
CH  4 ][ Elapsed: 32 s ][ 2009-02-06 06:30

BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

 00:18:84:A0:FC:ED   45       40        0    0  11  54e. WPA2 CCMP   PSK  wjopa2
 00:18:84:24:1E:7D   43       81        0    0   1  54e. OPN              FON_LINET
 00:18:84:24:1E:7E   41       96        0    0   1  54e. WPA  TKIP   PSK  LINET_PRIV
 00:1E:37:96:F8:27   14       57        0    0  10  54e  WPA  TKIP   PSK  Livebox-461a

 BSSID              STATION            PWR   Rate   Lost  Packets  Probe

4 – En conclusion…

L’intérêt d’un tel montage est, bien sûr, l’utilisation du matériel wifi dont est doté la Fonera, par une station qui en est dépourvu mais dispose d’un processeur bien plus performant. Outre c’est avantage, il n’est pas déplaisant de pouvoir transformer notre Fonera en sonde wifi, que nous pourrons connecter au plus près de notre point d’accès. Nous réaliserons ainsi nos tests, tranquillement, sans sortir du bureau et surtout, sans devoir répondre aux collègues qui se demandent pourquoi nous travaillons dans la cage d’escalier, un labtop sur les genoux… – Hum… Ils sont vraiment bizarres ces gars de l’info…-

En terminant cet article, j’imagine, qu’en bidouillant un minimum, nous pourrions nous affranchir du transformateur secteur de la Fonera en l’alimentant grâce à une batterie, de l’usb ou pourquoi pas,  depuis un switch POE.  Décidément, c’est vraiment un beau jouet cette Fonera !!!

Pourquoi ce modèle ? …Je ne sais pas, j’étais pressé, j’avais tombé mon précédent téléphone dans un torrent et l’eau fraiche et le choc l’ont « espouti » comme on dit à Toulouse.

Ce que je suis arrivé à faire après avoir perdu mon carnet d’adresses de la carte SIM, …et avoir bien failli passer sous Windows pour le récupérer  :

• le connecter sur mon microordiateur portable ASUS W5F sous Debian Lenny en USB:

• le connecter sur mon microordiateur portable ASUS W5F sous Debian Lenny en bluetooth:

Cela permet d’uploader ou downloader des photos, videos, musique, thèmes , ….

• le connecter sur mon ordinateur portable pour sauvegarder et recharger messages, carnet d’adresses etc …

• ressources qui m’ont aidé:

http://www.meeus-d.be/linux/bluetooth.html

http://www.thinkwiki.org/wiki/How_to_setup_Bluetooth

et beaucoup:

http://article.gmane.org/gmane.linux.bluez.devel/12155

http://article.gmane.org/gmane.linux.drivers.gnokii/10729/match=3600

Merci à eux

Connection bluetooth:

J’ai rédigé ceci à partir de ce que j’avais fait et mon bash_history , je n’ai pas retesté …. Il se peut (c’est sûr !) que j’ai oublié quelques éléments …

Je suppose que la carte bluetooth de l’ordinateur portable fonctionne:

# hciconfig

doit renvoyer quelque chose du type:

hci0:    Type: USB
BD Address: 00:17:31:09:95:1C ACL MTU: 384:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:937678 acl:55585 sco:0 events:2501 errors:0
TX bytes:8285 acl:287 sco:0 commands:77 errors:0

Installer les paquets ci dessous:

aptitude search bluez | grep ^i

i A bluez-audio                     - Support audio bluetooth
i A bluez-gnome                     - utilitaires Bluetooth pour GNOME
i A bluez-utils                     - outils et démons Bluetooth
i A python-bluez                    - Python wrappers around BlueZ for rapid b

aptitude search bluet | grep ^i
i   gnome-bluetooth                 - GNOME Bluetooth tools
i A libbluetooth2                   - Bibliothèque pour utiliser la pile BlueZ

 aptitude search obex | grep ^i

i A gnome-vfs-obexftp               - GNOME VFS module for OBEX FTP

i A libopenobex1                    - OBEX protocol library

i A obex-data-server                - D-Bus service for OBEX client and server s

i   obexfs                          - mount filesystem of ObexFTP capable device

i   obexftp                         - file transfer utility for devices that use

Dans /etc/default/bluetooth vérifier que:

BLUETOOTH_ENABLED=1

HID2HCI_ENABLED=1

HIDD_OPTIONS= »–master –server »

J’ai aussi:

DUND_ENABLED=1

DUND_OPTIONS= »–listen –persist »

Le paquet bluez-utils contient la commande hcitool

Allumer le tel portable et electionner Menu ->Paramètres->Connectivité->Bluetooth

et activer le bluetooth sur le tel portable

Si tout va bien:

hcitool scan

renvoie quelque chose comme:

Scanning ...
	00:21:AB:D9:75:25	Telbm

installer l2ping et en root:

#l2ping 00:21:AB:D9:75:25

Ping: 00:21:AB:D9:75:25 from 00:17:31:09:95:1C (data size 44) ...
0 bytes from 00:21:AB:D9:75:25 id 0 time 18.87ms
0 bytes from 00:21:AB:D9:75:25 id 1 time 37.94ms
0 bytes from 00:21:AB:D9:75:25 id 2 time 38.91ms
0 bytes from 00:21:AB:D9:75:25 id 3 time 35.91ms
0 bytes from 00:21:AB:D9:75:25 id 4 time 36.92ms
0 bytes from 00:21:AB:D9:75:25 id 5 time 26.92ms
0 bytes from 00:21:AB:D9:75:25 id 6 time 29.91ms
^C7 sent, 7 received, 0% loss

Dans /usr/share/doc/bluez-utils/examples/

décompresser passkey-agent.c.gz et le compiler

cd /usr/share/doc/bluez-utils/examples/
gunzip passkey-agent.c.gz
make

Lancer dans une fenêtre de terminal

./passkey-agent --default 0000

Editer dans un autre terminal /etc/bluetooth/hcid.conf et y mettre ceci:

options {
autoinit yes;
security auto;
pairing multi;

passkey "0000";
}
device {
name "asusBM";
class 0x3e0100;
iscan enable;
pscan enable;
lm accept;
lp rswitch,hold,sniff,park;
}

Relancer bluetooth

/etc/init.d/bluetooth restart

Dans un autre terminal lancer la commande :

obexftp -b 00:21:AB:D9:75:25 -l

Elle doit renvoyer quelque chose du genre:

# obexftp -b 00:21:AB:D9:75:25 -l
Browsing 00:21:AB:D9:75:25 ...
Channel: 10
Connecting...done
Receiving "(null)"...\<?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd"
 [ <!ATTLIST folder mem-type CDATA #IMPLIED> ]>
<folder-listing version="1.0">
    <folder name="Carte mémoire" user-perm="RW" mem-type="MMC"/>
    <folder name="Icônes" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Fichiers audio" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Thèmes" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Tonalités" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Clips vidéo" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Photos" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Enregistremts" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Fichiers reçus" created="20070101T000000" user-perm="R" mem-type="DEV"/>
</folder-listing>
done
Disconnecting...done

Autoriser le téléphone portable a se connecter automatiquement

Si oui c'est gagné, sinon ...

Il ne reste plus qu'a ouvrir le navigateur de fichiers et lui dire :

Aller à : obex://[00:21:AB:D9:75:25] (cf deuxième copie d'écran en haut de l'article)

connection USB

Pour accéder aux fichiers « généraux » (photos, vidéo, musique, ….

Au branchement du téléphone avec le câble USB il suffit de répondre « transfert de données » sur le tel portable.

Pour pouvoir accéder au carnet d’adresse, aux messages et au calendrier (pas testé ce dernier à ce jour) il faut installer xgnokii

aptitude install xgnokii

débrancher et rebrancher le cable USB et sur le téléphone répondre "PCSuite"

puis créer un fichier .gnokiirc

et y mettre:

[global]
port = /dev/ttyACM0
model = AT
initlength = default
connection = serial
use_locking = no
serial_baudrate = 19200
smsc_timeout = 10
[xgnokii]
allow_breakage = 0
[gnokiid]
bindir = /usr/sbin/

Lancer la commande

gnokii --monitor

qui doit renvoyer quelque chose du genre:

gnokiid Version 0.6.27

Entrée en mode surveillance...

Network: France Telecom, France (208 01)

LAC: 4302 (17154), CellID: 00006ea2 (28322)

Niveau RF: 6

Batterie: 68

Source d'energie: Battery

SIM: Utilise 0, Disponible 150

Telephone: Utilise 79, Disponible 1921

DC: Utilise 9, Disponible 11

FD: Utilise 5, Disponible 25

MC: Utilise  0, Disponible 20

RC: Utilise 0, Disponible 20

Appel0: inactif

Appel1: inactif

Niveau RF: 6

Batterie: 68

Source d'energie: Battery

SIM: Utilise 0, Disponible 150

Telephone: Utilise 79, Disponible 1921

DC: Utilise 9, Disponible 11

FD: Utilise 5, Disponible 25

...

Si cela fonctionne  lancer en utilisateur xgnokii (cf troisieme copie d’écran en haut de l’article)

Je ne me souviens plus si j’ai essayé de le connecter en bluetooth avec xgnokii.

Pour cela, je dispose d’une Fonera 2.0 flashée sous Openwrt kamikaze (8.09 RC1) sur laquelle est connecté un disque usb formaté en ext3. Le réseau est correctement configuré et opérationnel.

Commençons par installer quelques paquets indispensables :

• kmod-usb2 : gestion de l’ USB,
• kmod-usb-storage : gestion des périphériques de stockages USB,
• kmod-fs-ext3 : prise en charge des systèmes de fichiers ext3,
• nfs-kernel-server : serveur nfs,
• nfs-kernet-server-utils : utilitaires optionnels (tels que nfstat),
• portmap : indispensable pour le serveur nfs et pourtant oublié dans les dépendances.

# opkg update
# opkg install kmod-usb2
# opkg install kmod-usb-storage
# opkg install kmod-fs-ext3
# opkg install nfs-kernel-server
# opkg install nfs-kernel-server-utils
# opkg install portmap

Une fois les paquets installés, le disque devrait être reconnu et automatiquement monté dans /mnt/usbdrive.

Le suite consiste à configurer l’export nfs.

Pour cela, il faut éditer le fichier /etc/exports.

/mnt/usbdrive    192.168.7.0/24 (rw,no_root_squash,async)

• export de /mnt/usbdrive,
• pour toutes les machines du réseau 192.168.7.0,
• en lecture et écriture,
• autoriser root à accéder aux fichiers,
• en asynchrone.

Il ne reste plus qu’à démarrer le serveur nfs :

# /etc/init.d/portmap start
# /etc/init.d/nfsd start

Pour activer le lancement automatique des démons au démarrage d’openwrt :

# /etc/init.d/portmap enable
# /etc/init.d/nfsd enable

Côté client nfs, le montage se fait classiquement :

# mount -t nfs adresse_ip_fonera:/mnt/usbdrive /mnt/owrt