From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: ip_tables.c: mark_source_chains: bad negative verdict Date: Wed, 25 Jul 2007 17:22:58 +0200 Message-ID: <46A76AD2.1000000@trash.net> References: <200707201725.50459.thomas.jarosch@intra2net.com> <200707211613.18112.thomas.jarosch@intra2net.com> <46A62B9A.9010009@trash.net> <200707251116.37230.thomas.jarosch@intra2net.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: netfilter-devel@lists.netfilter.org To: Thomas Jarosch Return-path: In-Reply-To: <200707251116.37230.thomas.jarosch@intra2net.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org 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.