Emile “iMil” Heitor ‘s home

Ça fait un petit moment que je lorgne ce que fait cette boite. D’abord, j’ai cru à un simple plagiat du modèle de wifi “communautaire” de FON. Encore une ennième boite qui compte faire son beurre sur le dos de la Communauté et consciencieusement fermer son firmware grace aux retours des divers hackers qui auront décelé pour eux les failles potentielles.
Et puis je scrute un peu ce qui se fait chez Meraki, et je lis dans quelques blogs que leur routeur semble être ouvert (comprendre, “en ssh”) par defaut… et que c’est totalement volontaire ! Voici le motd que je copy/paste depuis ce site :

BusyBox v1.1.0 (2006.09.29-21:24+0000) Built-in shell (ash)
Enter ‘help’ for a list of built-in commands.

http://meraki.net

Welcome to your meraki mini.  Please look for developer
information at http://meraki.net. We would like to encourage
you to play with this platform and add your own features to it.
However, our lawyers require us to tell you that much of
the software on this device is protected by copyrights, and
may not be redistributed or sold.

Happy Hacking!
root@meraki-node:~#

Excusez du peu, mais on est loin de la paranoïa de la firme espagnole (et dieu sait que ça m’attriste d’ecrire cela) qui a été jusqu’à désactiver le shell sur la console serie dans sa “fonera+”…

Comme le dit très bien l’ami touff, c’est la Communauté qui tranchera.

Va pas croire que jme touche hein, mais manque de pot, les trucs sur lesquels je bosse ces temps cis, je peux pas les publier. Pas encore en tout cas. L’un d’entre eux, c’est le fameux GNU/Linux Manazine numero 100, que vous trouverez dans n’importe quel kiosque à journaux si vous n’y êtes pas abonné (ce qui est probablement une erreur :). Vous y lirez mon périple lors du setup de Zone0, la future machine de GCU.

Ensuite, ma marotte depuis près d’un an, FON. Si la récente marche arrière de la compagnie au minirouteur qui a finalement fermé tout acces exterieur a suscité la colère des Foneros-hackers (sens noble, toussa), de récentes discussions avec les autorités concernées laissent supposer que notre voix a été entendue. C’est préférable, car je doute qu’il y ait une seconde chance. More to come…

Enfin, mais c’est probablement le moins interessant pour toi ami comateur de imil.net, j’ai hérité d’une charge de travail non négligeable au boulot, ce qui me pousse à parfois ramener des casse-tête à la maison, mais j’y peux rien, j’aime ça.

Ah, un truc encore, recemment quelqun sur le canal (#gcu) m’a parlé d’un bijou. Ce bijou. Et en lisant un peu ce qui a été réalisé avec ce monstre, je tombe la dessus… ouh ouh ouuuh, y’aura bientot plus besoin d’accès ADSL dans le 17ème :)) NEED NEED NEED

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.

hum hum hum…

Y’a pas longtemps, j’ai peté ma “vieille” fonera. À force d’y coller des antennes au cul, j’ai fini par casser la soudure entre le connecteur d’antenne et la carte.

Par chance, j’ai recemment été convié à la Fiesta FON, ou l’on distribuait des fonera “classiques” (comprendre “pas fonera+”). Donc nickel bien, je remplace l’ancienne, ouvre la nouvelle, tout est ok. Sauf que non. Puisque désormais, evidemment, le portail FON ne me voit plus connecté :(
Alors comme ça, pour voir, j’ai été jeter un oeil dans les divers scripts de la fonera, me disant qu’après tout, pour localiser du materiel, ils devaient probablement se baser soit sur le S/N, soit une ou plusieurs MAC. Et bin ouais.
Si vous deviez, comme moi, changer voter fonera et que vous n’avez pas la patience d’attendre la réponse du support de FON, je vous conseille l’édition du fichier /bin/thinclient (oui, encore lui), et le hardocage des variables ETMAC et WLMAC, qui représentent respectivement l’adresse MAC de la carte ethernet et l’adresse MAC du lien WiFi public.
Exemple:

ETMAC="00:18:84:30:40:50"
WLMAC="00:18:84:30:40:51"

J’ai noté que dans les deux foneras, la MAC du lien wireless était la MAC du lien ethernet + 1.
Pour finir, on démarre thinclient en mode standalone :

/bin/thinclient start

Et on verifie que le portail FON ne dit plus que votre routeur est déconnecté :)

Si ça peut dépanner…

J’ai refait mon LAN. Dans les grandes lignes, une Fonera flashée en DD-WRT bridge la connexion au net via une freebox. Le wrt est le routeur du LAN, il est connecté à un bete switch sur lequel est branché une Fonera “legacy”, qui me fournit l’acces WiFi de manière classique via son SSID “MyPlace”.

Jusque là, rien de particulier.
Mais dans ce petit réseau, j’ai également des téléphones SIP dont un white, WiFi donc. Et comme vous le savez probablement, SIP et plus particulièrement RTP ne font pas bon ménage avec du NAT. Pour pallier ce problème, j’ai l’habitude d’utiliser des liens privés vers mes Asterisk en utilisant OpenVPN. J’ai testé par mal de packages avant de trouver une combinaison fonctionnelle sur Fonera/DD-WRT. En effet, les packages openvpn, libopenssl et liblzo disponibles ici: http://ipkg.k1k2.de/packages/ coredumpent simplement. Voici les emplacements de packages qui marchent:

http://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/libopenssl_0.9.8e-1_mips.ipk
http://ipkg.hotsplots.de/kamikaze/7.06/atheros-2.6/packages/liblzo_2.02-1_mips.ipk
http://ipkg.hotsplots.de/kamikaze/7.06/atheros-2.6/packages/openvpn_2.0.9-1_mips.ipk

J’ai également trouvé de très bons tips à cette adresse:

http://www.dd-wrt.com/wiki/index.php/OpenVPN

notemment quelques informations relatives au règles iptables à placer sur le DD-WRT après que le tunnel soit établi pour assurer un routage sans encombres.