Pourquoi mon routeur OpenWrt coupe Internet alors que la box répond au ping ?

Sur un routeur OpenWrt avec 4G de secours, mwan3 surveille la sortie WAN en pinguant des cibles fixes. Si ces cibles répondent mal, mwan3 déclare le WAN mort ; sans 4G disponible, la politique n’a plus de membre et le trafic vers Internet est rejeté. Les réseaux directement connectés, box comprise, restent joignables : la box répond, Internet non.

Comment voir si mwan3 bascule en boucle ?

Sur le routeur, logread | grep mwan3track affiche les changements d’état des interfaces surveillées. Des messages Interface wan (eth1) is disconnecting puis is connecting qui se répètent en boucle signalent un health-check trop sensible. uci show mwan3 | grep -E "track_ip|flush" montre ensuite les cibles et le vidage conntrack configurés.

Que fait l’option flush_conntrack de mwan3 ?

L’option flush_conntrack de mwan3 vide la table de suivi des connexions du noyau lors des événements listés (ifup, ifdown, connected, disconnected). Toutes les connexions TCP en cours sont alors coupées, y compris au retour à la normale. Sur une sortie principale qui bascule souvent à tort, never évite de transformer chaque fausse alerte en déconnexion générale.

Quelles cibles track_ip choisir pour mwan3 en France ?

Les cibles track_ip doivent être proches et fiables depuis le réseau surveillé. Derrière une Freebox, les DNS de Free (212.27.40.240, 212.27.40.241) plus un DNS de FDN (80.67.169.12) conviennent. Pour la 4G, les DNS Free ne sont pas garantis hors réseau Free : mieux vaut les DNS de FDN. Plusieurs cibles évitent qu’une seule panne déclenche une bascule.

mwan3 : le health-check d’usine qui coupe Internet

mwan3, le démon de bascule multi-WAN d’OpenWrt, coupait Internet chez moi plusieurs fois par quart d’heure : son health-check d’usine pinguait 223.5.5.5, le DNS public d’Alibaba, qui répond mal depuis la France. Trois pings ratés, et le routeur déclarait la sortie principale morte, rejetait le trafic faute de 4G disponible et vidait la table conntrack au passage. La box avait pourtant ses propres micro-coupures : le health-check d’usine ne les créait pas, il les transformait en blackouts répétés.

Le symptôme : des trous de 15 à 35 secondes

Le routeur est un modèle grand public avec modem 4G, sous un firmware constructeur basé sur OpenWrt 21.02-SNAPSHOT (SoC MediaTek MT7981), placé derrière une Freebox en mode routeur. C’est le même double NAT que dans l’article sur l’IPv6 ULA qui rendait le WiFi plus lent que la 4G.

Les coupures duraient de 15 à 35 s, TCP compris. Entre deux trous, le débit était normal (environ 16 Mo/s). Redémarrer le routeur ne changeait rien.

J’ai lancé un ping en parallèle vers chaque tronçon, depuis le PC :

for t in 192.168.1.1 192.168.0.254 1.1.1.1 8.8.8.8; do ping -c180 -i0.5 -q $t > p_$t & done; wait
for t in 192.168.1.1 192.168.0.254 1.1.1.1 8.8.8.8; do echo "$t: $(tail -2 p_$t | head -1)"; done

Cible	Perte sur 90 s
Routeur `192.168.1.1`	0,6 %
Box `192.168.0.254`	1,1 %
`1.1.1.1` / `8.8.8.8`	75 %

Une piste incomplète : la box et la ligne

Le tableau accuse la box : le routeur et la box répondent, Internet non. Les pings renvoyaient en plus Destination Net Unreachable, ce qui ressemble à une box qui perd sa route. J’ai cherché du côté de la ligne Free. Il y avait d’ailleurs de vraies micro-coupures côté box (une d’environ 25 s observée), ce qui brouillait le diagnostic.

Le test qui a tranché : pinguer la même cible en même temps depuis le PC et depuis le routeur. Si le routeur passe et le PC non, la perte est introduite par le routeur. C’était le cas ici, mais pas toute l’histoire : la ligne avait aussi ses vraies coupures, plus courtes et moins fréquentes que celles qu’ajoutait mwan3.

Pourquoi mwan3 coupe Internet tout seul ?

Les logs du routeur ont donné la réponse :

ssh root@192.168.1.1 'logread | grep mwan3track | tail; uci show mwan3 | grep -E "track_ip|flush"'

Les messages Interface wan (eth1) is disconnecting et Interface wan (eth1) is connecting tournaient en boucle : environ 15 bascules en un quart d’heure. La configuration d’usine de mwan3 était la suivante :

track_ip        '223.5.5.5' '8.8.8.8'     # 223.5.5.5 = DNS public d'Alibaba, en Chine
timeout / down  3 s / 3 échecs
flush_conntrack 'ifup' 'ifdown' 'connected' 'disconnected'

track_ip est la liste des adresses que mwan3 pingue pour juger qu’une interface est vivante. down est le nombre d’échecs consécutifs avant de la déclarer morte. À chaque bascule, deux choses se produisaient :

La politique hotspare (box en priorité, 4G en secours) n’avait plus de membre disponible : sans 4G, le trafic vers Internet était rejeté, alors que les réseaux directement connectés, dont la box, restaient joignables. D’où le Destination Net Unreachable.
Le vidage conntrack (flush_conntrack) fermait toutes les connexions TCP en cours, y compris au retour de la sortie, puisque connected figurait dans la liste.

Un health-check trop sensible transforme chaque micro-coupure de la box en blackout complet, et le vidage conntrack le prolonge au-delà du retour de la ligne.

Le correctif : des cibles proches et une bascule moins nerveuse

J’ai remplacé les cibles par des DNS fiables et proches, assoupli les seuils et désactivé le vidage :

uci delete mwan3.wan.track_ip
uci add_list mwan3.wan.track_ip='212.27.40.240'   # DNS Free
uci add_list mwan3.wan.track_ip='212.27.40.241'   # DNS Free
uci add_list mwan3.wan.track_ip='80.67.169.12'    # DNS FDN
uci set mwan3.wan.down='5'
uci set mwan3.wan.timeout='2'
uci delete mwan3.wan.flush_conntrack
uci add_list mwan3.wan.flush_conntrack='never'
uci commit mwan3 && mwan3 restart

Pour l’interface 4G, les DNS Free ne sont pas garantis hors du réseau Free : je n’y ai mis que les DNS de FDN (80.67.169.12, 80.67.169.40). Le firmware utilisait aussi 223.5.5.5 ailleurs (watchdog, voyants, DNS de la 4G) ; grep -rl 223.5.5.5 /etc les trouve tous.

Résultat : 0 % de perte sur 90 s, depuis le PC comme depuis le routeur. Sur une fenêtre plus longue, les micro-coupures de la box restaient visibles : ce correctif supprime l’amplification, pas la cause côté ligne.

⚠️ Le firmware garde ses valeurs d’usine dans /rom/etc/config/ : un reset usine réinjecte 223.5.5.5 et le vidage conntrack.

Lessons learned

Un routeur grand public avec 4G embarque un health-check d’usine qu’il faut lire. Les cibles et les seuils de mwan3 se vérifient avant d’accuser la box ou l’opérateur.
Un Destination Net Unreachable ne désigne pas forcément la box. La politique de routage du routeur en amont peut rejeter le trafic quand mwan3 n’a plus de sortie valide.
Le ping simultané depuis le PC et depuis le routeur localise la perte. Si le routeur passe et le PC non, la perte vient du routeur ; si les deux tombent ensemble, elle vient de plus loin.
flush_conntrack sur connected coupe les connexions au retour de la ligne. Sur une sortie qui bascule à tort, never limite les dégâts.
Un reset usine réintroduit les réglages de /rom/etc/config/. Le correctif doit être noté pour être réappliqué.