L'idée est d'obtenir une connexion réseau fonctionnelle sans artifice. Je cherche à faire fonctionner la solution trouvée par @Mastah.
Dans la version 24.10, il sera en effet possible de définir la priorité des paquets DHCP grâce à l'activation dans les sources Buildroot
d'une nouvelle option CONFIG_PACKAGE_kmod-nft-netdev=y (nouvelle fonctionnalité de netfilter).

Le problème est que l'interface doit exister avant que le pare-feu soit activé au démarrage. Or, pour protéger le système, le pare-feu
est activé avant la configuration des interfaces. Il faut donc réinitialiser les règles du pare-feu immédiatement après la création de
l'interface virtuelle et y ajouter une table de la famille netdev contenant les règles modifiant le PCP et DSCP des paquets DHCP.
Effectivement, une chaîne egress dans netdev doit spécifier le device (VLAN) sauf que celui-ci doit être déjà existant.

Ci-dessous se trouve ma configuration actuelle.

.config dans les sources de OpenWrt Buildroot.

CONFIG_PACKAGE_kmod-nft-arp=y
CONFIG_PACKAGE_kmod-nft-netdev=y

config. firewall

config include
option enabled '1'
option type 'nftables'
option path '/etc/custom-postrouting-chain.nft'
option chain 'mangle_postrouting'
option position 'chain-append'

config include
option enabled '1'
option type 'nftables'
option path '/etc/custom-arp-table.nft'
option position 'ruleset-post'

/etc/custom-arp-table.nft

table arp filter
flush table arp filter

table arp filter {
    chain output {
type filter hook output priority filter; policy accept;
oifname "eth1.832" meta priority set 0:6 counter
    }
}

/etc/custom-postrouting-chain.nft

oifname "eth1.832" icmpv6 type { 133, 135, 136 } meta priority set 0:6 ip6 dscp set cs6 counter

Remarque : Il me semble que la règle précédente aurait plutôt due figurer dans le crochet Netfilter output.

La config. que j'aurais voulu intégrer dans firewall4.

# Specify packet priority for packets forwarded to ISP.
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

/etc/custom-netdev-table.nft

table netdev filter
flush table netdev filter

table netdev filter {
        chain egress {
                type filter hook egress device eth1 priority filter; policy accept;
                udp dport 547 meta priority set 0:6 ip6 dscp set cs6 counter comment "Set PCP and DSCP fields to 6 for DHCPv6 packets"
                udp dport 67 meta priority set 0:6 ip dscp set cs6 counter comment "Set PCP and DSCP fields to 6 for DHCPv4 packets"
        }
}

[SUITE...]

Il s'avère que les règles de pare-feu sont rechargées dynamiquement par Hotplug au démarrage lors de chaque configuration d'interface. On
peut injecter dynamiquement la table netdev après chaque configuration.

/etc/hotplug.d/net/20-firewall

iface="eth1.832"

if [ "$ACTION" = "add" ] &&
   [ "$DEVTYPE" = "vlan" ] &&
   [ "$DEVICENAME" = "$iface" ]
then
logger -t firewall "Loading rules for DHCP clients"
nft add "table netdev filter" || exit 1
nft add "chain netdev filter egress { type filter hook egress device $iface priority 0; }" || exit 1
nft insert 'rule netdev filter egress udp dport 67 meta priority set 0:6 ip dscp set cs6 counter comment "Set PCP and DSCP fields to 6 for DHCPv4 packets"' || exit 1
nft insert 'rule netdev filter egress udp dport 547 meta priority set 0:6 ip6 dscp set cs6 counter comment "Set PCP and DSCP fields to 6 for DHCPv6 packets"' || exit 1
fi

Le script Hotplug dans le répertoire net s'exécute après la création de l'interface VLAN sur laquelle sont basées wan et wan6.

/etc/hotplug.d/iface/20-firewall (échantillon)

Mon fichier contient les commandes suivantes.

logger -t firewall "Reloading firewall due to $ACTION of $INTERFACE ($DEVICE)"
fw4 -q reload

En conséquence, il faut réinjecter les règles dans la table netdev car celles-ci ne figurent pas dans le fichier de configuration de fw4. Elles
s'effacent lorsque fw4 recharge (reload) ses règles.

iface="eth1.832"

logger -t firewall "Reloading DHCP rules initializing PCP and DSCP fields"
nft flush table netdev filter || exit 1
nft add "chain netdev filter egress { type filter hook egress device $iface priority 0; }" || exit 1
nft insert 'rule netdev filter egress udp dport 67 meta priority set 0:6 ip dscp set cs6 counter comment "Set PCP and DSCP fields to 6 for DHCPv4 packets"' || exit 1
nft insert 'rule netdev filter egress udp dport 547 meta priority set 0:6 ip6 dscp set cs6 counter comment "Set PCP and DSCP fields to 6 for DHCPv6 packets"' || exit 1

[SUITE...]

Pour simplifier, j'aurais souhaité désactiver /etc/custom-netdev-table.nft dans la config. de fw4 au redémarrage (ou arrêt) du routeur et l'activer au démarrage
par Hotplug (en basculant le booléen de l'option enabled "0/1" de la section include adéquate via uci ou un autre procédé, dans /etc/hotplug.d/net/20-firewall).
Ainsi, on pourrait retirer les règles DHCP du Hotplug /etc/hotplug.d/iface/20-firewall. Car celles-ci auraient été incorporé dans la config. de fw4.

@cedbouch:

Salut !

Ce n'est pas le bon fil de discussion. Mais l'intitulé est équivoque.

En fait, Orange impose des classes de services dans son réseau pour les requêtes DHCP, ICMP, ARP. Les abonnés Orange qui veulent changer leur Livebox par un routeur perso. doivent
faire de même pour avoir une connexion réseau fonctionnelle.

Cela dépasse mes compétences. Voir l'article sur SQM. Mais cela ne permet de contrôler que le bufferbloat (remplissage excessif des tampons provoquant une dégradation de la connexion
en cas de fort trafic). La congestion du réseau doit être gérée par l'opérateur. Mon commutateur Netgear GS108Tv3 proposait des options plus avancées (perdues car j'ai flashé OpenWrt).

In a switch, each physical port consists of one or more queues for transmitting packets on the attached network. Multiple queues per port are often provided to give preference
to certain packets over others based on user-defined criteria. When a packet is queued for transmission in a port, the rate at which it is serviced depends on how the queue is
configured and possibly the amount of traffic present in the other queues of the port. If a delay is necessary, packets are held in the queue until the scheduler authorizes the
queue for transmission. As queues become full, packets can no longer be held for transmission and are dropped by the switch.

Quality of Service (QoS) is a means of providing consistent, predictable data delivery by distinguishing packets with strict timing requirements from those that are more
tolerant of delay. Packets with strict timing requirements are given special treatment in a QoS-capable network. With this in mind, all elements of the network must be
QoS capable. The presence of at least one node that is not QoS capable creates a deficiency in the network path, and the performance of the entire packet flow is
compromised.

Du coup, je ne crois pas que l'on puisse prioriser le trafic d'une station par rapport aux autres avec OpenWrt.