La description de match : c'est exactement ce que je supposais :
match TYPE VAL MASQ at OFF signifie en C :
bool test (char *p) // p pointe sur le début de paquet
{
return (*(TYPE *) (p+OFF)) & MASQ == VAL;
}
L'exemple donné dans la doc correspond exactement :
Sauf que le commentaire "IP Total length 0x34 " est faux : en fait 0x34 n'apparait même pas dans le filtre!
Il faut traduire :
match u16 0x0000 0xffc0 at 2 en C :
(*(u16*)(p+2)) & 0xffc0 == 0x0000 or 0xffc0 égal ~ 0x3F en calculant en u16 (voir remarque)
donc | x & 0xffc0 | = x & ~ 0x3F |
| = x / 0x40 * 0x40 |
donc les conditions suivantes sont équivalentes :
x & 0xffc0 == 0x0000x / 0x40 * 0x40 == 0x / 0x40 == 0x < 0x40or x = *(u16*)(p+2) correspond à la taille du paquet donc :
taille du paquet est < 0x40
Ce raisonnement, juste pour analyser
une partie d'une commande "tc filter ... match", c'est quand même très laborieux.
Je trouve le système de filtrage de
tc pénible à souhait, au contraire des filtres
iptables.
En fait, plus je me documente sur les possibilités de discriminations IP de linux, plus je trouve que :
- c'est hyper compliqué;
- différents sous-systèmes semblent suivre une philosophie différente;
- du point de vue conception orientée vers l'administrateur, c'est zéro : plus abscons c'est difficile à imaginer;
- l'administrateur n'a aucun indice sur ce qui est efficace ou non (est-ce que beaucoup de règles iptables à la suite est efficace? on ne sait pas comment c'est implèmenté);
- dans le pur style linux, on aligne des règles à la suite au lieu de permettre des expressions complexes comme un véritable langage avec une grammaire récursive;
- la doc de chaque sous-système mentionne assez peu les autres; par exemple PREROUTING a lieu avant ou après l'examen des règles de routage pour un paquet généré localement? intuitivement il faut que ça soit après, mais ça n'est pas expliqué dans la doc de iptables;
- le comportement de la pile IP dépend de 42000 sysctl mal voir pas documentés du tout, ou documentés plusieurs fois avec une plage de valeurs permises différentes.
Je pense que le seule façon de débroussailler tout ça serait de tout décrire dans un formalisme rigoureux - si ce n'est pas déjà trop tard.
Les réponses a toutes les questions qu'on peut se poser doivent se trouver au beau milieu d'une discussion sur une de ML des dév. C'est là qu'est la vraie doc de linux.
Est-ce qu'une seule personne a une vision d'ensemble du circuit que peut faire une trame réseau dans un pont/routeur/... linux?
Je trouve ça vaguement monstrueux (dans le style de Firefox ou du C++).
KIWI fibre optique