Using libnetfilter_queue

[Rennie deGraaf <degraaf@cpsc.ucalgary.ca>]

[-- Attachment #1: Type: text/plain, Size: 2507 bytes --]

Hello all,

I am trying to write an application that uses libnetfilter_queue, and
have a few questions about its API.

If I understand correctly from the example program supplied with
libnetfilter_queue, the user is responsible for reading messages from
kernelspace with a recv() call.  At this point, the messages are still
opaque nfnetlink messages, which must be passed to nfq_handle_packet()
for parsing.  This function never returns a parsed message; the caller
only gets access to the message fields inside the callback that was
provided to nfq_create_queue().  The callback is expected to call either
nfq_set_verdict() or nfq_set_verdict_mark() before returning.

My questions follow:
1. How is the caller supposed to correctly read the message from
kernelspace, when the caller doesn't know the message size?  The caller
should know an upper bound on the size of the packet contents being
returned, but doesn't know the size of the metadata fields or the
netlink header.  The only ways that I have found to safely read messages
are to either allocate large buffers that *should* be able to fit
everything (this is the approach taken by the example program -- except
that the buffer that it allocates is too small for large packets) or to
first read a struct nlmsghdr using MSG_PEEK, decode the total message
size, allocate a buffer of appropriate size, and then read the whole
message (this breaks encapulation).  It seems to me that the better way
to do this would be for the libnetfilter_queue API to provide a function
that safely reads packets from kernelspace without exposing
implementation details to the caller.  If the callback architecture is
preserved, this could be done inside nfq_handle_packet().

2. What is the point of the callback?  It seems to me that it would be
much simpler to have nfq_handle_packet() (or better yet, a function that
reads a packet) return a parsed packet to the caller and let it handle
it as it wishes.  The only good reason that I can see for having a
callback is to require that nfq_set_verdict() gets called at some point,
but the callback doesn't actually enforce this.  I don't see what
advantage this architecture has over a simpler socket-like API where
programs can open a connection, read a packet, analyze its contents, set
a verdict, and close the connection all from the same logical block.

If I'm misunderstanding how the libnetfilter_queue API works, please let
me know.

Thanks,
Rennie deGraaf


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]