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

bigboo · « **Réponse #1260 le:** 23 février 2026 à 22:10:38 »

Citation de: bigboo le 22 décembre 2025 à 00:11:46

La version 25.12.0 rc1 est disponible depuis 2j:
https://downloads.openwrt.org/

J'attend avant de mettre à jour vu tous les changements que cela va représenter pour les fichiers de config spécifiques au remplacement de la Livebox.

Mais j'ai vraiment espoir de pouvoir bientôt tagguer tous les paquets avec QoS à 0 comme recommandé par levieuxorange pour régler le problème de Wireguard bridé à 5mb/s

Bon ben je me répond à moi-même

J'ai trouvé la solution pour lever le bridage à 5mb/s pour Wireguard, en me basant sur la config du premier post c'est finalement très simple, dans le fichier /etc/nftables.d/nft-prio6-rules.include Il faut ajouter la ligne:

Code: [Sélectionner]

oifname "eth0.832" counter meta priority set 4:1
Wireguard taggue ses paquets en CoS 4, avec cette ligne le firewall les retaggue en CoS 1, puis dans l'interface ils sont retagué en CoS 0.

Pour info voici mon fichier nft-prio6-rules.include modifié et mis à jour à partir de différents posts trouvés sur ce forum plus mon ajout personnel du jour pour retaguer tous les paquets en CoS 0 au final conformément à ce qui est attendu par Orange pour éviter tout bridage :

Code: [Sélectionner]

oifname "eth0.832" counter meta priority set 0:1
oifname "eth0.832" counter meta priority set 2:1
oifname "eth0.832" counter meta priority set 3:1
oifname "eth0.832" counter meta priority set 4:1
oifname "eth0.832" counter meta priority set 5:1
oifname "eth0.832" udp dport 67 counter meta priority set 0:6 ip dscp set cs6
oifname "eth0.832" udp dport 547 counter meta priority set 0:6 ip dscp set cs6
oifname "eth0.832" icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert } ip6 daddr fe80::ba0:bab/128 counter meta priority set 0:6 ip6 dscp set cs6
oifname "eth0.832" icmpv6 type nd-router-solicit counter meta priority set 0:6 ip6 dscp set cs6

EDIT:
en fait ca ne marche pas du tout
depuis mon pc windows >routeur openwrt>orange>livebox 5> serveur debian : pas de bridage pour wireguard
mais pour serveur debian>routeur openwrt>orange>livebox 5> serveur debian : bridage à 5mb/s pour wireguard.
je ne comprends pas

unipo · « **Réponse #1261 le:** 23 février 2026 à 23:13:04 »

Étrange, le bridage est inversé dans mon cas:
Serveur => routeur OpenWRT (wireguard peer) => Orange => Livebox => client (wireguard peer): Pas de bridage
Client (wireguard peer) => Livebox => Orange => routeur OpenWRT (wireguard peer) => serveur: Bridage 5mb/s

zof · « **Réponse #1262 le:** 24 février 2026 à 14:32:54 »

j'essaie de comprendre comment tout cela fonctionne avant de supprimer ma livebox mais c'est pas vraiment facile...

en lisant les précédents posts, j'ai l'impression que qu'il y a beaucoup de confusion (mais c'est peut être dans ma tête ;-) )

pour moi, il y a 3 endroits où on peut mettre une qualité :
- champ DSCP du paquet IP
- priorité interne du paquet linux
- champ PCP de la trame VLAN ethernet

pour moi, la directive "list egress_qos_mapping '1:0'" au niveau de l'interface permet de transformer une priorité interne en champ PCP sur une interface VLAN
et les regles nft "meta priority set xx" servent uniquement à fixer la priorité interne

est-ce que je me trompe ?

si c'est le cas, pas besoin de toucher au champ DSCP du paquet IP pour les trames DHCP ?

de plus, pour moi ces lignes ci-dessous se remplacent et donc n'ont aucune utilité à part la dernière :

oifname "eth0.832" counter meta priority set 0:1
oifname "eth0.832" counter meta priority set 2:1
oifname "eth0.832" counter meta priority set 3:1
oifname "eth0.832" counter meta priority set 4:1
oifname "eth0.832" counter meta priority set 5:1

je suis un peu perdu et les docs techniques ne sont pas toujours très claires (à mes yeux en tout cas ;-) )

basilix · « **Réponse #1263 le:** 24 février 2026 à 17:47:38 »

L'IA indique que meta priority modifie la priorité du connecteur réseau (socket) (SO_PRIORITY) :

meta priority → skb->priority
→ egress-qos-map
→ PCP dans vlan_tci
→ insertion 802.1Q

et que egress-qos-map fait correspondre cette priorité interne à la valeur du champ PCP.

Pour une interface VLAN logicielle (pas DSA), sans accélération matérielle (hardware offload) ou déchargement de flux (flow offloading) :

Code: [Sélectionner]

uci -q batch <<-EOF
	add firewall include
	set firewall.@include[-1].enabled='1'
	set firewall.@include[-1].type='nftables'
	set firewall.@include[-1].path='/etc/custom-netdev-table.nft'
	set firewall.@include[-1].position='ruleset-post'
EOF

wan_iface=$(jsonfilter -i /etc/board.json -e '$.network.wan.ports[0]')

cat >/etc/custom-netdev-table.nft <<EOF
table netdev filter
flush table netdev filter

table netdev filter {
        chain set_isp_vlan_832 {
                udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter comment "Set QoS for DHCPv6 packets"
                udp dport 67 vlan pcp set 6 ip dscp set cs6 counter comment "Set QoS for DHCPv4 packets"
                icmpv6 type { 133, 135, 136 } vlan pcp set 6 ip6 dscp set cs6 counter comment "Set QoS for ICMPv6 packets"
        }
        chain set_isp_vlan_840 {
                ip protocol igmp vlan pcp set 5 ip dscp set cs4 counter comment "Set QoS for IGMP packets"
        }
        chain lan_iptv {
                ip protocol igmp ip dscp set cs4 counter comment "Set DSCP for IGMP packets"
        }
        chain egress {
                type filter hook egress device $wan_iface priority filter; policy accept;
                vlan type arp vlan pcp set 6 counter comment "Set QoS for ARP packets"
                vlan id 832 jump set_isp_vlan_832
                vlan id 840 jump set_isp_vlan_840
                jump lan_iptv
        }
}
EOF

J'ai écrit cette configuration il y a plusieurs mois (cela commence à dater).

Les compteurs ne semblent pas fonctionner mais c'est une autre histoire.

Je n'ai pas testé sur la version 25.12. J'utilisais la version nocturne. Il faut au minimum la version 25.12 (nftables >= v1.1.3).

zof · « **Réponse #1264 le:** 26 février 2026 à 10:58:07 »

Citation de: basilix le 24 février 2026 à 17:47:38

J'ai écrit cette configuration il y a plusieurs mois (cela commence à dater).

Les compteurs ne semblent pas fonctionner mais c'est une autre histoire.

Je n'ai pas testé sur la version 25.12. J'utilisais la version nocturne. Il faut au minimum la version 25.12 (nftables >= v1.1.3).

Merci pour cette aide ! Il y a beaucoup beaucoup beaucoup d'infos super interessantes sur ce forum et je n'étais pas encore tombe dessus...

Cela me semble plus simple à mettre en place...
j'attends la version 25.12 final et testerai tout ça...

gaiusbaltar · « **Réponse #1265 le:** 26 février 2026 à 14:55:55 »

Je suis toujours en 21.02.1 et tout fonctionne impec. Quelles sont les risques à pas mettre à jour? Des vulnérabilités? (mon firewall est full fermé)

0xgrm · « **Réponse #1266 le:** 04 mars 2026 à 00:43:28 »

Bonsoir,

Je vous partage ici ma config OpenWRT qui me permet de bien taguer les paquets DHCP en CoS 6 d'une part, et de ne pas être soumis à la bride à 5 Mbps d'autre part sur n'importe quel type de trafic entrant et sortant.

Tout d'abord dans /etc/nftables.d/nft-prio6-rules.include :

Code: [Sélectionner]

oifname "eth1.832" udp dport 67  counter meta priority set 6
oifname "eth1.832" udp dport 547 counter meta priority set 6

oifname "eth1.832" ip protocol icmp counter meta priority set 6
oifname "eth1.832" ip protocol igmp counter meta priority set 6
oifname "eth1.832" ip6 nexthdr ipv6-icmp counter meta priority set 6

Puis dans /etc/config/network j'ai ajouté les lignes suivantes :

Code: [Sélectionner]

list egress_qos_mapping '0:0'
list egress_qos_mapping '1:0'
list egress_qos_mapping '2:0'
list egress_qos_mapping '3:0'
list egress_qos_mapping '4:0'
list egress_qos_mapping '5:0'
list egress_qos_mapping '6:6'
list egress_qos_mapping '7:0'

Le tuto en première page mappe quasiment toute le traffic sortant en CoS 6, ce qui permet de faire fonctionner le DHCP certes, mais avec une bride globale à 5 Mbps en upload !

Cela fonctionne bien avec Wireguard entre deux connexions Orange FTTH XGS-PON. J'obtiens un débit maximal stable de 630 Mo/s au sein du tunnel. Orange c'est du sérieux...

basilix · « **Réponse #1267 le:** 04 mars 2026 à 06:19:23 »

@Oxgrm:

Citer

Je vous partage ici ma config OpenWRT qui me permet de bien taguer les paquets DHCP en CoS 6 [...]

Comment cela fonctionne ?

J'ai la vague impression qu'il n'y a aucune logique dans ta configuration.

Code: [Sélectionner]

list egress_qos_mapping '4:0'

Il n'y a que la règle ci-dessus qui me paraît correspondre. Mais cela ne résout pas le problème de priorité lié au « raw socket ».

Code: [Sélectionner]

list egress_qos_mapping '6:6'

Logique du tutoriel

Le tutoriel fait la supposition que les paquets DHCP ont une priorité interne à 0. Des paquets DHCP sont émis par une « raw socket » ; ils ne peuvent
donc pas être manipulés par une règle de la famille inet, ip, ip6. Leur priorité interne reste inchangée à 0 tandis que celle des autres changent à 1.

Code: [Sélectionner]

oifname "eth0.832" counter meta priority set 0:1

Cette priorité interne 1 sera finalement « réinitialisée » à un champ PCP fixé à 0 (CoS).

Code: [Sélectionner]

        list egress_qos_mapping '1:0'

Les paquets ayant une priorité interne à 0 auront leur champ PCP fixé à 6.

Code: [Sélectionner]

        list egress_qos_mapping '0:6'
        list egress_qos_mapping '6:6'

basilix · « **Réponse #1268 le:** 04 mars 2026 à 06:36:05 »

La meilleure solution serait d'intégrer la fonctionnalité dans BusyBox (client DHCPv4). En effet, OpenWrt permet déjà de définir la CoS et le DSCP du client DHCPv6.

Un oubli dans le script du protocole empêche potentiellement de fixer le DSCP du client DHCPv6 via UCI.

Code source odhcp6c (voir ci-dessous).

Code: [Sélectionner]

		case 'K':
			config_set_sk_priority(atoi(optarg));
			break;

		case 't':
			config_set_rtx_timeout_max(CONFIG_DHCP_SOLICIT, atoi(optarg));
			break;

		case 'C':
			config_set_dscp(atoi(optarg));
			break;

Code: [Sélectionner]

	[ -n "$skpriority" ] && append opts "-K$skpriority"

Une autre solution serait de définir des règles dans la table netdev. Il me semble que cela ne fonctionnera pas sur tous les routeurs. Voir mon post.

0xgrm · « **Réponse #1269 le:** 04 mars 2026 à 10:46:53 »

Citation de: basilix le 04 mars 2026 à 06:19:23

@Oxgrm:

Comment cela fonctionne ? ...

Il s'agissait d'une erreur de compréhension de ma part concernant l'application des règles nftables.

Toutefois, je ne comprends toujours pas l'intérêt de cette ligne dans la configuration de l'interface :

Code: [Sélectionner]

list egress_qos_mapping '0:6'
Pour moi cette ligne n'a aucun intérêt car on marque déjà en interne les paquets nécessaires en CoS 6.
De plus lorsque je l'active, j'ai effectivement une bride à 5 Mbps car tous les paquets sortent en CoS 6.

Vivement l'intégration dans OpenWRT et BusyBox de la possibilité de définir ces options directement au niveau du client DHCP...

basilix · « **Réponse #1270 le:** 04 mars 2026 à 12:40:25 »

@Oxgrm :

Certains paquets DHCP passent par un connecteur réseau brut (raw socket). Mais ces paquets contournent des crochets (hooks) Netfilter.
En d'autres termes, les règles nftables qui modifient la priorité interne ne s'appliquent pas à ces paquets.

Code: [Sélectionner]

list egress_qos_mapping '0:6'

Je l'ai déjà mentionné dans mon post précédent. On suppose que les paquets DHCP ont une priorité interne par défaut à 0.
Les paquets DHCP dont la priorité interne n'est pas modifiée par nftables (à 0) auront ainsi leur champ PCP fixé à 6.

Citer

Vivement l'intégration dans OpenWRT et BusyBox de la possibilité de définir ces options directement au niveau du client DHCP...

C'est la 3ième relance sur la liste de diffusion de BusyBox mais apparemment sans succès. Les mainteneurs ne doivent pas être
très motivés pour cette fonctionnalité. Un correctif semblable a pourtant été intégré dans odhcp6c (client développé par OpenWrt).

0xgrm · « **Réponse #1271 le:** 04 mars 2026 à 22:12:43 »

@basilix :

Je comprends désormais la logique mais dès que j'ajoute cette ligne à l'interface, mon débit en upload est bridé à 5 Mbps.

Je pense que je ne pourrai pas faire beaucoup mieux tant que ce ne sera pas supporté directement par les clients DHCPv4 et v6 d'OpenWRT.
La solution netdev me paraît également plus performante mais je crains que l'activation du soft offloading de mon côté ne la rende bancale.