C'est le Wiki Netfilter.org qui me fait penser cela.

Base chain hooks

ingress (only in netdev family since Linux kernel 4.2, and inet family since Linux kernel 5.10): sees packets immediately after they are passed up from the NIC driver, before even prerouting. So you have an alternative to tc.

Introduction

nftables can replace not even iptables, but it can be used to replace very poorly documented tc filter rules and allow user to classify packets into tc class / qdisc infrastructure.
[...]
* action used to classify packets into tc structure is meta set priority "1:0x2" - 0x can be omitted, but says clearly it is hex number - double quotes are required

Ingress hook

You can use nftables with the ingress hook to enforce very early filtering policies that take effect even before prerouting. Do note that at this very early stage, fragmented datagrams have not yet been reassembled. So, for example, matching ip saddr and daddr works for all ip packets, but matching L4 headers like udp dport works only for unfragmented packets, or the first fragment.

Personnellement, je préfère que le client DHCP soit modifié si nécessaire afin de définir un PCP (priority code point) adéquat sur le paquet DHCP (trame) « Discovery ».

Personnellement, je préfère que le client DHCP soit modifié si nécessaire afin de définir un PCP (priority code point) adéquat sur le paquet DHCP (trame) « Discovery ».

De mon coté je préfère qu'un serveur DHCP n'ait pas à ce soucier de la prio des packets qu'il émet. Chaque couche devrait avoir sa responsabilité bien partagé.
Je préfère faire ça autrement. La solution via NFTable est pas mal du coup. A voir si fonctionnel cela dit.

Après j'ai un doute qu'avec NFTable tu puisses modifié un packet autre que l'accepter ou le refuser.

Mon objectif c'est de faire de l'auto-hébergement Web. Mais face à l'amplification des cyberattaques, je préfère me former. Il y a trop de choses que je ne connais pas
et ma technique d'apprentissage n'est pas forcément très efficace. Je pense que j'assimile les choses de manière trop séquentielle, cela me freine car je n'expérimente
pas de la bonne façon. Je lis le Wiki Netfilter.org alors que j'aurais pu essayer de réaliser des tests avec des machines virtuelles sur mon PC. Je ne sais pas pourquoi
mais cela ne me dit rien, ou je n'en ai pas vraiment envie. Je pense que c'est faire face à la complexité qui me fait peur. Bref !

J'ai également fait des recherches mais je n'ai pas trouvé tellement d'informations sur le sujet.

Après j'ai un doute qu'avec NFTable tu puisses modifier un packet autre que l'accepter ou le refuser.

Rules take action on network packets (e.g. accepting or dropping them) based on whether they match specified criteria.

Each rule consists of zero or more expressions followed by one or more statements. Each expression tests whether a packet matches a specific payload field or packet/flow metadata. Multiple expressions are linearly evaluated from left to right: if the first expression matches, then the next expression is evaluated and so on. If we reach the final expression, then the packet matches all of the expressions in the rule, and the rule's statements are executed. Each statement takes an action, such as setting the netfilter mark, counting the packet, logging the packet, or rendering a verdict such as accepting or dropping the packet or jumping to another chain. As with expressions, multiple statements are linearly evaluated from left to right: a single rule can take multiple actions by using multiple statements. Do note that a verdict statement by its nature ends the rule.

Source : Nftables Wiki: Simple rule management

Les systèmes d'exploitation ont intégré des fonctionnalités au cours de leur histoire. Et donc cela peut être difficile de s'y retrouver.

The netfilter project enables packet filtering, network address [and port] translation (NA[P]T), packet logging, userspace packet queueing and other packet mangling.

Source : Netfilter.org

Netfilter enables filtering at multiple networking levels. With iptables there is a separate tool for each level: iptables, ip6tables, arptables, ebtables. With nftables the multiple networking levels are abstracted into families, all of which are served by the single tool nft.

Source : Nftables families

Le projet Netfilter qualifie nftables (netfilter tables) de « système de classification de paquets » et pas seulement comme un pare-feu logiciel.

iptables is a generic firewalling software that allows you to define rulesets. Each rule within an IP table consists of a number of classifiers (iptables matches) and one connected action (iptables target).

nftables is the successor of iptables, it allows for much more flexible, scalable and performance packet classification. [...]

Source : Netfilter.org

J'essayerais de modifier la CoS avec nftables dans la configuration de mon routeur. Mais avant, je préfère me former sur le pare-feu.

Nicolas Massé mentionne qu'on devrait pouvoir faire cela avec nftables.

Il est à noter qu’à partir du noyau 5.7, le filtre “egress” de netfilter devrait permettre la capture des paquets DHCPv4 et l’étiquetage de leur priorité. Le client DHCP patché ne serait alors plus nécessaire.

@Mastah : Je ne sais pas mais il me semble qu'on peut le faire.

  table netdev filter {
        chain egress {
                type filter hook egress devices = { eth0, eth1 } priority 0;
                meta priority set ip saddr map { 192.168.10.2 : abcd:2, 192.168.10.3 : abcd:3 }
        }
  }

Source : https://lore.kernel.org/all/YZZV42ERgpDbk%2FzL@salvia/

Je pense que la configuration ci-dessous pourrait fonctionner (à tester).

  table netdev filter {
        chain egress {
                type filter hook egress device eth1 priority 0;
                ip daddr 255.255.255.255 meta priority set 0:6 comment "Set CoS value to 6 for DHCPv4 packets"
                ip6 daddr ff02::1:2 meta priority set 0:6 comment "Set CoS value to 6 for DHCPv6 packets"
        }
  }