Hi, On Mon, Mar 04, 2019 at 02:07:55PM +0100, Pablo Neira Ayuso wrote: > On Mon, Mar 04, 2019 at 01:43:11PM +0100, Phil Sutter wrote: > > Hi, > > > > On Sun, Mar 03, 2019 at 10:03:02PM +0100, Florian Westphal wrote: > > > Phil Sutter <phil@xxxxxx> wrote: > > > > > > Sorry for being late. > > > > No worries, it is not urgent. > > > > > > +@cp -f extensions/libxt_connlabel.conf.test extensions/libxt_connlabel.conf.tmp > > > > -m connlabel --label "bit40";=;OK > > > > -m connlabel ! --label "bit40";=;OK > > > > -m connlabel --label "bit41" --set;=;OK > > > > -m connlabel ! --label "bit41" --set;=;OK > > > > -m connlabel --label "bit128";;FAIL > > > > > > Maybe we should forget about the label names and just tests > > > -m connlabel --label 127 > > > > > > i.e., parse the numeric value instead of providing a fake > > > one. I agree that temporary replace of hosts one is bad. > > > > Fine with me as well. Obviously this would reduce code coverage of > > tests, although not much since libnetfilter_conntrack is used for label > > map lookup. Argh. So I started with simply dropping all the connlabel.conf mangling in libxt_connlabel.t along with replacing the names by values. Turns out the extension exits if file wasn't found, no big deal changing that. Doing so I discovered that parsing bit values is done by nfct_labelmap_get_bit() as well but only if library initialization has succeeded. Fine, manual parsing as a fallback it is. Checking libnetfilter_conntrack once again to be sure, I noticed that it doesn't accept bit values unless they appear in connlabel.conf. Now I start changing functional behaviour and dropping label name test becomes a larger change than supporting connlabel.conf in non-standard path. /o\ > We can probably place some mapping lookup tests for this in > libnetfilter_conntrack. I just found the ominous "qa" directory in there, so I guess we're already fine in that regard. :) Cheers, Phil
