J'avais pas de pas de match sur mes counters pour les règles DHCPv4/DHCPv6, j'ai donc farfouillé, et apparemment ça serait logique car les paquets DHCPv4/DHCPv6 proviennent de wan.832 et non pas de wan directement.
Ce n'est pas logique. Cela dépend de la façon dont est ajouté le tag VLAN. J'ai réalisé un test basique entre mon routeur et une station (LAN) : les compteurs sont effectivement incrémentés
et les champs PCP et DSCP sont correctement définis. C'est complexe et je n'ai pas suffisamment de connaissances. Il faudrait potentiellement déterminer s'il ne s'agit pas d'un problème
relatif aux offloads (de flux, matériel...) ou s'il est propre au pilote réseau. Mon routeur est inopérant (hors-service). Il aurait fallu que je finalise ma config. et que je lance une capture réseau
sur plusieurs semaines pour constater d'éventuels dysfonctionnements et observer si les champs des paquets sont tous correctement modifiés.
type filter hook egress device "eth0" priority 0; policy accept;
vlan type ip6 udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter accept
vlan id 832 udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter
Il me semble que l'expression vlan type ip6 dans ta règle est redondante : nftables va analyser le datagramme UDP (le champ port de destination). Que gagne t'on à filtrer le type de paquet ?
Je pense que ton
script Shell « test de vie » est valable.
Néanmoins, il manque toute une logique d'intégration système (à remplacer par un vrai programme). (
11:48 : Mon avis a été biaisé par mon aversion pour le Shell,
l'écriture est en générale moins évidente et repose sur plusieurs mécanismes : netifd (protocoles, config. réseau), procd (évènements hotplug), authentification Orange).