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

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 :)

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…

Fonera 2.0 : Boom Boom Boom Boom, I want you in my room ! Let's spendthe night together ! From now until forever !

Un matin comme les autres… Sauf qu’il y a eu un petit détour par la poste, un colis m’attendait. Dans le colis… Une Fonera 2.0 devel, des stickers, des stylos… Matin bonheur !

Pas vraiment le temps de faire le tour, ce sera pour cette nuit. Juste quelques infos après connexion de la console série :

32 Mb de RAM
Contrôleur USB 2.0
pilotes usblp, usb-serial, usb mass storage….
connexion clef USB, montage, bonheur…

Aller, en attendant la nuit, quelques photos :

Ça va être chaud ce soir dans le leflab !

Papi ! Y'a trop de Fonera ! Je m'y retrouve plus !

Le monde commence à grouiller de Fonera et de modèle différent de Fonera. 1.0, 1.1, plus, 2.0…. Aaaahhhhhh. Bon, récapitulatif :

FON2100 aka La Fonera 1.0 :
Atheros AR2315 180MHz, 8MB/16MB, 1 Ether (blindage métal sur le PCB, connecteur console à 10 pins)
FON2200 aka La Fonera 1.1 :
Atheros AR2315 180MHz, 8MB/16MB, 1 Ether (pas de blindage sur le PCB, connecteur console à 4 pins)
FON2201 aka La Fonera+ :
Atheros AR2315 180MHz, 8MB/16MB, 2 Ether (switch Marvell 88E6060).
FON2202 aka La Fonera 2.0 :
Atheros AR2315 180MHz, 8MB/32MB, 2 Ether (switch Marvell 88E6060) + USB 2.0.

La Fonera 2.0 disponible en version développeur

Cela fait quelques jours que la nouvelle Fonera 2.0 est disponible dans la boutique fon. Elle ressemble à une Fonera+ avec quelques ajouts importants :
contrôleur USB 2.0
une led en plus pour l’USB

Martin Varsavsky, super boss de Fon, l’annonce plus ou moins clairement sur son blog. La Fonera 2.0 est ouverte et il invite les développeurs à participer et créer des applications en plus de celles déjà en cours de finalisation (File sharing, serveur d’impression, Scanner, Webcam, etc) : «As you can see this is just the beginning of a great toy that we are making together with you guys, let´s have FUN!».

Résultat : une communauté de développeurs, liés au projet OpenWrt, appelée Fonosfera : «The Fonera 2.0 will be an open platform for developers to build their applications on top of, much like a hacked iPhone is now».

Bref, que du bon on dirait. Les miennes sont commandées, ne reste qu’à attendre et regarder tout cela de plus près… Le checkout le SVN OpenWrt et je branche mon fer à souder, tic, tac, tic, tac…

En attendant on peut regarder la page qui va bien sur le Wiki OpenWrt.

Vas-y josette sort le crémant, y'a OpenWrt qui tourne sur la Fonera+

Oui, vous avez bien lu ! Le dernier snapshot d’OpenWrt (20080910) passe comme une lettre par la poste et je dois dire que c’est un vrai bonheur. Après download de l’image rootfs (openwrt-atheros-root.jffs2-64k) et du kernel (openwrt-atheros-vmlinux.lzma) on flash tranquillement tout ça comme d’habitude via RedBoot et un adaptateur console judicieusement connecté au port qui va bien.

Le démarrage est des plus classique :
+Ethernet eth0: MAC address 00:00:00:00:0:00
IP: 192.168.10.10/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.10.1

RedBoot(tm) bootstrap and debug environment [ROMRAM]
OpenWrt certified release, version 1.1 – built 22:32:28, May 7 2007
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.

Board: FON 2201
RAM: 0x80000000-0x81000000, [0x80040290-0x80fe1000] available
FLASH: 0xa8000000 – 0xa87f0000, 128 blocks of 0x00010000 bytes each.
== Executing boot script in 10.000 seconds – enter ^C to abort
La Fonera+, ou plus exactement la FON2201, avec le firmware par défaut utilise un second bootloader (stage2 quoi) qui lui-même charge le kernel, etc… Le firmware OpenWrt n’a pas besoin de cela. Tout fonction exactement comme avec une Fonera classique (vieille maintenant). On flash donc exactement de la même manière à grands coups de :
fis init

ip_address -l 192.168.10.10/24 -h 192.168.10.1

load -r -b 0x80041000 openwrt-atheros-2.6-root.jffs2-64k
fis create -b 0x80041000 -f 0xA8030000 -l 0x006F0000 -e 0x00000000 rootfs

load -r -b 0x80041000 openwrt-atheros-2.6-vmlinux.lzma
fis create -r 0x80041000 -e 0x80041000 vmlinux.bin.l7
On patiente puis on s’occupe de la configuration de Redboot qui appel l’ancien loader :
RedBoot> fconfig -l -n
boot_script: true
boot_script_data:
.. fis load -b 0x80100000 loader
.. go 0x80100000

boot_script_timeout: 2
bootp: false
bootp_my_gateway_ip: 0.0.0.0
bootp_my_ip: 192.168.1.1
bootp_my_ip_mask: 255.255.255.0
bootp_server_ip: 192.168.1.254
console_baud_rate: 9600
gdb_port: 9000
info_console_force: false
net_debug: false
On corrige :
RedBoot> fconfig
Run script at boot: true
Boot script:
.. fis load -b 0x80100000 loader
.. go 0x80100000
Enter script, terminate with empty line
>> fis load -l vmlinux.bin.l7
>> exec
>>
Boot script timeout (1000ms resolution): 10
Use BOOTP for network configuration: false
Gateway IP address:
Local IP address: 192.168.10.10
Local IP address mask: 255.255.255.0
Default server IP address: 192.168.10.1
Console baud rate: 9600
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration – continue (y/n)?y
On reboot avec un petit reset. Et là ! Là, la magie arrive (je met une tartine mais, regardez bien, ça brille) :
RedBoot> fis load -l vmlinux.bin.l7
Image loaded from 0x80041000-0x80297085
RedBoot> exec
Now booting linux kernel:
Base address 0x80030000 Entry 0x80041000
Cmdline :
Linux version 2.6.26.3 (andy@devsandbox.padded-cell.net)
(gcc version 4.1.2) #1 Tue Sep 9 17:29:16 PDT 2008
CPU revision is: 00019064 (MIPS 4KEc)
Determined physical RAM map:
memory: 01000000 @ 00000000 (usable)
Initrd not found or empty – disabling initrd
Zone PFN ranges:
Normal 0 -> 4096
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 4096
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
Kernel command line: console=ttyS0,9600 rootfstype=squashfs,jffs2 init=/etc/preinit
Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 16 bytes
PID hash table entries: 64 (order: 6, 256 bytes)
console [ttyS0] enabled
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 13480k/16384k available (1943k kernel code, 2904k reserved, 323k data, 128k init, 0k highmem)
SLUB: Genslabs=6, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Mount-cache hash table entries: 512
net_namespace: 644 bytes
NET: Registered protocol family 16
Radio config found at offset 0xf8(0x1f8)
AR531x PCI init…
done
PCI: fixing up device 0,3,0
PCI: Failed to allocate mem resource #1:4000000@84000000 for 0000:00:00.0
PCI: Failed to allocate mem resource #1:4000000@84000000 for 0000:00:03.0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 512 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 512 bind 512)
TCP reno registered
NET: Registered protocol family 1
ar531x: Registering GPIODEV device
squashfs: version 3.0 (2006/03/15) Phillip Lougher
Registering mini_fo version $Id$
JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
msgmni has been set to 26
io scheduler noop registered
io scheduler deadline registered (default)
gpiodev: gpio device registered with major 254
gpiodev: gpio platform device registered with access mask FFFFFFFF

Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0xb1100003 (irq = 37) is a 16550A
eth0: Atheros AR231x: 00:18:84:a0:5b:98, irq 4
ar2313_eth_mii: probed
eth0: Marvell 88E6060 PHY driver attached.
eth0: attached PHY driver [Marvell 88E6060] (mii_bus:phy_addr=0:1f)

cmdlinepart partition parsing not available
Searching for RedBoot partition table in spiflash at offset 0x7d0000
Searching for RedBoot partition table in spiflash at offset 0x7e0000
6 RedBoot partitions found on MTD device spiflash
Creating 6 MTD partitions on « spiflash »:
0x00000000-0x00030000 : « RedBoot »
0x00030000-0x00720000 : « rootfs »
mtd: partition « rootfs » set to be root filesystem
split_squashfs: no squashfs found in « spiflash »
0x00720000-0x007e0000 : « vmlinux.bin.l7 »
0x007e0000-0x007ef000 : « FIS directory »
0x007ef000-0x007f0000 : « RedBoot config »
0x007f0000-0x00800000 : « boardconfig »
Registered led device: gpio0
Registered led device: gpio1
Registered led device: wlan
Registered led device: gpio3
Registered led device: gpio4
Registered led device: gpio7

nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
eth0: Configuring MAC for full duplex
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP vegas registered
NET: Registered protocol family 17
Bridge firewalling registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
VFS: Mounted root (jffs2 filesystem) readonly.
Freeing unused kernel memory: 128k freed
Please be patient, while OpenWrt loads …
Algorithmics/MIPS FPU Emulator v1.5
– preinit –
Press CTRL-C for failsafe
– init –
Please press Enter to activate this console. PPP generic driver version 2.4.2
device eth0.0 entered promiscuous mode
device eth0 entered promiscuous mode
br-lan: port 1(eth0.0) entering learning state
br-lan: topology change detected, propagating
br-lan: port 1(eth0.0) entering forwarding state
ipt_time loading
wlan: trunk
ath_hal: module license ‘Proprietary’ taints kernel.
ath_hal: 0.10.5.6 (AR5212, AR5312, RF5111, RF5112, RF2316, RF2317, TX_DESC_SWAP)
ath_rate_minstrel: Minstrel automatic rate control algorithm 1.2 (trunk)
ath_rate_minstrel: look around rate set to 10%
ath_rate_minstrel: EWMA rolloff level set to 75%
ath_rate_minstrel: max segment size in the mrr set to 6000 us
wlan: mac acl policy registered
ath_ahb: trunk
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
ath_ahb: wifi0: Atheros 2315 WiSoC: mem=0xb0000000, irq=3

BusyBox v1.11.1 (2008-09-09 15:08:51 PDT) built-in shell (ash)
Enter ‘help’ for a list of built-in commands.

_______ ________ __
| |.—–.—–.—–.| | | |.—-.| |_
| – || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
KAMIKAZE (bleeding edge, r12419) ——————-
* 10 oz Vodka Shake well with ice and strain
* 10 oz Triple sec mixture into 10 shot glasses.
* 10 oz lime juice Salute!
—————————————————
root@OpenWrt:/#
C’est bô ! On verse une larme, on s’essuit, on se mouche un bon coup et on se prépare pour les grandes émotions :
root@OpenWrt:/# cat /proc/net/dev
Inter-| Receive
face |bytes packets errs drop fifo…
lo: 0 0 0 0 0…
eth0: 0 0 0 0 0…
eth0.0: 0 0 0 0 0…
eth0.1: 0 0 0 0 0…
br-lan: 0 0 0 0 0…
wifi0: 0 0 0 0 0…
Mais ?! Mais le support VLAN intégré est configuré et fonctionne ! On a même droit à un bridge :
brctl show
bridge name bridge id STP enabled interfaces
br-lan 8000.001884a05b98 no eth0.0
J’aime pas pour les test, on revoit ça temporairement :
root@OpenWrt:/# ifconfig br-lan down
br-lan: port 1(eth0.0) entering disabled state
root@OpenWrt:/# brctl delbr br-lan
device eth0.0 left promiscuous mode
br-lan: port 1(eth0.0) entering disabled state
root@OpenWrt:/# ifconfig eth0.0 192.168.10.10
root@OpenWrt:/# ifconfig eth0.1 192.168.0.24
Et :
root@OpenWrt:/# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: seq=0 ttl=64 time=1.912 ms
64 bytes from 192.168.0.1: seq=1 ttl=64 time=1.475 ms
root@OpenWrt:/# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
64 bytes from 192.168.10.1: seq=0 ttl=64 time=2.538 ms
64 bytes from 192.168.10.1: seq=1 ttl=64 time=1.460 ms
Allez, juste pour le plaisir :
root@OpenWrt:/# arp
IP address HW type Flags HW address Mask Device
192.168.10.1 0x1 0x2 00:0d:60:cb:5a:27 * eth0.0
192.168.0.1 0x1 0x2 00:19:66:2e:b2:13 * eth0.1
Bien, on revoit la configuration, ce coup-ci on se passera d’uci et on va taper directement dans les fichiers de configuration :
# /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.24’

config ‘interface’ ‘wan’
option ‘ifname’ ‘eth0.1’
option ‘proto’ ‘static’
option ‘netmask’ ‘255.255.255.0’
option ‘ipaddr’ ‘192.168.10.10’
# /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 OWRTplus
option encryption psk
option key ‘coucou’
option txpower ’18’
On passera en DHCP plus tard (j’ai pas envie de tripotter la config, trop excité), en attendant, on reboot et on continu :
root@OpenWrt:/# cat > /etc/resolv.conf
nameserver 80.10.246.130
nameserver 80.10.246.3
root@OpenWrt:/# route add default gw 192.168.0.10
root@OpenWrt:/# ping www.google.com
PING www.google.com (209.85.129.147): 56 data bytes
64 bytes from 209.85.129.147: seq=0 ttl=239 time=47.223 ms
64 bytes from 209.85.129.147: seq=1 ttl=239 time=47.247 ms
Bien, la Fonera+ accède au net. Ca veut dire qu’on peut installer des choses. ipkg y’a plus, voici opkg et il est préconfiguré :
root@OpenWrt:/# cat /etc/opkg.conf
src snapshots http://downloads.openwrt.org/snapshots/atheros/packages
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists

root@OpenWrt:/# opkg update

root@OpenWrt:/# opkg install wpa-supplicant
Installing wpa-supplicant (0.6.3-1) to root…
Configuring wpa-supplicant

root@OpenWrt:/# opkg install hostapd
Installing hostapd (0.6.4-1) to root…
Installing libopenssl (0.9.8h-1) to root…
Installing zlib (1.2.3-5) to root…
Configuring hostapd
Configuring libopenssl
Configuring zlib
Là, à ce moment précis, je ronronne…. et je reboot. ET LA… C’EST LE DRAME !
device ath0 entered promiscuous mode
br-lan: port 2(ath0) entering learning state
br-lan: topology change detected, propagating
br-lan: port 2(ath0) entering forwarding state
br-lan: port 2(ath0) entering disabled state
device ath0 left promiscuous mode
br-lan: port 2(ath0) entering disabled state
Après moult recherches je lance finalement :
root@OpenWrt:/etc/init.d# /sbin/wifi down
root@OpenWrt:/etc/init.d# /sbin/wifi up
Configuration file: /var/run/hostapd-ath0.conf
Line 10: invalid WPA passphrase length 6 (expected 8..63)
WPA-PSK enabled, but PSK or passphrase is not configured.
2 errors found in configuration file ‘/var/run/hostapd-ath0.conf’
enable_atheros(wifi0): Failed to set up hostapd for interface ath0
Ok, je me cache derrière mon clavier et je change gentillement ma passphrase… hum hum. Allez pour être sûr un petit reboot. Et tout marche. Voici une Fonera+ avec un OpenWrt, deux ports ether, un bridge, et un AP WPA qui roule…

Les gars d’OpenWrt là, ils brillent la nuit et ont des poils de partout, pas de doute. Y’a encore à dire sur cette version, mais ce sera pour un prochain billet.

Modification du firmware Fon pour une Fonera+

Comme vous le savez, il y a quelque temps, j’ai tenté d’installer OpenWrt sur une Fonera+ (la grosse avec deux connecteur Ethernet). A force d’insister, j’ai fini par obtenir quelque chose de partiellement fonctionnel : recompilation du firmware Fon et mise en marche des deux ports Ethernet. Cependant, le Wifi reste toujours un problème. Après une periode de travail sur mes Fonera Frankensteinisés, j’ai donc décidé de m’y remettre et de tenter une autre approche. Utiliser le firmware binaire Fon et activer une console série.
Première étape, récupérer une mise à jour binaire pour la Fonera+ sous la forme du fichier foneraplus_1.1.1.1.fon. Il s’agit d’une archive tar compressée gzip à laquelle Fon à ajouté une entête spécifique comme l’explique Stefan Tomanek sur son site. Ses explications pour le firmware de la Fonera classique semble parfaitement valables pour la Fonera+. On joue donc de cat et de tail pour supprimer l’entête et obtenir une véritable archive :
% cat foneraplus_1.1.1.1.fon | tail -c +520 – > arch.tar.gz
Le fichier obtenu contient trois fichiers qui sont utilisés par le routeur pour se mettre lui-même à jour :
hotfix
image_full
upgrade
Le fichier image_full est construit avec l’image du kernel, le système de fichier racine et un cheksum pour le loader stage2 lancé par RedBoot. Un coup d’oeil au contenu du Makefile du BuildRoot Fon (les sources du firmware) et on comprend la procédure de construction :
le l’image du kernel compressé lzma est construite classiquement
le script Perl fonimage.pl ajoute une entête de 12 octets contenant un CRC via le module Digest::CRC
dd est utilisé pour obtenir un fichier multiple de 64Ko avec padding de zéro si nécessaire (bs=64k conv=sync)
le fichier image du kernel ne semble pas utilisée
fonimage.pl est également utilisé pour regouper le kernel et le système de fichiers racine en squashfs. Le script Perl et lancé pour construire l’image du système complet avec le CRC.

On en conclu donc que le fichier image_full est un entête/CRC de 12 octets suivi du kernel lzma puis de l’image squashfs du système de fichiers racine. Un coup d’oeil au script Perl nous apprend également la composition de l’entête de 12 octets :
4 octets pour la taille
4 octets pour le CRC
4 octets pour l’emplacement du système de fichier racine

Vérifier est un jeu d’enfant, il suffit d’afficher les valeurs en utilisant fonimage.pl à la main :
% ./fonimage.pl daimage vmlinux.lzma root.squashfs
size : 2295397
offset : 715783
% ls -l vmlinux.lzma daimage
2295409 2007-11-18 12:20 daimage
715783 2007-09-29 20:31 vmlinux.lzma
L’offset correspond à la taille du kernel et la taille (size) correspond à celle de l’image finale moins celle de l’entête. Les valeurs numériques sont enregistrées dans l’entête dans un format spécifique appelé unsigned long in « network » (big-endian) order. Effectivement dans l’entête du fichier daimage on retrouve :
% hexdump daimage | head -n 1
0000000 2300 6506 3616 ac9f 0a00 07ec 006d 8000
23006506 c’est en réalité 00230665, soit 2295397, la taille de daimage moins 12. Le fichier image_full a comme entête :
% hexdump image_full | head -n 1
0000000 2100 debf 14a2 9bd3 0a00 3450 006d 8000
2100debf c’est 0021bfde, soit, 2211806. 2211806+12 égale 2211818. Mais la taille du fichier est 2293764. Ça ne correspond pas ! Retour au Makefile.

Après avoir utilisé le script fonimage.pl, le Makefile appel prepare_generic_squashfs déclaré dans image.mk, un fichier d’OpenWrt. La fonction utilise dd :
dd if=$(1) of=$(KDIR)/tmpfile.1 bs=64k conv=sync
$(call add_jffs2_mark,$(KDIR)/tmpfile.1)
dd of=$(1) if=$(KDIR)/tmpfile.1 bs=64k conv=sync
$(call add_jffs2_mark,$(1))
On retrouve le padding en blocs de 64k et un appel à add_jffs2_mark qui fait :
echo -ne ‘xdexadxc0xde’ >> $(1)
Bref :
on resize l’image en blocs de 64k
on ajout 0xdeadc0de (Dead Code ???)
on resize encore
on ajoute encore 0xdeadc0de

Vérifions avec un BuildRoot de chez Fon compilé par nos soins :
% cd bin
% find .. -name *.lzma
../build_mips/linux-2.6-fonera/vmlinux.lzma
% find .. -name root.squashfs
../build_mips/linux-2.6-fonera/root.squashfs
% ../target/linux/fonera-2.6/image/fonimage.pl
daimage
../build_mips/linux-2.6-fonera/vmlinux.lzma
../build_mips/linux-2.6-fonera/root.squashfs
% dd if=daimage of=temp1 bs=64k conv=sync
35+1 enregistrements lus
36+0 enregistrements écrits
2359296 octets (2.4 MB) copiés, 0.00566277 seconde, 417 MB/s
% echo -ne ‘xdexadxc0xde’ >> temp1
% dd if=temp1 of=daimage1 bs=64k conv=sync
36+1 enregistrements lus
37+0 enregistrements écrits
2424832 octets (2.4 MB) copiés, 0.00597735 seconde, 406 MB/s
% echo -ne ‘xdexadxc0xde’ >> daimage1
% ls -l daimage1 openwrt-fonera-2.6.image
2424836 2007-11-18 13:37 daimage1
2424836 2007-09-29 20:31 openwrt-fonera-2.6.image
% md5sum daimage1 openwrt-fonera-2.6.image
b57f8b2279bdb9a6483e094c58fc3381 daimage1
b57f8b2279bdb9a6483e094c58fc3381 openwrt-fonera-2.6.image
Bingo ! Nous sommes en mesure de recréer manuellement une image. Nous avons donc parfaitement analysé le processus de construction. Reste à inverser ce processus pour obtenir un fichier du noyau et une image du rootfs que nous pourrons modifier.

Le plus simple pour être sûr est de démonter notre propre essai. On commence donc par regarder l’entête de daimage1 :
% hexdump daimage1 | head -n 1
0000000 2300 6506 3616 ac9f 0a00 07ec 006d 8000
Les valeurs qui nous intéressent ici sont :
la taille de l’image : 23006506 soit 00230665 soit 2295397 octets
la taille du kernel (l’offset pour trouver le rootfs) : 0a0007ec soit 000aec07 soit 715783

On retire l’entête :
% cat daimage1 | tail -c +13 > nohead
Puis le padding en utilisant la taille de l’image spécifiée dans l’entête :
% cat nohead | head -c +2295397 > nopad
Notre fichier est maintenant la concaténation du kernel et du rootfs. On utilise l’offset précisé dans l’entête pour récupérer le rootfs. taille image – offset = taille rootfs (2295397-715783=1579614):
% cat nopad | tail -c 1579614 > squash
Tant qu’à faire on extrait également le kernel pour avoir tous les éléments :
% cat nopad | head -c +715783 > dakern
Vérifions :
% md5sum dakern ../build_mips/linux-2.6-fonera/vmlinux.lzma
0c50b77f12c3e18a91db1d027fe0ecc6 dakern
0c50b77f12c3e18a91db1d027fe0ecc6 ../build_mips/linux-2.6-fonera/vmlinux.lzma
% md5sum squash ../build_mips/linux-2.6-fonera/root.squashfs
19576d7b96f07ba7694d615e2afe78d1 squash
19576d7b96f07ba7694d615e2afe78d1 ../build_mips/linux-2.6-fonera/root.squashfs
Ca marche, nous sommes en mesure de démonter une mise à jour officielle Fon. Appliquons cela à image_full :
% hexdump image_full | head -n 1
0000000 2100 debf 14a2 9bd3 0a00 3450 006d 8000
Un peu de calcul :
taille de l’image : 2100debf soit 0021bfde soit 2211806
taille du kernel : 0a003450 soit 000a5034 soit 675892
taille du rootfs : 2211806-675892=1535914

Démontage :
% cat image_full | tail -c +13 > nohead
% cat nohead | head -c +2211806 > nopad
% cat nopad | tail -c 1535914 > squash
% cat nopad | head -c +675892 > dakern
Ridicule vérification :
% hexdump dakern | head -n 1
0000000 006d 8000 ff00 ffff ffff ffff 00ff 0204
C’est bien une entête de kernel lzma.

Il nous faut maintenant démonter le squashfs. Nous nous heurtons à plusieurs problèmes dont la compression lzma et l’endian. L’image est construite pour un système big endian (MIPS) mais un PC x86 est little endian. Oubliez simplement l’idée de monter le système de fichiers en loopback. Il faut regarder du côté de l’outil unsquashfs mais là encore, beaucoup de problèmes. Après une grosse période de recherche, je suis finalement tombé sur un kit de modification de firmware : firmware_mod_tools_prebuilt.tar.gz.

Cette archive contient un unsquashfs-lzma qui fonctionne parfaitement avec les images pour la Fonera (la nouvelle comme l’ancienne) :
% /tmp/unsquashfs-lzma squash
Reading a different endian SQUASHFS filesystem on squash
created 407 files
created 67 directories
created 165 symlinks
created 0 devices
created 0 fifos
Et nous retrouvons un répertoire squashfs-root contenant l’arborescence utile. Un petit coup d’oeil dans /etc/inittab et effectivement, là, il manque quelque chose que j’aurai aimé :
ttyS0::askfirst:/bin/ash –login
On l’ajoute et on reconstruit un squashfs tout neuf en utilisant les outils du BuildRoot :
% /chemin/vers/openwrt/staging_dir_mips/bin/mksquashfs-lzma
squashfs-root root.squashfs -nopad -noappend -root-owned -be
Creating big endian 3.0 filesystem on root.squashfs, block size 65536.
Big endian filesystem, data block size 65536, compressed data,
compressed metadata, compressed fragments
Filesystem size 1499.77 Kbytes (1.46 Mbytes)
31.47% of uncompressed filesystem size (4766.19 Kbytes)
Inode table size 4801 bytes (4.69 Kbytes)
23.44% of uncompressed inode table size (20479 bytes)
Directory table size 5572 bytes (5.44 Kbytes)
57.00% of uncompressed directory table size (9776 bytes)
Number of duplicate files found 4
Number of inodes 639
Number of files 407
Number of fragments 28
Number of symbolic links 165
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 67
Number of uids 1
root (0)
Number of gids 0
Nous avons un kernel et un nouveau rootfs. Nous réutilisons les commandes permettant de créer une image : fonimage.pl, dd, echo, dd, echo. Nous obtenons une nouvelle image qu’il ne reste plus qu’à flasher sur la Fonera+ via RedBoot :
fis delete image
load -r -b 0x80041000 monimage
fis create -b 0x80041000 -f 0xA8040000 -l 0x00230004 -e 0x80040400 image
Après cette opération la Fonera+ est redémarrée par la commande reset. Aucun message du noyau n’apparaît, c’est normal, mais après la phase de démarrage complète on a bien un shell utilisable. Les messages du DHCP ne cessent de pourrir la console mais ça marche !