Re: [PATCH 08/13] netfilter: ctnetlink: Resolve conntrack L3-protocol flush regression

[Kristian Evensen <kristian.evensen@gmail.com>]

Hi Felix,

On Tue, Jun 25, 2019 at 4:45 PM Felix Kaechele <felix@kaechele.ca> wrote:
> So here's what my understanding is of what is happening:
>
> Let's go back to that line of code:
>
> u_int8_t u3 = nfmsg->version ? nfmsg->nfgen_family : AF_UNSPEC;
>
> Just to make sure I understand this correctly: If the version is set to
> 0 the address family (l3proto) will be set to AF_UNSPEC regardless of
> what the actual l3proto was set to by the user of the API.
> It is only set to the value chosen by the if the version is set to a
> non-null value.
> We assume that all clients that require the old behaviour set their
> version to 0, since that's the only valid value to set it to at this
> point anyway.

Yes, your understanding is correct and I think I now see what has gone
wrong. The change in the patch we are discussing here should only be
applied to the flush-path. What happened was that when fixing up the
support for flushing,  we (well, I) forgot about delete. Until my
original patch got merged, u3 was never used when flushing. However,
the value was used when deleting. By changing the value assigned to
u3, we unfortunately broke delete. By moving the "u3 = nfmsg->version
...." line to the else-clause (like Pablo did in his patch) and
passing nfmsg->nfgen_family (like Nicolas suggests) to the
parse_tuple-calls, the old behavior for delete should be restored and
filter still support flushing by L3-protocol.

BR,
Kristian