From: Patrick McHardy <kaber@trash.net>
To: Balazs Scheidler <bazsi@balabit.hu>
Cc: netdev@vger.kernel.org, netfilter-devel@lists.netfilter.org,
shemminger@osdl.org
Subject: Re: [patch] RFC: matching interface groups
Date: Fri, 04 Aug 2006 12:06:39 +0200 [thread overview]
Message-ID: <44D31C2F.2050702@trash.net> (raw)
In-Reply-To: <1154452209.6395.77.camel@bzorp.balabit>
Balazs Scheidler wrote:
> The use-case is as follows:
>
> * I have two different subsystems creating interfaces dynamically (for
> example pptpd and serial pppd lines, each creating dynamic pppX
> interfaces),
> * I would like to assign a different set of iptables rules for these
> clients,
> * I would like to react to a new interface being added to a specific set
> in a userspace application,
>
> The reasons I see this needs new kernel functionality:
>
> * iptables supports wildcard interface matching (for example "iptables
> -i ppp+"), but as the names of the interfaces used by PPTPD and PPPD
> cannot be distinguished this way, this is not enough,
> * Reloading the iptables ruleset everytime a new interface comes up is
> not really feasible, as it abrupts packet processing, and validating the
> ruleset in the kernel can take significant amount of time,
> * the kernel change is very simple, adapting userspace to this change is
> also very simple, and in userspace various software packages can easily
> interoperate with each-other once this is merged.
>
> The implementation:
>
> Each interface can belong to a single "group" at a time, an interface
> comes up without being a member in any of the groups.
>
> Userspace can assign interfaces to groups after being created, this
> would typically be performed in /etc/ppp/ip-up.d (and similar) scripts.
>
> In spirit "interface group" is somewhat similar to the "routing
> protocol" field for routing entries, which contains information on which
> routing daemon was responsible for adding the given route entry.
>
> Things to be done if you like this approach:
>
> * interface group match in iptables,
> * support for naming interface groups in userspace, a'la routing
> protocols,
> * emitting a netlink notification when the group of an interface
> changes,
> * possibly converting the "ip link" command to use NETLINK messages,
> instead of using ioctl()
>
> What do you think?
I like it .. kind of like routing realms. For your specific case there
is a possible solution already supported by the kernel, you can
pre-allocate ppp devices using PPPIOCNEWUNIT, rename them and later
attach to individual units in the ppp daemon using PPPIOCATTACH
(I have a patch for this somewhere if you're interested). But that
only works for PPP devices and the group idea looks more flexible.
next prev parent reply other threads:[~2006-08-04 10:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-01 17:10 [patch] RFC: matching interface groups Balazs Scheidler
2006-08-01 18:29 ` Stephen Hemminger
2006-08-02 7:18 ` Balazs Scheidler
2006-08-01 18:46 ` Phil Oester
2006-08-01 19:18 ` Sven Schuster
2006-08-02 7:04 ` Balazs Scheidler
2006-08-02 9:01 ` Amin Azez
2006-08-03 12:57 ` Gerd v. Egidy
2006-08-03 4:08 ` Stephen J. Bevan
2006-08-03 19:08 ` Balazs Scheidler
2006-08-04 10:06 ` Patrick McHardy [this message]
2006-08-07 11:44 ` Balazs Scheidler
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=44D31C2F.2050702@trash.net \
--to=kaber@trash.net \
--cc=bazsi@balabit.hu \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=shemminger@osdl.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.