(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