2.6.20-rc4: regression: iptables failed to load rules

2.6.20-rc4: regression: iptables failed to load rules

[Tomasz Kvarsin]

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
---

Re: 2.6.20-rc4: regression: iptables failed to load rules

[Linus Torvalds]

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

Re: 2.6.20-rc4: regression: iptables failed to load rules

[Patrick McHardy]

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.

Re: 2.6.20-rc4: regression: iptables failed to load rules

[Linus Torvalds]

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

Re: 2.6.20-rc4: regression: iptables failed to load rules

[Bill Davidsen]

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.

Re: 2.6.20-rc4: regression: iptables failed to load rules

[David Miller]

From: Linus Torvalds <torvalds@osdl.org>
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.