J'ai vu une discussion que le kernel settait les deux non ?

Code: [Sélectionner]

https://ocrete.ca/2009/07/24/when-a-man-page-lies/
https://gist.github.com/wenjianhn/5700915c16e3f7d29c1b

Moi aussi je faisais cette confusion. Du coup j'ai vérifié le code source du kernel il y a quelques temps...
Et non, le kernel n'associe pas la socket_priority interne de Linux au champs IP.DSCP. Aussi vérifié par l’expérimentation...
Quand bien même le kernel le ferait pour les socket "normales", ça ne marcherait pas sur les RAW sockets utilisées par les programmes clients DHCPv4.

On peut utiliser netfilter/iptabels/nftables pour la modifier, mais seulement pour les applis qui ne sont pas obligées d'utiliser des socket RAW. Celles-ci bypass complétement netfilter, on ne peut pas agir dessus. Comme pour les client DHCPv4.

Les astuces suivantes vont fonctionner:
- modifier le code source pour positionner la bonne valeur IP.DSCP directement dans las paquets DHCPv4 initiaux sur la RAW socket
- altérer les paquets au niveau L2/L3 par un smart switch en amont du port WAN

Les astuces suivants ne vont pas fonctionner:
- preload une lib .so qui va forcer un appel socket modifié conjoint avec un setsockopt sur la RAW socket: ne modifie pas la IP.DSCP
- utiliser un programme eBPF (kernel assez récent...) qui va altérer la socket priority de la RAW socket: ne modifie pas la IP.DSCP

En fait si, dans l'autre sens (IP.DSCP -> socket_priority, plus exactement, il le fait avec le champ IP.TOS, qui est l'ancêtre du DSCP et qui est au même endroit dans l'entête IP...), mais UNIQUEMENT sur les paquets routés (et donc pas sur les paquets dont l'origine est le routeur lui-même).

Le résultat de ça est d'ailleurs que dans certains cas des paquets routés se retrouvent avec une CoS VLAN à 6 à cause de leur DSCP. C'est notamment le cas avec certains clients SSH qui positionnent leur DSCP à CS6 qui se retrouve donc mappé en CoS 6 avec pour résultat des performances catastrophiques pour les transferts de fichier over SSH ou pour les tunnels...

ahah oui j'étais tombé la dessus aussi et j'y comprenais rien:
https://github.com/torvalds/linux/blob/68e77ffbfd06ae3ef8f2abf1c3b971383c866983/net/ipv4/ip_forward.c#L161
(activé par défaut...)

Hello,

Je suis preneur si tu as un script complet avec tc.
J’en ai un mais qui doit être incomplet.

Merci

Merci !

Je viens de perdre ma connexion. J’avais remplacer la livebox 6 par un ont orange externe… bon je vais remettre « ce truc ».

J'ai posté le script tc que j'utilise dans un post précédent dans ce sujet: https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/msg993988/#msg993988

Hello,

Juste pour clarifier, voici mon script à base de tc :
1: tc filter add dev $iface parent 1: prio 1 protocol 0x806 u32 match u32 0 0 action skbedit priority 0:6 # arp
2: tc filter add dev $iface parent 1: prio 2 u32 match ip protocol 17 ff match ip dport 67 ffff action skbedit priority 0:6 # dhcpv4
3: tc filter add dev $iface parent 1: prio 3 protocol ipv6 u32 match ip6 protocol 17 ff match ip6 dport 547 ffff action skbedit priority 0:6 # dhcpv6
4: tc  filter add dev $iface parent 1: prio 4 protocol ipv6 u32 match ip6 protocol 58 ff action skbedit priority 0:6 # icmpv6

ton script tc :
1: tc filter add dev ${iface} parent 1:  prio 1  protocol arp  u32  match u8 0 0  action skbedit priority 0:6
2: tc filter add dev ${iface}  parent 1: prio 2 protocol ip u32 match ip ihl 5 0xf match u16 0x0000 0x1fff at 6 match ip protocol 17 0xff match ip sport 68 0xffff match ip dport 67 0xffff action skbedit priority 0:6 pipe action pedit pedit munge ip tos set 0xc0 retain 0xfc pipe action csum ip4h

TA ligne 2 fait ce que font MES lignes (2 + 3 + 4) avec en plus le marquage DSCP pour être identique à la COS. C'est bien cela ?
Il faut lire un "OR" sur chaque critère ?
Il y a 2 fois "pedit pedit" sur TA ligne 2, c'est normal ?

Merci