ip_tables.c: mark_source_chains: bad negative verdict

Patrick McHardy kaber at trash.net
Wed Jul 25 17:22:58 CEST 2007


Thomas Jarosch wrote:
> Hello Patrick,
> 
> On Tuesday, 24. July 2007, you wrote:
> 
>>Yes, what you could do is use the original ruleset (not the saved one)
>>and find out which rule causes the error.
> 
> 
> The "saved" one is the only one I got. I executed the rules manually
> and it failed doing something like this: iptables -A R5_FWD xyz -j forward_ok.
> 
> "forward_ok" jumps to "forward_tolanok" which contains two rules jumping 
> to "clicount_in". "clicount_in" is used for accounting and can be referred
> by multiple places. IMHO this is the place where the "visisted" code fails:
> 
> -A forward_ok -o eth0 -j forward_tolan_ok
> -A forward_tolan_ok -i eth1 -m condition --condition inet_eth -j clicount_in
> -A forward_tolan_ok -i ppp0 -m condition --condition inet_ppp -j clicount_in
> 
> The corresponding debug output:
> Jul 20 17:11:13 intratest2 kernel: Jump rule 232960 -> 215940
> Jul 20 17:11:13 intratest2 kernel: Jump rule 233176 -> 215940
> Jul 20 17:11:13 intratest2 kernel: mark_source_chains: bad negative verdict 
> (-2140522486)
> 
> It works if I remove the second jump to clicount_in.
> Does that make sense to you? 


Yes, that makes sense, I think what happens is that the jump back goes
to the wrong position and things fall apart. I wasn't able to make a
simple testcase though.

> Now comes the strange part: The ruleset gets generated by an automatic system. 
> I have the same style of ruleset running on 20 machines, it only failed once. 
> Somehow I get the feeling the order of the rules/chains is important
> to trigger the problem.


It probably is.



More information about the netfilter-devel mailing list