Hi,
From: Eric Leblond <eric@xxxxxx>
Date: Fri, 23 Jan 2009 11:51:30 +0100
> > > static bool icmpv6_invert_tuple(struct nf_conntrack_tuple *tuple,
> > > const struct nf_conntrack_tuple *orig)
> > > {
> > > int type = orig->dst.u.icmp.type - 128;
> > > - if (type < 0 || type >= sizeof(invmap) || !invmap[type])
> > > +
> > > + if (type < 0 || type >= sizeof(invmap) || !invmap[type]) {
> > > return false;
> > > + }
> >
> > Really is this change necessary ?
>
> I've resend the patch without this change. It was forgotten during a
> merge of previous work. Sorry for that.
Ah, sorry & thank you for noticing.
> > > @@ -198,6 +212,17 @@ icmpv6_error(struct net *net, struct sk_buff *skb, unsigned int dataoff,
> > > return -NF_ACCEPT;
> > > }
> > >
> > > + /* autoconf message handling */
> > > + if (nf_ct_icmpv6_autoconf) {
> > > + int 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;
> > > + }
> > > + }
> >
> > I prefer 'NEW' rather than 'UNTRACKED' as other protocols which
> > validation is unclear. So another solution is to let the connection
> > tracking subsystem to create a new conntrack and to make
> > nf_contrack_proto_icmpv6 assign 0 as timeout. How do you think ?
>
> If we do that, we can have nfnetlink messages (NEW, DESTROY) send to
> userspace. Personnaly, I don't think they are necessary. But there is an
> other issue: as we can't invert the tuple, the information provided to
> userspace will be false.
>
> Once we agree on this last point, I will send a reworked patchset (with
> at least the removal of sysctl stuff).
Thank you. I understand why ICMPv6 packets are special here and
I agree to assign UNTRACKED to them. Indeed non-invertible tuple might
bring issues.
-- Yasuyuki Kozakai
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
