🌐 Aussi en: English · Deutsch · Español
Tout homelab finit par atteindre le stade où l’on n’a plus de serveurs à casser et où l’on commence à lorgner sur le routeur. Le mien est une FRITZ!Box 7690, qui fait tranquillement son travail de Wi-Fi et d’Internet, jamais vraiment auditée, jamais vraiment remise en question. Un soir, je me suis dit : pourquoi ne pas confier les identifiants à Claude et voir ce qu’il trouve ? Une règle, non négociable : regarder, ne pas toucher. Aucune modification, juste une inspection honnête.
Le résultat s’est révélé plus intéressant que prévu – et étayé par de vrais journaux du routeur, pas par des impressions. 🧾
🔑 Entrer poliment
Premier détail sympathique : la FRITZ!Box ne demande jamais réellement le mot de passe sur le réseau – pas une seule fois. Au lieu de « donnez-moi votre mot de passe pour que je le vérifie », elle joue à un petit jeu de vérification : la box envoie d’abord une pièce de puzzle aléatoire. Le mot de passe est mélangé à cette pièce de puzzle, passé des dizaines de milliers de fois dans un processus de brouillage volontairement lent, et seul le résultat brouillé est renvoyé – jamais le mot de passe lui-même. De son côté, la box effectue exactement le même brouillage avec le mot de passe qu’elle a enregistré, et si les deux résultats concordent, vous êtes connecté.
Le mot de passe lui-même ne transite jamais sur le réseau, à aucun moment, sous aucune forme. Même quelqu’un connecté au même Wi-Fi et capturant chaque paquet ne verrait que la pièce de puzzle et la réponse brouillée – et ni l’une ni l’autre ne permet de remonter au mot de passe. Pas besoin de navigateur non plus – juste un peu de script qui fait les mêmes calculs qu’un navigateur. Geek, mais rassurant : la connexion en elle-même est solide.
Une fois dedans, le backend de l’interface web de la box (data.lua) s’est révélé être une mine d’or – exactement le même JSON que celui utilisé par l’interface d’administration, simplement interrogeable directement. Plus besoin de cliquer dans les menus. 😌
📶 Les trois choses à corriger
Le problème avec les réglages Wi-Fi, c’est qu’ils paraissent abstraits tant qu’on ne les traduit pas en quelque chose du quotidien. Voici donc la version « expliquée à mon ami pas informaticien » de ce que Claude a signalé – et pourquoi.
1. La rue à 3 voies (largeur de canal en 2,4 GHz)
Imaginez la bande des 2,4 GHz comme une rue étroite comptant exactement 3 voies sans chevauchement (canaux 1, 6, 11 – tous les autres empiètent sur l’un d’eux). Normalement, votre Wi-Fi utilise une voie. Ma box était configurée pour en prendre deux à la fois (« 40 MHz ») afin de gagner en vitesse – sauf qu’avec seulement 3 voies sur toute la rue, c’est la quasi-totalité de la chaussée, et le Wi-Fi d’un voisin est presque à coup sûr garé sur l’une de ces voies lui aussi.
Le pompon : il existe une fonction « politesse » intégrée (coexistence 20/40 MHz) qui se replie automatiquement sur une seule voie dès qu’elle détecte un voisin – et elle était désactivée. La box occupait donc deux voies, entrait quand même en collision avec les voisins et ne récupérait rien du gain de vitesse promis, car les collisions imposent des retransmissions et des débits de repli plus lents. Le pire des deux mondes. 🚗💥🚗
2. L’autoroute large avec un barrage surprise (5 GHz, 160 MHz + DFS)
La bande des 5 GHz offre bien plus de voies, donc l’encombrement dû aux voisins n’y pose pas vraiment problème. Ma box roulait sur l’autoroute la plus large possible – 160 MHz, 8 voies regroupées, vitesse théorique maximale. Deux bémols, cependant : une partie de ce spectre (canaux 52–64) est partagée avec les radars météo et aéronautiques. Si la box détecte un radar, elle doit évacuer ce canal immédiatement, sans discussion – comme une route fermée sur-le-champ pour laisser passer une ambulance. Et un canal aussi large répartit la même puissance d’émission plus finement, ce qui coûte généralement un peu de portée et de traversée des murs par rapport à un canal plus étroit de 80 MHz.
Pas vraiment une erreur – juste un compromis vitesse/stabilité que je ne savais pas avoir fait.
3. La clé de secours sous le paillasson (WPS)
Le WPS, c’est le raccourci d’appairage « j’appuie sur un bouton du routeur, j’appuie sur un bouton de l’appareil, c’est fait ». Pratique – comme laisser une clé de secours sous le paillasson pour les invités. Le hic : il y a quelques années, des chercheurs ont découvert une faille dans la vérification du code PIN WPS qui permet de le casser bien plus vite que ne le devrait un PIN à 8 chiffres. Si vous ne l’utilisez pas activement pour appairer de nouveaux appareils, c’est une clé qui traîne sous le paillasson sans raison.
📊 Des preuves, pas des impressions
C’est là que l’affaire a cessé d’être théorique. Claude a récupéré le journal système de la FRITZ!Box – 1 088 entrées sur trois semaines – et il s’avère que j’ai en fait un petit réseau maillé (des points d’accès au rez-de-chaussée, au 1er et au 2e étage, pas une seule box). Les chiffres :
- 314 radars détectés sur les canaux DFS 5 GHz (120–124), répartis sur les deux points d’accès des étages, en trois semaines. Soit environ 15 fois par jour.
- 308 changements de canal forcés, conséquence directe et immédiate de ces détections radar.
- 138 fois « source de perturbation très forte détectée » sur les canaux 2,4 GHz 1 et 11 – exactement le problème de collision avec les voisins du point 1, consigné noir sur blanc.
- 12 fois, la logique de qualité automatique de la box a été si mécontente des conditions en 2,4 GHz qu’elle a elle-même réduit la largeur du canal, en plein fonctionnement.
Il ne s’agissait donc pas de « ça pourrait théoriquement poser problème quelque part ». Cela se produisait plusieurs fois par jour, en silence, depuis des semaines, sans que je remarque autre chose qu’un occasionnel « tiens, le Wi-Fi a ramé une seconde ». 🤷
🎓 La morale (pour l’instant)
Rien de tout cela ne concerne les ondes, la santé ou le « trop de Wi-Fi » – la largeur de canal n’a rien à voir avec la puissance d’émission, c’est purement une question de partage du spectre et de compromis vitesse/stabilité. Mais c’est un bon rappel que « ça marche très bien » et « c’est réellement bien configuré » sont deux affirmations très différentes, et que parfois on ne découvre laquelle est vraie qu’en lâchant une IA sur les journaux de son propre routeur en lui demandant simplement de regarder. 😅
🛠️ Mise à jour : on bascule vraiment les interrupteurs
De retour pour le deuxième round, cette fois avec la permission de toucher. Il s’avère que le point 1 cachait un rebondissement : les « interférences du voisin » sur le canal 1 ne venaient pas du tout d’un voisin. Un nouveau scan de l’environnement Wi-Fi n’a montré aucun réseau 2,4 GHz réellement étranger à proximité – chaque « autre réseau » signalé portait le préfixe MAC du fabricant de mon propre routeur. Deux de mes quatre radios maillées (box principale plus répéteurs sur trois étages) s’étaient discrètement installées sur exactement le même canal, entrant en collision avec elles-mêmes depuis différents étages de la même maison. Les voisins étaient innocents depuis le début. 🤦
La solution s’est révélée plus simple que l’option de coexistence que j’avais prévue : j’ai fixé manuellement le canal 2,4 GHz sur 6, qui était complètement libre. Le canal 1 n’apparaît plus du tout comme actif dans le tableau des canaux de la box, le canal 6 si. Pas une répartition 1/6/11 parfaitement propre sur les quatre radios – le canal fait toujours 40 MHz de large, il déborde donc encore un peu sur le spectre voisin – mais une vraie amélioration par rapport à deux de mes propres points d’accès qui partageaient littéralement un canal.
WPS : complètement désactivé. Petite note pour être précis – ce que cette box propose réellement, c’est le WPS par Push-Button, pas la version à code PIN qui présente la faiblesse face à la force brute décrite plus haut. Le mode bouton exige que quelqu’un se trouve physiquement devant la box pendant une fenêtre d’appairage active, il n’a donc jamais été exploitable à distance ici. Désactivé quand même, tout simplement parce que je n’en ai plus besoin.
🚧 Celui qui nous a échappé
Le point 2 – réduire cette autoroute de 160 MHz à 80 – est l’endroit où cette histoire cesse d’être une belle réussite bien rangée. Nous savons exactement ce que nous voulons changer. Nous ne trouvons simplement aucun endroit où le changer.
En cherchant le réglage, les choses deviennent franchement étranges : le champ est bel et bien toujours là. Lire les données internes de la box directement via son API affiche clairement ht160: active = true — le réglage existe dans le modèle de configuration, bien présent. Ce qui n’existe pas, c’est un moyen d’y accéder. Pas via l’interface web (ni caché derrière une option « vue avancée », ni rangé dans une section repliée – AVM a discrètement supprimé tout réglage fin de la largeur de canal de l’interface dans les versions récentes de FRITZ!OS), ni via cette même API : ce backend JSON vous laisse volontiers lire le champ, mais le côté écriture – les paramètres exacts dont une requête d’enregistrement aurait besoin pour le basculer – n’est documenté nulle part, et même Claude, en fouillant les mêmes points de terminaison que l’interface web utilise elle-même, n’a pas réussi à établir une manière confirmée et sûre de l’appeler. Deviner des paramètres POST non documentés sur un point de terminaison d’enregistrement de configuration en production semblait exactement le mauvais endroit pour improviser – si on se trompe, on n’échoue pas seulement à changer la largeur de canal, on risque de réinitialiser en silence un réglage sans rapport auquel on ne voulait jamais toucher.
La seule voie encore viable que quelqu’un ait trouvée est un outil tiers qui modifie directement le fichier d’export brut de la configuration de la box avant de le réimporter – et les témoignages de la communauté où cela a mal tourné (une configuration corrompue, tout droit sortie d’un fil de forum d’assistance) représentent exactement le genre de risque qui ne vaut pas la peine d’être pris sur un routeur dont dépend tout le foyer. Un hoquet du Wi-Fi, ça passe. Une box qui ne répond plus du tout, non.
Pour l’instant, ce point reste donc tout simplement non résolu – non pas parce que la solution elle-même est en question, mais parce qu’il n’existe actuellement aucun chemin pour y parvenir qui ne comporte pas plus de risques que le réglage n’en vaut. Classé dans « à surveiller » : si une future mise à jour du firmware ramène un réglage dans l’interface, ou si une voie d’API documentée et plus sûre apparaît, ce sera la première chose que je reprendrai.
🍂 Perspectives : FRITZ!OS 8.5 cet automne
Ce qui, fort à propos, nous amène à la vraie raison de garder un œil sur ce sujet : une mise à jour vers FRITZ!OS 8.5 est prévue pour l’automne, et sa fonctionnalité phare est le blocage des publicités et des traqueurs façon Pi-hole, intégré directement dans la box. Aujourd’hui, ce genre de filtrage au niveau DNS implique de faire tourner un appareil séparé sur le réseau ; l’avoir nativement sur le routeur qui se trouve déjà au centre de tout serait une vraie simplification. La saison des mises à jour de firmware est aussi la saison du « peut-être que le réglage de la largeur de canal revient discrètement » – plus de détails sur les deux dès que la 8.5 sera vraiment disponible.
