Auteur Sujet: Remplacement de la Livebox par un routeur Openwrt (Lu 528292 fois)

basilix · « **Réponse #1284 le:** 10 mars 2026 à 07:02:52 »

@Atmis :

Et cela détecte une perte de connexion de façon fiable ?

Citation de: levieuxatorange le 08 novembre 2022 à 09:18:30

Si vous ne testez pas la connexion montante, vous allez vous retrouver hors séquence et donc vous faire blaster régulièrement.

Atmis · « **Réponse #1285 le:** 10 mars 2026 à 11:09:30 »

Le script est exécuté par le client DHCP à chaque renew.

Et j'ai un watchdog qui ping le premier équipement réseau Orange dans mon traceroute (avec fallback sur 1.0.0.1 et 8.8.4.4) toutes les 5 mins. Si pas de réponse, ou bien si le statut du DHCP n'est pas bound, alors ça relance l'interface. C'est très rare que j'ai un problème à ce niveau (je reçois un mail de notification quand ça arrive).
Le crédit va à cyayon pour ce script RouterOS : https://lafibre.info/remplacer-livebox/onu-fs-com-tx-power-a-40db/msg1039481/#msg1039481

Avec ce système je n'ai jamais eu de problème.

zoc · « **Réponse #1286 le:** 10 mars 2026 à 11:47:21 »

Alors moi dans le cas de RouterOS j'utilise une combinaison de "checkping" sur la route par défaut (intégré à RouterOS, ce qui me permet de switcher automatiquement sur mon backup 4G qui a une route par défaut avec une distance supérieure à celle du lien primaire en FTTH) et d'un script qui relance le client DHCP si le "checkping" a fait tomber la route.

tit91 · « **Réponse #1287 le:** 10 mars 2026 à 18:44:43 »

Citation de: Atmis le 10 mars 2026 à 11:09:30

Le script est exécuté par le client DHCP à chaque renew.

Et j'ai un watchdog qui ping le premier équipement réseau Orange dans mon traceroute (avec fallback sur 1.0.0.1 et 8.8.4.4) toutes les 5 mins.

Bonsoir,

Les préconisations pour les tests de vie sont rarement suivies par les implémentations publiées sur le forum.
Pour rappel :

Citation de: levieuxatorange le 08 novembre 2022 à 09:18:30

De l'importance des tests de vie :
La cnx de la LB peut être interrompue sur plusieurs segments entre la LB et le BNG.
Si vous ne testez pas la cnx montante, vous allez vous retrouver hors séquence et donc vous faire blaster régulièrement.
Cela doit être fait sur LES DEUX stacks Ipv4 et IPv6
Préconisation d'algo pour les tests de vie :
IPv4 : faire une séquence ARP Request / Reply vers l'adresse du routeur donné en DHCPv4
IPv6 : faire une séquence ICMP6 NS/NA de fe80::ba0:bab
Pour chacun des deux stack
faire une séquence toutes les 120s
en cas de non réponse au bout de 10s , faire 2 répétitions
au 3ème timeout (donc au total 150s de timeout), considérer que la liaison est en échec
relancer CE stack
les req ARP et ICMPv6 doivent être faite avec la COS6

Il ne s'agit donc pas de s'appuyer sur des pings.

basilix · « **Réponse #1288 le:** 11 mars 2026 à 06:23:20 »

Je ne maîtrise pas bien ce sujet. J'ai interrogé l'IA.

Code: [Sélectionner]

[ BOX ] -- accès FAI -- [ BNG ] -- backbone -- [ Internet ] -- [ DNS ]
           ↑
       test Orange
[ BOX ] -- accès FAI -- [ BNG ] -- backbone -- [ Internet ] -- [ DNS ]
                                                               ↑
                                                           ping DNS

Un test DNS public est un diagnostic grossier (faux négatifs). Les échecs qui ne sont pas issus du réseau d'accès (FAI) provoquent des réinitialisations inutiles (côtés client et opérateur).
~~Et l''abonné lambda peut éventuellement croire que le réseau de son FAI est « instable ».~~

Peut-être que ce test engendre peu de faux résultats, je n'en sais rien.

zoc · « **Réponse #1289 le:** 11 mars 2026 à 06:55:29 »

Citation de: tit91 le 10 mars 2026 à 18:44:43

Il ne s'agit donc pas de s'appuyer sur des pings.

Ouais, enfin un ping IPv4/IPv6 entraine généralement une requête ARP/ICMP6 NS/NA...

Bref, 10 ans que je le fais avec des pings, jamais été "blasté"... Et ma connexion est toujours remontée automatiquement après une coupure (généralement des maintenances nocturnes de l'opérateur). D'ailleurs contrairement à la LB de ma voisine de 85 ans qui m'appelle au secours à chaque fois que sa TV ne marche plus....

basilix · « **Réponse #1290 le:** 11 mars 2026 à 11:35:19 »

Une différence imperceptible pour l'utilisateur en terme de performance si le nombre de faux négatifs successifs est rare.
Le test reste moins bon au niveau théorique ou conceptuel.

Toutefois, la différence apparaît dans le choix de la fréquence et du délai d'attente avant retransmission.

Un paquet envoyé toutes les cinq minutes, puis en cas d'échec, retransmis chaque seconde, cinq fois maximum,
relancera la pile réseau plus souvent que nécessaire (attendre plutôt 30 secs. et pas 5 secs. avant de relancer)
et le moment de détection sera rallongé (dans le pire des cas : 305 secs vs 150 secs).

0xgrm · « **Réponse #1291 le:** 11 mars 2026 à 19:26:01 »

Bonsoir,

J'ai mis à jour OpenWRT en 25.12 aujourd'hui et tout fonctionne.
Je n'ai pas eu à ajouter l'option iaid pour récupérer une IPv6.

simon · « **Réponse #1292 le:** **Hier** à 15:28:55 »

+1, upgrade faite en début de semaine, pas eu besoin de changer la conf non plus.

Pour les tests de vie, mon routeur ping fe80::ba0:bab toutes les 30s et fait l'équivalent d'un ifdown/ifup si pas de réponse en 5 ou 10 min.
En 3-4 ans, il a déclenché... 2 fois, et dans l'un des cas, c'était dû à une perte de signal ONT, donc il n'a pas amélioré la situation.

Le nombre de fois où le chemin réseau vers one.one.one.one a été perdu pendant plusieurs heures (tous les ~2 mois quand cloudflare se plante dans ses confs récemment, mais aussi à cause de soucis de routage) doit être bien supérieur à cela.
À mon sens, un tel test de vie n'a de sens que sur le premier saut (fe80::ba0:bab ou le routeur IPv4 annoncé en DHCP), sinon, autant ne rien faire et ne pas se tirer une balle dans le pied.

bigboo · « **Réponse #1293 le:** **Hier** à 22:57:11 »

Je viens de faire l'upgrade sur la version 25.12 et tout marche, j'ai en outre enfin trouvé comment éviter le bridage de Wireguard grâce à ce post:
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/msg1008679/#msg1008679

Je pense donc que le fichier /etc/nftables.d/nft-prio6-rules.include devrait être mis à jour dans le premier post de ce topic par cette version que j'utilise maintenant et qui à l'air de mieux respecter les recommandations protocolaires d'Orange:

Code: [Sélectionner]


oifname "wan.832" ip dscp set cs0
oifname "wan.832" ip6 dscp set cs0
oifname "wan.832" counter meta priority set 0:1
oifname "wan.832" udp dport 67 counter meta priority set 0:6 ip dscp set cs6
oifname "wan.832" udp dport 547 counter meta priority set 0:6 ip dscp set cs6
oifname "wan.832" icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit } counter meta priority set 0:6 ip6 dscp set cs6

J'ai bien l'accélération hardware fonctionnelle pour le NAT et 0% d'utilisation CPU en transfert à 2Gb/s sur un Zyxel EX5601-T0