Re: [RFC][PATCH] kill the fake conntrack

[Pablo Neira <pablo@eurodev.net>]

Patrick McHardy wrote:
> Pablo Neira wrote:
> 
>>Patrick McHardy wrote:
>>
>>
>>>What is the advantage of this patch?
>>
>>Whenever we work with conntracks, we always have to check if it's the
>>fake or not previously. For example, a bad use of NOTRACK together with
>>other targets, say ipt_CONNMARK, that doesn't currently check if it's
>>working with the fake conntrack or not. Same thing for NAT handlings, I
>>see that this can result in weirdness.
>>
>>Setting nfct to NULL will make NAT targets, conntrack helpers and
>>friends just ignore untracked packets, so we could forget about making
>>sure that we aren't messing with the fake conntrack.
> 
> 
> Sounds reasonable - but couldn't we simply change ip_conntrack_get
> to return NULL for untracked connections?

Then I won't be able to differenciate between invalid and untracked 
connections. So I'd need to return some extra info via ctinfo to achieve 
it, something in ip_conntrack_get like:

if (ct == &ip_conntrack_untracked)
	ctinfo = IP_CT_UNTRACKED

Well, but we'll still need the fake conntrack.

>>>Its changing the assumption
>>>that skb->nfctinfo is only valid if skb->nfct is set, so you probably
>>>need to set nfctinfo to 0 in nf_reset as well. This alone is a reason
>>>not to do it IMO.
>>
>>why need to set nfctinfo to 0 in nf_reset? since skb->nfct is NULL
>>nf_reset shouldn't be ever called. With the logic I'm proposing, this
>>packet will be handle just like invalid ones, so it will be just ignored.
> 
> 
> nf_reset is called independant of the contents of skb->nfct. nfctinfo
> needs to be set to 0 so a packet isn't untracked afterwards anymore.
> Think of tunnel devices.

OK. Hm, do you still consider that bad adding a line to nf_reset to 
reset skb->nfctinfo? This is the only drawback I see at the moment.

--
Pablo