Emile “iMil” Heitor ‘s home

Un p’tit fix vite fait. J’utilise, sur une Ubiquiti Litestation 2 le firmware OpenWrt Kamikaze 7.09. Je sais, c’est vieux, mais plusieurs témoignages de bricking suite à un upgrade en 8.09 ou backfire m’ont refroidit. Je place généralement mes AP publics en 802.11b afin de porter le plus loin possible. Je réalise ceci via la commande:

# iwpriv ath0 mode 11b

Sauf que, sur ma LS2, je mangeais l’erreur suivante:

Interface doesn't accept private ioctl...
mode (8BE2): Invalid argument

Rien à faire, ça foire.
J’ai trouvé un (vilain) hack pour ce problème sur le bug system de madwifi:

I get same problem using a Z-COM XG623 minPCI card (AR2413 11b&g modes) in AP mode. The failure is due to ieee80211_check_mode_consistency() that doesn’t validate 11b (2) mode because current channel (vap->iv_des_channel) is an 11g-dyn (CCK+OFDM) channel. A possible workaround is set current channel to 0 (any channel), select the requested mode (iwpriv athx mode 11b) and then configure again the rigth operating channel. This not fix the problem but allows 11b mode operations.

Et effectivement:

# iwconfig ath0 channel 0
# iwpriv ath0 mode 11b
# iwconfig ath0 channel 7

March.
Reste à rendre ce changement un peu plus élégant en modifiant le fichier /lib/wifi/madwifi.sh à la ligne 105:

iwconfig "$ifname" channel 0 >/dev/null 2>/dev/null

puisque de toutes façons, le canal est re-placé un peu plus bas.

Ce bug est probablement une typo et il semble être corrigé dans Kamikaze 8.09.

Hier, FRLinux me demande innocemment d’ajouter le module WPtouch, un chouette plugin pour WordPress, qui permet aux mobiles de visualiser le site sous forme d’application, bien plus lisible que le blog dans sa forme classique.
Ni une ni deux je m’execute… et m’aperçois que l’affichage d’iMil.net ne change pas d’un iota sur mes devices mobiles. Je me rappelle alors que le nginx placé devant l’Apache qui sert ce site cache la homepage pendant 10 minutes. Ceci explique cela.

Après quelques minutes de recherche, j’ai résolu le problème en plaçant ces quelques règles supplémentaires dans mon nginx.conf:

location / {
    set $mobile_ua '0';

    if ($http_user_agent ~* '(iPhone|iPod|mobile|Android|2.0\ MMP|240x320|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|hiptop|IEMobile)') {
        set $mobile_ua '1';
    }
    # ...directives proxypass...
    proxy_cache_key imil.net$request_uri$mobile_ua;
    # ...plein d'autres trucs...
}

Explication: on initialise une variable $mobile_ua à 0, si le User Agent match l’une des chaînes de caractères listées dans la condition if, la variable $mobile_ua est placée à 1.
La clé de cache étant maintenant composée également de cette variable, nous disposons de deux espaces de cache distincts, un pour les mobiles, l’autre pour le reste.

mmmmm nginx.

J’enquille donc sur le précédent post sur le sujet avec cette fois une configuration qui sied à une passerelle de type GNU/Linux calée en bridge derrière une freebox, voir deux billets plus bas pour l’explication de fond, nous irons à l’essentiel ici.
Dans cet exemple, eth0 représente l’interface raccordée à notre réseau privé, et eth1 celle raccordée à la freebox:

• Évidemment, il faudra activer le mode IPv6 sur votre interface free
• On place les sysctl adéquats:

  net.ipv6.conf.all.forwarding=1
  net.ipv6.conf.all.proxy_ndp=1
  # pas d'autoconfiguration pour la passerelle
  net.ipv6.conf.all.autoconf=0
  net.ipv6.conf.all.accept_ra=0

• On renseigne son IPv6, par exemple pour le sous-réseau 2a01:e35:39d7:e3e0::/64:

  ip -6 addr add 2a01:e35:39d7:e3e0::2/64 dev eth1

• On déclare sa passerelle:

  ip route add default via 2a01:e35:39d7:e3e0::1 dev eth1

• Puis on place une IPv6 qui servira de passerelle à notre réseau privé sur eth0 avec une longueur de préfixe juste suffisante:

  ip -6 addr add 2a01:e35:39d7:e3e0:1::1/126 dev eth0

• L’astuce, ici encore, consiste à proxyiser les adresses du LAN sur l’interface raccordée à la freebox afin d’apparaître comme un réseau “à plat”:

  ip neigh add proxy 2a01:e35:39d7:e3e0:1::1 dev eth1

• Il suffit alors de faire de même pour toute machine de votre LAN que vous souhaitez raccorder à l’IPv6, par exemple, toujours sur la passerelle:

  ip neigh add proxy 2a01:e35:39d7:e3e0:1::2 dev eth1

• Sur la machine qui portera l’adresse 2a01:e35:39d7:e3e0:1::2, on ajoute à l’interface son IPv6, et on déclare comme passerelle par défaut 2a01:e35:39d7:e3e0:1::1:

  ip -6 addr add 2a01:e35:39d7:e3e0:1::2/126 dev eth0
  ip route add default via 2a01:e35:39d7:e3e0:1::1

• Il conviendra de rajouter tout ce petit monde dans votre /etc/network/interfaces comme il se doit, encore une fois je vous renvoie 2 posts plus bas.

La méthode est fastidieuse et pas forcément élégante, mais tant que l’opérateur free ne se sera pas sorti les ne routera pas plus qu’un /64 dans les foyers, nous devrons nous contenter de cela… ou passer la freebox en mode routeur. Nan j’déconne.

Puisque ça fait 2-3 fois qu’on me le demande, voici un schéma du routage de sortie à la maison:

Ça a l’air tordu comme ça, mais jvous promets qu’il y a une bonne raison à tous ces choix :)

Sans vraiment y croire, je vais sur test-ipv6 avec ma tablette sous Android (une Asus Transformer), et quelle ne fut pas ma surprise de constater:

Pas d’étonnement, mon HTC Desire HD sous Android montre le même résultat:

Et histoire de me gausser, je fais le même test avec l’iPoo du boulot… bah pareil:

Ça commence à sentir bon !

Je précise qu’évidemment, ces tests ont été menés en mode WiFi et non en passant par l’opérateur de téléphonie.

Free et OVH proposent tous deux une connectivité IPv6 depuis un certain temps. Les deux ont ceci de commun que sur le papier, ils fournissent un prefixe /64, il se trouve qu’OVH fournit en réalité un /56, mais cela a peu d’intérêt pour l’astuce qui va suivre.

Les routeurs des deux sociétés s’attendent donc à recevoir du flux IPv6 depuis un réseau “plat”, et ceci pose un réel soucis lorsque vous souhaitez distribuer une connectivité IPv6 à votre réseau possiblement NATté derrière votre passerelle. Plusieurs astuces sont disponibles depuis belle lurette, parmi elles l’utilisation d’un bridge associé à une règle ebtables, mais aussi et surtout la mise en place du proxying NDP. Je me suis basé sur cette dernière méthode, que j’ai adapté à mon éternel setup: dom0 debian GNU/Linux et domU NetBSD.

La procédure est la suivante:

On active en premier lieu le mode proxy NDP ainsi que le forwarding IPv6 sur notre dom0:

sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv6.conf.all.proxy_ndp=1

Il conviendra evidemment de rendre cette configuration permanente en ajoutant ces valeurs dans le fichier /etc/sysctl.conf
Puis, sur notre interface de bridging Xen, nous ajoutons l’IPv6 dans le sous-réseau fourni par le fournisseur, cette adresse sera l’IP passerelle pour nos domUs:

# ifconfig xenbr0 inet6 add 2001:41e8:1:fe10::1/64

Toute l’astuce consiste à proxyiser l’adresse MAC de l’interface xenbr0 sur l’interface physique de la machine que voit réellement le fournisseur à l’aide de la commande ip:

ip neigh add proxy 2001:41e8:1:fe10::1 dev eth0

Il convient évidemment d’ajouter une route par défaut pour les adresses IPv6, cette dernière vous est fournie par votre fournisseur, par exemple pour OVH:

route -A inet6 add default gw 2001:41e8:1:feff:ff:ff:ff:ff

Nous attribuerons à notre domU l’IPv6 2001:41e8:1:fe10::2, ainsi, nous proxyisons également cette dernière de cette façon:

ip neigh add proxy 2001:41e8:1:fe10::2 dev eth0

Enfin, sur notre domU, nous ajoutons cette IP à l’interface raccordée au bridge ainsi qu’une route par défaut pointant vers l’IP de ce dernier:

ifconfig xennet0 inet6 2001:41e8:1:fe10::2 prefixlen 64
route -n add -inet6 default 2001:41e8:1:fe10::1

Et rendons ces paramètres permanents en ajoutant dans le fichier /etc/ifconfig.xennet0:

inet6 2001:41e8:1:fe10::2 prefixlen 64
!route -n add -inet6 default 2001:41e8:1:fe10::1

Finalement, nous inscrivons dans le fichier /etc/network/interfaces de notre dom0:

iface xenbr0 inet6 static
	2001:41e8:1:fe10::1
	netmask 64
	gateway 2001:41e8:1:feff:ff:ff:ff:ff
	# NDP / ARP proxying for xenbr0
	up ip neigh add proxy 2001:41e8:1:fe10::1 dev eth0
	down ip neigh del proxy 2001:41e8:1:fe10::1 dev eth0
	# NDP / ARP proxying for domU 1
	up ip neigh add proxy 2001:41e8:1:fe10::2 dev eth0
	down ip neigh del proxy 2001:41e8:1:fe10::2 dev eth0

Et le tour est joué.

Notez que je n’ai pas eu besoin, au contraire de ce qu’indique la documentation sur laquelle je me suis appuyé, de passer l’interface eth0 en mode promiscuous, probablement parce que j’utilise un bridge monté sur une interface de type dummy, dissocié de l’interface physique, et que les routes IPv6 de mes domU utilisent explicitement l’IP montée sur ce dernier.