(no subject)

Patrick McHardy kaber at trash.net
Tue Nov 1 18:47:17 CET 2005


Yasuyuki KOZAKAI wrote:
> Subject: Re: nf_conntrack comments
> From: Yasuyuki KOZAKAI <kozakai at isl.rdc.toshiba.co.jp>
> Fcc: +backup
> In-Reply-To: <20051029135524.GQ4479 at sunbeam.de.gnumonks.org>
> References: <20051018084924.GD20338 at sunbeam.de.gnumonks.org>
> 	<39e6f6c70510282108i60d78df6w9728f40641dccf80 at mail.gmail.com>
> 	<20051029135524.GQ4479 at sunbeam.de.gnumonks.org>
> X-Mailer: Mew version 4.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
> ----
> 
> Hi, Acme and all,
> 
> Acme, thank you for reviewing of nf_conntrack.
> 
> From: Harald Welte <laforge at netfilter.org>
> Date: Sat, 29 Oct 2005 15:55:24 +0200
> 
> 
>>>+       if (!h) {
>>>+               DEBUGP("icmpv6_error: no match\n");
>>>+               return NF_ACCEPT;
>>>+       } else {
>>>+               if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
>>>+                       *ctinfo += IP_CT_IS_REPLY;
>>>+       }
>>>+
>>>+       /* Update skb to refer to this connection */
>>>+       skb->nfct = &nf_ct_tuplehash_to_ctrack(h)->ct_general;
>>>+       skb->nfctinfo = *ctinfo;
>>>+       return -NF_ACCEPT;
>>>+}
>>>
>>>I noticed that some of the returns are NF_ACCEPT while at leat this last one
>>>returns -NF_ACCEPT, is this a special convention or should all be negative? or
>>>positive?
>>
>>I'll check that, looks like a bug to me, too.
> 
> 
> If we don't change, the result is same. If this function return NF_ACCEPT,
> connection tracking handles packet as normal packet. But it cannot find invert
> tuple for it and stop processing after all. Then no problem.
> 
> But it may be better to replace NF_ACCEPT with -NF_ACCEPT in this function to
> stop processing early.
> 
> BTW, this is common issue in nf_conntrack and ip_conntrack. Then it is
> necessary to both of them if we want.
> 
> Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai at toshiba.co.jp>
> 
> Netfilter folks, do you have any problem if I change these return value ?

I think its a good idea, there is no point in continuing to process
these packets.



More information about the netfilter-devel mailing list