Re: [PATCH] netfilter: don't track ICMPv6 negotiation message.

[Eric Leblond <eric@inl.fr>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Christoph Paasch a écrit :
> Hi,
> 
> I have two questions regarding this patch.
> 
> On Tue January 27 2009, Eric Leblond wrote:
>> +	type = icmp6h->icmp6_type - 130;
>> +	if (type >= 0 && type < sizeof(noct_valid_new)
>> +	    && noct_valid_new[type]) {
>> +		skb->nfct = &nf_conntrack_untracked.ct_general;
>> +		skb->nfctinfo = IP_CT_NEW;
>> +		nf_conntrack_get(skb->nfct);
>> +		return NF_ACCEPT;
>> +	}
> 
> Why do you set skb->nfctinfo = IP_CT_NEW?
> Because in xt_state.c, at state_mt(...) : 
> 	if it is in front of an untracked packet (using nf_ct_is_untracked(skb)) it
> 	automatically sets the statebit to UNTRACKED and so the IP_CT_NEW isn't used.

Not much to say on that point. I wanted to be homogeneous with what is
done in xt_NOTRACK.c.

> Why do you return NF_ACCEPT and not -NF_ACCEPT?
> By returning a positiv value, the packet will continue it's way through the 
> connection tracker.

If I understand well, icmpv6_error will be called in nf_conntrack_core.c
as l4proto->error :

	if (l4proto->error != NULL) {
		ret = l4proto->error(net, skb, dataoff, &ctinfo, pf, hooknum);
		if (ret <= 0) {
			NF_CT_STAT_INC_ATOMIC(net, error);
			NF_CT_STAT_INC_ATOMIC(net, invalid);
			return -ret;
		}
	}

It will thus increment error counters if return is -NF_ACCEPT. As the
packets we deal with are not error I don't think it is correct to return
- -NF_ACCEPT.

But I agree with the fact, that returning NF_ACCEPT leads to some
useless work inside the kernel.

BR,
- --
Eric Leblond <eric@inl.fr>
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJjxfknxA7CdMWjzIRAn0aAKCQCN4JpW8eae4isbeSA/77Fl0vagCfdfhJ
7n/HGloTFIT9V+mAKnG4oPs=
=65y5
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html