iptables error

iptables error

[Nishit Shah]

Hi,
	I am using 2.6.16.13 kernel in smp configuration. Machine is working
as a gateway and frequent iptables commands are fired as users logged in and
logged out.

      I got following error in between

[root@manage /root]# iptables -nvx -L INPUT
ERROR: 7 not a valid target)
Aborted (core dumped)

So, I tried to flush INPUT and got following

[root@manage /root]# iptables -F INPUT 
iptables: Too many levels of symbolic links

following is a message I got in /var/log/messages

Aug 26 14:38:30 1219741710 kernel: iptables: loop hook 1 pos 0 00000022.

Rgds,
Nishit Shah.        

Re: iptables error

[Patrick McHardy]

Nishit Shah wrote:
> Hi,
> 	I am using 2.6.16.13 kernel in smp configuration. Machine is working
> as a gateway and frequent iptables commands are fired as users logged in and
> logged out.
> 
>       I got following error in between
> 
> [root@manage /root]# iptables -nvx -L INPUT
> ERROR: 7 not a valid target)
> Aborted (core dumped)
> 
> So, I tried to flush INPUT and got following
> 
> [root@manage /root]# iptables -F INPUT 
> iptables: Too many levels of symbolic links
> 
> following is a message I got in /var/log/messages
> 
> Aug 26 14:38:30 1219741710 kernel: iptables: loop hook 1 pos 0 00000022.

That kernel version has an iptables locking bug that might
lead to corruption. Latest 2.6.16 version has this fixed.

RE: iptables error

[Nishit Shah]

Thanks :)

Rgds,
Nishit Shah.

-----Original Message-----
From: Patrick McHardy [mailto:kaber@trash.net] 
Sent: Monday, September 01, 2008 7:08 PM
To: Nishit Shah
Cc: netfilter-devel@vger.kernel.org
Subject: Re: iptables error

Nishit Shah wrote:
> Hi,
> 	I am using 2.6.16.13 kernel in smp configuration. Machine is working
> as a gateway and frequent iptables commands are fired as users logged in
and
> logged out.
> 
>       I got following error in between
> 
> [root@manage /root]# iptables -nvx -L INPUT
> ERROR: 7 not a valid target)
> Aborted (core dumped)
> 
> So, I tried to flush INPUT and got following
> 
> [root@manage /root]# iptables -F INPUT 
> iptables: Too many levels of symbolic links
> 
> following is a message I got in /var/log/messages
> 
> Aug 26 14:38:30 1219741710 kernel: iptables: loop hook 1 pos 0 00000022.

That kernel version has an iptables locking bug that might
lead to corruption. Latest 2.6.16 version has this fixed.

iptables ERROR

[Ritesh Majumdar]

Hello List,

I have recently added ipset code in to my kernel, so all the ipset
ralated ko's can be compiled while I compile kernel.
my compilation works fine and I can add ipset rules successfully.
but when I add iptables rules to macth specific set I get error.

Here is what I am trying to do.



ipset -N a_ipset iphash 
iptables -N a 
iptables -N b 
iptables -A a -p udp -m set --set a_ipset dst -j b 





when I try to add the last rule,(iptables -A a -p udp -m set --set
a_ipset dst -j b)  it fails with the error as below.

iptables: Invalid argument



I am not sure if its ipset issue or iptables.

I am using "kernel 2.6.27" "ipset-2.4.9" and "iptables-1.4.1.91"


Many Thanks.
Ritesh.

Re: iptables ERROR

[Richard Horton]

2009/6/25 Ritesh Majumdar <r.majumdar@globallogic.com>:
>
> ipset -N a_ipset iphash
> iptables -N a
> iptables -N b
> iptables -A a -p udp -m set --set a_ipset dst -j b
>

Isn't it meant to be:-
iptables -A a -p udp -m set --set a_ipset,dst -j b

(note the insertion of a comma)
-- 
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.solstans.co.uk - Solstans Japanese Bobtails and Norwegian Forest Cats
http://www.pbase.com/arimus - My online photogallery

Re: iptables ERROR

[Richard Horton]

2009/6/25 Ritesh Majumdar <r.majumdar@globallogic.com>:
>
> ipset -N a_ipset iphash
> iptables -N a
> iptables -N b
> iptables -A a -p udp -m set --set a_ipset dst -j b
>

Isn't it meant to be:-
iptables -A a -p udp -m set --set a_ipset,dst -j b

(note the insertion of a comma)
-- 
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.solstans.co.uk - Solstans Japanese Bobtails and Norwegian Forest Cats
http://www.pbase.com/arimus - My online photogallery

Re: iptables ERROR

[Ritesh Majumdar]

Hello,

As per my earlier mail.

Here is error I get on my /var/log/messages.

kernel: ip_tables: set match: invalid size 96 != 32



Thanks,




On Thu, 2009-06-25 at 18:26 +0530, Ritesh Majumdar wrote:
> Hello List,
> 
> I have recently added ipset code in to my kernel, so all the ipset
> ralated ko's can be compiled while I compile kernel.
> my compilation works fine and I can add ipset rules successfully.
> but when I add iptables rules to macth specific set I get error.
> 
> Here is what I am trying to do.
> 
> 
> 
> ipset -N a_ipset iphash 
> iptables -N a 
> iptables -N b 
> iptables -A a -p udp -m set --set a_ipset dst -j b 
> 
> 
> 
> 
> 
> when I try to add the last rule,(iptables -A a -p udp -m set --set
> a_ipset dst -j b)  it fails with the error as below.
> 
> iptables: Invalid argument
> 
> 
> 
> I am not sure if its ipset issue or iptables.
> 
> I am using "kernel 2.6.27" "ipset-2.4.9" and "iptables-1.4.1.91"
> 
> 
> Many Thanks.
> Ritesh.
> 
--
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

Re: iptables ERROR

[Jan Engelhardt]

On Thursday 2009-06-25 16:00, Ritesh Majumdar wrote:

>Hello,
>
>As per my earlier mail.
>
>Here is error I get on my /var/log/messages.
>
>kernel: ip_tables: set match: invalid size 96 != 32

This could be related to http://markmail.org/message/dijxb6i6325t6hge
So be sure to use ipset 3.0 (it's out now) with iptables 1.4.4.

Re: iptables ERROR

[Jozsef Kadlecsik]

On Thu, 25 Jun 2009, Jan Engelhardt wrote:

> On Thursday 2009-06-25 16:00, Ritesh Majumdar wrote:
> 
> >As per my earlier mail.
> >
> >Here is error I get on my /var/log/messages.
> >
> >kernel: ip_tables: set match: invalid size 96 != 32
> 
> This could be related to http://markmail.org/message/dijxb6i6325t6hge
> So be sure to use ipset 3.0 (it's out now) with iptables 1.4.4.

Yes, exactly: with ipset 3.0 you need iptables 1.4.4.

I'm sorry for breaking backward compatibility.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Iptables error [Was: 2.6.16-rc1-mm2]

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On Fri, Jan 20, 2006 at 05:23:18PM +0100, Jiri Slaby wrote:

> Commit 4f2d7680cb1ac5c5a70f3ba2447d5aa5c0a1643a (Linus' 2.6 git tree) breaks my
> iptables (1.3.4):

You missed to indicate on which architecture?

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Iptables error [Was: 2.6.16-rc1-mm2]

[Benoit Boissinot]

On 1/20/06, Harald Welte <laforge@netfilter.org> wrote:
> On Fri, Jan 20, 2006 at 05:23:18PM +0100, Jiri Slaby wrote:
>
> > Commit 4f2d7680cb1ac5c5a70f3ba2447d5aa5c0a1643a (Linus' 2.6 git tree) breaks my
> > iptables (1.3.4):
>
> You missed to indicate on which architecture?

On x86 (32bits), i have the same i think:
# iptables  -L
ERROR: 0 not a valid target)
Aborted

I can provide a strace if necessary.

regards,

Benoit

Re: Iptables error [Was: 2.6.16-rc1-mm2]

[Linus Torvalds]

On Fri, 20 Jan 2006, Benoit Boissinot wrote:
> 
> On x86 (32bits), i have the same i think:

Interestingly, __alignof__(unsigned long long) is 8 these days, even 
though I think historically on x86 it was 4. Is this perhaps different in 
gcc-3 and gcc-4?

Or do I just remember wrong?

		Linus

Re: Iptables error [Was: 2.6.16-rc1-mm2]

[Harald Welte]

[-- Attachment #1.1: Type: text/plain, Size: 960 bytes --]

On Fri, Jan 20, 2006 at 11:49:46AM -0500, Linus Torvalds wrote:
> On Fri, 20 Jan 2006, Benoit Boissinot wrote:
> > 
> > On x86 (32bits), i have the same i think:
> 
> Interestingly, __alignof__(unsigned long long) is 8 these days, even 
> though I think historically on x86 it was 4. Is this perhaps different in 
> gcc-3 and gcc-4?

The problem seems to have been accidentially introduced by DaveM's
"simplification" of my original patch.

I've already asked Dave to revert his change and apply my original
patch (see attachment), which _should_ fix the problem.

Thanks,
-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #1.2: 52-x_tables-alignment.patch.patch --]
[-- Type: text/plain, Size: 2031 bytes --]

[NETFILTER] x_tables: Fix XT_ALIGN() macro on [at least] ppc32

To keep backwards compatibility with old iptables userspace programs,
the new XT_ALIGN macro always has to return the same value as IPT_ALIGN,
IP6T_ALIGN or ARPT_ALIGN in previous kernels.

However, in those kernels the macro was defined in dependency to the
respective layer3 specifi data structures, which we can no longer do with
x_tables.

The fix is an ugly kludge, but it has been tested to solve the problem. Yet
another reason to move away from the current {ip,ip6,arp,eb}tables like
data structures.

Signed-off-by: Harald Welte <laforge@netfilter.org>

---
commit 470faeb379560fe877b685ca69be6a7e4f0e91ed
tree 5732ecd9bcab28469805752514e5c57ba26189a1
parent 44718bbfa186d58477163418d37df173aa2dd079
author Harald Welte <laforge@netfilter.org> Fri, 20 Jan 2006 01:44:24 +0100
committer Harald Welte <laforge@netfilter.org> Fri, 20 Jan 2006 01:44:24 +0100

 include/linux/netfilter/x_tables.h |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h
index 472f048..65f9cd8 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -19,7 +19,20 @@ struct xt_get_revision
 /* For standard target */
 #define XT_RETURN (-NF_REPEAT - 1)
 
-#define XT_ALIGN(s) (((s) + (__alignof__(void *)-1)) & ~(__alignof__(void *)-1))
+/* this is a dummy structure to find out the alignment requirement for a struct
+ * containing all the fundamental data types that are used in ipt_entry, ip6t_entry
+ * and arpt_entry.  This sucks, and it is a hack.  It will be my personal pleasure
+ * to remove it -HW */
+struct _xt_align
+{
+	u_int8_t u8;
+	u_int16_t u16;
+	u_int32_t u32;
+	u_int64_t u64;
+};
+
+#define XT_ALIGN(s) (((s) + (__alignof__(struct _xt_align)-1)) 	\
+			& ~(__alignof__(struct _xt_align)-1))
 
 /* Standard return verdict, or do jump. */
 #define XT_STANDARD_TARGET ""

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Iptables error

[David S. Miller]

From: Harald Welte <laforge@netfilter.org>
Date: Fri, 20 Jan 2006 20:32:01 +0100

> The problem seems to have been accidentially introduced by DaveM's
> "simplification" of my original patch.
> 
> I've already asked Dave to revert his change and apply my original
> patch (see attachment), which _should_ fix the problem.

Your struct won't be 8-byte aligned either as far as I
can tell on x86_64.

We need to use the aligned_u64 thing if you want that.

Re: Iptables error

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

On Fri, Jan 20, 2006 at 11:46:13AM -0800, David S. Miller wrote:

> Your struct won't be 8-byte aligned either as far as I can tell on
> x86_64.

According to my tests, the struct is 8-byte-aligned on x86_64, and
that's how I'd like it to be. 

Please don't ask me why it happens, I know that the alignment constraint
of a u64 on x86_64 is only 4.  But at least gcc-3.3.6 and gcc-4.0.3
(debian) result in __alignof__ of that test structure (and a 'u_int64_t
alone') to 8 bytes.  

When it comes to these things, I can only do trial+error.

Maybe it's because __alignof__ returns the recommended alignment, not
the required alignment.

> We need to use the aligned_u64 thing if you want that.

That should make sure that we always get what we want, yes.  

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Iptables error

[David S. Miller]

From: Linus Torvalds <torvalds@osdl.org>
Date: Fri, 20 Jan 2006 11:49:46 -0500 (EST)

> Interestingly, __alignof__(unsigned long long) is 8 these days, even 
> though I think historically on x86 it was 4. Is this perhaps different in 
> gcc-3 and gcc-4?
> 
> Or do I just remember wrong?

I think I remember the gcc folks talking about changing this
some time long in the past, aparently they did.

Iptables error [Was: 2.6.16-rc1-mm2]

[Jiri Slaby]

Andrew Morton wrote:
>Changes since 2.6.16-rc1-mm1:
>
>
> linus.patch
Hello,

Commit 4f2d7680cb1ac5c5a70f3ba2447d5aa5c0a1643a (Linus' 2.6 git tree) breaks my
iptables (1.3.4):
# iptables -L
execve("/sbin/iptables", ["iptables", "-L"], [/* 24 vars */]) = 0
brk(0)                                  = 0x8056000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fdb000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=71332, ...}) = 0
old_mmap(NULL, 71332, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fc9000
close(3)                                = 0
open("/lib/libdl.so.2", O_RDONLY)       = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\364\273"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=16164, ...}) = 0
old_mmap(0x4103b000, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4103b000
old_mmap(0x4103d000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x4103d000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0|\236\360"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1432592, ...}) = 0
old_mmap(0x4fef5000, 1162204, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4fef5000
old_mmap(0x5000b000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x116000) = 0x5000b000
old_mmap(0x5000f000, 7132, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x5000f000
close(3)                                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fc8000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7fc86c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x4103d000, 4096, PROT_READ)   = 0
mprotect(0x5000b000, 8192, PROT_READ)   = 0
mprotect(0x4fef1000, 4096, PROT_READ)   = 0
munmap(0xb7fc9000, 71332)               = 0
socket(PF_INET, SOCK_RAW, IPPROTO_RAW)  = 3
getsockopt(3, SOL_IP, 0x40 /* IP_??? */, "filter\0\0\0\0\0\0l\216\4\10\364\317\0PL!\0\0\330\320\0"..., [84]) = 0
brk(0)                                  = 0x8056000
brk(0x8077000)                          = 0x8077000
getsockopt(3, SOL_IP, 0x41 /* IP_??? */, "filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., [656]) = 0
write(2, "ERROR: 0 not a valid target)\n", 29ERROR: 0 not a valid target)
) = 29
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
gettid()                                = 3468
tgkill(3468, 3468, SIGABRT)             = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT +++

This is it:
[NETFILTER] x_tables: Make XT_ALIGN align as strictly as necessary.

Or else we break on ppc32 and other 32-bit platforms.

Based upon a patch from Harald Welte.

Signed-off-by: David S. Miller <davem@davemloft.net>
--- include/linux/netfilter/x_tables.h
+++ include/linux/netfilter/x_tables.h
@@ -19,7 +19,7 @@ struct xt_get_revision
/* For standard target */
#define XT_RETURN (-NF_REPEAT - 1)
-#define XT_ALIGN(s) (((s) + (__alignof__(void *)-1)) & ~(__alignof__(void *)-1))
+#define XT_ALIGN(s) (((s) + (__alignof__(u_int64_t)-1)) & ~(__alignof__(u_int64_t)-1))
/* Standard return verdict, or do jump. */
#define XT_STANDARD_TARGET ""

Is there more info needed? Did I miss something?

regards,
-- 
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E

Re: Iptables error [Was: 2.6.16-rc1-mm2]

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

On Fri, 20 Jan 2006 17:23:18 +0100, Jiri Slaby said:
> Andrew Morton wrote:
> >Changes since 2.6.16-rc1-mm1:
> >
> >
> > linus.patch
> Hello,
> 
> Commit 4f2d7680cb1ac5c5a70f3ba2447d5aa5c0a1643a (Linus' 2.6 git tree) breaks my
> iptables (1.3.4):

> This is it:
> [NETFILTER] x_tables: Make XT_ALIGN align as strictly as necessary.
> 
> Or else we break on ppc32 and other 32-bit platforms.
> 
> Based upon a patch from Harald Welte.
> 
> Signed-off-by: David S. Miller <davem@davemloft.net>
> --- include/linux/netfilter/x_tables.h
> +++ include/linux/netfilter/x_tables.h
> @@ -19,7 +19,7 @@ struct xt_get_revision
> /* For standard target */
> #define XT_RETURN (-NF_REPEAT - 1)
> -#define XT_ALIGN(s) (((s) + (__alignof__(void *)-1)) & ~(__alignof__(void *)-1))
> +#define XT_ALIGN(s) (((s) + (__alignof__(u_int64_t)-1)) & ~(__alignof__(u_int64_t)-1))
> /* Standard return verdict, or do jump. */
> #define XT_STANDARD_TARGET ""

Confirmed here.  Backing out this one-liner makes iptables work for me.
i686 on a Pentium-4, gcc 4.1.0 from Fedora -devel tree.



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Iptables error

[David S. Miller]

From: Valdis.Kletnieks@vt.edu
Date: Fri, 20 Jan 2006 13:13:36 -0500

> Confirmed here.  Backing out this one-liner makes iptables work for me.
> i686 on a Pentium-4, gcc 4.1.0 from Fedora -devel tree.

Ok this is on x86.  I think I see how it breaks, but I thought
Harald's patch would have the same problem.

I just ran a test program, and indeed __alignof__() gives 8
for "long long" and 4 for a struct containing a "long long"
on x86.  Yikes...

Linus is likely about to be on his way to the airport so I'll
push the fix in New Zealand.

RE: Iptables error

[Jason Opperisano]

> This morning I rebooted one of our firewalls, I have created a new kernel for
> it (2.4.20, patched kernel with latest p-o-m ng).
> When I run my firewall script, all I get is errors, seems to be a problem with
> iptables 'tables' as none of the rules are create but the default policies
> are in place, in dmesg I have the following error:
>
> ip_tables: table screwed up!
>
> This firewall is a production server and I can only really take it down
> tonight to check it, anyone had something like this before?
>
> Paulo

sounds to me like you applied p-o-m, rebuilt your kernel, but did not rebuild your userspace.  anytime you apply a patch from pom that changes structures, or requires additional libraries, you need to recompile your userspace iptables utilities.  since it's unclear to me when the userspace rebuild is required--i do it everytime.  sounds like it was in this case for you...

-j

RE: Iptables error

[Jose Maria Lopez]

El mié, 25 de 08 de 2004 a las 14:56, Jason Opperisano escribió:
> > This morning I rebooted one of our firewalls, I have created a new kernel for
> > it (2.4.20, patched kernel with latest p-o-m ng).
> > When I run my firewall script, all I get is errors, seems to be a problem with
> > iptables 'tables' as none of the rules are create but the default policies
> > are in place, in dmesg I have the following error:
> >
> > ip_tables: table screwed up!
> >
> > This firewall is a production server and I can only really take it down
> > tonight to check it, anyone had something like this before?
> >
> > Paulo
> 
> sounds to me like you applied p-o-m, rebuilt your kernel, but did not rebuild your userspace.  anytime you apply a patch from pom that changes structures, or requires additional libraries, you need to recompile your userspace iptables utilities.  since it's unclear to me when the userspace rebuild is required--i do it everytime.  sounds like it was in this case for you...
> 
> -j
> 

I also agree the problem could be that you have not recompiled the
userspace utils, but it's strage, because I think p-o-m use to ask
for the iptables sources to be executed. Maybe you have a too old
version of iptables or maybe the p-o-m ng it's too new for your
quite old (2.4.20) kernel. Why don't updating the iptables to the
last version and also the kernel to 2.4.27 so you have to recompile
both of them?

-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
                -- Jack Kerouac, "On the Road"

Iptables error

[Paulo Andre]

This morning I rebooted one of our firewalls, I have created a new kernel for 
it (2.4.20, patched kernel with latest p-o-m ng). 
When I run my firewall script, all I get is errors, seems to be a problem with 
iptables 'tables' as none of the rules are create but the default policies 
are in place, in dmesg I have the following error:

ip_tables: table screwed up!

This firewall is a production server and I can only really take it down 
tonight to check it, anyone had something like this before?

Paulo

IPTables error

[Jerry Rasmussen]

When I try to add a command with eth1:1 get this error 'iptables -t nat
-A PREROUTING -p tcp -i $ex_dev -d 216.27.xxx.xx --dport 3389 -j DNAT
--to 192.168.xx.xxx
Warning: wierd character in interface `eth1:1' (No aliases, :, ! or *)."

I have done a good bit of Googleing I am sure there is an easy answer
that I am missing any help would be apperciated.  I need to have more
than 1 ip address on eth1

Thanks
Jerry

Re: IPTables error

[Antony Stone]

On Thursday 15 January 2004 12:08 am, Jerry Rasmussen wrote:

> When I try to add a command with eth1:1 get this error 'iptables -t nat
> -A PREROUTING -p tcp -i $ex_dev -d 216.27.xxx.xx --dport 3389 -j DNAT
> --to 192.168.xx.xxx
> Warning: wierd character in interface `eth1:1' (No aliases, :, ! or *)."
>
> I have done a good bit of Googleing I am sure there is an easy answer
> that I am missing

You are correct.   The easy answer is: "leave out the :1 on the interface 
name".

Multiple IPs are still bound to one real interface (this is more obvious if 
you use the recommended ip addr command instead of ifconfig eth1:1), and your 
netfilter rules should simply refer to the real interface which the packets 
come in on.

Antony

-- 
This email was created using 100% recycled electrons.

                                                     Please reply to the list;
                                                           please don't CC me.

iptables error

[jelenkovic]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

ok i'm having problems with the new iptables and 1.4.19 kernel.
here is the log error:
Nov 11 04:55:29 BAKER kernel: ASSERT ip_conntrack_core.c:1063 &ip_conntrack_lock not readlocked
Nov 11 04:55:29 BAKER kernel: ASSERT: ip_nat_core.c:839 &ip_conntrack_lock not readlocked

and then this is what happens later at some point:
Nov 11 20:57:58 BAKER kernel: IPTABLES Dead Input: IN=eth0 OUT= MAC=00:50:04:55:d1:a4:00:02:4b:13:33:60:08:00 SRC=213.250.59.123 DST=************ LEN=48 TOS=0x00 PREC=0x00 TTL=125 ID=19471 DF PROTO=TCP SPT=4682 DPT=10 WINDOW=16384 RES=0x00 SYN URGP=0 

notice that the destination port is 10.it shows that for all ports i think?
this was logged when i tried to use the web server.
so it should have recognized port 80 and not logged anything.
I've seen other ppl having the same problem (searched google) but no one knows what the problem might be.

any ideas?

[-- Attachment #2: Type: text/html, Size: 1767 bytes --]