expectation mask handling in nfctnetlink (Was Re: [PATCH] fix
nf_conntrack_netlink expectation dumping/event notification)
Pablo Neira Ayuso
pablo at netfilter.org
Wed Feb 1 03:09:21 CET 2006
I'd like to recover this thread.
Yasuyuki KOZAKAI wrote:
>>I feel strange to find l3proto with 0xffff as address family or to find proto
>>with 0xff as protocol number.
>>After all, ctnetlink_dump_tuples() gets nf_conntrack_l3proto_generic /
>>nf_conntrack_proto_generic and they doesn't fill any contents, right ?
>>If so, I think that it's better to make ctnetlink_exp_dump_expect() use
>>l3proto/proto for &exp->tuple to dump &exp->mask, and then
>>we would not need to remove above unlikely().
> I've re-visited this. For now, I'm not sure this is the best solution
> because I don't see how format and contents of expectation mask
> is required by libnetfilter_conntrack. It doesn't use dumped expectation
> mask at all.
Maybe userspace helpers could need that information some day. I don't
want to add limitations to libnetfilter_conntrack just because we have
> Then the other idea can be considerd, too. For example, dumping union of
> l3part(mask->u3.all) and union of proto part(mask->u.all) without assumption
> of specific address family/protocol. Do you have any idea on this ?
We shouldn't send the whole union via netlink. If the union is modified
further, it will break backward compatibility for userspace applications
since the size could change.
So, the possibilities I see up to now are:
a) just remove the unlikely() statement.
Drawback: Not so efficient, since that checking isn't always required.
b) back to my idea: set l3num to the maximum known value (0x1F), and add
a bug trap in nf_ct_expect_related to check that nobody uses a value >=
Drawback: People surely will hit bug while writing their own helpers.
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris
More information about the netfilter-devel