OpenWrt Kamikaze SVN sur La Fonera 2.0
Tags : fonera
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 :)
