All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Philip Craig <philipc@snapgear.com>, Thomas Graf <tgraf@suug.ch>
Cc: Netfilter Development Mailinglist <netfilter-devel@vger.kernel.org>
Subject: libnl netfilter log
Date: Sat, 08 Dec 2007 06:20:07 +0100	[thread overview]
Message-ID: <475A2987.8030505@trash.net> (raw)

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?


             reply	other threads:[~2007-12-08  5:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-08  5:20 Patrick McHardy [this message]
2007-12-08 18:16 ` libnl netfilter log Pablo Neira Ayuso
2007-12-08 18:24   ` Pablo Neira Ayuso
2007-12-09 16:08     ` Patrick McHardy
2007-12-09 16:09   ` Patrick McHardy
2007-12-10  0:53 ` Philip Craig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=475A2987.8030505@trash.net \
    --to=kaber@trash.net \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=philipc@snapgear.com \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.