kaber at trash
Jul 25, 2007, 8:22 AM
Post #6 of 6
(824 views)
Permalink
|
|
Re: ip_tables.c: mark_source_chains: bad negative verdict
[In reply to]
|
|
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.
|
iptables.gz
