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.

Samsung YP-K3 en mode disque dur UMS (USB Mass Storage)

Je vais le dire comme je le pense, le support du protocole MTP pour les lecteurs MP3 est une véritable bouse sous GNU/Linux. Applications multimédia, FUSE/MTPFS, etc… sux ! Pour moi, clairement, un bon balladeur MP3 c’est Mass Storage ou c’est pas. Et quand c’est pas… c’est quand même ! Comment passer un Samsung YP-K3 en mode Mass Storage (UMS) sans l’ombre d’un Windows ? Simple… suivez le guide…
Il existe un firmware (micro-programme) pour le YP-K3 permettant :

mode UMS USB Mass Storage, Yeah ! Mais Yeah quoi !!!!
plus besoin de tags id3
Navigateur de fichiers
Support Ogg
Lecture de texte
Egaliseur configurable
2 fonts en plus
Nouvelles animations en lecture
3 niveau de sensibilité FM
3 couleur d’affichage (red ici)
Plus de limitation de niveau de son

C’est un firmware coréen version 4.06. La procédure est la suivante (Attention, vous pouvez rendre inutilisable votre matériel, venez pas pleurer, chez moi ça a marché au poil, après quelques reset car le mode MTP était… beuaaarggg. Si vous tentez la procédure c’est à vos risques et périls. Je suis absolument pas responsable et je ne vous demande pas de faire ce qui suit. Ceci est donné à titre purement indicatif. Et non, je veux pas le faire pour vous non plus !) :

récupération du firmware koréen 4.06 (un par couleur d’interface) :
http://file-yepp.muz.co.kr/firmware/YP-K3%20V4.06%20BLUE_man.zip

http://file-yepp.muz.co.kr/firmware/YP-K3%20V4.06%20LIME_man.zip

http://file-yepp.muz.co.kr/firmware/YP-K3%20V4.06%20RED_man.zip
Dézipage. On récupère : YPK3.IMG et YPK3.rom
Montage mtpfs/fuse (bouseux)
sudo -s
aptitude install mtpfs
mkdir /mnt/K3
mtpfs -d -f /mnt/K3 # debug/foreground
copie des fichiers firmware et démontage
cp /tmp/YPK3.IMG /tmp/YPK3.rom /mnt/K3
sync
fusermount -u K3
débrancher le K3. Allumer. Message upgrade firmware puis message d’erreur « y’a pas de DB ». Normal y’a pas de FS initialisé
rebranchage du K3
usb-storage: device found at 17
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 5:0:0:0: Direct-Access SAMSUNG YP-K3 1.00 PQ: 0 ANSI: 0
sd 5:0:0:0: [sda] 7880704 512-byte hardware sectors (4035 MB)
sd 5:0:0:0: [sda] Write Protect is off
sd 5:0:0:0: [sda] Mode Sense: 37 00 00 08
sd 5:0:0:0: [sda] Assuming drive cache: write through
sd 5:0:0:0: [sda] 7880704 512-byte hardware sectors (4035 MB)
sd 5:0:0:0: [sda] Write Protect is off
sd 5:0:0:0: [sda] Mode Sense: 37 00 00 08
sd 5:0:0:0: [sda] Assuming drive cache: write through
sda: unknown partition table
sd 5:0:0:0: [sda] Attached SCSI removable disk
création partition avec fdisk /dev/sda. Une partoche type b (W95 FAT32)
formatage : mkfs.vfat -F 32 /dev/sda1
mountage : mount /dev/sda1 /mnt/K3
copie une seconde fois des fichiers firmware
démontage et déconnexion
Allumage : upgrade firmware, allumage, upgrade image (interface)
Allumage : réglage francais (un peu coréen par défaut)
Done !!!!

Rha comme je l’ai soumis ce YP-K3 !!!!!!

Sources :

http://gentoo-wiki.com/HARDWARE_Samsung_K3
http://forums.gentoo.org/viewtopic-p-4955759.html?sid=2c23ec866d6564ca2f2185c780a139e9

Récepteur Infra-rouge USB

Dans un précédent billet j’ai détaillé l’utilisation d’AVRlirc de Paul Fox. Voici un petit hack permettant consistant à le lier avec un adaptateur série/USB pour en faire un ensemble IR/USB.

Il n’y a pas grand chose à dire si ce n’est qu’on récupère directement le +5V sur le câble USB juste avant l’adaptateur. Une fois connecté le périphérique est vu comme un /dev/ttyUSB* qu’il suffit d’utiliser avec avrlirc2udp. Un peu de configuration Lirc et c’est un total bonheur pour des présentations ou toutes autres choses.

J’utilise ce montage pour palier au manque de sensibilité du capteur IR de mon ThinkPad x31 pourtant utilisable avec Lirc. La portée est impressionnante même avec des petites télécommandes comme celles qu’on peut trouvez pour quelques Euros sur ebay :

La Légende du PCMCIA sur iBook

L’objectif de ce billet était, normalement, de montrer qu’il est simple d’utiliser le port PCMCIA sous le clavier d’un iBook pour adapter n’importe quelle carte Wifi. Et bien non, c’est un billet pour dire qu’il ne faut pas croire tout ce qu’on voit sur le Web.

Il n’y a pas de port PCMCIA, au sens stricte du terme, dans un iBook. J’en vois déjà qui hurlent et qui s’agitent… Non, ce n’est pas un VRAI port PCCARD mais un ersatz tout pourri.
J’ai continué mon bricolage en retirant, à la scie à métaux, une grande partie du circuit de la carte TrendNet. Les deux Leds et les antennes y sont passées mais j’ai conservé les points de soudure pour les antennes.

La carte, maintenant plus petite, peu se loger dans l’iBook sans problème. Seulement voilà, il n’y a pas de support PCCARD pour le Mac, ni dans Linux, ni dans Mac OS X. Les hack qu’on peut voir sur le Web consistent simplement à utiliser en lieu et place d’une carte Airport, une carte Wavelan compatible. Il n’existe pas de support pour un bridge PCMCIA sur les iBook. Impossible d’utiliser les outils PCMCIA standards. Point.

En revanche ce qui est amusant, c’est le résultat sur le lappy PC :
ath0 IEEE 802.11g ESSID: »OpenWrt » Nickname: » »
Mode:Managed Frequency:2.432 GHz Access Point: xx:xx:xx:xx:xx:xx
Bit Rate:54 Mb/s Tx-Power:18 dBm Sensitivity=1/1
Retry:off RTS thr:off Fragment thr:off
Encryption key:CE36-2568-4095-B3AD-CBDD-96A4-2FD1-16A3
Power Management:off
Link Quality=72/70 Signal level=-22 dBm Noise level=-95 dBm
Rx invalid nwid:9037 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
La carte découpée équipée d’une antenne fonctionne encore mieux :)

Ajout d'antenne sur un adaptateur Wifi PCMCIA

Trouver une carte PCMCIA ne nécessitant pas cette saleté d’NDISwrapper est déjà relativement difficile (bon, d’accord, de moins en moins avec la popularité grandissante des puces atheros). Si en plus on veux un mode monitor et un connecteur d’antenne cela devient très sportif.

Pour ma part je me suis tourné vers du pas cher bas de gamme : Trendnet TEW-441PC. Cette carte est supportée par madwifi (semi-libre) et support tous les modes intéressants. Mais voilà, pas de connecteur d’antenne ! Mais Lefinnois est une tête de mule, donc il ajout le connecteur lui-même.
En démontant la carte PCMCIA on découvre que la partie externe ne comporte pas beaucoup de composants : deux leds et deux condensateurs.

On trouve aussi, sous la carte, deux mignons petit emplacement… pour y souder une antenne (à gauche l’original et à droite la version gratouillée pour la soudure) :

Résultat, sans l’antenne :
ath0 IEEE 802.11g ESSID: »OpenWrt » Nickname: » »
Mode:Managed Frequency:2.432 GHz Access Point: xx:xx:xx:xx:xx:xx
Bit Rate:24 Mb/s Tx-Power:18 dBm Sensitivity=1/1
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=48/70 Signal level=-43 dBm Noise level=-91 dBm
Rx invalid nwid:229 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Avec l’antenne (provenant d’une Fonera) :
ath0 IEEE 802.11g ESSID: »OpenWrt » Nickname: » »
Mode:Managed Frequency:2.432 GHz Access Point: xx:xx:xx:xx:xx:xx
Bit Rate:24 Mb/s Tx-Power:18 dBm Sensitivity=1/1
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=61/70 Signal level=-30 dBm Noise level=-91 dBm
Rx invalid nwid:278 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Le but initial de la manipulation n’est pas de disposer d’une carte avec une antenne (quoi que, je suis un grand consommateur de chicorée café) mais d’intégrer la carte dans un iBook G3. Les cartes airport et leur chipset orinoco sont passablement énervantes. Intégrer la carte sous le clavier de l’iBook nécessitera quelques manipulations mécaniques (la carte est trop grande) et la soudure/connection de l’antenne intégrée à l’écran du lappy. Bref, c’est pour un prochain billet.

PS : Non, je n’aime pas NDISwrapper. Je n’aime pas intégrer du binaire Windows dans mon GNU/Linux. Je n’aime pas non plus les émulateurs pour utiliser des applis Windows sous GNU/Linux. Et je n’aime pas la choucroute non plus.

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 !

Un écran LCD pour la Fonera

Décidément La Fonera est un super jouet. Comme, de toutes façon, j’ai désactivé la console série pour utiliser le port pour autre chose, j’ai tenté l’utilisation d’un écran LCD 128*128 série fabriqué par 4D Systems et vendu par Dontronics.
Il s’agit d’un modèle d’afficheur qui n’est plus fabriqué. Celui-ci est remplacé par un modèle OLED bien plus efficace et riche incluant un lecteur micro SD pour stocker des images et des animations. Le modèle utilisé ici ne permet que d’afficher des primitives graphiques simples (trait, cercle, texte) ainsi que des images pixel par pixel.

Peu importe, ce qu’il est possible de faire avec ce vieux modèle l’est également avec les nouveaux. Le mode de connexion est relativement simple. Le module LCD est alimenté en +5Volts tiré de La Fonera, l’interfacage série est en +3.3/0V (comme le port série du routeur donc).

Il suffit donc de brancher tous cela pour que cela fonctionne ? NON !

Le module auto-détecte la vitesse du port série sur demande. C’est la première requête qu’il faut lui envoyer à la mise sous tension. Le problème qui se pose alors vient de RedBoot qui envoi sur le port série tout un blabla à la mise sous tension du routeur. Inutile de vouloir modifier RedBoot, non seulement cela semble des plus délicat mais, en plus on risque de perdre définitivement la main sur le routeur en cas de problème. Ne touchons pas a RedBoot.

La solution consiste à allumer le module LCD après le démarrage du routeur. Toutes les lignes GPIO placées à l’arrière de La Fonera de test sont utilisées pour mon bus i2c. Reste la led WAN pilotée par un transistor. La modification consiste donc à retirer la led et le transistor et utiliser la ligne via un BC547B permettant de piloter l’alimentation du module :

On voit ici que j’ai placé un petit strap entre la ligne 2 (base de l’ancien transistor) et l’anode de la led. Ceci permet, tout simplement d’utiliser l’emplacement juste dessous pour souder un fil (jaune). Il ne reste ensuite plus qu’à brancher le fil sur la base du BC547 via une résistance de 47 Ohms (c’est suffisant pour saturer le transistor). Ce qui nous donne le schémas suivant :

Il ne reste plus, ensuite qu’à piloter le module depuis le routeur. Pour cela j’ai écrit un petit code en C permettant différentes manipulations sur le module (effacement, contraste, rétro-éclairage, chargement d’image PNG). C’est une version préliminaire permettant déjà d’afficher point par point une image sur l’écran (c’est très lent car, même en 115200 il faut attendre l’accusé réception pour chaque pixel, et il y en a 16384). Une option permet de minimiser le nombre de pixels à afficher en déterminant la couleur dominante de l’image et en en remplissant le fond de l’écran. Ne reste ensuite qu’à afficher les pixels d’une couleur différente. Ce genre de choses n’est plus nécessaire avec les nouveaux modules OLED. Il suffit de stocker les images sur la micro SD et le module les affiche à vitesse grand V.

Voici le nécessaire :
Les sources pour OpenWrt
Le paquet IPKG pour Kamikaze 7.09

Les sources ne seront peut-être pas compilables avec votre BuildRoot OpenWrt et pour cause. Il semble que les règles Build/InstallDev du Makefile de la libGD soient… heu… étranges. J’ai donc un peu bricolé dedans.

Au final, La Fonera peut afficher (doucement) de sympathiques images en 128*128 :

Miaouuuuu !

Il vous faudra aussi le module kernel proc_gpio disponible ici : http://daubau.net/proc_gpio/

La vous pourrez alimenter le module avec :
insmod proc_gpio
echo 1 > /proc/gpio/2_dir
echo 1 > /proc/gpio/2_out

Fonera en récepteur infrarouge

Dans un précédent article, je vous parlais de la nouvelle solution pour mettre en place un récepteur IR compatible Lirc sous GNU/Linux sans utiliser de module kernel via un petit montage utilisant un AVR Attiny2313. Utilisant une simple ligne RX en TTL il devient possible de l’utiliser sur un système embarqué disposant d’un port série simple (RX/TX en TTL 0/5V), j’ai nommé : La Fonera !

La solution est toute simple. Puisque le montage AVRLirc utilise une ligne RX il est possible de le connecter au port série normalement utilisé pour la console série de La Fonera. Le connecteur dans le routeur se présent ainsi :

Il suffit de connecter la patte 3 de l’AVR sur RX sans oublier la masse et récupérer l’alimentation +5V sur le circuit du routeur, tout près du connecteur d’alimentation. Le Vcc du connecteur console ne délivre qu’une tension de 3.3V.

Il faut ensuite construire un firmware OpenWRT et le configurer pour ne plus utiliser la console série. Plusieurs éléments de configuration doivent être changés.
Configurer le kernel via make kernel_menuconfig puis retirer des arguments par défaut passés au kernel la mention de la console série (Kernel Hacking / Default kernel command string).
Toujours dans la configuration du kernel, supprimer la console série : Device Drivers / Character devices / Serial drivers / Console on 8250/16550 and compatible serial port doit être désactivé.
Désactiver la console série dans l’inittab du firmware. Il suffit de supprimer la ligne concernant ttyS0 dans package/base-files/files/etc/inittab.

Une fois le firmware construit et installé sur La Fonera, le seul moyen de contacter le système est Telnet. Laissez démarrer le système (la première fois cela met un peu de temps en raison de l’effacement de la Flash non utilisée), connectez-vous en Telnet et définissez un mot de passe pour l’utilisateur root. Ceci aura pour effet d’activer le serveur SSH et de désactiver telnetd.

Configurez le système pour qu’ipkg puisse être utilisé correctement puis installer avrlirc2udp, le client. Voici un paquet binaire pour Kamilaze 7.09 et un tarball des sources à placer dans le répertoire package de l’arborescence OpenWrt :
Paquet IPKG
Tarball sources

Il ne vous reste plus qu’à configurer Lircd sur la machine hôte de votre choix en réception UDP (comme dans le billet précédent sur le sujet) et, sur le routeur d’utiliser :
avrlirc2udp -H -t /dev/ttyS0 -h 192.168.0.1
Vous disposez maintenant d’un routeur capable de recevoir des signaux IR et de les transmettre au serveur Lirc via une liaison filaire ou Wifi.

RedBoot reste utilisable au démarrage du routeur et le fait qu’il envoi des données sur le port série n’est pas un problème. La ligne TX du port du routeur n’est pas connecté. Il en va tout autrement s’il s’agit d’utiliser ce port série pour autre chose comme un modem ou un afficheur LCD. Sans doute la prochaine étape du voyage dans le hack de La Fonera.

PS : Si, comme moi, vous avez reconfiguré RedBoot pour un délai plus important (10s) il est possible de se passer du port série. Au moment du démarrage du routeur, RedBoot est en attente de connexion sur le port 9000 (à condition qu’il soit configuré correctement, IP, masque, etc). 10 secondes laissent largement le temps de se connecter avec un telnet. Malheureusement, je n’ai pas trouvé d’autre moyen pour envoyer un ^C que de faire :
% cd /tmp
% cat > break
[CTRL+V][CTRL+C][Entrée]
[CTRL+D]
puis
% nc -vvv 192.168.0.12 9000 < break; telnet 192.168.0.12 9000
C’est pas beau, il y a sûrement mieux, mais ça marche.