libnetfilter_queue and libnetfilter_conntrack API questions

libnetfilter_queue and libnetfilter_conntrack API questions

[Thomas Mader]

Hello,

why is it that I cannot get the conntrack ID when I set up a callback 
function for DESTROY events with libnetfilter_conntrack?
When I do

int id = nfct_get_attr_u32(ct, ATTR_ID);
printf("delete ID: %d\n", id);

in my callback function. The id I get is always 0.
It works for conntrack dumps but not for events it seems.

The other question I have is the following.
I need to port a kernelspace netfilter module to userspace. It deals 
with udp and icmp packets, and in kernelspace I have the match function 
as a callback and in that match function I grab the corresponding 
conntrack tuple for the incoming packet to get the conntrack id. With 
this id I can search a list, if this connection is already in that list, 
and can update information in that list or add the connection to the 
list if it is not yet in that list.
I also have a notifier callback function where I get notified when a 
connection was deleted. I need this to get the id of the deleted 
connection and delete it as well in my list with connections.
Now the question is, how I can do this in userspace. I managed to get 
the match function from kernelspace ported to userspace by using 
libnetfilter_queue API. But to implement the delete notifier and to get 
the conntrack id I need to use libnetfilter_conntrack API where the 
problems arise.
I need

while ((rv = recv(fd, buf, sizeof(buf), 0)) && rv >= 0) {
		nfq_handle_packet(h, buf, rv);
}

to handle packets with my libnetfilter_queue callback function. But if I 
want to get notified by conntrack for delete events I need nfct_catch, 
which also blocks my program.
So my question is, if I need to spawn multiple threads to get it done or 
if there is another solution?

thanks in advance,
Thomas Mader

Re: libnetfilter_queue and libnetfilter_conntrack API questions

[Pablo Neira Ayuso]

Thomas Mader wrote:
> Hello,
> 
> why is it that I cannot get the conntrack ID when I set up a callback
> function for DESTROY events with libnetfilter_conntrack?
> When I do
> 
> int id = nfct_get_attr_u32(ct, ATTR_ID);
> printf("delete ID: %d\n", id);
> 
> in my callback function. The id I get is always 0.
> It works for conntrack dumps but not for events it seems.

The events do not include the ID, this is how it goes as for now.
Actually I'm not a big fun of the ID.

@Patrick: I don't remember exactly the reason why we decided to keep the
ID there, and if we have decided to do so, it seems inconsistent to me
not to include it in the events.

> The other question I have is the following.
> I need to port a kernelspace netfilter module to userspace. It deals
> with udp and icmp packets, and in kernelspace I have the match function
> as a callback and in that match function I grab the corresponding
> conntrack tuple for the incoming packet to get the conntrack id. With
> this id I can search a list, if this connection is already in that list,
> and can update information in that list or add the connection to the
> list if it is not yet in that list.
> I also have a notifier callback function where I get notified when a
> connection was deleted. I need this to get the id of the deleted
> connection and delete it as well in my list with connections.
> Now the question is, how I can do this in userspace. I managed to get
> the match function from kernelspace ported to userspace by using
> libnetfilter_queue API. But to implement the delete notifier and to get
> the conntrack id I need to use libnetfilter_conntrack API where the
> problems arise.
> I need
> 
> while ((rv = recv(fd, buf, sizeof(buf), 0)) && rv >= 0) {
>         nfq_handle_packet(h, buf, rv);
> }
> 
> to handle packets with my libnetfilter_queue callback function. But if I
> want to get notified by conntrack for delete events I need nfct_catch,
> which also blocks my program.
> So my question is, if I need to spawn multiple threads to get it done or
> if there is another solution?

I'd prefer polling from both sockets instead of using threads, you can
access the socket descriptors via nfct_fd() and nfq_fd().

Anyway, the main problem that I see is that you'll have to delay the
packet verdict until you receive the conntrack event, otherwise you risk
to have a race condition. However, I think that the solution would not
be that performant.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: libnetfilter_queue and libnetfilter_conntrack API questions

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> The events do not include the ID, this is how it goes as for now.
> Actually I'm not a big fun of the ID.
> 
> @Patrick: I don't remember exactly the reason why we decided to keep the
> ID there, and if we have decided to do so, it seems inconsistent to me
> not to include it in the events.


I agree. I guess the reason why its not sent on events is that it
was originally only introduced (IIRC, I might be confusing it with
the ordered list on second thought) for dumps.

The reason why we kept it at all is that people are already using
it as unique identifier, we only changed the uniqueness to mean
"unique at any given point in time", but not over time. I guess
the logical thing to do would be to also include it in events.
I know some people are using patches to do this already.

Re: libnetfilter_queue and libnetfilter_conntrack API questions

[Pablo Neira Ayuso]

Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> The events do not include the ID, this is how it goes as for now.
>> Actually I'm not a big fun of the ID.
>>
>> @Patrick: I don't remember exactly the reason why we decided to keep the
>> ID there, and if we have decided to do so, it seems inconsistent to me
>> not to include it in the events.
> 
> 
> I agree. I guess the reason why its not sent on events is that it
> was originally only introduced (IIRC, I might be confusing it with
> the ordered list on second thought) for dumps.
> 
> The reason why we kept it at all is that people are already using
> it as unique identifier, we only changed the uniqueness to mean
> "unique at any given point in time", but not over time. I guess
> the logical thing to do would be to also include it in events.
> I know some people are using patches to do this already.

Well, I'm not big fun of reducing the limited bandwidth of netlink but
let's inserted it. I have a couple of patches here for ctnetlink. I can
include one for this.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: libnetfilter_queue and libnetfilter_conntrack API questions

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>> Pablo Neira Ayuso wrote:
>>> The events do not include the ID, this is how it goes as for now.
>>> Actually I'm not a big fun of the ID.
>>>
>>> @Patrick: I don't remember exactly the reason why we decided to keep the
>>> ID there, and if we have decided to do so, it seems inconsistent to me
>>> not to include it in the events.
>>
>> I agree. I guess the reason why its not sent on events is that it
>> was originally only introduced (IIRC, I might be confusing it with
>> the ordered list on second thought) for dumps.
>>
>> The reason why we kept it at all is that people are already using
>> it as unique identifier, we only changed the uniqueness to mean
>> "unique at any given point in time", but not over time. I guess
>> the logical thing to do would be to also include it in events.
>> I know some people are using patches to do this already.
> 
> Well, I'm not big fun  of reducing the limited bandwidth of netlink but
> let's inserted it. I have a couple of patches here for ctnetlink. I can
> include one for this.

Thanks Pablo.

Re: libnetfilter_queue and libnetfilter_conntrack API questions

[Thomas Mader]

Pablo Neira Ayuso wrote:
> I'd prefer polling from both sockets instead of using threads, you can
> access the socket descriptors via nfct_fd() and nfq_fd().
> 
> Anyway, the main problem that I see is that you'll have to delay the
> packet verdict until you receive the conntrack event, otherwise you risk
> to have a race condition. However, I think that the solution would not
> be that performant.

Would it be better if I just spawn another thread with a timer which 
looks at intervals if a connection in my list has to be deleted? This 
way I would not need conntrack at all and it might be the fastest solution.

Btw. I did a throughput test on the kernelspace module and the userspace 
daemon without conntrack (so no deletion of connections in my list). I 
figured out that the kernelspace module had less throughput than my 
daemon and I didn't had a good explanation for this.
Is it possible that my conntrack solution in kernelspace is lowering the 
performance below the performance in userspace without conntrack?