Je me demande si ebtables ne pourrait pas régler le problème. Il peut fouiller dans les paquets ethernets et appliquer des rules comme iptables.

http://ebtables.netfilter.org/misc/ebtables-man.html
et plus spécifiquement ça:
http://ebtables.netfilter.org/examples/basic.html#ex_nobridge

Je sais pas. Ca m'étonnerait qu'il agisse sur les RAW sockets...

si avec un bridge ca marche (en théorie):

- on crée un bridge avec dedans une seule interface (la wan)
- on met la config dhcp sur le bridge au lieu de l'interface
- on met une règle ebtables qui envoi sur iptables le trafic dhcp sortant (grace a la table broute: -t broute −j redirect −−redirect−target DROP)
- on met une regle iptables qui CoS 6 le trafic dhcp sortant

probleme c'est que tout le trafic wan devient bridgé ce qui peut impacter les perfs.

Faut voir car je viens de regarder et "ebtables" ne semble pas être une commande disponible

sur quelle machine ?

Sous DD-WRT
Parce que tu comptes faire ca sur quoi ?

n'importe quel routeur ou pc sous linux. ce topic n'est pas spécifique a dd-wrt.

a priori ebtables existe aussi sous dd-wrt mais je ne suis pas spécialiste de dd-wrt.

Ah ok, j'avais pas vu que ce n'était plus aacebedo qui me parlait ;-)

ebtables est dispo sur mon DDWRT mais apparemment la version est defecteuse et fige.
Du coup je l'ai récupéré ici https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1103763#1103763

Maintenant je n'ai pas encore mon boitier fibre mais j'ai tenté de jouer un peu avec le routeur DDWRT quand même et je n'ai pas réussi à capturer les paquets sortants sur l'interface pour vérifier la tronche du paquet sortant. Du coup je ne sais pas si ebtables set correctement la cos.

La commande que j'ai tentée est la suivante:
/tmp/ebtables -A FORWARD -p ipv4 --ip-protocol udp --ip-source-port 67 -j ACCEPT
Je pense qu'il faudrait un truc comme ça
/tmp/ebtables -A FORWARD -i vlanXXX -p ipv4 --ip-protocol udp --ip-source-port 67:68 -j ACCEPT --vlan-prio 6
/tmp/ebtables -A OUTPUT -i vlanXXX -p ipv4 --ip-protocol udp --ip-source-port 67:68 -j ACCEPT --vlan-prio 6

avec vlanXXX le vlan sur lequel on met le port WAN du routeur taggé avec le bon id

Reste à voir si ca vaut les 80€ du switch...

--vlan-prio c'est une 'match extension' ca ne sert pas à mettre la prio mais a la tester (comme un pattern matching).

ebtables ne peut changer la prio.

il faut passer par iptables comme  indiquer dans mon post précedent:

- on met une règle ebtables qui envoi sur iptables le trafic dhcp sortant (grace a la table broute: -t broute −j redirect −−redirect−target DROP)

donc ca donnera un truc du genre:

faire un bridge br0 et mettre l'interface vlanXXX dedans.

ebtables −t broute −A BROUTING −i br0 −p ipv4 −−ip−protocol udp --ip-source-port 68 −j redirect −−redirect−target DROP

ceci va intercepter les dhcp clients entrant dans le bridge (donc quand le process dhcpclient va emettre des "raw socket" sur le bridge br) et les remonter au niveau d'iptables . DROP sur un broute => router le paquet . cf la doc:

broute is used to make a brouter, it has one built-in chain: BROUTING. The targets DROP and ACCEPT have a special meaning in the broute table (these names are used instead of more descriptive names to keep the implementation generic). DROP actually means the frame has to be routed, while ACCEPT means the frame has to be bridged. The BROUTING chain is traversed very early. However, it is only traversed by frames entering on a bridge port that is in forwarding state. Normally those frames would be bridged, but you can decide otherwise here. The redirect target is very handy here.

le paquet étant routé il arrive sur iptables, c'est la qu'il faut le marquer en QoS.

donc pas confondre le fonctionnement d'iptables et d'ebtables c'est pas trop la meme chose.
lecture: http://ebtables.netfilter.org/br_fw_ia/br_fw_ia.html (oui je sais c'est pas simple:))

Petit retex concernant le GS716Tv3 (j'avais un v2 jusqu'à hier).

- Quelques trucs en plus (routage/protected port/MVR)
- Un temps de boot multiplié par 2, voire 3 (environ 1m30, c'est looooooong)
- Refroidissement passif (0 Db, du bonheur)
- L'interface web est beaucoup plus réactive

Malheureusement, pas de progrès du coté DiffServ (donc toujours pas de possibilité de marquage CoS6 en IPv4 et en IPv6 en simultané).
Le système de "protected port" n'a aucun intérêt pour moi.
En effet, on peut juste marquer les ports comme protégés (ou pas), et il n'y a alors aucune communication possible entre deux ports protégés.
Je ne vois qu'une application à ça : l'isolation des clients (qui m'est déjà offerte en WiFi par mon contrôleur Unifi)

Je vais un peu me pencher sur l'aspect routage du bouzin pour voir si ça a un intérêt quelconque, mais comme ça, à froid, je vois pas.

En résumé, rien de vraiment folichon, mais c'était principalement les 0 db qui me faisaient de l'oeil.