From: Massimiliano Hofer <max@nucleus.it>
To: netfilter@lists.netfilter.org
Subject: Re: Controlling an iptables-match from userspace
Date: Mon, 29 May 2006 01:36:34 +0200 [thread overview]
Message-ID: <200605290136.34804.max@nucleus.it> (raw)
In-Reply-To: <815d745e0605281119g1ab45281h80f080b760399469@mail.gmail.com>
On Sunday 28 May 2006 8:19 pm, Manfred Stock wrote:
> > I'm working on some other changes that should make it more acceptable,
> > althought I've been busy in the last couple of weeks.
>
> Sounds good :) Btw. is there somewhere some more recent
> Netfilter-Hacking-Howto-like documentation besides the kernel sources?
> The Howto was not even for 2.6, and at least 2.6.16 had some larger
> netfilter-related changes...
If there is, I would like it too. Most of the documentation I found dated from
the 2.4.x era and cantained obsolete information. I cross examined other
netfilter code and specific documentation for other parts of the kernel.
:(
> Definitely. Adding a new setsockopt option as mentioned in the Howto
> would be another possibility, but it at least feels a little weird if
> you can create a socket, set a special option on it and as a result
> you have influenced the behaviour of netfilter... Nevertheless it's
> fairly easy to use on the kernel side. Probably netlink/nfnetlink
> would be another (not file based) alternative.
Feasible, but I wouldn't like to implement it this way.
If you find a compelling reason not to go for the current multiple files
approach I can create a single file that receives batches of commands.
The only reason this would be necessary would be in order to have transations
of multiple simultaneous changes, but I think we would be solving the wrong
problem.
> > - a file interface doesn't require a special app.
>
> It also fits nicely into the "everything is a file" paradigm, and it's
> easy to use if you do write a special app to use that functionality.
OK.
> netfilter match. But after a short look at
> Documentation/filesystems/configfs/configfs.txt I would say that
> configfs was intended for this kind of stuff. As for /proc, I don't
> really know what to say, but my feelings are that it should rather not
> be used for new non process related things - they have duplicated some
Many people think that /proc is in a sorry state. The current trend is not to
accept patches that use /proc for anything new that is not process related.
I'm still using /proc in order to maintain backward compatibility, but I was
already considering a transition to /config. Another thing holding me back
was the lack of other modules already using it. There is no accepted naming
convention and I wouldn't like to keep moving my files.
Anyway I'll soon release a new version of condition that uses configfs.
I'll put the directory name to popular vote:
- /config/xt_condition (this seem the preferred one by the configfs
documentation);
- /config/netfilter/xt_condition (this would be more clear if other netfilter
modules ever wanted to use configfs);
- ... (fill in the blanks);
--
Bye,
Massimiliano Hofer
next prev parent reply other threads:[~2006-05-28 23:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-23 11:42 Controlling an iptables-match from userspace Manfred Stock
2006-05-23 12:04 ` Sven-Haegar Koch
2006-05-23 15:00 ` Manfred Stock
2006-05-25 22:00 ` Massimiliano Hofer
2006-05-26 2:17 ` STRING agrument Allan Parreno
2006-05-27 2:49 ` Eric Benton
2006-05-28 18:19 ` Controlling an iptables-match from userspace Manfred Stock
2006-05-28 23:36 ` Massimiliano Hofer [this message]
2006-05-30 7:36 ` Manfred Stock
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=200605290136.34804.max@nucleus.it \
--to=max@nucleus.it \
--cc=netfilter@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox