Emile "iMil" Heitor 's home

Pour ceux qui ne connaissent pas encore cette methode magique pour accéder au réseau IPv6, je vous invite à jeter un oeil à cette news.

Il semble qu’il y ait un problème de dépendance dans le package kmod-ipv6 de Kamikaze. En effet, ce dernier installe le module sit.ko nécessaire au montage d’un tunnel 6to4, mais pas le module tunnel4.ko dont sit.ko dépend.

On s’execute :

# ipkg install kmod-iptunnel4

On automatise le chargement de sit.ko

# cat > /etc/modules.d/40-sit
sit
^D

Et pour la session courante :

# insmod sit

l’installation du package kmod-iptunnel4 a déjà chargé le module tunnel4.

La methode “officielle” sous linux pour monter ce type de tunnel est d’utiliser la commande ip. Si ce n’est déjà fait, installez le package :

# ipkg install ip

Reste à monter le lien :

root@OpenWrt:~# ip tunnel add tun6to4 mode sit ttl 64 remote 192.88.99.1 local [votre.ipv4.publique]
root@OpenWrt:~# ip link set dev tun6to4 up
root@OpenWrt:~# ip -6 addr add [votre:ipv4:convertie:en:ipv6]/16 dev tun6to4
root@OpenWrt:~# ip -6 route add 2000::/3 via 2002:c058:6301:: dev tun6to4 metric 1

Quelques mots sur cette barbarie. Vous lirez dans les docs officielles que la création du tunnel se fait de cette façon :

# ip tunnel add tun6to4 mode sit ttl [ttlpardéfaut] remote any local [adresseipv4locale] 

Bah merci, mais ça marche pas. Heureusement, fosco a mis la main à la pate et a découvert qu’en remplaçant any par l’IP de la gateway 6to4 (elle possède toujours la meme IP), ça fonctionnait tout de suite mieux.

Nota: Voir l’update en fin de ce billet.

Pour obtenir la conversion de votre IPv4 en IPv6, vous pouvez utiliser la commande suivante (directement pompée de la sus-citée doc officielle) :

ipv4="1.2.3.4"; printf "2002:%02x%02x:%02x%02x::1" `echo $ipv4 | tr "." " "`

Enfin, 2002:c058:6301::, gateway par defaut, n’est autre que l’IPv6, toujours la meme également, des passerelles 6to4.

Finalement, grace à tout ça :

root@OpenWrt:~# ping6 -c1 www.6bone.net
PING 6bone.net (2001:5c0:0:2::24): 56 data bytes
64 bytes from 2001:5c0:0:2::24: icmp6_seq=0 ttl=62 time=236.1 ms

--- 6bone.net ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 236.1/236.1/236.1 ms

Il ne vous reste plus qu’à router vos réseaux.

Quelques autres bons tips sont disponibles le Wiki OpenWRT

Update

Voici finalement ma conf, fonctionnelle, qui contredit les infos précédentes :

root@OpenWrt:~# cat /etc/init.d/ipv6.sh
#!/bin/sh

. /etc/functions.sh

IPV4=$(uci get network.wan.ipaddr)
IPV6PREFIX=$(printf "2002:%02x%02x:%02x%02x" `echo $IPV4 | tr "." " "`)

ip tunnel add tun6to4 mode sit ttl 64 remote any local $IPV4
ip link set dev tun6to4 up
ip -6 addr add ${IPV6PREFIX}::1/16 dev tun6to4
ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1

ip -6 addr add ${IPV6PREFIX}:1::1/64 dev br-lan

Il semble que le dysfonctionnement du mot clé any soit lié à la manière d’annoncer la passerelle 6to4. En effet, lorsque j’annonce la route en utilisant la notation ::192.88.99.1, la documentation officielle s’applique parfaitement.

dnsmasq, un cache DNS intégrant un serveur DHCP embarqué dans Kamikaze, réagissait de manière assez surprenante. En effet, la configuration de base :

config dhcp
        option interface        lan
        option start    100
        option limit    150
        option leasetime        12h

config dhcp
       option interface        wan
       option ignore   1

laissait présumer que ce dernier allait servir le DHCP sur le réseau “lan” et ignorer le réseau “wan”. Mais contre toute attente :

663 nobody      400 S   /usr/sbin/dnsmasq -I ath1 --dhcp-range=wan,un-pool-d'ips-sur-le-reseau-wan

ath1 étant mon interface wan.

Après avoir bidouillé un peu le fichier /etc/config/dhcp, voici un (le ?) format qui fait faire ce que je souhaite à dnsmasq :

config dhcp
        option interface        lan
        option start    100
        option limit    150
        option leasetime        12h
        option ignore   0

#config dhcp
#       option interface        wan
#       option ignore   1

Bug ou feature, j’attend un sursaut de #openwrt.

Je trouvais ça un peu dommage de pas utiliser le second SSID de la Fonera, par exemple pour en faire un bridge sur le LAN. Après un brin de recherches, voici la conf nécessaire à l’activation et l’utilisation d’ath0 et d’ath1 :

config wifi-device  wifi0
        option type     atheros
        option disabled 0
        option mode             11bg
        option diversity        0
        option txantenna        1
        option rxantenna        1

# l'interface client
config wifi-iface
        option device   wifi0
#        option network  wan
        option mode     sta
        option ssid     empire
        option bssid    CA:CA:CA:FE:FE:FE
        option key      donnemoitoncorpsbebe
        option bgscan   0
        option encryption psk
        option txpower 18
        
# l'interface à bridger
config wifi-iface
        option device wifi0
        option mode ap
        option network lan
        option ssid OpenWRT
        option encryption psk
        option key ohouitoncorpsbebe

Puis :

root@OpenWrt:~# cat /etc/config/network 
# Copyright (C) 2006 OpenWrt.org

config interface loopback
        option ifname   lo
        option proto    static
        option ipaddr   127.0.0.1
        option netmask  255.0.0.0

config interface lan
        option ifname   eth0 ath0
        option type     bridge
        option proto    static
        option ipaddr   192.168.1.254
        option netmask  255.255.255.0

config interface wan
        option ifname   ath1
        option dns "212.27.53.252 212.27.54.252"
        option proto    static
        option ipaddr   212.20.30.40
        option netmask  255.255.255.0
        option gateway  212.20.30.254

Un /etc/init.d/network restart n’est pas suffisant pour prendre cette nouvelle conf en charge, en effet, les rules de firewalling et l’interpretation de pas mal de variables ne sont pas totalement faites. Un petit reboot du routeur permettra de s’assurer que tout est opérationnel.

NB: ah, evidemment pour que l’AP puisse gérer le WPA/WPA2, vous aurez besoin du package hostapd. De meme, pour pouvoir authentifier le client sur un AP en WPA/WPA2, vous aurez besoin de wpa-supplicant :

root@OpenWrt:~# ipkg install hostapd wpa-supplicant

Finalement, je suis presque content de ma déception passée sur DD-WRT-sale. J’ai pu me plonger corps et âme dans l’apprentissage de Kamikaze, la nouvelle version d’OpenWRT, entre autres fonctionnelle pour… la Fonera evidemment.

Alors oui, la GUI est pourrie et buggée. Ok. Mais tu sais quoi ? dans un firmware bien rangé, c’est vraiment pas problématique.
Explication.

Déjà, et c’est pas rien, les gens d’OpenWRT ont des packages qui marchent :

root@OpenWrt:/etc/config# ipkg update
Downloading http://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
Updated list of available packages in /usr/lib/ipkg/lists/release
Downloading http://downloads.openwrt.org/kamikaze/packages/mips/Packages
Updated list of available packages in /usr/lib/ipkg/lists/packages
Downloading http://downloads.x-wrt.org/xwrt/kamikaze/7.09/atheros-2.6/packages/Packages
Updated list of available packages in /usr/lib/ipkg/lists/X-Wrt
Done.

Pardon mais ça fait du bien.
Ensuite, exit les nvram show|grep maiscestquoilaclé, on a un beau /etc/config tout bien structuré et read/write, car les bonhommes sont pas crétins :

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
none                      6.6M     92.0k      6.6M   1% /tmp
tmpfs                   512.0k         0    512.0k   0% /dev
/dev/mtdblock3            5.9M      2.4M      3.5M  41% /jffs
mini_fo:/jffs             1.0M      1.0M         0 100% /

Fonctionnellement, j’ai besoin des choses suivantes:
. Rediriger un / des ports
. Router statiquement vers d’autres réseaux
. Monter un OpenVPN client
. monitorer le routeur en SNMP

Accroche-toi lutin, ça fait mal tellement c’est bien gaulé :

Redirection de ports

root@OpenWrt:~# tail -2 /etc/config/firewall 
forward:dport=2222:192.168.10.3:22
forward:dport=6890-6999:192.168.10.5

routage statique

Ajouter au /etc/config/network :

config route blah
        option interface lan
        option target 192.168.12.0
        option netmask 255.255.255.0
        option gateway 192.168.10.10 

OpenVPN

root@OpenWrt:~# ipkg install openvpn

Suivi de la conf classique d’OpenVPN

SNMP

root@OpenWrt:~# ipkg install snmpd

(trop dur)

Afin d’assurer le lancement automatique des services à chaque reboot d’OpenWRT, on ln -s dans /etc/rc.d, assez classiquement ma foi.

Quelques liens du meilleur effet :
Client Mode HOWTO
La doc officielle
La doc d’install

On notera qu’un

svn checkout https://svn.openwrt.org/openwrt/trunk kamikaze

prend quelques minutes et pèse environ 100 Megs contre les quelques heures et les 17Go de DD-WRT. Mais surtout, que le premier builde sans ruses minables visant à contourner l’absence de modules que l’auteur aura choisi de ne plus distribuer.

Allez, va mourrir dans un coin BS.

Ça fait plusieurs jours que je bataille avec ma seconde fonera munie d’un firmware OpenWRT Kamikaze avec des logs du genre :

Associated with xx:xx:xx:xx:xx:xx
Authentication with xx:xx:xx:xx:xx:xx timed out.

wpa_supplicant faisait sa mauvaise tête, impossible d’associer Kamikaze à la première Fonera en WPA / TKIP. J’avais lu que la release 7.06 était dispo et j’ai pas cherché plus loin, ntt ntt iMil enfin… un peu de jugeote. En allant jeter un oeil sur l’arbo d’OpenWRT je m’aperçois qu’une version 7.07 était dispo et que le Changelog explique bien clairement :

Changes since Kamikaze 7.06
---------------------------
[bla, bli, blu]
- WPA related bugfixes in the wifi scripts for Broadcom and Atheros

Bien vu.

Ni une ni deux, je m’engage dans l’upgrade du firmware. Dans la mesure du possible, j’aime bien me caler sur des docs de gentils hackers qui ont galéré avant moi, du coup j’ai trouvé cette doc, qui même si elle est ecrite en allemand, langue à laquelle je bite pas un mot, highlighte bien consciensieusement les parties “code”.
Je résume pour la forme :

. On récupère http://downloads.openwrt.org/kamikaze/7.07/atheros-2.6/openwrt-atheros-2.6-vmlinux.lzma
. On récupère http://downloads.openwrt.org/kamikaze/7.07/atheros-2.6/openwrt-atheros-2.6-root.squashfs

Puis moyennant le setup d’un serveur tftp (je vais pas expliquer cette partie résumée dans 782364892 blogs), on soumet RedBoot de cette façon :

RedBoot> ip_addr -l ip_de_la_fonera/cidr -h ip_du_serveur_tftp
RedBoot> fis init
RedBoot> load -r -b %{FREEMEMLO} openwrt-atheros-2.6-vmlinux.lzma
RedBoot> fis create -e 0x80041000 -r 0x80041000 vmlinux.bin.l7
RedBoot> load -r -b %{FREEMEMLO} openwrt-atheros-2.6-root.squashfs
RedBoot> fis create -l 0x6f0000 rootfs
RedBoot> fis load -l vmlinux.bin.l7
RedBoot> exec

Et nous voici en 7.07.

Afin d’assurer l’association en WPA, vous aurez evidemment besoin du package wpa-supplicant.
On setup une conf réseau minimale (on suppose que la fonera est pour le moment branchée via un lien classique ethernet sur un reseau dont la gate est 192.168.20.254)

# ifconfig eth0 192.168.20.2 netmask 255.255.255.0
# route add default gw 192.168.20.254

On edite le resolv.conf puis

# ipkg update
# ipkg install wpa-supplicant

et eventuellent

# ipkg install wpa-cli

Pour les plus faignants, voici à quoi ressemble mon /etc/config/wireless, fichier interprété par les initscripts de Kamikaze pour démarrer wpa_supplicant. L’/etc/config/network varie selon la topo cible (bridge, client routé, client bridge…)

config wifi-device  wifi0
        option type     atheros
        option disabled 0
        option mode             11bg
        option diversity        0
        option txantenna        1
        option rxantenna        1

config wifi-iface
        option device   wifi0
        option network  lan
        option mode     sta
        option ssid     MyPlace
        option bssid    xx:xx:xx:xx:xx:xx
        option key      1234567890
        option bgscan   0
        option encryption psk

Un petit /etc/init.d/network restart, on attend qques secondes, on regarde le resultat via wpa_cli et ça devrait être la teuf.