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

ochbob · « **Réponse #1392 le:** 10 septembre 2026 à 09:56:34 »

Citation de: unipo le 19 avril 2026 à 17:29:46

J'ai fait un petit mix et documenté de tout ça ici https://github.com/luneth/OpenWRT-Livebox/ au cas ou je veuille y remettre la truffe, ou si ça peut aider certains

Je pense que c'est le "guide" le plus à jour avec tout ce qui va bien aujourdui.
Faudrait ptet juste upgrade la FP pour y faire pointer son repo pour la version 25.12.x
Si Ubune passe par ici

simon · « **Réponse #1393 le:** 10 septembre 2026 à 10:00:54 »

Avec un ONT externe (Ethernet) c'est sans maintenance... je fais les upgrades quand elles sortent et j'ai zero souci.

IPv6-only sur les LAN + NAT64 (tayga), règles nft custom, unbound en tant que resolveur, collectd pour les métriques CPU/RAM/packet counters, etc. Donc pas exactement un setup "simple", mais aucun souci lors des upgrades.
J'utilise sysupgrade en SSH et je réinstalle les paquets nécessaires une fois l'upgrade flashée.

unipo · « **Réponse #1394 le:** **Hier** à 22:54:39 »

Citation de: ochbob le 10 septembre 2026 à 09:56:34

Je pense que c'est le "guide" le plus à jour avec tout ce qui va bien aujourdui.
Faudrait ptet juste upgrade la FP pour y faire pointer son repo pour la version 25.12.x
Si Ubune passe par ici

Content de voir que quelqu'un ai trouvé ce post dans les méandres de ce sujet

Ça mérite tout de même également une mention au guide de chat_roux de base pour Turris Omnia, mais ça reste de l'openwrt.
Certe dans la langue de Shakespeare mais il a également l'avantage de parler en profondeur de l'importance de taguer tout le flux sortant hors destiné à orange en PCP0, et démontre aussi comment faire de même avec l'hardware flow offloading d'activer 👍
Et pis contrairement à mon repo il a, comme ubune, un dossier prêt à copy-pasta (en modifiant identifiant/MAC/etc...) pour ceux que ça intéresse

basilix · « **Réponse #1395 le:** **Aujourd'hui** à 10:08:18 »

@unipo :

Recopier la configuration est efficace, mais ce n'est pas la méthode recommandée. Il aurait idéalement fallu aller un cran plus loin.
Car cela inclut les erreurs éventuelles et redéfinit également certaines valeurs par défaut.

Citation de: Wiki nftables

You could use meta l4proto to match on the transport protocol (ie. TCP, UDP, ICMPv6,...), this is walking down the headers until the real transport protocol is found.

If you specifically want to match on the ICMPv6 type, then nftables creates an implicit meta l4proto dependency that is not shown, therefore, there is no need for being verbose in your notation, ie.

Code: [Sélectionner]
% nft add rule filter input icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
works fine to accept all ICMPv6 traffic regardless any possible extension headers.

Hyperlink: Matching IPv6 headers

Exemple d'erreur dans la configuration

nft add rule inet fw4 mangle_postrouting oifname "eth0.832" ip protocol icmpv6 counter meta priority set 0:6

Code: [Sélectionner]

nft add rule inet fw4 mangle_postrouting oifname "eth0.832" meta l4proto ipv6-icmp counter meta priority set 0:6

Citer

Code: [Sélectionner]
l4proto <protocol>
Protocol numbers assigned by IANA

basilix · « **Réponse #1396 le:** **Aujourd'hui** à 16:22:38 »

@unipo :

On peut utiliser la règle ci-dessous pour changer le champ DSCP des paquets IGMP.

Code: [Sélectionner]

vlan id 840 ip protocol igmp vlan pcp set 5 ip dscp set cs4 counter comment "Set QoS for IGMP packets"