On Fri, 17 Jan 2014, Vytas Dauksa wrote: > as promised attaching third patch, which prints mark and markmask in > hexadecimal. Patch is applied with a small modification: the prefix "0x" was missing at printing/saving mark/mask values. Best regards, Jozsef > On 9 January 2014 21:02, Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx> wrote: > > On Thu, 9 Jan 2014, Vytas Dauksa wrote: > > > >> > Why it's important that the kernel should mask the mark value, when the > >> > user could add the intended value directly? The only case where it's > >> > required when entries added/deleted by the SET target. It's more natural > >> > for me if the markmask value has a meaning and effect for kernel side > >> > add/del operations only, and ignored for user add/del/test and kernel > >> > tests. What's your opinion? > >> > >> The kernel must apply the mask at test time - that's the whole reason > >> for it. In our use case the desired mask is 0xff000000, because those > >> bits identify the protocol, and the other bits are for an unrelated purpose. > >> Because the other bits could be set to anything, without a mask there > >> might have to be 2^24 entries for the other possible values. > >> > >> If the kernel applies a mask on test, but values added by the user aren't > >> masked, those entries would never match. It seems clearer to mask them > >> at add time, so that the user gets sensible errors; for instance, adding two > >> different values which mask to the same thing will give the same error as > >> adding the same value twice. > >> > >> Another option we discounted was that each entry could have its own > >> mask. This didn't make sense because they're not strictly ordered like > >> netmasks, so multiple entries could be equally applicable, and no hashing > >> is possible. If 12000000/ff000000 and 00340000/00ff0000 are in the set, > >> but one is nomatch, and a packet has mark 12345678, which entry should > >> take effect? > > > > I see - good arguments, keep the original operations then. > > > >> > A small thing, but I'd prefer if the mark value were printed/saved in hex > >> > instead of decimal, similarly to iptables. Better introduce a new print > >> > function for it. > >> > >> Sure, will implement this on Friday > > > > Best regards, > > Jozsef > > - > > E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx > > PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt > > Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences > > H-1525 Budapest 114, POB. 49, Hungary > > > > -- > Vytas Dauksa > Junior Developer > vytas.dauksa@xxxxxxxxxxxxxx > > Smoothwall Ltd > Phone: +44 (0) 8701 999500 > www.smoothwall.net > - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary
