Include the id in conntrack netlink events.
Subsystems (2)
PATCH 1/1 Include the id in conntrack netlink events.
I need the id in ctnetlink events for my application, so here's a patch to add it in case this wasn't left out intentionally.
Include the id in conntrack netlink events.
net/netfilter/nf_conntrack_netlink.c +3 -0
@@ -362,6 +362,9 @@ static int ctnetlink_conntrack_event(str nfmsg->version =NFNETLINK_V0 ; nfmsg->res_id =0 ; +if (ctnetlink_dump_id (skb, ct) <0 ) + goto nfattr_failure; + nest_parms =NFA_NEST (skb,CTA_TUPLE_ORIG );if (ctnetlink_dump_tuples (skb,tuple (ct,IP_CT_DIR_ORIGINAL )) <0 ) goto nfattr_failure;
Quoted 3 lines · Philip Craig
I need the id in ctnetlink events for my application, so here's a patch to add it in case this wasn't left out intentionally.
It was, we have plans to remove it. What for do you need it exactly?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 11 lines · Philip Craig
Quoted 7 lines · Patrick McHardy
Quoted 3 lines · Philip Craig
I need the id in ctnetlink events for my application, so here's a patch to add it in case this wasn't left out intentionally.
It was, we have plans to remove it. What for do you need it exactly?
So it won't be needed for dumping either?
No, I removed that in 2.6.23-rc.
Quoted 8 lines
It's just a simple way of matching up events, so that I can log both start and finish time, as well as the other details.
The alternative is to cache the tuples in userspace and match on them, but that is significantly more complicated. And caching requires more memory usage than having an id in the kernel.
True, but its quite a waste in the kernel as well when considering that almost nobody needs this. I was thinking about derriving a unique ID just for userspace from the conntrack address (in memory). Its not unique over time, just as tuples aren't, but when combined with the tuples it should only clash very rarely, and you'll always get a DESTROY + NEW event before a clash. Would that work for you?
Quoted 6 lines · Patrick McHardy
True, but its quite a waste in the kernel as well when considering that almost nobody needs this. I was thinking about derriving a unique ID just for userspace from the conntrack address (in memory). Its not unique over time, just as tuples aren't, but when combined with the tuples it should only clash very rarely, and you'll always get a DESTROY + NEW event before a clash. Would that work for you?
Yes, that should be fine. I've used that previously with an old linux 2.4 conntrack events patch.