headers
Yasuyuki KOZAKAI | 1 Dec 2006 05:14
Picon

Re: nf_conntrack allocation issue

From: Patrick McHardy <kaber <at> trash.net>
Date: Thu, 30 Nov 2006 16:45:19 +0100

> I've added these three patches to fix the allocation problems.
> I don't want to add the new module option introduced by
> Jozsef's patch since the current situation is just ridiculous,
> we need to search for both helpers and expectations twice for
> every new connection, so this needs to be redesigned anyway.

I agree.

> It seems to work fine in some quick testing. This was the
> last problem I'm aware of, so I'm probably going to push
> all patches soon.
> 
> Last thing is the helper renaming, any objections to prefix
> all helpers with nf_conntrack_helper_?

no objection.

-- Yasuyuki Kozakai
Permalink | Reply | 0 comments |
headers
David Miller | 1 Dec 2006 05:22
Favicon

Re: Broken commit: [NETFILTER]: ipt_REJECT: remove largely duplicate route_reverse function

From: Herbert Xu <herbert <at> gondor.apana.org.au>
Date: Wed, 29 Nov 2006 17:51:46 +1100

> I'm just emphasising that LL_MAX_HEADER is by no means the *maximum*
> header size in a Linux system.

But it is the maximum "link level" singular header size.

It is MAX_HEADER which is the hack and the main issue.

What MAX_HEADER's setting is trying to do is optimistically allocate
enough for a single level of tunnelling.  It does not handle nested
tunneling at all, of course.

> As to getting rid of those ifdefs, here is one idea.  We keep a
> read-mostly global variable that represents the actual current
> maximum LL header size.  Everytime a new device appears (or if
> its hard header size changes) we update this variable if needed.
> 
> Hmm, we don't actually update the hard header size should the
> underlying device change for tunnels.  Good thing the tunnels
> only use that as a hint and reallocate if necessary :)
> 
> This is not optimal in that it never decreases, but it's certainly
> better than a compile-time constant (e.g., people using distribution
> kernels don't necessarily use tunnels).

I like this idea for the most part.  It also deals nicely with, as you
alude to, how the MAX_HEADER scheme uses the space even if you don't
configure any tunnels at all.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Herbert Xu | 1 Dec 2006 05:37
Picon
Picon

Re: Broken commit: [NETFILTER]: ipt_REJECT: remove largely duplicate route_reverse function

On Thu, Nov 30, 2006 at 08:22:06PM -0800, David Miller wrote:
> 
> What MAX_HEADER's setting is trying to do is optimistically allocate
> enough for a single level of tunnelling.  It does not handle nested
> tunneling at all, of course.

Agreed, I should've said MAX_HEADER.

> Actually, I wonder how antiquated this all is.  I bet we could get rid
> of MAX_HEADER, then if we have to realloc headroom, we adjust some
> per-device header thing which will behave like your global value idea
> does.  On the next allocation, we'll do the right thing.  Although I
> cannot come up with a scheme that works without reintroducing another
> net_device pointer to sk_buff, which seems necessary to handle arbitrary
> nesting. :-/

Actually the scarier part is that TCP as well as ip_route_me_harder
doesn't guarantee enough headroom for IPsec.  Fortunately TCP reserves
enough room (128 bytes) by default that it's unlikely to break with
non-nested IPsec.  But it's still pretty nasty.

So in general when allocating packets we have two scenarios:

1) The dst is known and fixed, i.e., all datagram protocols.  This is
the easy case where the headroom is known exactly beforehand.

2) The dst is unknown or may vary, this includes TCP, SCTP and DCCP.
This is where we currently use MAX_HEADER plus some protocol-specific
headroom.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jozsef Kadlecsik | 1 Dec 2006 09:38
Picon

Re: nf_conntrack allocation issue

Hi Patrick,

On Thu, 30 Nov 2006, Patrick McHardy wrote:

> I've added these three patches to fix the allocation problems.
> I don't want to add the new module option introduced by
> Jozsef's patch since the current situation is just ridiculous,

In your patch the part

--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
 <at>  <at>  -579,7 +579,8  <at>  <at>  __nf_conntrack_alloc(const struct nf_con
        /* FIXME: protect helper list per RCU */
        read_lock_bh(&nf_conntrack_lock);
        helper = __nf_ct_helper_find(repl);
-       if (helper)
+       /* NAT might want to assign a helper later */
+       if (helper || features & NF_CT_F_NAT)
                features |= NF_CT_F_HELP;
        read_unlock_bh(&nf_conntrack_lock);

means that in the IPv4+NAT case we loose what we wanted to gain by the 
features, i.e. for IPv4 with NAT all conntrack entries will be full sized.

> we need to search for both helpers and expectations twice for
> every new connection, so this needs to be redesigned anyway.

As I see this is the price we pay for the features.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Retesh | 1 Dec 2006 12:36
Picon

hashlimit not working in iptable chains

Hi All
I am having a scenario where the iptables hashlimit feature is not
working as expected. Following is the list of IP rules

INPUT (policy ACCEPT 1342 packets, 488K bytes)
1840  755K TEST       all  --  any    any     anywhere             anywhere

TEST (1 references)
0     0 CHAIN2     all  --  any    any     anywhere
anywhere            set SET2 dst
1840  755K CHAIN1     all  --  any    any     anywhere
anywhere            set SET1 dst

CHAIN1 (1 references)
919  375K ACCEPT     all  --  any    any     anywhere
anywhere            limit: avg 200/sec burst 10 mode dstip
921  380K LOG        all  --  any    any     anywhere
anywhere            LOG level warning prefix `_SET1'

CHAIN2 (1 references)
0     0 ACCEPT     all  --  any    any     anywhere
anywhere            limit: avg 50/sec burst 10 mode dstip
0     0 LOG        all  --  any    any     anywhere
anywhere            LOG level warning prefix `_SET2'

Here, SET1 and SET2 are iphash

Now after applying the above rules, irrespective of which set (SET1 or
SET2), I send the packets from I find that the limit that is used is
50/s, even though there are different chains for different sets. That
(Continue reading)

Permalink | Reply | 2 comments |
headers
Arnaud Fontaine | 1 Dec 2006 13:00
Favicon

libipt_multiport: getsockopt failed strangely: Invalid argument

Hello,

When I try to use the '-m multiport' argument, I have the following
error message:

# /sbin/iptables -A INPUT -p tcp -m multiport --sports \
                 ssh,www,imap2,pop3,domain,https,smtp,auth -m state \
                  --state NEW,ESTABLISHED,RELATED -j ACCEPT
getsockopt failed strangely: Invalid argument

strace results:

munmap(0xf7fde000, 8192)                = 0
open("/lib/iptables/libipt_multiport.so", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0\10"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9208, ...}) = 0
mmap(NULL, 73704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7dc0000
mprotect(0xf7dc2000, 65512, PROT_NONE)  = 0
mmap(0xf7dd0000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0) = 0xf7dd0000
close(3)                                = 0
socket(PF_INET, SOCK_RAW, IPPROTO_RAW)  = 3
getsockopt(3, SOL_IP, 0x42 /* IP_??? */, 0xff565346, 0xff565364) = -1 EINVAL (Invalid argument)
write(2, "getsockopt failed strangely: Inv"..., 46getsockopt failed strangely: Invalid argument) = 46                             

This error happens only with 2.6.17 and 2.6.18, using 2.6.15 it works
fine. I don't know at all how I could identify the problem. I'm using
Debian GNU/Linux with sparc64-smp Linux kernel and iptables 1.3.6. I
hope that i have sent this mail to the proper mailing list.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Patrick McHardy | 1 Dec 2006 14:11
Favicon

Re: nf_conntrack allocation issue

Jozsef Kadlecsik wrote:
> Hi Patrick,
> 
> In your patch the part
> 
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
>  <at>  <at>  -579,7 +579,8  <at>  <at>  __nf_conntrack_alloc(const struct nf_con
>         /* FIXME: protect helper list per RCU */
>         read_lock_bh(&nf_conntrack_lock);
>         helper = __nf_ct_helper_find(repl);
> -       if (helper)
> +       /* NAT might want to assign a helper later */
> +       if (helper || features & NF_CT_F_NAT)
>                 features |= NF_CT_F_HELP;
>         read_unlock_bh(&nf_conntrack_lock);
>  
> means that in the IPv4+NAT case we loose what we wanted to gain by the 
> features, i.e. for IPv4 with NAT all conntrack entries will be full sized.

Yes - actually that part is similar to your patch besides the
keep_helper option.

>>we need to search for both helpers and expectations twice for
>>every new connection, so this needs to be redesigned anyway.
> 
> 
> As I see this is the price we pay for the features.

I see it as a sign of serious misfit of the allocation scheme.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jozsef Kadlecsik | 1 Dec 2006 16:07
Picon

Re: nf_conntrack allocation issue

On Fri, 1 Dec 2006, Patrick McHardy wrote:

[...]  
> The reason why I didn't want to add it is that IMO the allocation
> scheme needs to be redesigned anyway, so when we do it we might end
> up with a module parameter we had for two months and need to carry
> around forever. We can still add it any time we want, but for now
> my priority is to get it right (i.e. working properly, not
> optimized) without doing anything we might regret later. Module
> parameters for rather obscure internal stuff tend not to get used
> anyway, so most users don't loose anything.

You're right. And that double lookup is truly horrid, we'll have to find a 
way to eliminate.

Best regards,
Jozsef
-
E-mail  : kadlec <at> blackhole.kfki.hu, kadlec <at> sunserv.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
Permalink | Reply | 0 comments |
headers
ArcosCom Linux User | 1 Dec 2006 16:19
Favicon

ROUTE target broken under 2.6.18.3 kernel

I had problems with 2.6.19 kernel, appears to be some "binaries" problems
about iptables and kernel modules, then I pass to try the 2.6.18.3 kernel
to tests some things.

When I put -j ROUTE into -t mangle table and PREROUTING chain, I have no
problems, but when I try -j ROUTE into POSTROUTING chain, my system loss
all network access (and it is posible it crash, I'm not there to view
screen).

My system has:
   SMP kernel (dual Xeon 3,0 GHz)
   2.6.18.3 kernel + connlimit + layer7 + ROUTE patches
   1.3.5 iptables (FC5 distro sources) with connlimit + layer7 + ROUTE
patches (as I see, I only need change the makefile into distro sources
to allow connlimit and ROUTE work)

The command that break off network (and posibility crash the machine) is:

iptables -t mangle -A POSTROUTING -p tcp --dport msnp -j ROUTE --gw <mygw>
--continue

I have 2 uplinks with 2 diferents gw ip's, and I detected disconnection
problems with messenger clients (amsn, windows msn, msn-messenger, gaim,
etc....) and I only want to route all msn traffic into only one uplink.

Any help about this? It is really a bug with ROUTE Patch and 2.6.8.3
kernel? Or its a bug with the 1.3.5 iptables version (FC5 distro sources).

Please, help me a bit to solve this problem.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick McHardy | 1 Dec 2006 17:24
Favicon

Re: libipt_multiport: getsockopt failed strangely: Invalid argument

Arnaud Fontaine wrote:
> Hello,
> 
> When I try to use the '-m multiport' argument, I have the following
> error message:
> 
> # /sbin/iptables -A INPUT -p tcp -m multiport --sports \
>                  ssh,www,imap2,pop3,domain,https,smtp,auth -m state \
>                   --state NEW,ESTABLISHED,RELATED -j ACCEPT
> getsockopt failed strangely: Invalid argument
> 
> strace results:
> 
> munmap(0xf7fde000, 8192)                = 0
> open("/lib/iptables/libipt_multiport.so", O_RDONLY) = 3
> read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0\10"..., 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=9208, ...}) = 0
> mmap(NULL, 73704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7dc0000
> mprotect(0xf7dc2000, 65512, PROT_NONE)  = 0
> mmap(0xf7dd0000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE,
3, 0) = 0xf7dd0000
> close(3)                                = 0
> socket(PF_INET, SOCK_RAW, IPPROTO_RAW)  = 3
> getsockopt(3, SOL_IP, 0x42 /* IP_??? */, 0xff565346, 0xff565364) = -1 EINVAL (Invalid argument)
> write(2, "getsockopt failed strangely: Inv"..., 46getsockopt failed strangely: Invalid argument) =
46                             
> 
> This error happens only with 2.6.17 and 2.6.18, using 2.6.15 it works
> fine. I don't know at all how I could identify the problem. I'm using
> Debian GNU/Linux with sparc64-smp Linux kernel and iptables 1.3.6. I
(Continue reading)

Permalink | Reply | 3 comments |

Gmane