During boot into 2.6.20-rc4 iptables says
iptables-restore: line 15 failed.
And works fine with my default kernel: 2.6.18.x
Here is rules:
---
# cat /var/lib/iptables/rules-save
# Generated by iptables-save v1.3.5 on Tue Jan 9 10:20:35 2007
*filter
:INPUT DROP [26037:8838791]
:FORWARD DROP [0:0]
:OUTPUT DROP [13:618]
[380565:126936795] -A INPUT -d 127.0.0.0/255.0.0.0 -i lo -j ACCEPT
[7169377:10305891759] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[43:2598] -A INPUT -p icmp -j ACCEPT
[3964:5136292] -A INPUT -m state --state INVALID -j LOG --log-prefix
"INVALID packet: "
[4626:5179524] -A INPUT -p tcp -j LOG --log-prefix "UNMATCHED TCP packet: "
[21404:3658854] -A INPUT -p udp -j LOG --log-prefix "UNMATCHED UDP packet: "
[380565:126936795] -A OUTPUT -d 127.0.0.0/255.0.0.0 -o lo -j ACCEPT
[8745533:1380343927] -A OUTPUT -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
[0:0] -A OUTPUT -p icmp -j ACCEPT
COMMIT
# Completed on Tue Jan 9 10:20:35 2007
---
On Tue, 9 Jan 2007, Tomasz Kvarsin wrote:
>
> During boot into 2.6.20-rc4 iptables says
> iptables-restore: line 15 failed.
> And works fine with my default kernel: 2.6.18.x
I bet you enabled the new transport-agnostic netfilter, and didn't enable
some of the actual rules needed for your iptables setup (they have new
config names).
I do think that the netfilter team has been very irritating in changing
the config names, even if it "is logical".
Somebody should stop the madness, and tell people what config options they
need for a regular iptables setup like this. Rather than say "just compile
everything". There's about a million different filters, and they all
depend on one infrastructure or another.
And then the networking people should F*NG STOP that config name changing
madness! The config names should match the _usage_, not some
implementation detail. And failing that, leave the config options named
something illogical, as long as people don't have to change their config
file all the time and answer millions of questions that they don't care
about!
David, please crack some heads.
Linus
Linus Torvalds wrote:
>
> On Tue, 9 Jan 2007, Tomasz Kvarsin wrote:
>
>>During boot into 2.6.20-rc4 iptables says
>>iptables-restore: line 15 failed.
>>And works fine with my default kernel: 2.6.18.x
>
>
> I bet you enabled the new transport-agnostic netfilter, and didn't enable
> some of the actual rules needed for your iptables setup (they have new
> config names).
>
> I do think that the netfilter team has been very irritating in changing
> the config names, even if it "is logical".
>
> Somebody should stop the madness, and tell people what config options they
> need for a regular iptables setup like this. Rather than say "just compile
> everything". There's about a million different filters, and they all
> depend on one infrastructure or another.
>
> And then the networking people should F*NG STOP that config name changing
> madness! The config names should match the _usage_, not some
> implementation detail. And failing that, leave the config options named
> something illogical, as long as people don't have to change their config
> file all the time and answer millions of questions that they don't care
> about!
In the x_tables case it really caused a lot of unnecessary confusion,
the recent connection tracking changes however needed new config
options since we're keeping the old implementation around for a few more
releases. Unfortunately when switching between the two implementations,
Kconfig deselects all options depending on either one, even though the
dependencies are still fulfilled (f.e. NETFILTER_XT_MATCH_CONNTRACK:
depends on IP_NF_CONNTRACK || NF_CONNTRACK), which means you have
to select all those options again.
It probably won't be necessary anymore to make changes like this in
the future, but in case it is I'll make sure to at least provide
compatibility options for a few releases.
On Wed, 10 Jan 2007, Patrick McHardy wrote:
>
> In the x_tables case it really caused a lot of unnecessary confusion,
> the recent connection tracking changes however needed new config
> options since we're keeping the old implementation around for a few more
> releases.
It's too late now, but it _could_ have fairly easily been handled totally
differently: namely by having the user-visible config options be
INDEPENDENT of the actual back-end.
The Kconfig language is actually pretty powerful for configuration issues,
and the way to do this is relatively straightforward:
config CONNTRACK
tristate "Netfilter support"
...
config NEW_CONTRACK_SUPPORT
bool "Layer 3 Independent Connection tracking"
...
config CONNTRACK_MARK
bool 'Connection mark tracking support'
depends on CONNTRACK
...
config OLD_CONNTRACK_MARK
bool
depends on CONNTRACK_MARK && CONNTRACK && !NEW_CONTRACK_SUPPORT
default y
config NEW_CONNTRACK_MARK
bool
depends on CONNTRACK_MARK && CONNTRACK && NEW_CONTRACK_SUPPORT
default y
See? The _user_ just sees a single "CONNTRACK_MARK" option (that just
depends on the *generic* CONNTRACK config option), but then the Kconfig
file splits that into "OLD_CONNTRACK_MARK" or "NEW_CONNTRACK_MARK"
depending on whether "NEW_CONTRACK_SUPPORT" was set or not.
> It probably won't be necessary anymore to make changes like this in
> the future, but in case it is I'll make sure to at least provide
> compatibility options for a few releases.
In general, I'd much rather see the config options impact what the "user
experience" should be. Notice how the above does exactly that: all the
USER really cares about whether the connection marks are enabled or not,
and the "NEW_CONTRACK_SUPPORT" is _not_ part of the user-visible config
(apart from the _one_ question that asks about which implementation you
want to pick), but it is only used to pick which _implementation_ to
choose.
So making the Kconfig files more user-oriented and less implementation-
oriented automatically solves the problem with config options that change
names (because if the effect is the same, it should have the same name -
regardless of how it is implemented!).
Linus
Linus Torvalds wrote:
>
> On Tue, 9 Jan 2007, Tomasz Kvarsin wrote:
>> During boot into 2.6.20-rc4 iptables says
>> iptables-restore: line 15 failed.
>> And works fine with my default kernel: 2.6.18.x
>
> I bet you enabled the new transport-agnostic netfilter, and didn't enable
> some of the actual rules needed for your iptables setup (they have new
> config names).
>
> I do think that the netfilter team has been very irritating in changing
> the config names, even if it "is logical".
>
> Somebody should stop the madness, and tell people what config options they
> need for a regular iptables setup like this. Rather than say "just compile
> everything". There's about a million different filters, and they all
> depend on one infrastructure or another.
>
> And then the networking people should F*NG STOP that config name changing
> madness! The config names should match the _usage_, not some
> implementation detail. And failing that, leave the config options named
> something illogical, as long as people don't have to change their config
> file all the time and answer millions of questions that they don't care
> about!
This could apply to some other things, like PAE support. Instead of
having to know what memory models set what option which impact
virtualization, set the option if the feature is needed for any config
option choice. This probably hits people wanting virtualization on small
memory machines more than others.
From: Linus Torvalds <[email protected]>
Date: Tue, 9 Jan 2007 09:33:32 -0800 (PST)
> David, please crack some heads.
I have some patches from Patrick in my queue which try to add some
sanity to this situation, we'll see how much better we can make it.