Hello,

Une problématique courante dans cette section du forum est de patcher des softs (typiquement des clients DHCP) pour qu'ils « préparent le terrain » à la mise en place de la CoS (c-à-d les trois bits "PCP" dans l'en-tête 802.1Q). Sur les machines et routeurs basés sur Linux, cela passe typiquement par l'ajustement de la skb->priority via setsockopt(SOL_SOCKET, SO_PRIORITY).

En résumé :
        programme (ex : dhclient)                  kernel          interface vlan      paquet réseau
setsockopt(SOL_SOCKET, SO_PRIORITY, 6, 4);  ->  skb->priority  ->  egress-qos-map  ->    802.1Q/PCP   -> Orange content

Une rapide recherche m'a confirmé que setsockopt() était fréquemment discuté ou du moins mentionné mais LD_PRELOAD est beaucoup moins souvent évoqué, alors que ça permet potentiellement de s'épargner une recompilation (ou de ne pas embêter zoc).

Aujourd'hui, j'ai pris le temps d'écrire un petit objet LD_PRELOAD qui émet un setsockopt() après chaque appel à socket (ce qui est un peu bourrin en théorie mais a priori inoffensif dans la pratique) : so_priority.so

Je vous copie-colle bêtement le README :

Set SO_PRIORITY (aka skb->priority on Linux) right after each socket() call.

Compile with:

Code: [Sélectionner]

gcc -shared -ldl -fPIC so_priority.c -o so_priority.so
Usage:

Code: [Sélectionner]

SO_PRIORITY_DEBUG=1 SO_PRIORITY_VALUE=6 LD_PRELOAD=/path/to/so_priority.so program arg1 arg2

Petite limitation : pour ceux qui voudraient l'utiliser avec l'utilitaire ping, cela ne fonctionne que si vous êtes root (parce que la prise en compte de LD_PRELOAD est désactivée pour les binaires setuid ou associés à une capability, ce qui est le cas de ping).

That's it.

Ah oui, Linux ça va mais alors le clavier, c'est une autre histoire...
=> corrigé -- merci pour le signalement

Je voulais juste dire merci pour ce soft. Presque deux ans plus tard il m'a permis de lancer un Debian 11 en tant que routeur.

De rien

Il n'y a pas de réponse absolue à cette question.
Tu mentionnes que tu cherches la solution la plus light (en termes de performances, je suppose) et la plus propre (en termes de maintenabilité je suppose).

En termes de performances, tc va demander au kernel de prendre un peu de temps (vraiment pas longtemps, ça doit se compter en cycles) pour vérifier si chaque paquet est un paquet DHCP. Si oui, il corrigera la skb->priority de ce paquet pour que celle-ci soit prise en compte par l'egress-qos-map associée à l'interface VLAN. so_priority.so positionne directement cette skb->priority depuis l'user land et ce uniquement pour le programme dhclient. Le kernel n'a plus à inspecter tous les paquets à la recherche de paquets DHCP. Sur ce point, so_priority.so l'emporte sur tc.

En termes de maintenabilité... c'est difficile à juger. tc est fourni par et intégré à ta distribution, alors que so_priority.so est une "pièce rapportée", à compiler soi-même selon un processus indéfini, ce qui peut être un "big no-no" dans certaines situations. Sur ce point, tc l'emporte sur so_priority.so.