libnl netfilter log

libnl netfilter log

[Patrick McHardy]

I've added support for netfilter queueing to libnl based on the
logging support and would like to suggest a few changes.

One of the problems with the netfilter libraries has been adding
support for new features, since that often required changing
function signatures, for example:

extern int nfq_set_verdict(struct nfq_q_handle *qh,
                              u_int32_t id,
                              u_int32_t verdict,
                              u_int32_t data_len,
                              unsigned char *buf);

extern int nfq_set_verdict_mark(struct nfq_q_handle *qh,
                                   u_int32_t id,
                                   u_int32_t verdict, 

                                   u_int32_t mark,
                                   u_int32_t datalen,
                                   unsigned char *buf);

libnl always took an object-centric approach, so this would
look something like this:

nfnl_queue_msg_set_verdict(pkt, verdict);
nfnl_queue_msg_set_mark(pkt, mark);
nfnl_queue_msg_send_verdict(pkt);

which avoids this problem. The libnl logging support deviates
from this scheme, for example with this function:

int nfnl_log_set_mode(struct nl_handle *nlh, uint16_t queuenum,
                       uint8_t copy_mode, uint32_t copy_range)

What I would like to change is make struct nfnl_log the logging
instance, so you would have:

nfnl_log_set_mode(log, mode);
nfnl_log_set_copy_range(log, range);
nfnl_log_send_config(log);

and add a new struct nfnl_log_message, which represents the
actual messages. Similar for queueing, we would have a
struct nfnl_queue and nfnl_queue_message.

Any objections or suggestions to this API change?

Somewhat related, there currently is a problem with message
reception since libnl uses a page-sized buffer for recvmsg(),
but netfilter can send messages up to 64k. I recall there
was some recvmsg buffer size probing some time ago, but it
seems to be gone. Should I reintroduce it, increase the size
to 64k or make it configurable?

Re: libnl netfilter log

[Pablo Neira Ayuso]

Patrick McHardy wrote:
> I've added support for netfilter queueing to libnl based on the
> logging support and would like to suggest a few changes.
> 
> One of the problems with the netfilter libraries has been adding
> support for new features, since that often required changing
> function signatures, for example:
> 
> extern int nfq_set_verdict(struct nfq_q_handle *qh,
>                              u_int32_t id,
>                              u_int32_t verdict,
>                              u_int32_t data_len,
>                              unsigned char *buf);
> 
> extern int nfq_set_verdict_mark(struct nfq_q_handle *qh,
>                                   u_int32_t id,
>                                   u_int32_t verdict,
>                                   u_int32_t mark,
>                                   u_int32_t datalen,
>                                   unsigned char *buf);
> 
> libnl always took an object-centric approach, so this would
> look something like this:
> 
> nfnl_queue_msg_set_verdict(pkt, verdict);
> nfnl_queue_msg_set_mark(pkt, mark);
> nfnl_queue_msg_send_verdict(pkt);
> 
> which avoids this problem. The libnl logging support deviates
> from this scheme, for example with this function:
> 
> int nfnl_log_set_mode(struct nl_handle *nlh, uint16_t queuenum,
>                       uint8_t copy_mode, uint32_t copy_range)
> 
> What I would like to change is make struct nfnl_log the logging
> instance, so you would have:
> 
> nfnl_log_set_mode(log, mode);
> nfnl_log_set_copy_range(log, range);
> nfnl_log_send_config(log);
> 
> and add a new struct nfnl_log_message, which represents the
> actual messages. Similar for queueing, we would have a
> struct nfnl_queue and nfnl_queue_message.
> 
> Any objections or suggestions to this API change?

Looks fine to me. Actually, much better than the current API :)

> Somewhat related, there currently is a problem with message
> reception since libnl uses a page-sized buffer for recvmsg(),
> but netfilter can send messages up to 64k. I recall there
> was some recvmsg buffer size probing some time ago, but it
> seems to be gone. Should I reintroduce it, increase the size
> to 64k or make it configurable?

If you reintroduce the probing I think that something similar to the
libnfnetlink behaviour would be fine. But, indeed, I prefer to make it
configurable.

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

Re: libnl netfilter log

[Pablo Neira Ayuso]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>> I've added support for netfilter queueing to libnl based on the
>> logging support and would like to suggest a few changes.
>>
>> One of the problems with the netfilter libraries has been adding
>> support for new features, since that often required changing
>> function signatures, for example:
>>
>> extern int nfq_set_verdict(struct nfq_q_handle *qh,
>>                              u_int32_t id,
>>                              u_int32_t verdict,
>>                              u_int32_t data_len,
>>                              unsigned char *buf);
>>
>> extern int nfq_set_verdict_mark(struct nfq_q_handle *qh,
>>                                   u_int32_t id,
>>                                   u_int32_t verdict,
>>                                   u_int32_t mark,
>>                                   u_int32_t datalen,
>>                                   unsigned char *buf);
>>
>> libnl always took an object-centric approach, so this would
>> look something like this:
>>
>> nfnl_queue_msg_set_verdict(pkt, verdict);
>> nfnl_queue_msg_set_mark(pkt, mark);
>> nfnl_queue_msg_send_verdict(pkt);
>>
>> which avoids this problem. The libnl logging support deviates
>> from this scheme, for example with this function:
>>
>> int nfnl_log_set_mode(struct nl_handle *nlh, uint16_t queuenum,
>>                       uint8_t copy_mode, uint32_t copy_range)
>>
>> What I would like to change is make struct nfnl_log the logging
>> instance, so you would have:
>>
>> nfnl_log_set_mode(log, mode);
>> nfnl_log_set_copy_range(log, range);
>> nfnl_log_send_config(log);
>>
>> and add a new struct nfnl_log_message, which represents the
>> actual messages. Similar for queueing, we would have a
>> struct nfnl_queue and nfnl_queue_message.
>>
>> Any objections or suggestions to this API change?
> 
> Looks fine to me. Actually, much better than the current API :)

Hm, wait. Did libnl adopt an API similar to libnetfilter_log? Uh bad :)
Then, instead of changing the API that is something that could break any
existing application, I think that you can introduce the new API that
you propose and put the old one with the __attribute__((deprecated)) thing.

BTW, is libnl website broken? Any CVS or something I can get a working
copy to have a look at current netfilter support?

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

Re: libnl netfilter log

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Hm, wait. Did libnl adopt an API similar to libnetfilter_log? Uh bad :)
> Then, instead of changing the API that is something that could break any
> existing application, I think that you can introduce the new API that
> you propose and put the old one with the __attribute__((deprecated)) thing.

Its quite new, I guess there are no applications yet.

> BTW, is libnl website broken? Any CVS or something I can get a working
> copy to have a look at current netfilter support?

Its hosted on http://git.kernel.org

Re: libnl netfilter log

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:

>> Somewhat related, there currently is a problem with message
>> reception since libnl uses a page-sized buffer for recvmsg(),
>> but netfilter can send messages up to 64k. I recall there
>> was some recvmsg buffer size probing some time ago, but it
>> seems to be gone. Should I reintroduce it, increase the size
>> to 64k or make it configurable?
> 
> If you reintroduce the probing I think that something similar to the
> libnfnetlink behaviour would be fine. But, indeed, I prefer to make it
> configurable.


Me too, and maybe have it switch to 64k automatically once a
nfnetlink queue or log socket is opened.

Re: libnl netfilter log

[Philip Craig]

Patrick McHardy wrote:
> I've added support for netfilter queueing to libnl based on the
> logging support and would like to suggest a few changes.
> 
> One of the problems with the netfilter libraries has been adding
> support for new features, since that often required changing
> function signatures, for example:
> 
> extern int nfq_set_verdict(struct nfq_q_handle *qh,
>                               u_int32_t id,
>                               u_int32_t verdict,
>                               u_int32_t data_len,
>                               unsigned char *buf);
> 
> extern int nfq_set_verdict_mark(struct nfq_q_handle *qh,
>                                    u_int32_t id,
>                                    u_int32_t verdict, 
> 
>                                    u_int32_t mark,
>                                    u_int32_t datalen,
>                                    unsigned char *buf);
> 
> libnl always took an object-centric approach, so this would
> look something like this:
> 
> nfnl_queue_msg_set_verdict(pkt, verdict);
> nfnl_queue_msg_set_mark(pkt, mark);
> nfnl_queue_msg_send_verdict(pkt);
> 
> which avoids this problem. The libnl logging support deviates
> from this scheme, for example with this function:
> 
> int nfnl_log_set_mode(struct nl_handle *nlh, uint16_t queuenum,
>                        uint8_t copy_mode, uint32_t copy_range)
> 
> What I would like to change is make struct nfnl_log the logging
> instance, so you would have:
> 
> nfnl_log_set_mode(log, mode);
> nfnl_log_set_copy_range(log, range);
> nfnl_log_send_config(log);
> 
> and add a new struct nfnl_log_message, which represents the
> actual messages. Similar for queueing, we would have a
> struct nfnl_queue and nfnl_queue_message.
> 
> Any objections or suggestions to this API change?

That makes a lot of sense to me. And don't worry about breaking the
API for this or other netfilter stuff.  I doubt anyone besides me has
used it. There's no publicly available programs besides the test ones
in libnl.