# 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.

Deux OpenWRT configurés en simples bridges permettent aux invités de se raccorder au VLAN dédié au wireless public :

/etc/config/wireless

config wifi-device  wifi0
        option type     atheros
        option disabled 0
        option mode             11b
        option distance         10000
        option diversity        0
        option txantenna        1
        option rxantenna        1
        option channel          6

config wifi-iface
        option device   wifi0
        option ifname   ath0
        option network  lan
        option mode     ap
        option ssid     Empire-Network
        option encryption none
        option txpower 18

/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 ifname   eth0 ath0
        option type     bridge
        option proto    static
        option ipaddr   192.168.200.253
        option netmask  255.255.255.0

Où un serveur dhcp leur fournira une IP dans le subnet adéquat. Un simple règle pf redirigera alors toute requète http vers un portail captif qui expliquera à l’invité quelles informations entrer dans son browser afin de pouvoir utiliser HTTP, HTTPS et FTP (notez que pour le moment un seul sur une bonne 30aine a reussi à effectuer cette opération heutement technique…). Quelques règles de QoS m’assurent que l’invité ne crame pas toute ma bande passante :

/etc/pf.conf

int="fxp0"

table <empire_guests> { 192.168.200.0/24, ! 192.168.200.254, ! 192.168.200.253, ! 192.168.200.252 }

altq on $int cbq bandwidth 28Mb queue { empirenet_in, empirenet_out }
queue empirenet_in bandwidth 2Mb priority 1 cbq(default)
queue empirenet_out bandwidth 128Kb priority 7

rdr on $int inet proto tcp from any to <empire_guests> port www -> 127.0.0.1 port 80

pass in on $int from any to <empire_guests> queue empirenet_in
pass out on $int from <empire_guests> to any queue empirenet_out

L’utilisateur passe alors via Squid et son activité est soumise au filtrage de squidGuard dans lequel j’ai interdit les catégories !aggressive !violence !hacking !ads !porn !warez !suspect.
J’applique sur le switch des access-list par port qui n’autorisent que les protocoles HTTP, SSH et DHCP.

[...]
ip access-list extended wifiout
 permit ip any host 192.168.200.254
 permit tcp any any eq http
 permit udp any any eq bootps
 permit tcp any any eq ssh
[...]
interface e 18
 ip access-group wifiout in
[...]

Le tout est graphé par Cacti, notemment grace à l’extension dhcpd-snmp de Net-SNMP et au template cacti associé.

Si vous passez dans le 17eme, cherchez le ssid “Empire-Network” :)

update

Bon bah en fait si, y’aura un article :)

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.

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.

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

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.

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.