Hi Felix, On Tue, Jun 25, 2019 at 4:45 PM Felix Kaechele <felix@xxxxxxxxxxx> 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
