From: Eric Leblond <eric@inl.fr>
To: Harald Welte <laforge@netfilter.org>
Cc: Netfilter Development Mailinglist <netfilter-devel@lists.netfilter.org>
Subject: Re: [ANNOUNCE] netfilter-2.6.14 git tree / TODO
Date: Sun, 31 Jul 2005 20:04:44 +0200 [thread overview]
Message-ID: <1122833084.4159.24.camel@porky> (raw)
In-Reply-To: <20050731103812.GF14874@rama.de.gnumonks.org>
[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]
On Sun, 2005-07-31 at 12:38 +0200, Harald Welte wrote:
> On Sun, Jul 31, 2005 at 11:29:53AM +0200, Eric Leblond wrote:
> > Hi,
> >
> > On Sun, 2005-07-31 at 10:01 +0200, Harald Welte wrote:
> > > Hi!
> > So, we are really interested in userspace counterparts. In particular,
> > our center of interest is libnfnetlink_queue. I will do some test in
> > the coming days to check if NuFW is working with NFQUEUE.
>
> great. Please consider supporting nfnetlink_queue natively, rather than
> using the (still incomplete) compat_libipq interface. The latter has to
> do one additional copy of every packet (to build the fake
> ipq_packet_msg_t), which you definitely want to avoid.
Ok, I will work in that direction.
> The problem are the optional attributes. A packet from the kernel could
> optionally contain
> PAYLOAD
> MARK
> TIMESTAMP
> IFINDEX_IN
> IFINDEX_OUT
> ...
> and this may change from packet to packet. so we cannot just pass a
> fixed structure to the application program like libipq did. OTOTH, I
> don't want the applications have to do their own netlink message parsing
> (with NFA_... macros), since that would violate the layering. Any ideas?
It reminds me the problem we had when we had to define the NuFW
protocols. We take the idea from radius protocol which can contains an
arbitrary number of fields. This works as follow :
start of the message contains the type of the message and its length
(calculate from the content). Then we have fields all optional
containing their type, option and length
Decomposition is the following :
MSG type | option | length
field type | option | length
DATA of field
field type | option | length
DATA of field
...
field type | option | length
DATA of field
It can easily be extended for any new fields as long as there is room in
the field type interval.
Hope this can help.
BR,
--
Eric Leblond <eric@inl.fr>
INL
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-07-31 18:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-31 8:01 [ANNOUNCE] netfilter-2.6.14 git tree / TODO Harald Welte
2005-07-31 9:29 ` Eric Leblond
2005-07-31 10:38 ` Harald Welte
2005-07-31 18:04 ` Eric Leblond [this message]
2005-07-31 19:11 ` Harald Welte
[not found] ` <1122798262.18329.16.camel@www.l-chr.com.ar>
2005-07-31 10:27 ` Harald Welte
2005-08-02 11:14 ` Samir Bellabes
2005-08-02 11:14 ` Samir Bellabes
2005-08-02 14:19 ` Krzysztof Oledzki
2005-08-05 18:27 ` Harald Welte
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=1122833084.4159.24.camel@porky \
--to=eric@inl.fr \
--cc=laforge@netfilter.org \
--cc=netfilter-devel@lists.netfilter.org \
/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.