* Formal submission of Xtables2
@ 2012-12-13 6:00 Jan Engelhardt
2012-12-13 11:00 ` Pablo Neira Ayuso
0 siblings, 1 reply; 26+ messages in thread
From: Jan Engelhardt @ 2012-12-13 6:00 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
Greetings.
This is Xtables2, a collective term used for much-sought enhancements
to the already-existing xtables infrastructure
(net/netfilter/x_tables.c and so on).
In this patch series of size 33, a new Netlink interface that gives
more flexibility for future extending is introduced, as well as a new
family-independent table space that removes the need to have the many
tables that classic {ip,ip6,eb,arp}tables does.
Network namespaces, arbitrary chain nesting and atomic rule
replacement as you know it is also retained/available again. Matches,
targets, verdicts (collectively known as actions) can appear in
arbitrary order. Existing xt_*.ko extensions continue to be usable,
provided they are coded for NFPROTO_UNSPEC operation. Of course,
there are more improvements planned.
Please consider for merging.
The set consists of some 33 patches. Do you want me to post them in
chunks of ~11-13, or all at once, (or any other arrangement)?
Thanks everybody.
== git toolchain form output ==
The following changes since commit e4e541a84863b6a41f2427f59cc9156c644491a8:
sock-diag: Report shutdown for inet and unix sockets (v2) (2012-10-23 14:57:52 -0400)
are available in the git repository at:
git://git.inai.de/linux xtables2_a9
for you to fetch changes up to 1cf0d7b3398109bddf4e8bfb740fcc36a9ed72ed:
netfilter: xtables2: support for goto action type (2012-12-13 06:30:38 +0100)
----------------------------------------------------------------
[The first two patches are needed for "base chain functionality",
but they live at the front so that I do not (did not)
get whole-kernel recompiles when amending any of the xtables2
commits, which is a relief.]
Jan Engelhardt (33):
netfilter: add a private member to nf_hook_ops
netfilter: make nf_hook_ops.priv available to hooks
netfilter: xtables2: initial table skeletal functions
netfilter: xtables2: initial Netlink interface
netfilter: xtables2: chain creation and deletion
netfilter: xtables2: transaction commit operation
netfilter: xtables2: (atomic) table replace support
netfilter: xtables2: transaction abort support
netfilter: xtables2: redirect writes into transaction buffer
netfilter: xtables2: supply a revision number
netfilter: xtables2: chain dump support
netfilter: xtables2: table dump support
netfilter: xtables2: prepare for addition of more transaction buffer types
netfilter: xtables2: implement the splice buffer
netfilter: xtables2: skeleton for single rules and rule buffer
netfilter: xtables2: core part for splice operation
netfilter: xtables2: netlink part for splice operation
netfilter: xtables2: rule entry handler
netfilter: xtables2: rule dumping
netfilter: xtables2: base chain functionality
netfilter: xtables2: support nomination for chains
netfilter: xtables2: support for entering/dumping rule verdicts
netfilter: xtables2: execute verdicts in live rule traversal
netfilter: xtables2: store netns in table and rule blob
netfilter: xtables2: iterator for obtain/drop references to actions
netfilter: xtables2: support for entering/dumping match actions
netfilter: xtables2: execute matches in live rule traversal
netfilter: xtables2: support for entering/dumping target actions
netfilter: xtables2: execute targets in live rule traversal
netfilter: xtables2: support for entering/dumping jumps
netfilter: xtables2: provide a jump stack
netfilter: xtables2: execute jump actions in live rule traversal
netfilter: xtables2: support for goto action type
include/linux/netfilter.h | 20 +-
include/net/netfilter/xt_core.h | 275 ++++
include/uapi/linux/netfilter/Kbuild | 1 +
include/uapi/linux/netfilter/nfnetlink.h | 3 +-
include/uapi/linux/netfilter/nfnetlink_xtables.h | 124 ++
net/bridge/br_netfilter.c | 60 +-
net/bridge/netfilter/ebtable_filter.c | 16 +-
net/bridge/netfilter/ebtable_nat.c | 16 +-
net/decnet/netfilter/dn_rtmsg.c | 9 +-
net/ipv4/netfilter/arptable_filter.c | 5 +-
net/ipv4/netfilter/ipt_CLUSTERIP.c | 6 +-
net/ipv4/netfilter/iptable_filter.c | 7 +-
net/ipv4/netfilter/iptable_mangle.c | 16 +-
net/ipv4/netfilter/iptable_nat.c | 38 +-
net/ipv4/netfilter/iptable_raw.c | 6 +-
net/ipv4/netfilter/iptable_security.c | 7 +-
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 42 +-
net/ipv4/netfilter/nf_defrag_ipv4.c | 14 +-
net/ipv6/netfilter/ip6table_filter.c | 5 +-
net/ipv6/netfilter/ip6table_mangle.c | 10 +-
net/ipv6/netfilter/ip6table_nat.c | 39 +-
net/ipv6/netfilter/ip6table_raw.c | 5 +-
net/ipv6/netfilter/ip6table_security.c | 5 +-
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 44 +-
net/ipv6/netfilter/nf_defrag_ipv6_hooks.c | 13 +-
net/netfilter/Kconfig | 8 +-
net/netfilter/Makefile | 2 +
net/netfilter/core.c | 2 +-
net/netfilter/ipvs/ip_vs_core.c | 40 +-
net/netfilter/xt_core.c | 1473 +++++++++++++++++++++
net/netfilter/xt_nfnetlink.c | 1520 ++++++++++++++++++++++
net/netfilter/xt_nfnetlink.h | 7 +
security/selinux/hooks.c | 47 +-
33 files changed, 3646 insertions(+), 239 deletions(-)
create mode 100644 include/net/netfilter/xt_core.h
create mode 100644 include/uapi/linux/netfilter/nfnetlink_xtables.h
create mode 100644 net/netfilter/xt_core.c
create mode 100644 net/netfilter/xt_nfnetlink.c
create mode 100644 net/netfilter/xt_nfnetlink.h
== Ohloh Line Count Summary ==
Language Files Code Comment Comment % Blank Total
-------- ----- --------- --------- --------- --------- ---------
c 4 2097 744 26.2% 283 3124
cpp 1 166 86 34.1% 23 275
-------- ----- --------- --------- --------- --------- ---------
Total 5 2263 830 26.8% 306 3399
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-13 6:00 Formal submission of Xtables2 Jan Engelhardt
@ 2012-12-13 11:00 ` Pablo Neira Ayuso
2012-12-13 11:36 ` Jan Engelhardt
2012-12-14 9:41 ` Andreas Herz
0 siblings, 2 replies; 26+ messages in thread
From: Pablo Neira Ayuso @ 2012-12-13 11:00 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Thu, Dec 13, 2012 at 07:00:07AM +0100, Jan Engelhardt wrote:
[...]
> Please consider for merging.
nftables and its compatibility layer already provide this and we will
not have to maintain two different netlink interfaces, which is too
much overhead.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-13 11:00 ` Pablo Neira Ayuso
@ 2012-12-13 11:36 ` Jan Engelhardt
2012-12-13 12:05 ` Pablo Neira Ayuso
2012-12-14 9:41 ` Andreas Herz
1 sibling, 1 reply; 26+ messages in thread
From: Jan Engelhardt @ 2012-12-13 11:36 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Thursday 2012-12-13 12:00, Pablo Neira Ayuso wrote:
>On Thu, Dec 13, 2012 at 07:00:07AM +0100, Jan Engelhardt wrote:
>[...]
>> Please consider for merging.
>
>nftables and its compatibility layer already provide this and we will
>not have to maintain two different netlink interfaces, which is too
>much overhead.
I refer you to our previous discussion on the topic
for the justifications:
http://www.spinics.net/lists/netfilter-devel/msg23919.html
Netlink is not the main selling point.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-13 11:36 ` Jan Engelhardt
@ 2012-12-13 12:05 ` Pablo Neira Ayuso
2012-12-13 13:08 ` Jan Engelhardt
0 siblings, 1 reply; 26+ messages in thread
From: Pablo Neira Ayuso @ 2012-12-13 12:05 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Thu, Dec 13, 2012 at 12:36:21PM +0100, Jan Engelhardt wrote:
> On Thursday 2012-12-13 12:00, Pablo Neira Ayuso wrote:
>
> >On Thu, Dec 13, 2012 at 07:00:07AM +0100, Jan Engelhardt wrote:
> >[...]
> >> Please consider for merging.
> >
> >nftables and its compatibility layer already provide this and we will
> >not have to maintain two different netlink interfaces, which is too
> >much overhead.
>
> I refer you to our previous discussion on the topic
> for the justifications:
>
> http://www.spinics.net/lists/netfilter-devel/msg23919.html
I don't think that feature-set provides compelling reasons to push
this mainstream.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-13 12:05 ` Pablo Neira Ayuso
@ 2012-12-13 13:08 ` Jan Engelhardt
2012-12-13 14:28 ` Pablo Neira Ayuso
0 siblings, 1 reply; 26+ messages in thread
From: Jan Engelhardt @ 2012-12-13 13:08 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Thursday 2012-12-13 13:05, Pablo Neira Ayuso wrote:
>> >[...]
>> >> Please consider for merging.
>> >
>> >nftables and its compatibility layer already provide this and we will
>> >not have to maintain two different netlink interfaces, which is too
>> >much overhead.
>>
>> I refer you to our previous discussion on the topic
>> for the justifications:
>>
>> http://www.spinics.net/lists/netfilter-devel/msg23919.html
>
>I don't think that feature-set provides compelling reasons to push
>this mainstream.
Well, if not that, then what - documentation, code size?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-13 13:08 ` Jan Engelhardt
@ 2012-12-13 14:28 ` Pablo Neira Ayuso
2012-12-13 14:53 ` Jan Engelhardt
0 siblings, 1 reply; 26+ messages in thread
From: Pablo Neira Ayuso @ 2012-12-13 14:28 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Thu, Dec 13, 2012 at 02:08:03PM +0100, Jan Engelhardt wrote:
> On Thursday 2012-12-13 13:05, Pablo Neira Ayuso wrote:
> >> >[...]
> >> >> Please consider for merging.
> >> >
> >> >nftables and its compatibility layer already provide this and we will
> >> >not have to maintain two different netlink interfaces, which is too
> >> >much overhead.
> >>
> >> I refer you to our previous discussion on the topic
> >> for the justifications:
> >>
> >> http://www.spinics.net/lists/netfilter-devel/msg23919.html
> >
> >I don't think that feature-set provides compelling reasons to push
> >this mainstream.
>
> Well, if not that, then what - documentation, code size?
Not only that. Xtables2 (in its feature-set) inherits many of the
design decisions that were taken while designing iptables back in the
late nineties.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-13 14:28 ` Pablo Neira Ayuso
@ 2012-12-13 14:53 ` Jan Engelhardt
2012-12-13 15:16 ` Pablo Neira Ayuso
0 siblings, 1 reply; 26+ messages in thread
From: Jan Engelhardt @ 2012-12-13 14:53 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Thursday 2012-12-13 15:28, Pablo Neira Ayuso wrote:
>> >>
>> >> http://www.spinics.net/lists/netfilter-devel/msg23919.html
>> >
>> >I don't think that feature-set provides compelling reasons to push
>> >this mainstream.
>>
>> Well, if not that, then what - documentation, code size?
>
>Not only that. Xtables2 (in its feature-set) inherits many of the
>design decisions that were taken while designing iptables back in the
>late nineties.
nf_tables itself retains some "late nineties" design decisions as
well.
In my opinion, there is nothing wrong with keeping some concepts. A
developer is not required to reevaluate and reinnovate every concept
there has been just for the heck of it. (The old "evolution, not
revolution" credo.) Throwing everything overboard generally does not
turn out to work these days.
That reminds me of Linus's statement from this year's LinuxCon:
'''there were all these crazy people doing “innovative” operating
systems, and they were all horrible. And they were trying to
do things in new ways, and it turns out, sometimes, the old
ways are the correct ways, and, you have done something for
30 years one way, because that works.'''
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-13 14:53 ` Jan Engelhardt
@ 2012-12-13 15:16 ` Pablo Neira Ayuso
2012-12-13 16:41 ` Jan Engelhardt
0 siblings, 1 reply; 26+ messages in thread
From: Pablo Neira Ayuso @ 2012-12-13 15:16 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Thu, Dec 13, 2012 at 03:53:45PM +0100, Jan Engelhardt wrote:
[...]
> In my opinion, there is nothing wrong with keeping some concepts. A
> developer is not required to reevaluate and reinnovate every concept
> there has been just for the heck of it. (The old "evolution, not
> revolution" credo.) Throwing everything overboard generally does not
> turn out to work these days.
Nobody is going to throw everything overboard. Nftables is backward
compatible while providing a new framework, revolutions are never
backward compatible.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-13 15:16 ` Pablo Neira Ayuso
@ 2012-12-13 16:41 ` Jan Engelhardt
2012-12-13 17:25 ` Pablo Neira Ayuso
0 siblings, 1 reply; 26+ messages in thread
From: Jan Engelhardt @ 2012-12-13 16:41 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Thursday 2012-12-13 16:16, Pablo Neira Ayuso wrote:
>On Thu, Dec 13, 2012 at 03:53:45PM +0100, Jan Engelhardt wrote:
>[...]
>> In my opinion, there is nothing wrong with keeping some concepts. A
>> developer is not required to reevaluate and reinnovate every concept
>> there has been just for the heck of it. (The old "evolution, not
>> revolution" credo.) Throwing everything overboard generally does not
>> turn out to work these days.
>
>Nobody is going to throw everything overboard. Nftables is backward
>compatible while providing a new framework[,]
That sounds just like xt2. Compatibility exists such that there is a
defined mapping from xt1->xt2 rules (at one point I did write a
setsockopt translator in the past...); the userspace tool mimics
iptables in syntax, though I have allowed myself to not have certain
options in the CLI tool. New framework, same thing, I guess. xt_core is
independent of xt_nfnetlink and I do not see any hurdle in introducing
new concepts if so desired.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-13 16:41 ` Jan Engelhardt
@ 2012-12-13 17:25 ` Pablo Neira Ayuso
2012-12-13 18:19 ` Jan Engelhardt
0 siblings, 1 reply; 26+ messages in thread
From: Pablo Neira Ayuso @ 2012-12-13 17:25 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Thu, Dec 13, 2012 at 05:41:28PM +0100, Jan Engelhardt wrote:
> On Thursday 2012-12-13 16:16, Pablo Neira Ayuso wrote:
>
> >On Thu, Dec 13, 2012 at 03:53:45PM +0100, Jan Engelhardt wrote:
> >[...]
> >> In my opinion, there is nothing wrong with keeping some concepts. A
> >> developer is not required to reevaluate and reinnovate every concept
> >> there has been just for the heck of it. (The old "evolution, not
> >> revolution" credo.) Throwing everything overboard generally does not
> >> turn out to work these days.
> >
> >Nobody is going to throw everything overboard. Nftables is backward
> >compatible while providing a new framework[,]
>
> That sounds just like xt2. Compatibility exists such that there is a
> defined mapping from xt1->xt2 rules (at one point I did write a
> setsockopt translator in the past...); the userspace tool mimics
> iptables in syntax, though I have allowed myself to not have certain
> options in the CLI tool.
We provided that compatibility layer that mimics iptables in Oct 2012
[1]. However, it seems you prefered to code it your way from almost
scratch, that's confusing.
> New framework, same thing, I guess. xt_core is independent of
> xt_nfnetlink and I do not see any hurdle in introducing new concepts
> if so desired.
We have already new concepts in nftables, have a look at it.
Please, I think this conversation just started spinning and the same
arguments are showing up over and over again, it's time to stop this.
[1] http://www.spinics.net/lists/netfilter-devel/msg23831.html
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-13 17:25 ` Pablo Neira Ayuso
@ 2012-12-13 18:19 ` Jan Engelhardt
2012-12-17 0:08 ` Pablo Neira Ayuso
0 siblings, 1 reply; 26+ messages in thread
From: Jan Engelhardt @ 2012-12-13 18:19 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Thursday 2012-12-13 18:25, Pablo Neira Ayuso wrote:
>> >> turn out to work these days.
>> >
>> >Nobody is going to throw everything overboard. Nftables is backward
>> >compatible while providing a new framework[,]
>>
>> That sounds just like xt2. Compatibility exists such that there is a
>> defined mapping from xt1->xt2 rules (at one point I did write a
>> setsockopt translator in the past...); the userspace tool mimics
>> iptables in syntax, though I have allowed myself to not have certain
>> options in the CLI tool.
>
>We provided that compatibility layer that mimics iptables in Oct 2012
>[1]. However, it seems you prefered to code it your way from almost
>scratch, that's confusing.
That's just not true; I did post before on the xt2 matter as well,
in its various stages.
xtables2_a8: http://marc.info/?l=netfilter-devel&m=132699055220975&w=2
xtables2_a7: https://lwn.net/Articles/426896/
https://lwn.net/Articles/417619/
There is even older experimenting stuff in my git repo, which you
can look at. (The dates are not forged - you will have to trust me
on that.)
Each of us are (understandably) biased, as each has contributed
to "their" implementation. But, you also have the decisive power
as the Linux kernel Netfilter subsystem maintainer, and I fear
that you might use this to reject xt2 to force nft.
That thought _terrifies_ me, and were it so, it would not be an
environment I want to work in.
Just say so if I am to GTFO.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-13 11:00 ` Pablo Neira Ayuso
2012-12-13 11:36 ` Jan Engelhardt
@ 2012-12-14 9:41 ` Andreas Herz
2012-12-14 18:49 ` Jan Engelhardt
2012-12-16 23:57 ` Pablo Neira Ayuso
1 sibling, 2 replies; 26+ messages in thread
From: Andreas Herz @ 2012-12-14 9:41 UTC (permalink / raw)
To: Netfilter user mailing list
On 13/12/12 at 12:00, Pablo Neira Ayuso wrote:
> On Thu, Dec 13, 2012 at 07:00:07AM +0100, Jan Engelhardt wrote:
> [...]
> > Please consider for merging.
>
> nftables and its compatibility layer already provide this and we will
> not have to maintain two different netlink interfaces, which is too
> much overhead.
Apart of your discussion (i think it's quite interesting although you
might not agree), is there a summary of the status of nftables?
The last time i read about it, while i was at the university, i thought
it was dead.
I read that Patrick McHardy was the one pushing the project but never
heard any news after 2010. Now i read that Pablo is taking care of it.
So i would love to hear more details on the roadmap for nftables, might
be interesting for me and my work here.
thanks
--
Andreas Herz
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-14 9:41 ` Andreas Herz
@ 2012-12-14 18:49 ` Jan Engelhardt
2012-12-18 14:09 ` Andreas Herz
2012-12-16 23:57 ` Pablo Neira Ayuso
1 sibling, 1 reply; 26+ messages in thread
From: Jan Engelhardt @ 2012-12-14 18:49 UTC (permalink / raw)
To: Andreas Herz; +Cc: Netfilter user mailing list
On Friday 2012-12-14 10:41, Andreas Herz wrote:
>On 13/12/12 at 12:00, Pablo Neira Ayuso wrote:
>> On Thu, Dec 13, 2012 at 07:00:07AM +0100, Jan Engelhardt wrote:
>> [...]
>> > Please consider for merging.
>>
>> nftables and its compatibility layer already provide this and we will
>> not have to maintain two different netlink interfaces, which is too
>> much overhead.
>
>Apart of your discussion (i think it's quite interesting although you
>might not agree), is there a summary of the status of nftables?
>The last time i read about it, while i was at the university, i thought
>it was dead.
>I read that Patrick McHardy was the one pushing the project but never
>heard any news after 2010. Now i read that Pablo is taking care of it.
>
>So i would love to hear more details on the roadmap for nftables, might
>be interesting for me and my work here.
For parity, I am posting my roadmap document as it exists so far
as well. Please see http://inai.de/nfxt/ .
And before the question of "who's maintaining?" coming up again -
I'd be glad to maintain if only I was given the chance to.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-14 9:41 ` Andreas Herz
2012-12-14 18:49 ` Jan Engelhardt
@ 2012-12-16 23:57 ` Pablo Neira Ayuso
1 sibling, 0 replies; 26+ messages in thread
From: Pablo Neira Ayuso @ 2012-12-16 23:57 UTC (permalink / raw)
To: Andreas Herz; +Cc: Netfilter user mailing list, netfilter-devel
Hi Andreas,
On Fri, Dec 14, 2012 at 10:41:41AM +0100, Andreas Herz wrote:
> On 13/12/12 at 12:00, Pablo Neira Ayuso wrote:
> > On Thu, Dec 13, 2012 at 07:00:07AM +0100, Jan Engelhardt wrote:
> > [...]
> > > Please consider for merging.
> >
> > nftables and its compatibility layer already provide this and we will
> > not have to maintain two different netlink interfaces, which is too
> > much overhead.
>
> Apart of your discussion (i think it's quite interesting although
> you might not agree), is there a summary of the status of nftables?
> The last time i read about it, while i was at the university, i
> thought it was dead. I read that Patrick McHardy was the one
> pushing the project but never heard any news after 2010. Now i read
> that Pablo is taking care of it.
It's true that nftables suffered an hiatus in its development, but
we're back on it and there has been quite a lot of activity on it
recently. This is the kernel branch, you can check the changelog here:
http://1984.lsi.us.es/git/nf-next/log/?h=nf_tables8
And there's an iptables compatibility layer that is ready for IPv4,
you can find details here:
http://www.spinics.net/lists/netfilter-devel/msg23831.html
> So i would love to hear more details on the roadmap for nftables, might
> be interesting for me and my work here.
I understand you want to know more on the future of nftables, but
because the way I am, I prefer to skip "hot air" wording by now and
talk on code done anytime soon.
So I have to request some patience from you. We promise to deliver as
much information as possible once we are done with the core features.
Thanks.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-13 18:19 ` Jan Engelhardt
@ 2012-12-17 0:08 ` Pablo Neira Ayuso
2012-12-17 1:39 ` Jan Engelhardt
0 siblings, 1 reply; 26+ messages in thread
From: Pablo Neira Ayuso @ 2012-12-17 0:08 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Thu, Dec 13, 2012 at 07:19:28PM +0100, Jan Engelhardt wrote:
[...]
> Each of us are (understandably) biased, as each has contributed
> to "their" implementation. But, you also have the decisive power as
> the Linux kernel Netfilter subsystem maintainer, and I fear that you
> might use this to reject xt2 to force nft.
I have to ask you to stick to technical arguments. Discrediting me
here in the mailing list and everywhere and using irritating wording
will not help to get this mainstream. Stop this.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-17 0:08 ` Pablo Neira Ayuso
@ 2012-12-17 1:39 ` Jan Engelhardt
2012-12-17 9:53 ` Pablo Neira Ayuso
0 siblings, 1 reply; 26+ messages in thread
From: Jan Engelhardt @ 2012-12-17 1:39 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Monday 2012-12-17 01:08, Pablo Neira Ayuso wrote:
>On Thu, Dec 13, 2012 at 07:19:28PM +0100, Jan Engelhardt wrote:
>[...]
>> Each of us are (understandably) biased, as each has contributed
>> to "their" implementation. But, you also have the decisive power as
>> the Linux kernel Netfilter subsystem maintainer, and I fear that you
>> might use this to reject xt2 to force nft.
>
>I have to ask you to stick to technical arguments.
Ok, let me try again then. We should merge xtables2, because
(some selected arguments follow):
- It brings a NL-type (<- long-sought) interface
- It uses a single table because there simply is no need
to have multiple ones. This has benefits for replacement atomicity
guarantees, and gives some memory previously spent for modules
back to the user, for example.
- This table is NFPROTO_UNSPEC which means that the duplication of
rules between ip(4)tables and ip6tables users had to make is
gone, meaning less maintenance/complexity/etc. for the administrator,
and of course, less rules lead to less memory usage.
- and because it retains some characteristics, for example
atomic replaces and netns.
>You wrote on Thu, 13 Dec 2012 13:05:09 +0100:
>>I don't think that feature-set provides compelling reasons to push [xt2]
Not everybody cares about these things, that would be unrealistic.
However, some users, and me included, _do have_ an interest in having
what is presented, because they do e.g. run containers. Otherwise,
we would not be having netns in iptables today, right?
Now, don't dismiss these arguments.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-17 1:39 ` Jan Engelhardt
@ 2012-12-17 9:53 ` Pablo Neira Ayuso
2012-12-17 10:12 ` Maciej Żenczykowski
2012-12-17 13:01 ` Jan Engelhardt
0 siblings, 2 replies; 26+ messages in thread
From: Pablo Neira Ayuso @ 2012-12-17 9:53 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Mon, Dec 17, 2012 at 02:39:07AM +0100, Jan Engelhardt wrote:
> On Monday 2012-12-17 01:08, Pablo Neira Ayuso wrote:
>
> >On Thu, Dec 13, 2012 at 07:19:28PM +0100, Jan Engelhardt wrote:
> >[...]
> >> Each of us are (understandably) biased, as each has contributed
> >> to "their" implementation. But, you also have the decisive power as
> >> the Linux kernel Netfilter subsystem maintainer, and I fear that you
> >> might use this to reject xt2 to force nft.
> >
> >I have to ask you to stick to technical arguments.
>
> Ok, let me try again then. We should merge xtables2, because
> (some selected arguments follow):
>
> - It brings a NL-type (<- long-sought) interface
>
> - It uses a single table because there simply is no need
> to have multiple ones. This has benefits for replacement atomicity
> guarantees, and gives some memory previously spent for modules
> back to the user, for example.
You can implement this with nftables. Actually, nftables allows you to
have as many tables as you want. No matter what configuration you
select, it's extremely flexible.
> - This table is NFPROTO_UNSPEC which means that the duplication of
> rules between ip(4)tables and ip6tables users had to make is
> gone, meaning less maintenance/complexity/etc. for the administrator,
> and of course, less rules lead to less memory usage.
Once single table means no table at all to me. We have also planned
adding agnostic tables to avoid the IPv4/IPv6 cases.
> - and because it retains some characteristics, for example
> atomic replaces and netns.
>
> >You wrote on Thu, 13 Dec 2012 13:05:09 +0100:
> >>I don't think that feature-set provides compelling reasons to push [xt2]
>
> Not everybody cares about these things, that would be unrealistic.
> However, some users, and me included, _do have_ an interest in having
> what is presented, because they do e.g. run containers. Otherwise,
> we would not be having netns in iptables today, right?
Again, those are completely possible with nftables.
> Now, don't dismiss these arguments.
So far, I haven't see any *strong reason* to drop nftables code and
write something from scratch as flexible as it is, my impression is
that you don't know how nftables is designed and it works, so you'll
have to tell me why I'm wrong.
As said, please provide convincing arguments, no more rants.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-17 9:53 ` Pablo Neira Ayuso
@ 2012-12-17 10:12 ` Maciej Żenczykowski
2012-12-17 13:01 ` Jan Engelhardt
1 sibling, 0 replies; 26+ messages in thread
From: Maciej Żenczykowski @ 2012-12-17 10:12 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Jan Engelhardt, Netfilter Developer Mailing List,
Netfilter user mailing list
> So far, I haven't see any *strong reason* to drop nftables code and
> write something from scratch as flexible as it is, my impression is
> that you don't know how nftables is designed and it works, so you'll
> have to tell me why I'm wrong.
>
> As said, please provide convincing arguments, no more rants.
So far, Pablo, you've yet to make any argument whatsoever.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-17 9:53 ` Pablo Neira Ayuso
2012-12-17 10:12 ` Maciej Żenczykowski
@ 2012-12-17 13:01 ` Jan Engelhardt
2012-12-17 14:30 ` Pablo Neira Ayuso
1 sibling, 1 reply; 26+ messages in thread
From: Jan Engelhardt @ 2012-12-17 13:01 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Monday 2012-12-17 10:53, Pablo Neira Ayuso wrote:
>> - It uses a single table because there simply is no need
>> to have multiple ones. This has benefits for replacement atomicity
>> guarantees, and gives some memory previously spent for modules
>> back to the user, for example.
>
>You can implement this with nftables.
>Actually, nftables allows you to have as many tables as you want.
Multiple table objects are possible in Xtables2, I do not think
it's something exclusive to nft.
It is just that I do not see a usecase and hence a need for multiple
active tables, so the netns only stores one.
>> - This table is NFPROTO_UNSPEC which means that the duplication of
>> rules between ip(4)tables and ip6tables users had to make is
>> gone, meaning less maintenance/complexity/etc. for the administrator,
>> and of course, less rules lead to less memory usage.
>
>We have also planned adding agnostic tables to avoid the IPv4/IPv6 cases.
So now xt2 gets copied... hmm must be a successful concept :)
>> - and because it retains some characteristics, for example
>> atomic replaces and netns.
>>
>> >You wrote on Thu, 13 Dec 2012 13:05:09 +0100:
>> >>I don't think that feature-set provides compelling reasons to push [xt2]
>>
>> Not everybody cares about these things, that would be unrealistic.
>> However, some users, and me included, _do have_ an interest in having
>> what is presented, because they do e.g. run containers. Otherwise,
>> we would not be having netns in iptables today, right?
>
>Again, those are completely possible with nftables.
There are no traces of pernet operations for nft in 3cb3000158^{tree}.
>> Now, don't dismiss these arguments.
>
>So far, I haven't see any *strong reason* to drop nftables code
In all fairness, I have never said anything about dropping nft.
I am focused on xt2, its inclusion and subsequent maintenance, because
it resolves the ipt shortcomings in a way that I think appeals most to
the userspace crowd.
>and write something from scratch as flexible as it is
I am avoiding from-scratch where possible. Given that ip_tables.c
exposes its ABI to userspace so much and deferred ruleset operations
to userspace as well, it is nearly impossible to change, and so
inherently, there will be some new code for any future replacement.
But it is my credo to reuse, and I do.
>my impression is that you don't know how nftables is designed and it
>works, so you'll have to tell me why I'm wrong.
How are users supposed to know how nftables is designed?
Xtables2 has documentation, explains where and why it deviates from
iptables. If there is only a doubt in your mind, @Dear Users, mail it -
I want the doc to leave no question unanswered.
If the "flexibility" mentioned above is important to you, I encourage
you to checkout xtables2 and give some thought on how your feature
could be integrated into it. Or rather, I'll offer on top: describe
the feature, and I write it.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-17 13:01 ` Jan Engelhardt
@ 2012-12-17 14:30 ` Pablo Neira Ayuso
2012-12-17 20:51 ` Jan Engelhardt
0 siblings, 1 reply; 26+ messages in thread
From: Pablo Neira Ayuso @ 2012-12-17 14:30 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Netfilter Developer Mailing List, Netfilter user mailing list
On Mon, Dec 17, 2012 at 02:01:07PM +0100, Jan Engelhardt wrote:
[...]
> >So far, I haven't see any *strong reason* to drop nftables code
>
> In all fairness, I have never said anything about dropping nft.
> I am focused on xt2, its inclusion and subsequent maintenance, because
> it resolves the ipt shortcomings in a way that I think appeals most to
> the userspace crowd.
I'm still not convinced but I want find a short-term compromise
solution for this which does not involve tons of email. We'll announce
the netfilter workshop soon, likely to happen at Q1 2013 depending on
availability of the organizer, but maybe Q2 2013 (but not later), I
think it's the place to debate your proposal and nftables, of course.
I will not get anything into mainline until then.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-17 14:30 ` Pablo Neira Ayuso
@ 2012-12-17 20:51 ` Jan Engelhardt
2012-12-17 23:49 ` Jozsef Kadlecsik
0 siblings, 1 reply; 26+ messages in thread
From: Jan Engelhardt @ 2012-12-17 20:51 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Netfilter Developer Mailing List, Netfilter user mailing list,
Maciej Żenczykowski
On Monday 2012-12-17 15:30, Pablo Neira Ayuso wrote:
>On Mon, Dec 17, 2012 at 02:01:07PM +0100, Jan Engelhardt wrote:
>[...]
>> >So far, I haven't see any *strong reason* to drop nftables code
>>
>> In all fairness, I have never said anything about dropping nft.
>> I am focused on xt2, its inclusion and subsequent maintenance, because
>> it resolves the ipt shortcomings in a way that I think appeals most to
>> the userspace crowd.
>
>I'm still not convinced but I want find a short-term compromise
>solution for this which does not involve tons of email. We'll announce
>the netfilter workshop soon, likely to happen at Q1 2013 depending on
>availability of the organizer, but maybe Q2 2013 (but not later), I
>think it's the place to debate your proposal and nftables, of course.
>
>I will not get anything into mainline until then.
Delaying this for more months is not a good idea, I think.
The amount of patches will grow as more features are implemented. If
there is an objection to a patch, then this can have implications for
all those that follow (not rebase conflicts, but actual
invalidating), which gets more painful the larger the patchset is.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-17 20:51 ` Jan Engelhardt
@ 2012-12-17 23:49 ` Jozsef Kadlecsik
2012-12-18 1:11 ` Jan Engelhardt
2012-12-18 1:27 ` David Miller
0 siblings, 2 replies; 26+ messages in thread
From: Jozsef Kadlecsik @ 2012-12-17 23:49 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Pablo Neira Ayuso, Netfilter Developer Mailing List,
Netfilter user mailing list, Maciej Żenczykowski
On Mon, 17 Dec 2012, Jan Engelhardt wrote:
> On Monday 2012-12-17 15:30, Pablo Neira Ayuso wrote:
>
> >On Mon, Dec 17, 2012 at 02:01:07PM +0100, Jan Engelhardt wrote:
> >[...]
> >> >So far, I haven't see any *strong reason* to drop nftables code
> >>
> >> In all fairness, I have never said anything about dropping nft.
> >> I am focused on xt2, its inclusion and subsequent maintenance, because
> >> it resolves the ipt shortcomings in a way that I think appeals most to
> >> the userspace crowd.
> >
> >I'm still not convinced but I want find a short-term compromise
> >solution for this which does not involve tons of email. We'll announce
> >the netfilter workshop soon, likely to happen at Q1 2013 depending on
> >availability of the organizer, but maybe Q2 2013 (but not later), I
> >think it's the place to debate your proposal and nftables, of course.
> >
> >I will not get anything into mainline until then.
>
> Delaying this for more months is not a good idea, I think.
>
> The amount of patches will grow as more features are implemented. If
> there is an objection to a patch, then this can have implications for
> all those that follow (not rebase conflicts, but actual
> invalidating), which gets more painful the larger the patchset is.
A few months won't really hurt - TPROXY had been discussed for a couple of
years at every workshop (and it was much simpler, smaller code). Both
nftables and xtables2 have got nice features, so it's not a simple
question.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-17 23:49 ` Jozsef Kadlecsik
@ 2012-12-18 1:11 ` Jan Engelhardt
2012-12-18 1:51 ` Neal Murphy
2012-12-18 1:27 ` David Miller
1 sibling, 1 reply; 26+ messages in thread
From: Jan Engelhardt @ 2012-12-18 1:11 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Pablo Neira Ayuso, Netfilter Developer Mailing List,
Netfilter user mailing list, Maciej Żenczykowski
On Tuesday 2012-12-18 00:49, Jozsef Kadlecsik wrote:
>>>
>>>I'm still not convinced [...] I will not get anything into mainline
>>>until then.
>>
>>Delaying this for more months is not a good idea, I think. The amount
>>of patches will grow as more features are implemented.[...]
>
>A few months won't really hurt - TPROXY had been discussed for a couple
>of years at every workshop (and it was much simpler, smaller code).
>Both nftables and xtables2 have got nice features, so it's not a simple
>question.
Ok.
I'll go with your mediating words. :)
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-17 23:49 ` Jozsef Kadlecsik
2012-12-18 1:11 ` Jan Engelhardt
@ 2012-12-18 1:27 ` David Miller
1 sibling, 0 replies; 26+ messages in thread
From: David Miller @ 2012-12-18 1:27 UTC (permalink / raw)
To: kadlec; +Cc: jengelh, pablo, netfilter-devel, netfilter, zenczykowski
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date: Tue, 18 Dec 2012 00:49:26 +0100 (CET)
> On Mon, 17 Dec 2012, Jan Engelhardt wrote:
>
>> On Monday 2012-12-17 15:30, Pablo Neira Ayuso wrote:
>>
>> >On Mon, Dec 17, 2012 at 02:01:07PM +0100, Jan Engelhardt wrote:
>> >[...]
>> >> >So far, I haven't see any *strong reason* to drop nftables code
>> >>
>> >> In all fairness, I have never said anything about dropping nft.
>> >> I am focused on xt2, its inclusion and subsequent maintenance, because
>> >> it resolves the ipt shortcomings in a way that I think appeals most to
>> >> the userspace crowd.
>> >
>> >I'm still not convinced but I want find a short-term compromise
>> >solution for this which does not involve tons of email. We'll announce
>> >the netfilter workshop soon, likely to happen at Q1 2013 depending on
>> >availability of the organizer, but maybe Q2 2013 (but not later), I
>> >think it's the place to debate your proposal and nftables, of course.
>> >
>> >I will not get anything into mainline until then.
>>
>> Delaying this for more months is not a good idea, I think.
>>
>> The amount of patches will grow as more features are implemented. If
>> there is an objection to a patch, then this can have implications for
>> all those that follow (not rebase conflicts, but actual
>> invalidating), which gets more painful the larger the patchset is.
>
> A few months won't really hurt - TPROXY had been discussed for a couple of
> years at every workshop (and it was much simpler, smaller code). Both
> nftables and xtables2 have got nice features, so it's not a simple
> question.
Agreed.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-18 1:11 ` Jan Engelhardt
@ 2012-12-18 1:51 ` Neal Murphy
0 siblings, 0 replies; 26+ messages in thread
From: Neal Murphy @ 2012-12-18 1:51 UTC (permalink / raw)
To: netfilter
As a disinterested third party*, I think Jan is voicing stronger arguments,
and that Pablo may need to enhance his debating skills.
N
* Disinterested in that I don't have a bone to pick in this debate. I do have
a few netfilter thoughts, though, concerning general usability enhancements to
the facility: 32 bit connmarks can be rather limiting (64 bits would be far
more adequate), integrated IPv4/IPv6 (it'd be nice to be able to specify both
addresses for a node in a single rule, for dual-stacked nodes), and a way to
explicitly include related conns in a rule (after establishment, there seems
to be no way to associate a related conn with the rule that allowed it in the
first place).
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Formal submission of Xtables2
2012-12-14 18:49 ` Jan Engelhardt
@ 2012-12-18 14:09 ` Andreas Herz
0 siblings, 0 replies; 26+ messages in thread
From: Andreas Herz @ 2012-12-18 14:09 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Netfilter user mailing list
On 14/12/12 at 19:49, Jan Engelhardt wrote:
> On Friday 2012-12-14 10:41, Andreas Herz wrote:
> >On 13/12/12 at 12:00, Pablo Neira Ayuso wrote:
> >> On Thu, Dec 13, 2012 at 07:00:07AM +0100, Jan Engelhardt wrote:
> >> [...]
> >> > Please consider for merging.
> >>
> >> nftables and its compatibility layer already provide this and we will
> >> not have to maintain two different netlink interfaces, which is too
> >> much overhead.
> >
> >Apart of your discussion (i think it's quite interesting although you
> >might not agree), is there a summary of the status of nftables?
> >The last time i read about it, while i was at the university, i thought
> >it was dead.
> >I read that Patrick McHardy was the one pushing the project but never
> >heard any news after 2010. Now i read that Pablo is taking care of it.
> >
> >So i would love to hear more details on the roadmap for nftables, might
> >be interesting for me and my work here.
>
> For parity, I am posting my roadmap document as it exists so far
> as well. Please see http://inai.de/nfxt/ .
>
> And before the question of "who's maintaining?" coming up again -
> I'd be glad to maintain if only I was given the chance to.
Thanks so far for the informations. I will just see how the development
is going on and if i/we need some parts.
--
Andreas Herz
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2012-12-18 14:09 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-13 6:00 Formal submission of Xtables2 Jan Engelhardt
2012-12-13 11:00 ` Pablo Neira Ayuso
2012-12-13 11:36 ` Jan Engelhardt
2012-12-13 12:05 ` Pablo Neira Ayuso
2012-12-13 13:08 ` Jan Engelhardt
2012-12-13 14:28 ` Pablo Neira Ayuso
2012-12-13 14:53 ` Jan Engelhardt
2012-12-13 15:16 ` Pablo Neira Ayuso
2012-12-13 16:41 ` Jan Engelhardt
2012-12-13 17:25 ` Pablo Neira Ayuso
2012-12-13 18:19 ` Jan Engelhardt
2012-12-17 0:08 ` Pablo Neira Ayuso
2012-12-17 1:39 ` Jan Engelhardt
2012-12-17 9:53 ` Pablo Neira Ayuso
2012-12-17 10:12 ` Maciej Żenczykowski
2012-12-17 13:01 ` Jan Engelhardt
2012-12-17 14:30 ` Pablo Neira Ayuso
2012-12-17 20:51 ` Jan Engelhardt
2012-12-17 23:49 ` Jozsef Kadlecsik
2012-12-18 1:11 ` Jan Engelhardt
2012-12-18 1:51 ` Neal Murphy
2012-12-18 1:27 ` David Miller
2012-12-14 9:41 ` Andreas Herz
2012-12-14 18:49 ` Jan Engelhardt
2012-12-18 14:09 ` Andreas Herz
2012-12-16 23:57 ` Pablo Neira Ayuso
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.