Connexion n810 sur Asterisk over OpenVPN

Le tabletPC n810 de Nokia est un super jouet. La première chose installée est un client OpenVPN pour pouvoir se connecter à ses ressources en toute sécurité (relative) depuis n’importe où. Parmi ses ressources il y a un serveur Asterisk. Le n810 intègre, en effet, un client VoIP. De quoi s’amuser, téléphoner via un forfait depuis n’importe quel endroit et surtout recevoir des appels comme si on était chez soi.

Seulement voilà : çapamarche ! Impossible de s’enregistrer sur le serveur Asterisk pourtant  à l’autre bout du VPN. Après quelques recherche, il s’avère que le problème ne vient pas d’Asterisk et encore moins d’OpenVPN mais bien de la configuration sur le n810. Le bestiaux n’utilise pas l’adresse local VPN par défaut, il faut le lui préciser explicitement.

On ouvre donc un terminal (j’adore des périphériques mobiles avec un terminal), on passe en root avec root et on utilise :
mc-account set sip0 string:local-ip-address=ADRESSE_LOCALE_DU_VPN
Magie, le client sip/VoIP se connecte et tout roule.

Il est possible d’automatiser la configuration mais j’étais trop impatient pour configurer cela avant de poster. Explications sur : http://talk.maemo.org/archive/index.php/t-20921.html

FreeRunner GTA-02 FSO/Debian et mode USB host

Après de nombreux essais de différents firmwares pour le FreeRunner, je me suis finalement tourné vers FSO (FreeSmartphone.Org) qui reprend pas mal d’éléments de configuration de Debian/OpenWrt. Les images sont disponibles ici : http://downloads.freesmartphone.org/fso-stable/milestone4.1/.

Tout ceci se flash exactement comme les autres firmwares et après reboot on accède au FreeRunner via USB. Par défaut, son IP est 192.168.0.202. Comme mes interfaces réseau sur ma machine de travail sont bridgées, j’ajoute simplement usb0 au bridge :
% brctl addif br0 usb0
% ifconfig usb0 up
% ping 192.168.0.202
PING 192.168.0.202 (192.168.0.202) 56(84) bytes of data.
64 bytes from 192.168.0.202: icmp_seq=1 ttl=64 time=216 ms
64 bytes from 192.168.0.202: icmp_seq=2 ttl=64 time=29.9 ms
^C
Ce qui me permet un accès SSH sur le FreeRunner (root, pas de mot de passe). Ainsi, je peux configurer le Wifi en ajoutant simplement ce qu’il faut dans /etc/network/interface comme sur une Debian :
iface eth0 inet dhcp
        wireless-mode Managed
        wireless-essid dalefwrt
        wpa-conf /etc/wpa_supplicant/openwrthome.conf
Ainsi qu’un /etc/wpa_supplicant/openwrthome.conf qui va bien :
network={
        ssid= »dalefwrt »
        psk= »laphrasedepass »
}
Un petit ifup eth0 et le tour est joué. Plus besoin de l’interface usb0, ifdown usb0 donc. Le Freerunner est accessible en SSH par Wifi à condition de modifier la configuration de dropbear qui n’écoute que sur l’IP de l’interface usb0 par défaut. On édite /etc/default/dropbear pour avoir ceci :
DROPBEAR_PORT=22
Comme le port USB n’est plus vraiment utile en mode device autant le passer en mode host pour pouvoir utiliser des périphériques USB avec le FreeRunner. Ceci se fait très simplement avec :
echo host > /sys/devices/platform/s3c2410-ohci/usb_mode
On repasse en mode device avec :
echo device > /sys/devices/platform/s3c2410-ohci/usb_mode
Par défaut le FreeRunner est en mode device et utilise l’USB comme source de courant pour se recharger. En mode host il lui faut normalement alimenter les périphériques USB. Le GTA-02, aka FreeRunner, peut basculer d’un mode à l’autre de manière logicielle. Avec ceci :
echo 1 > /sys/devices/platform/neo1973-pm-host.0/hostmode
le FreeRunner alimente le port USB avec un courant de 500mA, exactement comme une machine standard. Des résistances de rappel de 15K à la masse sont activées sur les lignes D+ et D- de l’USB. Malheureusement, ceci consomme énormément de courant et vide rapidement la batterie.

Avec :
echo 0 > /sys/devices/platform/neo1973-pm-host.0/hostmode
on repasse en mode standard. Les résistances sont désactivées et la charge depuis l’USB est réactivé. Notez que ceci est indépendant du mode USB device/host. Et justement, c’est ce qui permet d’utiliser le courant fourni par un hub USB pour charger le FreeRunner alors qu’il est en mode host.

Attention, tout les hub USB fournissent du courant aux périphériques mais pas nécessairement à l’hôte. Le plus simple est d’avoir quelques hub sous la main et de faire les essais. Une autre solution consiste, tout simplement à récupérer du +5V en sortie du hub et de le connecter au Vcc du connecteur côté hôte. Enfin, une autre solution est de jeter un oeil au hub. Souvent, une simple diode est utilisée pour bloquer le courant du hub vers l’hôte.

Regardez http://wiki.openmoko.org/wiki/Neo1973_USB_host et http://wiki.openmoko.org/wiki/Specialized_USB_cables pour plus d’informations.

De mon côté j’ai la chance de disposer d’un pauvre hub sans marque acheté en supermarché, mais qui alimente effectivement l’hôte en courant. Il m’a donc suffit de bricoler un connecteur me permettant de brancher le hub sur du le connecteur mini type B jack du FreeRuner.

On trouve ce type de câble (mini type B plug vers type A jack) sur le net (eBay). J’ai opté pour une autre solution :
un câble mini type B plug vers type A plug
un double déporteur type A jack provenant d’un PC que j’ai ponté avec des cavaliers
le connecteur type A plug du hub

Je peux ainsi alimenter le FreeRunner tout en utilisant le mode host et le hub USB pour y connecter plein de choses :

# lsusb
Bus 001 Device 001: ID 0000:0000
Bus 001 Device 082: ID 05e3:0606 Genesys Logic, Inc.
Bus 001 Device 085: ID 0951:1603 Kingston Technology
Bus 001 Device 086: ID 0718:0286 Imation Corp.
Bus 001 Device 087: ID 9710:7830
Bus 001 Device 088: ID 4348:5523
Tout ne fonctionne pas par défaut faute de drivers. Il faut installer les modules adéquates sous forme de paquets avec opkg (qui est déjà configuré). Exemple :
# opkg update
# opkg install kernel-module-cp2101 kernel-module-pl2303 kernel-module-ftdi-sio
[…]
Configuring kernel-module-cp2101
Configuring kernel-module-pl2303
Configuring kernel-module-ftdi-sio
# dmesg
[…]
ftdi_sio 1-2.3:1.0: FTDI USB Serial Device converter detected
drivers/usb/serial/ftdi_sio.c: Detected FT232RL
usb 1-2.3: FTDI USB Serial Device converter now attached to ttyUSB0
Un convertisseur USB/série permet d’étendre les sorties du FreeRunner. Il suffit de lui ajouter un AVR (Attiny2313) pour disposer de plein de GPIO. Le FreeRunner dispose d’un GPS, d’un modem GSM/GPRS, du Wifi, du BlueTooth, d’un écran, d’un périphérique audio… En utilisant le port USB en mode host on lui offre tout ce qui manque. Je ne parle plus de téléphone mais d’un système embarqué autonome accessible en IP et GSM/GPRS. Imaginez deux secondes ce qu’il devient possible de faire si je dis, par exemple, «domotique».

Idem pour la robotique. Le FreeRunner peut devenir le cœur d’un drone très efficace…

Firmware Fonera 2.0 RC1 !

Je viens de mettre à jour le firmware d’une de mes Fonera 2.0 avec la toute nouvelle version RC1. Beaucoup de changement dans l’interface de cette version, une révision complète :

Je n’ai pas encore regardé tout l’aspect «plugins» qui semble maintenant pleinement utilisable. Côté console, voici également quelques info :

root@Fonera:/# mount
rootfs on / type rootfs (rw)
/dev/root on /rom type squashfs (ro)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
tmpfs on /dev type tmpfs (rw,size=512k)
devpts on /dev/pts type devpts (rw,mode=600)
mini_fo:/tmp/root on /tmp/root type mini_fo (rw)
none on /proc/bus/usb type usbfs (rw)
mountd(pid1632) on /tmp/run/mountd type autofs
(rw,fd=7,pgrp=1631,timeout=60,minproto=5,maxproto=5,indirect)
/dev/mtdblock4 on /jffs type jffs2 (rw)
mini_fo:/jffs on / type mini_fo (rw)
root@Fonera:/# df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                    3.3M      3.3M         0 100% /
/dev/root                 3.3M      3.3M         0 100% /rom
tmpfs                    14.6M    324.0k     14.3M   2% /tmp
tmpfs                   512.0k         0    512.0k   0% /dev
mini_fo:/tmp/root         3.3M      3.3M         0 100% /tmp/root
/dev/mtdblock4            2.2M    216.0k      2.0M  10% /jffs
mini_fo:/jffs             3.3M      3.3M         0 100% /
root@Fonera:~# ps aux 
  PID USER       VSZ STAT COMMAND
    1 root      1972 S    init      
    2 root         0 SW<  [kthreadd]
    3 root         0 SW<  [ksoftirqd/0]
    4 root         0 SW<  [events/0]
    5 root         0 SW<  [khelper]
   29 root         0 SW<  [kblockd/0]
   55 root         0 SW   [pdflush]
   56 root         0 SW   [pdflush]
   57 root         0 SW<  [kswapd0]
   58 root         0 SW<  [aio/0]
  103 root         0 SW<  [mtdblockd]
  356 root      1972 S    logger -s -p 6 -t 
  358 root      1984 S    /bin/ash –login
  534 root      1984 S    syslogd -C16
  536 root      1964 S    klogd
  547 root      1132 S    /sbin/hotplug2 –override –persistent –max-children
  683 root         0 SW<  [khubd]
 1206 root      1412 S    hostapd -P /var/run/wifi-ath1.pid -B /var/run/hostapd
 1562 root      2740 S    fonstated -D
 1581 root      2220 S    fonstated -D
 1582 root      2484 S    fonstated -D
 1598 root      1964 S    /sbin/watchdog -t 5 -F /dev/watchdog
 1604 root      3464 S    /usr/bin/lucittpd /usr/lib/lucittpdredirect/plugins/
 1632 root      1700 S    /sbin/mountd
 1639 root      3492 S    /usr/bin/lucittpd
 1655 root      3196 S    /usr/sbin/fonsmcd
 1660 nobody    1276 S    /usr/sbin/dnsmasq -K -D -y -Z -b -E -s lan -S /lan/ –
 1675 root         0 SWN  [jffs2_gcd_mtd4]
 5055 root      1972 R    ps aux
root@Fonera:/root# netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     
netstat: no kernel support for AF INET6 (tcp)
udp        0      0 0.0.0.0:53              0.0.0.0:*                          
udp        0      0 0.0.0.0:67              0.0.0.0:*                          
netstat: no kernel support for AF INET6 (udp)
netstat: no kernel support for AF INET6 (raw)
Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node Path

Androïd sur Neo Freerunner

Après avoir essayé plusieurs «distributions» pour le Neo et n’ayant pas été vraiment satisfait du résultat, j’ai finalement décidé de regarder si, à tout hasard, il n’existerait pas un portage d’Androïd sur le Neo… et c’est bien le cas !

Ceci est principalement le résultat du travail de Sean McNeil qui a produit et maintient des images rootfs et kernel pour le Neo. Vous pouvez récupérer ces dernières sur http://people.openmoko.org/sean_mcneil/. Puis flasher le Neo avec :
dfu-util -a rootfs -R -D androidfs.jffs2
dfu-util -a kernel -R -D uImage-android
Vous trouverez également un binaire pour GNU/Linux : adb, le serveur de debug permettant de «contacter» le Neo. En effet, l’interface USB du Neo est configurée en CDC Ethernet Device avec une IP 192.168.0.202. Voici qui peut poser problème dans une configuration LAN classique 192.168.0.1/24. Il faut alors jouer un peu du bridge et revoir sa configuration réseau.

Personnellement j’ai déjà un bridge installé regroupant eth0, tap10 et tap11 (pour les machines virtuelles KVM). Il suffit alors d’ajouter usb0 :
% sudo brctl addif br0 usb0
% sudo ifconfig usb0 up
% sudo brctl showstp br0
[…]
usb0 (0)
port id 0000 state forwarding
designated root 8000.0019662eb213 path cost 100
designated bridge 8000.0019662eb213 message age timer 0.00
designated port 8004 forward delay timer 0.00
designated cost 0 hold timer 0.79
flags

% ping 192.168.0.202
PING 192.168.0.202 (192.168.0.202) 56(84) bytes of data.
64 bytes from 192.168.0.202: icmp_seq=1 ttl=64 time=0.663 ms
64 bytes from 192.168.0.202: icmp_seq=2 ttl=64 time=0.563 ms
^C
Obtenir un shell sur le Neo est ensuite chose facile :
ADBHOST=192.168.0.202 ./adb shell
D’autres informations sont présentes sur :

http://wiki.openmoko.org/wiki/User:Seanmcneil3 et http://wiki.openmoko.org/wiki/Android

OpenWrt Kamikaze SVN sur La Fonera 2.0

La population de Fonera (FON2100) et Fonera 2 (FON2202) chez moi ne cesse d’augmenter. Ceci permet de jouer à la fois avec le firmware Fon et OpenWrt. L’une de mes FON2202 est maintenant flashée avec OpenWrt Kamikaze et tout va pour le mieux. Retour d’expérience…

Le firmware utilisé est un checkout SVN :
% cd kkpart
% svn checkout https://svn.openwrt.org/openwrt/trunk/ kamikaze
% cd kamikaze
% ./scripts/feeds update
% make package/symlinks
% wget http://www.lefinnois.net/Atheros_fonera2.config
% make menuconfig
On utilise «Load an Alternate Configuration File» pour charger Atheros_fonera2.config et obtenir une configuration adaptée pour la plateforme. Il s’agit de mon fichier de configuration, basé celui utilisé pour le build snapshot de septembre. Il ne reste ensuite plus qu’à créé le monde :
% make world
On retrouve ensuite dans bin les images à flasher sur La Fonera : openwrt-atheros-root.jffs2-64k et openwrt-atheros-vmlinux.lzma. On connecte ensuite la console de La Fonera et on reset. Un petit CTRL+C lors du temps de pause offert par RedBoot et on flash. La procédure est identique à celle utilisée pour une Fonera+. On n’oublie pas de changer la configuration de RedBoot. Voici pour le serveur TFTP via xinetd :
% cat /etc/xinetd.d/tftp2
service tftp
{
        disable         = no
        socket_type     = dgram
        protocol        = udp
        wait            = yes
        user            = root
        server          = /usr/sbin/in.tftpd
        server_args     = -v -s /mnt/six4/kamikaze/bin
}
On n’oublie pas non plus, pour la suite, de configurer un serveur HTTP pour installer les paquets OPKG (Lighttpd fait parfaitement l’affaire, comme pour beaucoup d’applications d’ailleurs).

Côté système embarqué, après un premier démarrage, on s’occupe de la configuration. D’abord OPKG
root@OpenWrtF2:~# cat /etc/opkg.conf
src/gz snapshots http://192.168.0.1/packSVN
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
On installe ensuite les paquets wpa-supplicant, hostapd et libopenssl via opkg install. On en profite également pour installer les modules pour le support USB. Pour moi :
kmod-usb-core – 2.6.26.5-atheros-1 –
kmod-usb-serial – 2.6.26.5-atheros-1 –
kmod-usb-serial-ark3116 – 2.6.26.5-atheros-1 –
kmod-usb-serial-ftdi – 2.6.26.5-atheros-1 –
kmod-usb-serial-pl2303 – 2.6.26.5-atheros-1 –
kmod-usb-storage – 2.6.26.5-atheros-1 –
kmod-usb2 – 2.6.26.5-atheros-1 –
Puis on se tourne vers la configuration :
root@OpenWrtF2:~# cat /etc/config/network
# /etc/config/network
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 ‘type’ ‘bridge’
        option ‘proto’ ‘static’
        option ‘netmask’ ‘255.255.255.0’
        option ‘ifname’ ‘eth0.0’
        option ‘ipaddr’ ‘192.168.0.25’

config ‘interface’ ‘wan’
        option ‘ifname’ ‘eth0.1’
        option ‘proto’ ‘static’
        option ‘netmask’ ‘255.255.255.0’
        option ‘ipaddr’ ‘192.168.10.10’
root@OpenWrtF2:~# cat /etc/config/wireless
config wifi-device  wifi0
        option type        atheros
        option channel     auto
        option disabled    0
        option channel     6
        option disabled    0
        option diversity   0
        option txantenna   1
        option rxantenna   1
        option mode        11bg

config wifi-iface
        option device     wifi0
        option network    lan
        option mode       ap
        option ssid       OWRT_F2
        option encryption psk
        option key        ‘1234567890’
        option txpower    ’18’

config wifi-iface
        option device     wifi0
        option mode       ap
        option ssid       OWRT_F2b
        option encryption psk
        option key        ‘0987654321’
        option txpower    ’18’
J’utilise ici les deux SSID disponible pour obtenir ath0 et ath1. ath0 et eth0.0 sont bridgés sous br-lan. eth0.1 est configuré sur un autre réseau et ath1, bien que configuré en Master, n’est pas adressé. On verra plus tard, ce n’est pas une configuration de production.

Si on jete un œil sur /etc/fstab on voit que : « WARNING: this is an auto generated file, please use uci to set static filesystems« . Ce fichier est généré au démarrage. Par défaut, une clef USB en /dev/sda1 sera montée dans /home et /dev/sda2 utilisée en swap (??). Inutile de tout casser, on change cela en passant par :
root@OpenWrtF2:~# cat /etc/config/fstab
config mount
        option target   /proc/bus/usb
        option device   none
        option fstype   usbfs
        option options  defaults
        option enabled  0
Il y a, apparement, quelques problèmes avec les périphériques USB 1. Mes adaptateurs USB/série/TTL par exemple. La simple connexion plante littéralement le contrôleur USB. La connexion ne « remonte » rien et toutes connexions d’un autre périphérique USB ne provoque plus aucune réaction. L’utilisation d’un hub USB 2.0 règle le problème. Bug du pilote ? Du contrôleur USB ? Limitation technique ? Aucune idée.

Quoi qu’il en soit, l’USB fonctionne à merveille en dehors de ce point :
root@OpenWrtF2:~# cat /proc/bus/usb/devices | grep -e « ^[P|S|C] »
P:  Vendor=1d6b ProdID=0002 Rev= 2.06
S:  Manufacturer=Linux 2.6.26.5 ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:00.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA

P:  Vendor=0409 ProdID=005a Rev= 1.00
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA

P:  Vendor=0403 ProdID=6001 Rev= 6.00
S:  Manufacturer=FTDI
S:  Product=FT232R USB UART
S:  SerialNumber=A90066ai
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 90mA

P:  Vendor=0409 ProdID=005a Rev= 1.00
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA

P:  Vendor=6547 ProdID=0232 Rev= 0.01
S:  Manufacturer=ArkMicroChips
S:  Product=USB-UART Controller
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA

P:  Vendor=08ec ProdID=0008 Rev= 1.00
S:  Manufacturer=Intuix
S:  Product=DiskOnKey
S:  SerialNumber=0DB15550F3830A3A
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=200mA
Côté GPIO, puisque certains s’y intéressent, tout semble être utilisé soit par les leds, soit par le contrôle du reset (le bouton sous La Fonera). En revanche le contrôle des leds est grandement facilité par le support directe du noyau. On se retrouve avec un chouette répertoire :
root@OpenWrtF2:~# ls /sys/class/leds/
gpio1  gpio3  gpio4  gpio7  wlan
root@OpenWrtF2:~# ls /sys/class/leds/gpio7/
brightness  device      subsystem   trigger     uevent
Et là, ça devient intéressant :
root@OpenWrtF2:~# echo 1 > /sys/class/leds/gpio7/brightness
Et voici que la led POWER s’allume en orange. Voici les correspondances :

gpio7 : POWER orange (led bicolore)
gpio4 : POWER vert (led bicolore)
gpio3 : USB vert (led standard)
gpio1 : WIRELESS orange (led bicolore)
wlan : WIRELESS vert (led bicolore)
INTERNET : eth0.1
COMPUTER : eth0.0

Mais le plus intéressant est le fichier trigger permettant de définir le contrôle d’une led :
root@OpenWrtF2:~# cat /sys/class/leds/gpio7/trigger
[none] timer heartbeat default-on netdev
root@OpenWrtF2:~# echo heartbeat > /sys/class/leds/gpio7/trigger
Et voici que la led POWER clignote comme un battement de cœur en orange. Ou encore :
root@OpenWrtF2:~# echo timer > /sys/class/leds/gpio7/trigger
root@OpenWrtF2:~# ls /sys/class/leds/gpio7/
brightness  delay_off   delay_on    device      subsystem   trigger     uevent
root@OpenWrtF2:~# echo 50 > /sys/class/leds/gpio7/delay_on
root@OpenWrtF2:~# echo 1500 > /sys/class/leds/gpio7/delay_off
Et la même led pulse avec une durée allumée de 50ms et éteinte de 1500ms. C’est beau :)

Adaptateur USB/Série TTL

Enfin, enfin mes amis bulgares m’ont expédiés ma commande sur eBay. L’objet ? Un sympathique adaptateur USB/série (FTDI) vers TTL. En clair, on entre en USB, Linux voit un port série supplémentaire, mais l’interface se fait en TTL (5V) ou 3.3V. Fini les adaptateurs USB/Série RS232 en +/-12V puis RS232/console TTL. Je peux, à présent, connecter directement un microcontrôleur AVR Attiny2313 via son UART avec une box Linux USB (ou une Fonera 2.0).

C’est tout petit et ça simplifie grandement les choses. Je suis maintenant en mesure de développer des périphériques USB (sans consommer la majorité de la Flash de l’AVR).

Que voit Linux ? Ceci :

[862432.095490] usb 5-3.4: FTDI USB Serial Device converter now attached to ttyUSB1
[862432.096332] usb 5-3.4: New USB device found, idVendor=0403, idProduct=6001
[862432.096336] usb 5-3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[862432.096340] usb 5-3.4: Product: FT232R USB UART
[862432.096343] usb 5-3.4: Manufacturer: FTDI
[862432.096345] usb 5-3.4: SerialNumber: A90066ac

Et en plus c’est tout choupy :

Ça vaut 15€/pièce, mais quel gain d’espace, de ressources et de temps ! Viens, Fonera 2.0 ! Je vais te faire parler avec le monde du dehors !

Nouveau jouet : Freerunner GTA02

Aller à l’EuroBSDcon est dangeureux. On y va tranquillement avec plein de BSD dans la tête et là, bam ! On tombe sur Wim, son stand de tshirt, de livres et… tiens ?! Un téléphone sur lequel on fantasme depuis longtemps. Pire ! Il est vendu moins cher que par l’importateur français ! Comment résister ?!

Plus d’info à suivre. En attendant, quelques photos (oui c’est flou, mais quand on est réveillé par les démons d’OpenMoko, du hack et de l’embarqué à 5h30 du matin, difficile de faire des photos nettes) :

Fonera 2.0 : premières impressions et firmware beta

Je suis tombé amoureux ! Cette bête est tout simplement une merveille :
deux ports ethernet
deux SSID
32 Mo de RAM
Un port USB

Les possibilités d’extension sont sans limites. Avec le port USB il devient possible de tout faire. Je ne parle pas seulement de ca. Je parle de tout ce qui n’est pas encore prévu, de lecteur de smartcard, d’interfaces USB/série/AVR/relais, le tokens X509, de…

Le port USB ouvre des possibilités incroyables. Imaginez, un microcontrôleur Atmel AVR Attiny2313 connecté en série via un adaptateur USB/serial FTDI comme ceci (Oui, on peut aussi jouer de l’USB directement avec les AVR mais je préfère garder la Flash pour mon code).

La Fonera 2 arrive avec un firmware de Fonera+, point d’accès Fon parfaitement standard. Le firmware béta est téléchargeable ici. La mise à jour via l’interface Web ne semble pas marcher, j’ai donc opté pour l’utilisation de la commande mtd.
BusyBox v1.11.1 (2008-09-25 22:20:43 CEST) built-in shell (ash)
Enter ‘help’ for a list of built-in commands.

                ,^~~~-.         .-~~~ »-.
               :  .–.        /  .–.              
               : (    .-`<^~~~-: :    )  :            
               `. `-,~            ^- ‘  .’           
                 `-:                ,.-~                           
                .’                  `.                           
               ,’   @   @            |                           
               :    __               ;                           
            …{   (__)          ,—-.            
           /   `.              ,’ ,–. `.           
          |      `.,___   ,      :    : :          
          |     .’    ~~~~           / :          
           .. /               `. `–‘ .’           
              |                  ~—-~            
              |                   |
              |                   |
              beware the evil teddy

——–  Fonera 2.0 Firmware (v2.1.0.1) ———–
 * Based on OpenWrt – http://openwrt.org
 * Powered by FON – http://www.fon.com
—————————————————-
root@Fonera:/#
Oh ! Un teddy ! Le firmware 2.0 promet de belles choses. On peut d’ors et déjà :
Monter un disque USB
Gérer une webcam (quand le pense que j’ai acheté une webcam Wifi il y a un mois)
Installer un serveur FTP ou un partage Samba
Partager une imprimante
Piloter un scanner

et…Qu’est ce que je vois ?

Un menu « Plugins » ?! Mais, mais… show me the SDK !!! Fast !!!

Le firmware beta est sympatique mais je ne peux m’arrêter à cela et m’empêcher de vérifier une chose : les sources. Après téléchargement la suite des opérations est simple :
% tar xfvv fon2.0-beta-2.1.0.1.tar.bz2
% cd fon2.0-beta
% ./install.sh
% cd trunk
% make menuconfig   # pour voir
% make world
Oui, il y a des sources. Mais pas tout. Le FON Status Manager Client Daemon (fonsmcd) est livré en binaire. Pourquoi ?

Bien, ça build… Dès qu’il commence à y avoir des infos sur de développement de plugins… Enfin, vous vous doutez de la suite…