Auteur Sujet: Remplacement de la Livebox par un routeur Openwrt (Lu 637449 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:** 11 septembre 2026 à 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 logiciel d'activé 👍 (édit: que ses règles nftables ne se retrouvent pas bypassées)
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:** 12 septembre 2026 à 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:** 12 septembre 2026 à 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"

unipo · « **Réponse #1397 le:** 13 septembre 2026 à 01:34:28 »

@basilix
Bien vu concernant les règles, ça mériterait un petit PR.
Mais cela s'applique à l'approche de chat_roux, je joue avec un hook egress netdev & vlan type ip6 icmpv6 type et non avec inet fw4 + mangle_postrouting.

On est bien d'accord sur les risques de copier/coller au hasard une configuration sans savoir de ce que l'on fait.
D'un autre côté, mettre à disposition une configuration type comme ce que faisait ubune, que l'utilisateur n'ai qu'à renseigner son fti/pass + chaine XAUTH + addresse mac pour remplacer sa livebox c'est quand même sympathique.

Le meilleur des deux monde reste sûrement une config prête-à-collée + un joli tuto qui explique le pourquoi du comment... Un peu comme le premier poste en fait

basilix · « **Réponse #1398 le:** 13 septembre 2026 à 05:57:22 »

@unipo :

J'ai la flemme de faire une « requête d'intégration » (demande de fusion). J'envisage aussi de quitter GH pour être centré sur les fondamentaux
sans interférences avec l'IA. Je l'ai beaucoup interrogé hors ligne sur la forme, pour le style, déceler les erreurs et trouver une direction. Mais elle
m'embrouille aussi l'esprit. Je trouve que ses informations sont pertinentes mais cela ne me conduit pas directement dans la direction convenable.
Parfois, j'ai l'impression d'arpenter un labyrinthe avec les détours ou les mauvais chemins. Les tutoriels sont un véritable support pour construire
une base de départ. Mais ce sont des blocs monolithiques plus ou moins figés. Je préfère quelque chose de dynamique et atomique pour adapter
les paramètres. En outre, reproduire fréquemment une nouvelle configuration est fastidieux. De plus, il y a plein de choses à ajouter qui ne rentreront
pas dans un tutoriel, on est moins dans la définition que sur l'opérationnel (prévoir les améliorations et les changement d'états).

Partie 3 : Télévision

Code: [Sélectionner]

config device
        option name 'eth0.840'
        option type '8021q'
        option ifname 'eth0'
        option vid '840'
        list egress_qos_mapping '0:5'
        list egress_qos_mapping '1:5'
        list egress_qos_mapping '2:5'
        list egress_qos_mapping '3:5'
        list egress_qos_mapping '4:5'
        list egress_qos_mapping '5:5'
        list egress_qos_mapping '6:5'
        list egress_qos_mapping '7:5'

config interface 'tvorange'
        option device 'eth0.840'
        option proto 'static'
        option ipaddr '192.168.255.254'
        option netmask '255.255.255.255'
        option delegate '0'

Tu pourrais également ressortir une déclaration de charge utile pour fixer la valeur du champ PCP des paquets IGMP dans un crochet egress.

Code: [Sélectionner]

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

unipo · « **Réponse #1399 le:** 13 septembre 2026 à 08:24:49 »

@basilix
Je te rejoints concernant ce sentiment mitigé envers les LLM
Leur capacité à passer par X raisonnements, tout plus tordu les uns que les l'autre, pour en finalité avoir 50/50 de chance d'avoir ce que tu as demandé est ahurissante. ( C'est peut-être moi qui ne sais pas formuler d'instruction

)
Pour autant ce sont d'excellents outils de débogage, la possibilité de lui faire avaler des journaux de plusieurs centaines de milliers de lignes et te ressortir ce que tu cherches en quelque secondes reste tout de même particulièrement utile
Mais d'absolument vouloir l'intégrer dans le moindre système... Me file des boutons. Et je comprends le besoin d'exode vers des plateformes libre ces distractions

Citation de: basilix le 13 septembre 2026 à 05:57:22

Code: [Sélectionner]
vlan id 840 ip protocol igmp vlan pcp set 5 ip dscp set cs4 comment "Set QoS for IGMP packets"

Effectivement ! J'irai y pousser la modification. Ça fait plusieurs années que je ne me sers plus de la box TV d'orange, je n'y ai donc pas touché à la configuration en copiant le tuto d'ubune. (Cela confirme ton apriori sur les tutoriels et le copy-pasta

)

basilix · « **Réponse #1400 le:** 13 septembre 2026 à 10:18:48 »

@unipo

L'autre problème est l'intégration effective dans OpenWrt.

Comment intégrer des modifications régulières ou ponctuelles plus ou moins significatives ?

On peut imaginer modifier continuellement la configuration pour tester, ou déployer un nouveau service.

Il aurait fallu exploiter le gestionnaire de paquets ou un autre mécanisme pour déployer la configuration afin de la rendre
plus accessible, sous forme de mises à jour. Mais c'est trop compliqué pour moi à mettre en œuvre actuellement.

ubune · « **Réponse #1401 le:** 17 septembre 2026 à 21:37:04 »

Bonjour à tous !

Wow, déjà 8ans depuis le post initial, on vieillit ^^'.

Désolé, je ne suis pas passé ici depuis un bon moment et je n’ai plus d’abonnement Orange depuis quelque temps, donc je ne suis plus vraiment à jour sur les évolutions récentes.

Que souhaitez-vous / conseillez-vous pour mettre à jour le premier post ? Je vois qu'il y a pas mal d'initiatives sympa sur git, je mets un lien direct git vers le repo cité plus haut ?
Dites-moi je vous fait confiance

A bientôt

unipo · « **Réponse #1402 le:** 18 septembre 2026 à 01:16:10 »

@ubune
Heureux de te voir de passage, espérant que cette dernière année t'ait correctement traité!
Ton tutoriel est dans l'ensemble toujours d'actualité, c'est pas sans raison que je l'ai copier en quasi totalité !

Seule une adaptation pour les flux prioritaire, tirant parti de la nouveauté de odhcp6 depuis 25.12 (dscp & skprio) + adaptation des règles nftables (mention spéciale à @bigboo ) et ajout de scripts gérant la régénération automatique de la chaine XAUTH (mention spéciale à @chat_roux ) & tests de vie suivant les conseils de @levieuxatorange (arpings + ping6 sur les prochains sauts)

basilix · « **Réponse #1403 le:** **Aujourd'hui** à 06:39:07 »

@unipo :

Je pense que l'info d'authentification est générée puis envoyée par ubus à odhcp6c. Il semblerait que ton script de régénération ne soit pas appliqué.

Citation de: jow

uci commit on the cli will not trigger service reloads, you'll have to manually call /sbin/reload_config afterwards.

LuCI uses the ubus uci namespace (ubus call uci commit ...) which will emit change events for any committed /etc/config/xxx file which are then in turn processed by services having a reload trigger installed (grep -r procd_add_reload_trigger /etc/init.d/)

Hyperlien : https://forum.openwrt.org/t/addition-of-new-services-to-openwrt/40479/3

Cette commande vérifie l'état des configurations et déclenche un événement ubus "config.change".

Citer

Specifying triggers

While start_service() takes care of setting service instances states and submitting them to the procd (for a potential service restart), it has to be explicitly called to do so. In most cases it should happen on some related change.

That's where service_triggers() comes in handy and allows specifying triggers. Most system important changes result in generating events that service_triggers() can use for triggering various actions. There are multiple procd_add_*_trigger() helpers for that purpose.

Every configurable service has to specify what system changes should result in its reconfiguration. Those events should be defined in the service_triggers() using available helpers. When related procd service event occurs it will result in executing /etc/init.d/<foo> reload.

Example:

service_triggers()
{
procd_add_reload_trigger "<uci-file-name>" "<second-uci-file>"
procd_add_reload_interface_trigger <interface>
procd_add_reload_mount_trigger <path> [<path> ...]
}

Function    Arguments    Event used    Description
procd_add_reload_trigger    list of config files    config.change    Uses /etc/init.d/<foo> reload as the handler
procd_add_reload_interface_trigger    interface name    interface.*    Uses /etc/init.d/<foo> reload as the handler
procd_add_reload_mount_trigger    paths to watch for    mount.add    Uses /etc/init.d/<foo> reload as the handler
procd_add_restart_mount_trigger    paths to watch for    mount.add    Uses /etc/init.d/<foo> restart as the handler

When using uci from command line uci commit doesn't generate config.change event. It requires calling reload_config afterwards.

This does not apply to using uci over rpcd plugin.

Hyperlien : https://openwrt.org/docs/guide-developer/procd-init-scripts#specifying_triggers

Je crois que cela exécute la fonction reload_service() définit dans le service network.

Code: (/etc/init.d/network) [Sélectionner]

reload_service() {
        local rv=0

        init_switch
        ubus call network reload || rv=1
        return $rv
}

Il me semble que c'est équivalent à service network reload.

Code: (/sbin/service) [Sélectionner]

#!/bin/sh

main() {
        local service="$1"
        shift

        local boot status

        if [ -f "/etc/init.d/${service}" ]; then
                /etc/init.d/"${service}" "$@"
                exit "$?"
        fi

        if [ -n "$service" ]; then
                echo "Service \"$service\" not found:"
                exit 1
        fi

        echo "Usage: $(basename "$0") <service> [command]"
        for service in /etc/init.d/* ; do
                boot="$($service enabled && echo "enabled" || echo "disabled" )"
                status="$( [ "$(ubus call service list "{ 'verbose': true, 'name': '$(basename "$service")' }" \
                        | jsonfilter -q -e "@['$(basename "$service")'].instances[*].running" | uniq)" = "true" ] \
                        && echo "running" || echo "stopped" )"

                printf "%-30s\\t%10s\\t%10s\\n"  "$service" "$boot" "$status"
        done
}

main "$@"

Citer

reload If the service supports this operation (usually by sending SIGHUP signal) then reload configuration files on the fly without stopping. Otherwise if the service does not implement reload then make a full restart (stop then start).

Hyperlien : https://openwrt.org/docs/guide-user/base-system/managing_services

Cela (procd avec reload_config) appelle la commande ubus call network reload. Les clients DHCP sont gérés par netifd. Je crois qu'udhcpc ne supporte pas de mécanisme inter-processus.
Je ne sais pas comment cela fonctionne. Peut-être que cela redémarre udhcpc ?