Adieu DG834G, bonjour WRT54GL et OpenWRT

Table des matières

Mon fidèle modem-routeur Netgear DG834Gv3 m'a lâché récemment. Comment ? Bah il a tout simplement grillé alors que tous les appareils qui lui sont connectés directement ou indirectement étaient éteint. Il n'y avait pas non plus d'orage ce jour là mais un beau soleil. Un problème d'origine électrique est aussi à exclure car il était raccordé au secteur via une alimentation sans interruption en interaction avec le réseau (ce que certains appellent "onduleur" in-line) qui a fait ses preuves. Bref : une mort mystérieuse.

Hommage au DG834Gv3

Ce modem-routeur répondait à la plupart de mes besoins exceptés la QdS et une gestion assez chaotique des VPN.

Il permettait entre autre de gérer le Wake On Lan qui est une technique permettant d'allumer un ordinateur à "distance", via le réseau, via l'ajout d'un "module". Voir à cette adresse pour le CGI et les fichiers HTML : Wake on lan utility for DG834(G) routers by Alessandro Soggia. J'avais compilé à la fois l'utilitaire et le firmware afin de :

  • pouvoir utiliser la dernière version du firmware Netgear (4.01.40) alors que l'image pré-compilée disponible sur le site utilise le firmware 4.01.19
  • mettre à jour la page "menu.html" afin que les options ajoutées avec le nouveau firmware (exemple : WDS) ne disparaissent pas du menu et aussi pour que le menu affiche "Wake On Lan" et pas un énigmatique "WOL"
  • faire en sorte que le formulaire soit pré-rempli avec l'adresse de diffusion de mon réseau et l'adresse MAC de l'ordinateur à allumer
  • traduire un peu les messages affichés, tant qu'à faire

Je met à votre disposition :

Attention si vous utilisez le firmware que j'ai compilé : d'une part, le formulaire est pré-rempli avec l'adresse de diffusion de mon réseau, qui ne sera peut-être pas la même chez vous et avec l'adresse MAC d'un de mes ordinateurs, qui ne sera pas, à coup sûr, l'adresse MAC de votre ordinateur. Ensuite, je n'ai mis que les fichiers HTML de la version française. Si vous utilisez une autre langue, vous n'aurez pas accès à l'utilitaire via l'interface web, à moins de taper l'URL directe dans votre navigateur.

Le remplaçant

Le premier remplaçant fût un DG834Gv5. Malheureusement le hardware et le software ont bien changés et Netgear a compliqué les tentatives de bricolage.

En effet, les modules CGI semblent être compilés directement dans le démon HTTPD. Difficile donc d'utiliser l'ancien CGI. Si encore j'avais pu trouver un "how to".

J'imagine une autre solution : activer le serveur telnet présent sur le routeur, utiliser la commande arp pour fixer l'association entre l'adresse IP du PC à réveiller et son adresse MAC de manière permanente. Ainsi, il me suffirait de rediriger le port 9 vers l'adresse IP du PC à réveiller et cela fonctionnerait. Malheureusement, la version de busybox intégrée dans le DG834Gv5 ne contient pas la commande arp. Qu'à cela ne tienne : utilisons la commande ip ... qui est aussi indisponible.

Je regarde alors les sources et je tombe sur le fichier product/U12L060_RETAIL_ST/open-src/applications/busybox-1.2.1/.config. Je remarque que toutes les commandes qui sont disponibles sur busybox sont à "yes" dans ce fichier (ex : CONFIG_IFCONFIG=y et la commande ifconfig est disponible). Je pense donc qu'il suffirait de passer CONFIG_ARP à "y" pour que la commande soit disponible. Il ne me reste donc plus qu'à compiler le firmware avec ce changement.

C'est là que commencent les problèmes. D'abord, le script cxnt_setenv.sh qu'il faut lancer avant le make, selon les instructions (qui datent de 2008 : "Date : 2008 Nov. 21th") se termine en erreur. Ensuite la commande make trébuche sur quelques labels introuvables dans les makefile. Difficile de recréer les sections des makefile que nous n'avons pas. Entêté, je continue néanmoins à chercher.

Mais l'interface web d'administration du routeur est souvent inaccessible et il faut redémarrer le routeur pour y avoir de nouveau accès. Sur le modèle de Dodo, il arrive que le net se coupe, sans raison et seul un redémarrage du routeur peut faire revenir le net. En revanche, aucun souci du côté de l'administration. Devant un tel fail de Netgear, et surtout parce que quand j'achète un routeur que je configure souvent je ne souhaite pas avoir une administration souvent inaccessible, je décide de retourner le DG834Gv5 au magasin et de m'acheter autre chose.

Finalement, le remplaçant sera un Linksys WRT54GL v1.1 couplé à un Netgear DM111P. L'ensemble est plus cher (quelle surprise !) mais bien plus bidouillable.

Choix d'un firmware alternatif pour le WRT54GL v1.1

Afin de ne pas partir dans tous les sens, je décide de ne comparer que les firmwares alternatifs que je connaissais (uniquement de nom) avant : OpenWRT et DD-WRT.

Il apparait que les fonctionnalités sont les mêmes, offertes de manières différentes. Je n’ai pas réussi à séparer les deux firmwares sur les fonctions qui me sont nécessaires.

En cherchant un peu, je trouve des informations subjectives selon lesquelles OpenWRT serait plus bidouillable que DD-WRT, que OpenWRT est moins "user friendly", que OpenWRT est vraiment fait pour les geeks/bidouilleurs. C'est cela qui m'a convaincu d'utiliser OpenWRT : après le fail du Netgear devenu bien moins bidouillable en même pas deux versions, il était hors de questions que je n'aie pas le contrôle.

Installation

Parmi les différentes "versions" d'openWRT, j'ai décidé de prendre la plus récente, Backfire 10.03 qui a été diffusée le 6 avril 2010. Après, il faut choisir entre brcm-2.4 ou brcm47xx. La différence notable est que brcm-2.4 contient un noyau Linux 2.4 alors que brcm47 contient un noyau 2.6. L'autre différence, si j'ai bien compris, vient du fait que la déclinaison brcm47 ne contient plus de code propriétaire de Broadcom en ce qui concerne la gestion du wifi. Aprés, il y a des petits détails : on ne peut pas utiliser le filtrage par adresse MAC des stations Wifi ni définir le rôle de chaque antenne du WRT54GL sur la déclinaison bcrm47xx. Voir la fin de ce billet et les commentaires pour plus d'informations.

ÉDIT 26/08/2011 15h05 : Évidemment, la déclinaison brcm47 occupe plus de place dans la mémoire du routeur, ce qui fait qu'il reste moins de place pour vos applications. Pour vous donner un ordre d'idée : sur mon WRT54GL, il reste 1.2M après l'installation de la déclinaison bcrm-2.4 de Backfire 10.03 alors qu'il ne reste que 820k après l'installation de la déclinaison bcrm47xx.

Personnellement, j'ai d'abord commencé par installer la déclinaison brcm 2.4 depuis l'interface web de Linksys. D'une part car on disait que le wifi ne fonctionnait pas avec le noyau 2.6 et que la commande nvram n'existait plus et ne permettait plus d'activer le boot_wait, c'est à dire l'option qui permet au bootloader de recevoir un firmware propre via TFTP si jamais le firmware interne est endommagé. Mais étant passé ensuite à la déclinaison brcm47, je peux vous dire que le wifi fonctionne très bien et que la commande nvram est disponible et fonctionnelle. Preuve :

root@OpenWRT:~# uname -a
Linux OpenWRT 2.6.32.10 #20 Tue Apr 6 15:53:48 CEST 2010 mips GNU/Linux
root@OpenWRT:~# nvram get boot_wait
off
root@OpenWRT:~# nvram set boot_wait=on
root@OpenWRT:~# nvram get boot_wait
on
root@OpenWRT:~# nvram commit

Vous pouvez donc installez directement une déclinaison brcm47xx sans problèmes.

Dans la suite de ce tutoriel/guide, je considère que vous avez choisi le même firmware que moi, à savoir :
OpenWRT Backfire 10.03 brcm47xx pour le WRT54G au format squashfs.

Que faire si vous avez endommagé le firmware interne

Avant de continuer, il me paraît évident d'en parler. OpenWRT propose deux modes : le failsafe mode et le flashage en récupérant l'image via TFTP.

Si les dommages ne sont pas trop importants, vous pouvez utiliser le failsafe mode (= mode sans échec). Comme je l'ai dit dans les commentaires, je n'ai jamais réussi à utiliser ce mode. En effet, je reçois le paquet en broadcast, j’appuie sur le bouton "reset" mais je ne reçois pas de paquet "Entering failsafe". La led DMZ clignote rapidement et la led "on" clignote à un débit normal. Le routeur ne répond à rien, pas même les requêtes ARP. Difficile dans ces conditions d'utiliser le mode sans échec.

Si les dommages sont plus importants ou que vous n'avez pas accès au failsafe mode, vous pouvez utiliser le flashage du firmware. Pour que cela fonctionne, la variable boot_wait doit être à "on" ! (voir ci-dessus). Celle-ci permet de mettre en pause le processus de boot pour attendre une éventuelle connexion TFTP. Il suffit de changer sa valeur une fois et de faire un commit pour qu'elle soit conservée indéfiniment, même si vous flasher votre routeur.

Sous GNU/Linux, il faut installer l'utilitaire atftp, si ce n'est pas déjà fait, puis suivre le tutoriel officiel.

Sous Windows, j'utilise le client TFTP de Linksys.

Quel que soit votre système d'exploitation, la marche à suivre est très simple : il faut lancer l'envoi du firmware, que ce soit avec l'outil TFTP de Linksys ou avec atftp, pile 3 secondes après avoir mis le routeur sous tension. En tout cas, il faut procéder comme cela avec un WRT54GL v1.1.

Voici quelques conseils pour la route :

  • N'oubliez pas de désactiver temporairement votre pare-feu ou d'y autoriser le protocole TFTP. Si vous ne le faites pas et si vous êtes sous GNU/Linux, vous aurez une erreur "Operation not permitted".
  • Vu le timing serré, il vaut mieux utiliser une configuration statique de la pile réseau. En clair : pas de DHCP.
  • Placer un intermédiaire (switch, hub, ...) entre le routeur et le PC qui servira à remettre le firmware permet d'éviter de manquer le moment pendant lequel le routeur est disposé à recevoir le nouveau firmware à cause d'un système d'exploitation qui annonce que le câble réseau est débranché.
  • Enfin, je vous recommande de lancer la commande "ping" en direction du routeur (sous Windows pensez à ajouter le paramètre -N 100 pour que le ping dure plus longtemps). Cela permet à l'ordinateur et au routeur d'échanger leur adresse MAC via le protocole ARP ce qui permet de gagner du temps lors de l'envoi TFTP.

Configurer OpenWRT

Deux modes sont disponibles : l’interface web (LuCi) ou la ligne de commande (uci). Avec le temps, vous préférerez uci ;) .

Quelques correspondances générales entre LuCi et uci

Afin de vous faire aimer Luci, je vous met ici les correspondances entre LuCi et uci. VOus n'avez donc plus d'excuses pour ne pas manipuler uci.

Status -> Interface

Mélange entre la commande ifconfig, brctl show et /proc/switch .

Status -> Firewall
iptables -t filter -L -n && iptables -t nat -L -n && iptables -t mangle -L -n
Status -> Connexions actives
arp && netstat -taupn
Status -> Routes
route -n
Status -> Journal système
logread

Pour écrire quelque chose dans ce journal, utilisez la commande :

logger <votre message>
Status -> Journal du noyau
dmesg
Système -> Système -> Nom d’hôte
uci set system.@system[0].hostname="Nouveau_nom"
Système -> Système -> Fuseau horaire
uci set system.@system[0].zonename=Europe/Paris 2>/dev/null
uci set system.@system[0].timezone=CET-1CEST,M3.5.0,M10.5.0/3 2>/dev/null

Pour les timezones, voir le wiki d'OpenWRT

Système -> Logiciels
Éditez la liste des paquets et le répertoire de destination
vi /etc/opkg.conf
Mettre à jour la liste des paquets
opkg update
Télécharge et installe le paquet
opkg install <nom du paquet>
Filtrer
opkg search *nom du paquet*

ou

opkg list | grep *nom du paquet*
Installed packages
opkg list-installed
Available packages
opkg list
Système -> Mot de passe administrateur
passwd
Système -> Clés SSH
vi /etc/dropbear/authorized_keys
Système -> Processus

Mélange entre la commande ps et la commande top.

Signal (HUP)

Plutôt que d'utiliser la commande kill (kill -s SIGHUP pid ou kill -1 pid), on préférera utiliser /etc/init.d/processus restart.

Terminer

Même remarque que ci-dessus. kill -s SIGTERM pid ou /etc/init.d/processus stop

Tuer
kill -9 pid
Système -> Configuration des leds

Voir à la fin de ce billet.

Système -> Flash firmware

Méthode TFTP (voir ci-dessus) ou :

cd /tmp/
wget http://downloads.openwrt.org/backfire/10.03/brcm47xx/openwrt-brcm47xx-squashfs.trx
mtd write /tmp/openwrt-brcm47xx-squashfs.trx linux && reboot
Système -> Redémarrage
reboot
Services -> initscripts
/etc/init.d/script enable/disable/start/restart/stop
Services -> dropbear SSHd

Pour voir les valeurs de chaque paramètre associè à dropbear :

uci show | grep dropbear

Pour modifier la valeur d'un paramètre :

uci set <nom complet du parametre>
Services -> dnsmasq

Même raisonnement que pour dropbear SSHd

Services -> Taches régulières

Voir : OpenWrt Scheduling Jobs With cron on OpenWrt.

Réseau -> Interfaces

Tout se configure en éditant le fichier /etc/config/network

Les bridges peuvent être configurés avec l'utilitaire brctl

Réseau -> Wi-Fi

Il suffit d'éditer le fichier /etc/config/wireless

Réseau -> Switch

Les VLANs se cofnigurent depuis le fichier /etc/config/network

Réseau -> DHCP

Pour voir les valeurs de chaque paramètre associè au dhp:

uci show | grep dhcp

Pour les éditers, vous connaisez déjà la procédure. Pour ajouter des associations statiques, ajoutez des entrées dhcp.@host[x] avec uci set. Exemple :

dhcp.@host[0]=host
dhcp.@host[0].name=Serveur_NFS
dhcp.@host[0].mac=00:11:22:33:44:55
dhcp.@host[0].ip=192.16.1.25
Réseau -> Nom d'hotes

Ajoutez des entrées dhcp.@domain[x] avec uci set. Exemple :

dhcp.@domain[0]=domain
dhcp.@domain[0].name=NFS_SERVER
dhcp.@domain[0].ip=192.168.1.25
Réseau -> Routes statiques

Tout se configure avec l'utilitaire route.

Réseau -> Pare-feu

Tout se règle avec iptables.

Activer SSH et désactiver implicitement telnet

Il faut changer le mot de passe pour le compte root, soit via l'interface web, soit via telnet (avec la commande passwd).

Avoir l'interface web en français

Il faut installer le package luci-i18n-french :

root@OpenWRT:~# opkg update
root@OpenWRT:~# opkg install luci-i18n-french

Note : opkg update doit être lancé après chaque reboot du routeur si vous souhaitez installer un package et/ou obtenir la liste des packages disponibles (commande opkg list).

Normalement, la langue doit s'activer toute seule. Néanmoins, si ce n'est pas le cas, il faut aller dans le menu "Overwiev" => "User Interface" et choisir la langue française dans la liste déroulante.

Utiliser un service de DNS dynamique (exemple : DynDNS.com)

Il faut installer le package ddns-scripts et le package luci-app-ddns si vous souhaitez configurer cela depuis l'interface web. Chez moi, l'option n'est apparue dans l'interface web qu'après un reboot complet de la machine. Un reboot du démon uhhtpd (démon HTTP) n'a pas suffit.

Utiliser la QdS

Si vous voulez configurer la QdS à la main avec iptables et Traffic Control, vous avez seulement besoin du package tc. Sinon, vous pouvez installer le package qos-scripts et luci-app-qos et configurer la QdS depuis l'interface web. Remarquons que les règles pré-écrites sont incomplètes : il manque par exemple la priorisation des flags ACK de TCP.

Gagner du temps au démarrage

J'empêche, via l'interface web, le démon USB de démarrer en même temps que le routeur car le WRT54GL ne possède pas de ports USB. Puis je m'assure que telnet ne se relancera jamais, même par erreur, au démarrage, dans le but d'accroitre la sécurité (oui, telnet n'est pas un protocole sécurisé) :

rm /etc/rc.d/S50telnet

Configurer SSH

Je change le port sur lequel écoute dropbear (démon SSH). Pour cela, il faut éditer le fichier /etc/config/dropbear en changeant la ligne "Port".

Ensuite, j'ouvre le port, dans iptables, pour qu'il soit accessible depuis internet et je protège le service contre une attaque par brute force. Pour faire cela, il faut éditer le fichier /etc/firewall.user avec vi, par exemple, et ajouter :

iptables -A input_wan -p tcp --dport 7523 -m state --state NEW -m recent --name ATTACKER_SSH --rsource --update --seconds 600 --hitcount 2 -j DROP
iptables -A input_wan -p tcp --dport 7523 -m state --state NEW -m recent --name ATTACKER_SSH --rsource --set
iptables -A input_wan -p tcp --dport 7523 -m state --state NEW -j ACCEPT

Notes :

  • 7523 est le port choisi.
  • Ce code est inspiré de celui fourni sur le wiki officiel mais lui fonctionne, au moins ;) .
  • Ce code nécessite que les packages iptables-mod-conntrack-extra et kmod-ipt-conntrack-extra soient installés. Ils ne le sont pas par défaut.

Explication rapide : L'attaquant sera donc bloqué pendant 10 minutes après 2 connexions (qui permettent chacune d'essayer 10 mots de passe). On ne peut pas plus réduire le nombre de connexions. Si vous mettez 1, vous ne devrez jamais vous tromper quand vous tapez le login. Car dans ce cas, vous devrez quitter la session et en recommencer une mais vous serez alors bloqué pendant 10 minutes. Évidemment, cela s'applique uniquement aux paquets venant d'internet, pas du LAN.

Pour le fun vous pouvez aussi changer le message qui s'affiche quand vous vous connectez via SSH. Pour cela, il faut modifier le fichier /etc/banner. Mettez un message original. ;) Notez que le fichier /etc/banner est appelé automatiquement par défaut par dropbear, le démon SSH et qu'il ne sert à rien de dé-commenter la ligne "option BannerFile '/etc/banner'" dans le fichier /etc/config/dropbear à moins que vous ne vouliez que le message s'affiche deux fois : une fois lors de l'ouverture de la connexion, l'autre fois après une validation réussit d'un mot de passe.

Vous pouvez maintenant rebooter le démon SSH ainsi que le firewall afin que les modifications soient prises en compte:

­root@OpenWrt:~# /etc/init.d/dropbear restart
­root@OpenWrt:~# /etc/init.d/firewall restart

ÉDIT du 09/07/2011 à 0h05 : Pour apporter plus de sécurité lors de vos connexion SSH depuis l'extérieur (par exemple pour faire des tunnels ;) ), vous pouvez créer un compte utilisateur qui ne possédera pas les droits d’administration. Pour cela, voir ce billet : Créer un compte utilisateur sans droits sur OpenWRT. Fin de l'édit

ÉDIT du 26/08/2011 à 17h30 : Pour améliorer la sécurité de votre démon SSH et limiter l'impact des attaques par bruteforce sur vos ressources, reportez vous à ce billet : OpenWRT : sécuriser l’accès SSH. Fin de l'édit

Bloquer les pings en provenance d'internet

Je bloque les echo request du protocole ICMP (vulgairement appelés "ping") en provenance d'internet. Le routeur peut toujours être interrogé depuis le LAN sans problèmes.

Contrairement à ce que l'on voit sur certains sites et forums, il ne faut pas bloquer tout le protocole ICMP car il ne prend pas en charge que le ping : c'est aussi via ce protocole que le réseau avertit votre ordinateur qu'un serveur n'est pas accessible (Host Unreachable) ou qu'un port n'est pas accessible (bien que normalement, en TCP, le flag RST soit fait pour cela)

Il ne faut pas non plus bloquer les echo reply du protocole ICMP, sinon vous ne recevrez jamais les réponses des pings que vous envoyez à un serveur sur internet.

Pour mettre cela en place, il faut d'abord supprimer la règle présente par défaut dans OpenWRT qui autorise le ping :

­root@OpenWrt:~# uci delete firewall.@rule[1]
­root@OpenWrt:~# uci commit firewall
root@OpenWrt:~# uci commit

Ensuite, il ne reste plus qu'a déclarer notre régle personnelle dans le fichier /etc/firewall.user :

iptables -A input_wan -p icmp --icmp-type 8 -j DROP

Note : Oui, je sais que j'aurais pu changer la règle présente par défaut grâce à un simple

root@OpenWrt:~# uci set firewall.@rule[1].target=DROP
root@OpenWrt:~# uci commit firewall
root@OpenWrt:~# uci commit

Mais je préfère la supprimer car je ne compte pas utiliser LuCi/uci pour écrire mes règles personnelles et je souhaite donc que toutes mes règles soient regroupées dans le même fichier, à savoir /etc/firewall.user.

En parlant de règle à supprimer, vous pouvez supprimer une autre des règles présente par défaut avec cette commande :

­root@OpenWrt:~# uci delete firewall.@rule[0]
­root@OpenWrt:~# uci commit firewall
root@OpenWrt:~# uci commit

Celle-ci ouvre le port 68 (DHCP) sur le port WAN. Cela n'a pas d'intérêt, même si votre routeur obtient son adresse auprès de votre modem avec DHCP.

Désinstaller quelques packages

Attention à ce que vous faites : ne désinstallez pas n'importe quoi ... J'ai désinstallé la libgcc (car je ne pensais pas en avoir besoin vu que je ne comptais pas compiler quoi que ce soit sur le routeur) et cela m'a valu un petit flashage via la méthode TFTP.

Si vous ne voulez pas de l'interface web allégée (= qui ne contient pas toutes les options et qui est intégrée dans la version complète) :

opkg remove --force-removal-of-dependent-packages luci-admin-mini

Ensuite il faut redémarrer le routeur afin que l'interface web passe automatiquement en version complète. En effet, si vous vous connectez maintenant, vous obtiendrez un message bizarre. Redémarrer le démon uhttpd n'a pas suffit chez moi.

Personnellement, je n'ai rien désinstallé d'autre.

ÉDIT du 26/08/2011 à 17h35 : Vous pouvez désinstaller le paquet qui contient la traduction anglaise de LuCi si vous ne vous en servait pas :

opkg remove luci-i18n-english

Vous pouvez même désinstaller complétement LuCi/uhttpd si l'interface web ne vous sert pas.
Fin de l'édit

Wake On Lan (WOL)\ Wake On Wan (WOW)

Deux méthodes sont possibles : utiliser un utilitaire dédié, etherwake ou configurer une association statique entre l'adresse IP du PC à réveiller et son adresse MAC. La plus simple et la plus sécurisée étant d'installer etherwake.

Une autre méthode est souvent présentée : il s'agit de rediriger un port choisi (généralement le 9) vers l'adresse de diffusion du réseau (exemple : 192.168.0.255). Cette méthode n'a jamais fonctionné pour moi, même avec iptables.

Utiliser etherwake

Il faut d'abord l'installer :

opkg install etherwake

. Ensuite, pour allumer votre ordinateur, vous devrez vous connectez via SSH à votre routeur (voir plus haut pour ouvrir le port et le protéger) et taper :

etherwake MAC

en remplaçant "MAC" par l'adresse MAC de l'ordinateur à réveiller.

Pour être précis dans les termes, il s'agit ici véritablement de Wake On Lan : vous allumez une machine du même réseau. En effet, le paquet magique part de votre routeur qui se trouve dans le même réseau que l'ordinateur à allumer.

Autre méthode

Pour créer l'association statique entre l'adresse IP du PC à réveiller et son adresse MAC, on peut habituellement utiliser la commande arp. Mais dans OpenWRT on ne peut pas car elle sert uniquement à afficher la table ARP. Il faut donc utiliser la commande ip.

Installation :

opkg install ip

Utilisation :

ip neigh add IP lladdr MAC nud permanent dev br-lan

Évidemment, "IP" est à remplacer par l'adresse IP du PC à réveiller et "MAC" par son adresse MAC. Sur votre routeur, le périphérique ne sera peut-être pas br-lan. Il faut en tout cas indiquer le périphérique (réel ou non (comme br-lan)) qui désigne le réseau local.

Il ne vous reste plus qu'a rediriger, via l'interface web, le port 9 (ou celui de votre choix) vers l'adresse IP du PC à réveiller). Il faut aussi veiller à ce que le serveur DHCP donne toujours la même adresse IP à votre PC ... ou à utiliser une configuration IP statique.

Vous n'avez plus qu'à utiliser un service web (comme Dépicius.com) ou un logiciel dédié. Cette méthode est moins sécurisée car vous dépendez d'un service web. Si vous utilisez un logiciel, il faut que l'endroit depuis lequel vous vous connectez ne bloque pas le port que vous avez choisit. Et n'oubliez pas que le paquet circulera en clair sur le réseau.

Attention : l'association est effacée lors de chaque arrêt du routeur. Nous verrons dans un prochain article comment réaliser un script qui s'exécute au démarrage du routeur et rétablit l'association. ÉDIT du 09/07/2011 à 0h05 : Voici le billet en question : Protéger le cache ARP de vos machines.

Pour être précis dans les termes, il s'agit ici de Wake On Wan (WoW) : vous allumez une machine qui n'est pas sur le même réseau.

Installer un résolveur DNS sur votre routeur (ÉDIT du 09/07/2011 à 0h05)

Voir ce billet : Mettre en place un résolveur DNS sur un WRT54GL équipé d’OpenWRT

Utiliser un client Network Time Protocol (ÉDIT du 09/07/2011 à 0h05)

Voir ce billet : Utiliser NTP (Network Time Protocol) sur OpenWRT.

Installer un serveur Network Time Protocol (ÉDIT du 26/08/2011 à 17h40)

Voir ce billet : Installer un serveur NTP sur OpenWRT.

Comprendre le mécanisme de watchdog (ÉDIT du 26/08/2011 à 17h40)

Voir ce billet : OpenWRT : watchdog - en voilà un bon toutou !

Créez votre image personnalisée d’OpenWRT (ÉDIT du 04/09/2011 à 21h10)

Voir ce billet : Créez votre image personnalisée d’OpenWRT

Jouer avec les LEDs

Le pseudo-système de fichier procfs permet de faire l'interface entre l'utilisateur, le noyau et le matériel. Et il nous permet de jouer.

Listons le contenu de /proc/diag/led :

root@OpenWRT:~# ls /proc/diag/led
dmz         power       ses_orange  ses_white   wlan

On remarque qu'il y a un fichier pour chaque LED présente sur la façade du routeur à l'exception des ports LAN et de la LED SES (= le logo Cisco à gauche de la façade) qui est représentée en double pour les deux couleurs qu'elle peut prendre. Dans chacun de ces fichiers, vous pouvez inscrire une valeur :

  • 0 : la led correspondante sera éteinte
  • 1 : la led correspondante sera allumée
  • f : la led correspondante clignotera

Faisons clignoter la LED SES en orange :

echo "f" &gt; /proc/diag/led/ses_orange

Allumons la LED wifi :

echo "1" &gt; /proc/diag/led/wlan

Bref, vous l'aurez compris les possibilités sont importantes.

Vous pouvez par exemple concevoir un script qui fait clignoter la LED SES aux tops horaires : il suffit de réaliser un script shell qui écrit "f" dans le fichier /proc/diag/led/ses_orange, qui se met en pause pendant 30 secondes puis qui écrit "0" dans le même fichier. Ensuite vous demandez au démon cron de lancer le script en début de chaque heure. Pour poursuivre dans cette voie, il est même possible de faire une horloge : vous allumez la LED SES blanche à chaque quart d'heure et la LED SES orange toutes les heures. Inutile donc indispensable ;) .

Vous pouvez aussi concevoir un script qui allume la LED wifi à chaque fois que vous activez le wifi et qui l'éteint quand vous désactivez le wifi. Cela se faisait tout seul avec le noyau 2.4 mais plus maintenant. Mais il suffit de vérifier si le wifi est activé (l'interface wlan apparait dans le listing de la commande ifconfig si le wifi est activé ;) ) et d'allumer ou éteindre la LED en conséquence. Bien sûr, le script sera exécuter régulièrement par cron. Une autre méthode est possible : trouver le script qui allume la diode SES quand vous activez le wifi et changer le code de ce script pour qu'il allume la diode wifi à la place.

A vous de trouver d'autres idées :D

Les "fails" d'OpenWRT

Malgré toutes mes manip', je n'ai remarqué que deux "fails" dans OpenWRT :

  1. Il n'est pas possible d'activer le filtrage par adresse MAC pour le wifi sur la déclinaison brcm47. Mais vu la faiblesse de cette "protection", ce n'est pas un gros manque.
  2. Quand vous sauvegardez les paramètres du wifi dans l'interface web, même si vous n'activez pas le wifi, vous perdez l'accès à internet sur les PCS branchés sur les ports LAN. En les sauvegardant une deuxième fois, le net revient.

Je pense que j'ai fait le tour de la configuration d'un WRT54GL v1.1 avec OpenWRT.

4 commentaires pour le moment

Ajoutez votre commentaire
  1. Bonjour,

    Je suis en train de mettre en place OpenWRT sur des WRT54GL, d’où l’intérêt pour votre billet. J’ai évidemment quelques questions sur le sujet :

    1/ Vous parlez du mode boot_wait pour reflasher un WRT en cas d’erreur qui le rende inaccessible ; avez-vous testé l’autre méthode présentée par OpenWRT, nommé « failsafe mode » (dans http://wiki.openwrt.org/oldwiki/openwrtdocs/troubleshooting) ? Pour ma part, je n’arrive pas toujours à le faire fonctionner, sans savoir pourquoi.

    2/ Vous indiquez des problèmes dans OpenWRT (je pense notamment à la QOS auquelle manquerait des règles de priorité) : avez-vous remonté ces problèmes aux dévs. du projet, pour savoir si c’est toujours d’actualité ?

    Pour ma part, je suis resté en version brcm2-4, car le support wifi en brcm47xx est moins riche, et j’ai par exemple besoin de sélectionner le connecteur d’antenne en émission/réception, ce que ne permet pas la nouvelle version…

    Merci pour votre article en tout cas, il est très intéressant !

  2. Bonjour,

    Tout d’abord : merci.

    Pour la première question : oui j’ai essayé le failsafe mode et comme vous, je n’ai jamais réussi à m’en servir. La LED DMZ se met a clignoter mais je n’obtiens jamais le paquet UDP « Entering Failsafe! » et le routeur n’est pas accessible à l’adresse 192.168.1.1.

    Pour la deuxième question : attention : la QoS fonctionne très bien. C’est juste qu’il manque des règles pré-écrites dans les packages qos-scripts et luci-app-qos. Mais rien n’empêche de les ajouter soi-même. Tout comme les « fails », je n’ai pas fait remonter l’information aux développeurs.

    Je ne savais pas que l’on pouvait choisir la fonction de chaque antenne dans la déclinaison brcm2-4 …

  3. bonjour,

    un grand merci également car c’est la première fois que je trouve un petit guide en français qui donne les bases.

    petite question je n’arrive pas a faire marché mon wrt54g v2 en mode pont.??? le wifi est connecté mais impossible de faire le moindre ping. j’ai de gros doute sur ma configuration réseau fichier network et wifi. pourrais tu me montrer les tiens ?

    merci.

  4. Bonjour,

    Merci 🙂

    Malheureusement, je n’ai jamais tenté de faire un bridge wifi entre deux routeurs donc je ne peux pas t’aider. Je n’ai pas un autre routeur sous la main, sinon j’aurais essayé. Je préfère donc me taire plutôt que de t’induire en erreur.