Name: Warn that ipchains and ipfwadm are going away
Status: Trivial
Signed-off-by: Rusty Russell <[email protected]>
At the recent netfilter workshop in Erlangen, we was decided to remove
the backwards compatibility code for ipchains and ipfwadm. This will
allow significant cleanup of interfaces, since we had to have a
mid-level interface for the backwards compatibility layer to use.
Start off with a warning for 2.6.9, so any remaining users have a
chance to migrate. Their firewall scripts might not check return
values, and they might get a nasty surprise when this goes away.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .5978-linux-2.6.9-rc2-bk6/net/ipv4/netfilter/ipchains_core.c .5978-linux-2.6.9-rc2-bk6.updated/net/ipv4/netfilter/ipchains_core.c
--- .5978-linux-2.6.9-rc2-bk6/net/ipv4/netfilter/ipchains_core.c 2004-09-16 00:17:16.000000000 +1000
+++ .5978-linux-2.6.9-rc2-bk6.updated/net/ipv4/netfilter/ipchains_core.c 2004-09-21 09:06:07.000000000 +1000
@@ -1,3 +1,5 @@
+#warning ipchains is obsolete, and will be removed soon.
+
/* Minor modifications to fit on compatibility framework:
[email protected]
*/
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .5978-linux-2.6.9-rc2-bk6/net/ipv4/netfilter/ipfwadm_core.c .5978-linux-2.6.9-rc2-bk6.updated/net/ipv4/netfilter/ipfwadm_core.c
--- .5978-linux-2.6.9-rc2-bk6/net/ipv4/netfilter/ipfwadm_core.c 2004-09-16 00:17:16.000000000 +1000
+++ .5978-linux-2.6.9-rc2-bk6.updated/net/ipv4/netfilter/ipfwadm_core.c 2004-09-21 09:06:18.000000000 +1000
@@ -1,3 +1,5 @@
+#warning ipfwadm is obsolete, and will be removed soon.
+
/* Minor modifications to fit on compatibility framework:
[email protected]
*/
On Tue, 21 Sep 2004 09:09:02 +1000
"Rusty Russell (IBM)" <[email protected]> wrote:
> Name: Warn that ipchains and ipfwadm are going away
> Status: Trivial
> Signed-off-by: Rusty Russell <[email protected]>
>
> Start off with a warning for 2.6.9, so any remaining users have a
> chance to migrate. Their firewall scripts might not check return
> values, and they might get a nasty surprise when this goes away.
Isn't a compile-time warning a bit "soft"? Especially when compilation of
a kernel easily produces > 100 warnings, as it does right now.
Regards
Rusty Russell (IBM) wrote:
> Name: Warn that ipchains and ipfwadm are going away
> Status: Trivial
> Signed-off-by: Rusty Russell <[email protected]>
>
> At the recent netfilter workshop in Erlangen, we was decided to remove
> the backwards compatibility code for ipchains and ipfwadm. This will
> allow significant cleanup of interfaces, since we had to have a
> mid-level interface for the backwards compatibility layer to use.
>
> Start off with a warning for 2.6.9, so any remaining users have a
> chance to migrate. Their firewall scripts might not check return
> values, and they might get a nasty surprise when this goes away.
I thought I understood the "new development model" but I guess I don't.
Are working features now going to be removed from the "stable" chain
instead of during a development cycle?
Not a complaint, I thought the new method was regarding new features...
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Tue, 2004-09-21 at 22:36, Marc Ballarin wrote:
> On Tue, 21 Sep 2004 09:09:02 +1000
> "Rusty Russell (IBM)" <[email protected]> wrote:
>
> > Name: Warn that ipchains and ipfwadm are going away
> > Status: Trivial
> > Signed-off-by: Rusty Russell <[email protected]>
>
> Isn't a compile-time warning a bit "soft"? Especially when compilation of
> a kernel easily produces > 100 warnings, as it does right now.
Sure, but you have to start somewhere. Next step will be #error. Then
finally remove the whole thing (I don't want to remove the whole thing
to start with, since that would create a silent failure).
Cheers,
Rusty.
--
http://linux.conf.au - Call for papers. Join us!
On Wed, 22 Sep 2004 07:58:22 +1000
Rusty Russell <[email protected]> wrote:
> Sure, but you have to start somewhere. Next step will be #error. Then
> finally remove the whole thing (I don't want to remove the whole thing
> to start with, since that would create a silent failure).
I was rather thinking of some prominent printks at module init time.
People using distro kernels will never see compile time warnings.
I just added some warnings, but modprobe ipchains always fails on
2.6.9-rc2:
FATAL: Error inserting ipchains
(/lib/modules/2.6.9-rc2-rcf/kernel/net/ipv4/netfilter/ipchains.ko): Device
or resource busy
in log buffer:
ip_conntrack version 2.1 (8191 buckets, 65528 max) - 332 bytes per
conntrack
Unable to register netfilter socket option
Am I missing something?
Regards
On Wed, 22 Sep 2004 00:36:46 +0200
Marc Ballarin <[email protected]> wrote:
> I just added some warnings, but modprobe ipchains always fails on
> 2.6.9-rc2:
>
> FATAL: Error inserting ipchains
> (/lib/modules/2.6.9-rc2-rcf/kernel/net/ipv4/netfilter/ipchains.ko): Device
> or resource busy
You can't have ipchains and iptables loaded at the same time.
You must first manually unload iptables, then you can
successfully load the ipchains module.
On Tue, 21 Sep 2004 15:36:00 -0700
"David S. Miller" <[email protected]> wrote:
> You can't have ipchains and iptables loaded at the same time.
> You must first manually unload iptables, then you can
> successfully load the ipchains module.
Yes, I know, something seems strange here.
Just to be sure, I disabled iptables completely and rebooted:
(Complete config.gz is attached.)
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_TUNNEL=m
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
CONFIG_IP_NF_QUEUE=m
# CONFIG_IP_NF_IPTABLES is not set
CONFIG_IP_NF_NAT_NEEDED=y
# CONFIG_IP_NF_ARPTABLES is not set
CONFIG_IP_NF_COMPAT_IPCHAINS=m
CONFIG_IP_NF_COMPAT_IPFWADM=m
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
This gives me the same error upon modprobe ipchains.
If I disable CONFIG_IP_NF_CONNTRACK, I get unresolved symbols:
ipchains: Unknown symbol ip_ct_log_invalid
(Is that combination supposed to work?)
lsmod (ALSA snipped):
vfat 10432 0
stir4200 10052 0
irda 110972 1 stir4200
crc_ccitt 1664 1 irda
fat 36320 1 vfat
parport_pc 29440 1
lp 7976 0
parport 32072 2 parport_pc,lp
floppy 50576 0
radeon 120676 2
nvidia_agp 5404 1
agpgart 26024 2 nvidia_agp
8139too 19200 0
mii 3712 1 8139too
crc32 3840 2 stir4200,8139too
evdev 6848 0
Regards
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/09/22 02:04:02+02:00 [email protected]
# {NETFILTER]: Move ip_ct_log_invalid to ip_conntrack_core.c
#
# Signed-off-by: Patrick McHardy <[email protected]>
#
# net/ipv4/netfilter/ip_conntrack_standalone.c
# 2004/09/22 02:03:37+02:00 [email protected] +0 -2
# {NETFILTER]: Move ip_ct_log_invalid to ip_conntrack_core.c
#
# Signed-off-by: Patrick McHardy <[email protected]>
#
# net/ipv4/netfilter/ip_conntrack_core.c
# 2004/09/22 02:03:37+02:00 [email protected] +1 -0
# {NETFILTER]: Move ip_ct_log_invalid to ip_conntrack_core.c
#
# Signed-off-by: Patrick McHardy <[email protected]>
#
diff -Nru a/net/ipv4/netfilter/ip_conntrack_core.c b/net/ipv4/netfilter/ip_conntrack_core.c
--- a/net/ipv4/netfilter/ip_conntrack_core.c 2004-09-22 02:10:28 +02:00
+++ b/net/ipv4/netfilter/ip_conntrack_core.c 2004-09-22 02:10:28 +02:00
@@ -74,6 +74,7 @@
static kmem_cache_t *ip_conntrack_cachep;
static kmem_cache_t *ip_conntrack_expect_cachep;
struct ip_conntrack ip_conntrack_untracked;
+unsigned int ip_ct_log_invalid;
DEFINE_PER_CPU(struct ip_conntrack_stat, ip_conntrack_stat);
diff -Nru a/net/ipv4/netfilter/ip_conntrack_standalone.c b/net/ipv4/netfilter/ip_conntrack_standalone.c
--- a/net/ipv4/netfilter/ip_conntrack_standalone.c 2004-09-22 02:10:28 +02:00
+++ b/net/ipv4/netfilter/ip_conntrack_standalone.c 2004-09-22 02:10:28 +02:00
@@ -48,8 +48,6 @@
extern atomic_t ip_conntrack_count;
DECLARE_PER_CPU(struct ip_conntrack_stat, ip_conntrack_stat);
-unsigned int ip_ct_log_invalid = 0;
-
static int kill_proto(const struct ip_conntrack *i, void *data)
{
return (i->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.protonum ==
On Wed, 22 Sep 2004, Rusty Russell wrote:
> On Tue, 2004-09-21 at 22:36, Marc Ballarin wrote:
> > On Tue, 21 Sep 2004 09:09:02 +1000
> > "Rusty Russell (IBM)" <[email protected]> wrote:
> >
> > > Name: Warn that ipchains and ipfwadm are going away
> > > Status: Trivial
> > > Signed-off-by: Rusty Russell <[email protected]>
> >
> > Isn't a compile-time warning a bit "soft"? Especially when compilation of
> > a kernel easily produces > 100 warnings, as it does right now.
>
> Sure, but you have to start somewhere. Next step will be #error. Then
> finally remove the whole thing (I don't want to remove the whole thing
> to start with, since that would create a silent failure).
>
> Cheers,
> Rusty.
> --
What replaces the firewall stuff? It can't just "go away"!
Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.
On Wed, 22 Sep 2004, Richard B. Johnson wrote:
> > Sure, but you have to start somewhere. Next step will be #error. Then
> > finally remove the whole thing (I don't want to remove the whole thing
> > to start with, since that would create a silent failure).
> >
> > Cheers,
> > Rusty.
> > --
>
> What replaces the firewall stuff? It can't just "go away"!
Ever heard of iptables?
/Martin
On Wed, 22 Sep 2004 07:36:47 -0400 (EDT)
"Richard B. Johnson" <[email protected]> wrote:
>
> What replaces the firewall stuff? It can't just "go away"!
In the upcoming kernel 2.4, which will be released January 2001, iptables
will replace ipchains.
Regards
Richard B. Johnson wrote:
> On Wed, 22 Sep 2004, Rusty Russell wrote:
>
>
>>On Tue, 2004-09-21 at 22:36, Marc Ballarin wrote:
>>
>>>On Tue, 21 Sep 2004 09:09:02 +1000
>>>"Rusty Russell (IBM)" <[email protected]> wrote:
>>>
>>>
>>>>Name: Warn that ipchains and ipfwadm are going away
>>>>Status: Trivial
>>>>Signed-off-by: Rusty Russell <[email protected]>
>>>
> What replaces the firewall stuff? It can't just "go away"!
>
> Cheers,
> Dick Johnson
ipchains and ipfwadm are very old firewall implementations.
The current linux firewall code is called "iptables" and that has been
present for a long time time, and that is staying.
So, the linux kernel still has firewall features, even with ipchains and
ipfwadm removed.
James
On Wed, 22 Sep 2004, Martin Josefsson wrote:
> On Wed, 22 Sep 2004, Richard B. Johnson wrote:
>
> > > Sure, but you have to start somewhere. Next step will be #error. Then
> > > finally remove the whole thing (I don't want to remove the whole thing
> > > to start with, since that would create a silent failure).
> > >
> > > Cheers,
> > > Rusty.
> > > --
> >
> > What replaces the firewall stuff? It can't just "go away"!
>
> Ever heard of iptables?
>
> /Martin
I guess I'll have to convert 1340 lines of ipchains commands to
iptables -yech!
I had convert something to ipchains a couple of years ago.
That's when I only had to kill-off only about 100 spam-hosts.
Now I gotta convert again. Soon they'll be replacing `ls`
with `echo *` and nothing will work.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.
Martin Josefsson <[email protected]> writes:
> On Wed, 22 Sep 2004, Richard B. Johnson wrote:
>
>> > Sure, but you have to start somewhere. Next step will be #error. Then
>> > finally remove the whole thing (I don't want to remove the whole thing
>> > to start with, since that would create a silent failure).
>> >
>> > Cheers,
>> > Rusty.
>> > --
>>
>> What replaces the firewall stuff? It can't just "go away"!
>
> Ever heard of iptables?
Except that it doesn't have usable 32bit emulation on x86-64.
32bit userland on x86-64 kernel cannot use iptables, they have
to use ipchains.
I would ask for to not drop ipchains until this is fixed.
-Andi
On Wednesday 22 September 2004 08:05, Richard B. Johnson wrote:
>On Wed, 22 Sep 2004, Martin Josefsson wrote:
>> On Wed, 22 Sep 2004, Richard B. Johnson wrote:
>> > > Sure, but you have to start somewhere. Next step will be
>> > > #error. Then finally remove the whole thing (I don't want to
>> > > remove the whole thing to start with, since that would create
>> > > a silent failure).
>> > >
>> > > Cheers,
>> > > Rusty.
>> > > --
>> >
>> > What replaces the firewall stuff? It can't just "go away"!
>>
>> Ever heard of iptables?
>>
>> /Martin
>
>I guess I'll have to convert 1340 lines of ipchains commands to
>iptables -yech!
Ouch! If it takes 1340 lines of ipchains commands, a direct
translation to iptables syntax is both counter-productive and
extremely wastefull of system resources, cpu in particular. I
admittedly have a dsl router in front of my machine, so it does 99%
of that job, but if I wanted to put up with the idiosyncracies of the
Roaring Penguin PPPoE, I could skip the router and be just as secure
with the less than 30 active lines of my present iptables script.
With the router, I'm invisible to the outside world. Of course that
does restrict me some as I've not figured out how to drill a hole
thru all that to allow a torrent server to function. The peace of
mind is worth that loss IMO. Its been over a year now since
portsentry-1.1 saw a trigger and logged it.
Humm, thats a lie, from the firewalls /var/log/messages.1 file:
[root@gene root]# grep attackalert /var/log/messages*
/var/log/messages.1:Sep 16 18:09:16 gene portsentry[1159]:
attackalert: UDP scan from host: home1.bellatlantic.net/199.45.32.43
to UDP port: 32771
/var/log/messages.1:Sep 16 18:09:16 gene portsentry[1159]:
attackalert: Host 199.45.32.43 has been blocked via wrappers with
string: "ALL: 199.45.32.43"
/var/log/messages.1:Sep 16 18:09:17 gene portsentry[1159]:
attackalert: Host 199.45.32.43 has been blocked via dropped route
using command: "/sbin/iptables -I INPUT -s 199.45.32.43 -j DROP"
/var/log/messages.1:Sep 16 18:09:17 gene portsentry[1159]:
attackalert: UDP scan from host: home1.bellatlantic.net/199.45.32.43
to UDP port: 32771
/var/log/messages.1:Sep 16 18:09:17 gene portsentry[1159]:
attackalert: Host: home1.bellatlantic.net/199.45.32.43 is already
blocked Ignoring
Time to send another nastygram to verizon since thats one of their
nameservers, and clear out that address from the hosts.deny file.
FWIW, the last time that happened, in April 2003, the hack attempt
trashed a siemans router and I had to replace it with that linksys.
Must be time to change the user and password in it again too...
FWIW, verizon has apparently a problem keeping their nameservers from
being hacked.
>I had convert something to ipchains a couple of years ago.
>That's when I only had to kill-off only about 100 spam-hosts.
>
>Now I gotta convert again. Soon they'll be replacing `ls`
>with `echo *` and nothing will work.
Surely you jest?
>Cheers,
>Dick Johnson
>Penguin : Linux version 2.4.26 on an i686 machine (5570.56
> BogoMips). Note 96.31% of all statistics are fiction.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
On Wed, 22 Sep 2004 02:16:08 +0200
Patrick McHardy <[email protected]> wrote:
> Fixed by this patch.
Yes, works fine. Does this mean that ipchains was broken for a while, but
no one complained?
Anyway, here is another trivial patch against -bk7 that adds runtime
warnings. IMO most users are going to miss compile time warnings, or
won't even compile kernels themselves.
Regards
diff -Nurp tmp/linux-2.6.9/net/ipv4/netfilter/ipchains_core.c
linux-2.6.9/net/ipv4/netfilter/ipchains_core.c
--- tmp/linux-2.6.9/net/ipv4/netfilter/ipchains_core.c 2004-09-22 14:45:26.398827000 +0200
+++ linux-2.6.9/net/ipv4/netfilter/ipchains_core.c 2004-09-22 14:51:20.017069184 +0200
@@ -1800,6 +1800,9 @@ int ipfw_init_or_cleanup(int init)
if (!init) goto cleanup;
+ printk(KERN_WARNING
+ "Warning: ipchains is obsolete, and will be removed soon!\n");
+
#ifdef DEBUG_IP_FIREWALL_LOCKING
fwc_wlocks = fwc_rlocks = 0;
#endif
diff -Nurp tmp/linux-2.6.9/net/ipv4/netfilter/ipfwadm_core.c
linux-2.6.9/net/ipv4/netfilter/ipfwadm_core.c
--- tmp/linux-2.6.9/net/ipv4/netfilter/ipfwadm_core.c 2004-09-22 14:45:53.545700000 +0200
+++ linux-2.6.9/net/ipv4/netfilter/ipfwadm_core.c 2004-09-22 14:51:37.780368752 +0200
@@ -1420,6 +1420,9 @@ int ipfw_init_or_cleanup(int init)
if (!init)
goto cleanup;
+ printk(KERN_WARNING
+ "Warning: ipfwadm is obsolete, and will be removed soon!\n");
+
ret = register_firewall(PF_INET, &ipfw_ops);
if (ret < 0)
goto cleanup_nothing;
On Wed, 22 Sep 2004, Marc Ballarin wrote:
> Date: Wed, 22 Sep 2004 15:37:07 +0200
> From: Marc Ballarin <[email protected]>
> To: Patrick McHardy <[email protected]>
> Cc: [email protected], [email protected], [email protected],
> [email protected], [email protected]
> Subject: Re: [PATCH] Warn people that ipchains and ipfwadm are going away.
>
> On Wed, 22 Sep 2004 02:16:08 +0200
> Patrick McHardy <[email protected]> wrote:
>
> > Fixed by this patch.
>
> Yes, works fine. Does this mean that ipchains was broken for a while, but
> no one complained?
>
> Anyway, here is another trivial patch against -bk7 that adds runtime
> warnings. IMO most users are going to miss compile time warnings, or
> won't even compile kernels themselves.
>
I like having runtime info as well as a compile time warning, but maybe
the message should mention that iptables is staying and people should
migrate??
> + printk(KERN_WARNING
> + "Warning: ipchains is obsolete, and will be removed soon!\n");
> +
Perhaps something like this instead:
"Warning: ipchains is obsolete, and will be removed soon. Please migrate to iptables."
--
Jesper Juhl
On Wed, 2004-09-22 at 14:15 +0200, Andi Kleen wrote:
> > Ever heard of iptables?
>
> Except that it doesn't have usable 32bit emulation on x86-64.
> 32bit userland on x86-64 kernel cannot use iptables, they have
> to use ipchains.
>
> I would ask for to not drop ipchains until this is fixed.
Agreed. The iptables compatibility with 32-bit userspace is completely
broken.
--
dwmw2
On Wed, 22 Sep 2004, Jesper Juhl wrote:
> On Wed, 22 Sep 2004, Marc Ballarin wrote:
>
> > Date: Wed, 22 Sep 2004 15:37:07 +0200
> > From: Marc Ballarin <[email protected]>
> > To: Patrick McHardy <[email protected]>
> > Cc: [email protected], [email protected], [email protected],
> > [email protected], [email protected]
> > Subject: Re: [PATCH] Warn people that ipchains and ipfwadm are going away.
> >
> > On Wed, 22 Sep 2004 02:16:08 +0200
> > Patrick McHardy <[email protected]> wrote:
> >
> > > Fixed by this patch.
> >
> > Yes, works fine. Does this mean that ipchains was broken for a while, but
> > no one complained?
> >
> > Anyway, here is another trivial patch against -bk7 that adds runtime
> > warnings. IMO most users are going to miss compile time warnings, or
> > won't even compile kernels themselves.
> >
>
> I like having runtime info as well as a compile time warning, but maybe
> the message should mention that iptables is staying and people should
> migrate??
>
> > + printk(KERN_WARNING
> > + "Warning: ipchains is obsolete, and will be removed soon!\n");
> > +
>
> Perhaps something like this instead:
>
> "Warning: ipchains is obsolete, and will be removed soon. Please migrate to iptables."
>
>
> --
> Jesper Juhl
FYI. I just migrated to iptables. The code downloaded from the Debian
site did not compile cleanly, but enough worked to make most of the
shared libraries and the iptables executable.
The total time to do everything was slightly under 2 hours.
The errors from the distribution are:
cc -O2 -Wall -Wunused -I/usr/src/linux-2.4.26/include -Iinclude/ -DNETFILTER_VERSION=\"1.2.6a\" -fPIC -o extensions/libipt_ECN_sh.o -c extensions/libipt_ECN.c
extensions/libipt_ECN.c: In function `parse':
extensions/libipt_ECN.c:51: `IPT_ECN_OP_REMOVE' undeclared (first use in this function)
extensions/libipt_ECN.c:51: (Each undeclared identifier is reported only once
extensions/libipt_ECN.c:51: for each function it appears in.)
extensions/libipt_ECN.c: In function `print':
extensions/libipt_ECN.c:82: `IPT_ECN_OP_REMOVE' undeclared (first use in this function)
extensions/libipt_ECN.c:83: warning: unreachable code at beginning of switch statement
extensions/libipt_ECN.c: In function `save':
extensions/libipt_ECN.c:99: `IPT_ECN_OP_REMOVE' undeclared (first use in this function)
extensions/libipt_ECN.c:100: warning: unreachable code at beginning of switch statement
make: [extensions/libipt_ECN_sh.o] Error 1 (ignored)
ld -shared -o extensions/libipt_ECN.so extensions/libipt_ECN_sh.o
ld: cannot open extensions/libipt_ECN_sh.o: No such file or directory
make: [extensions/libipt_ECN.so] Error 1 (ignored)
ip6tables.o: In function `addr_to_host':
ip6tables.o(.text+0x4d8): undefined reference to `getnameinfo'
ip6tables.o: In function `parse_hostnetworkmask':
ip6tables.o(.text+0x731): undefined reference to `in6addr_any'
ip6tables.o: In function `print_firewall':
ip6tables.o(.text+0x19e7): undefined reference to `in6addr_any'
collect2: ld returned 1 exit status
make: [ip6tables] Error 1 (ignored)
The build command was:
#
#!/bin/sh
#
#make pending-patches KERNEL_DIR=/usr/src/linux-`uname -r`
make -i KERNEL_DIR=/usr/src/linux-`uname -r`
The pending patches resulted in many rejects but the kernel
was virgin 2.4.26.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.
Richard B. Johnson wrote:
>I guess I'll have to convert 1340 lines of ipchains commands to
>iptables -yech!
>
>I had convert something to ipchains a couple of years ago.
>That's when I only had to kill-off only about 100 spam-hosts.
>
>Now I gotta convert again. Soon they'll be replacing `ls`
>with `echo *` and nothing will work.
>
iptables is a much better firewall than ipchains and, in my opinion,
anybody using ipchains should upgrade to iptables. I, for one, am quite
pleased to see that ipchains will be removed.
--
Sean
Good day, all,
On Wed, 22 Sep 2004, Richard B. Johnson wrote:
> On Wed, 22 Sep 2004, Martin Josefsson wrote:
>
> > On Wed, 22 Sep 2004, Richard B. Johnson wrote:
> >
> > > What replaces the firewall stuff? It can't just "go away"!
> >
> > Ever heard of iptables?
>
> I guess I'll have to convert 1340 lines of ipchains commands to
> iptables -yech!
I have a script that does a first pass of converting an ipchains
firewall script to an iptables firewall script at
http://www.stearns.org/i2i/ipchains2iptables
http://www.stearns.org/i2i/ipchains2iptables.README
Because of architectural differences between the two firewall
technologies it can't produce a perfect translation, but it does handle
most of the grunt work.
Cheers,
- Bill
---------------------------------------------------------------------------
"The sign on the window next to the entrance of OptInRealBig's
offices in Westminster leaves no room for misunderstanding. Or irony.
NO SOLICITING."
http://www.westword.com/issues/2004-01-29/feature.html/3/index.html
--------------------------------------------------------------------------
William Stearns ([email protected]). Mason, Buildkernel, freedups, p0f,
rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org
--------------------------------------------------------------------------
Andi Kleen writes:
> Martin Josefsson <[email protected]> writes:
>> Ever heard of iptables?
>
> Except that it doesn't have usable 32bit emulation
> on x86-64. 32bit userland on x86-64 kernel cannot
> use iptables, they have to use ipchains.
>
> I would ask for to not drop ipchains until this is fixed.
Who is doing a 32-bit userland on x86-64, and WTF for?
Why do they not also run a 32-bit kernel?
Albert Cahalan wrote:
> Who is doing a 32-bit userland on x86-64, and WTF for?
> Why do they not also run a 32-bit kernel?
Backwards compatibility? Desire to run binary-only 32-bit software as well as
64-bit software on the same kernel?
Chris
On Thu, 2004-09-23 at 15:33, Chris Friesen wrote:
> Albert Cahalan wrote:
>
> > Who is doing a 32-bit userland on x86-64, and WTF for?
> > Why do they not also run a 32-bit kernel?
>
> Backwards compatibility? Desire to run binary-only 32-bit software as well as
> 64-bit software on the same kernel?
Nope. For that, you run 99% 64-bit, including iptables.
That's what is typically done. So you'd have a 32-bit
OpenOffice maybe, and everything else is 64-bit.
I'm still not seeing a need to run an x86-64 kernel
with an i386 iptables.
Albert Cahalan wrote:
> On Thu, 2004-09-23 at 15:33, Chris Friesen wrote:
>
>>Albert Cahalan wrote:
>>
>>
>>>Who is doing a 32-bit userland on x86-64, and WTF for?
>>>Why do they not also run a 32-bit kernel?
>>
>>Backwards compatibility? Desire to run binary-only 32-bit software as well as
>>64-bit software on the same kernel?
>
>
> Nope. For that, you run 99% 64-bit, including iptables.
> That's what is typically done. So you'd have a 32-bit
> OpenOffice maybe, and everything else is 64-bit.
>
> I'm still not seeing a need to run an x86-64 kernel
> with an i386 iptables.
>
>
Easy migration: take your fully-set-up server image, throw in an Opteron
with 16GB RAM, and boot a 64-bit kernel. As long as you don't need more
than 4GB/program, you're set. Except your firewall is broken.
--Andy
On 23 Sep 2004 15:36:34 -0400
Albert Cahalan <[email protected]> wrote:
> I'm still not seeing a need to run an x86-64 kernel
> with an i386 iptables.
Me neither. And it's not like the netfilter tools have
any interesting library dependencies either, ldd on
iptables for example is merely:
libdl.so.2 => /lib/ultra3/libdl.so.2 (0x7002c000)
libnsl.so.1 => /lib/ultra3/libnsl.so.1 (0x70040000)
libc.so.6 => /lib/ultra3/libc.so.6 (0x70068000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x70000000)
And that's just libc.
If Andi would code on kernel bug fixes for these problems
as much as he complained about them, he wouldn't have anything
to complain about :-)
I would like to see a netfilter compat layer translater engine
of some sort, none the less. With the right design it won't
be hard to implement things properly.
Albert Cahalan <[email protected]> wrote:
> Who is doing a 32-bit userland on x86-64, and WTF for?
> Why do they not also run a 32-bit kernel?
Debian will be shipping a 32-bit userland with a 64-bit kernel. The
reasons are long, awkward, and mostly uninteresting. The reason for
shipping a 64-bit kernel is that it makes it easier for users who
require large quantities of VM to obtain it.
--
Matthew Garrett | [email protected]
On Fri, 24 Sep 2004 00:08:13 +0100
Matthew Garrett <[email protected]> wrote:
> Albert Cahalan <[email protected]> wrote:
>
> > Who is doing a 32-bit userland on x86-64, and WTF for?
> > Why do they not also run a 32-bit kernel?
>
> Debian will be shipping a 32-bit userland with a 64-bit kernel. The
> reasons are long, awkward, and mostly uninteresting. The reason for
> shipping a 64-bit kernel is that it makes it easier for users who
> require large quantities of VM to obtain it.
But just like the sparc64 port, there is a 64-bit userland
compilation environment available, and debian has the means
to ship 64-bit specific packages on top of a mostly 32-bit
userland. So it is very easy for them to ship a 64-bit
netfilter utility package if they wanted to.