2.6.6-rc3 - "ip_conntrack_in: Frag of proto 17" (udp) with kNFS r/wsize > 8192

2.6.6-rc3 - "ip_conntrack_in: Frag of proto 17" (udp) with kNFS r/wsize > 8192

[Kenneth Aafløy]

Hi!

I hope this problem has not been reported before or that I'm not just picking 
up on some user-keyboard troubles, I've read over the archives, but could not 
find anything relevat to this issue.

I've come across some strange behavior with a nfs server running on 2.6.6-rc3 
today. My clients is also running this version. Basically when I set the NFS 
client r/wsize = 8192, or remove the connection tracking netfilter modules 
the problem goes away. If I set the r/wsize to 16834 and the conntrack module 
is loaded I end up in the code segment below. When this happens the NFS 
client will almost lose connection with the server, and print a lot of;
NFS server not responding, still trying. NFS server OK.

I've also tried 2.6.5, and the error is present there too, but not the segment 
below, so I got no warning. I have not yet tried any lower version of the 
kernel yet, but will do so if it's requested. I could also have provided you 
with extensive information about my setup's, but I belive it's a minor 
problem with the reassembly of fragmented packets. 

ip_conntrack_core.c:798
    /* Never happen */
    if ((*pskb)->nh.iph->frag_off & htons(IP_OFFSET)) {
        if (net_ratelimit()) {
        printk(KERN_ERR "ip_conntrack_in: Frag of proto %u (hook=%u)\n",
               (*pskb)->nh.iph->protocol, hooknum);
        }
        return NF_DROP;
    }

Does anybody have a solution for the problem exept making (manually) sure that 
any client does not request a r/wsize above 8192?

Kenneth

Re: 2.6.6-rc3 - "ip_conntrack_in: Frag of proto 17" (udp) with kNFS r/wsize > 8192

[Martijn Lievaart]

Kenneth Aafløy wrote:

>Hi!
>
>I hope this problem has not been reported before or that I'm not just picking
>up on some user-keyboard troubles, I've read over the archives, but could not
>find anything relevat to this issue.
>
>I've come across some strange behavior with a nfs server running on 2.6.6-rc3
>today. My clients is also running this version. Basically when I set the NFS
>client r/wsize = 8192, or remove the connection tracking netfilter modules
>the problem goes away. If I set the r/wsize to 16834 and the conntrack module
>is loaded I end up in the code segment below. When this happens the NFS
>client will almost lose connection with the server, and print a lot of;
>NFS server not responding, still trying. NFS server OK.
>
>

I'm seeing this to on a 2.4.22 kernel. I didn't change anything on the
r/wsize, so I have the default of 4096, I think. Both have conntrack loaded.

Martijn Lievaart

Re: 2.6.6-rc3 - "ip_conntrack_in: Frag of proto 17" (udp) with kNFS r/wsize > 8192

[Martin Josefsson]

On Fri, 7 May 2004, Kenneth Aafløy wrote:

> Hi!
>
> I hope this problem has not been reported before or that I'm not just picking
> up on some user-keyboard troubles, I've read over the archives, but could not
> find anything relevat to this issue.
>
> I've come across some strange behavior with a nfs server running on 2.6.6-rc3
> today. My clients is also running this version. Basically when I set the NFS
> client r/wsize = 8192, or remove the connection tracking netfilter modules
> the problem goes away. If I set the r/wsize to 16834 and the conntrack module
> is loaded I end up in the code segment below. When this happens the NFS
> client will almost lose connection with the server, and print a lot of;
> NFS server not responding, still trying. NFS server OK.
>
> I've also tried 2.6.5, and the error is present there too, but not the segment
> below, so I got no warning. I have not yet tried any lower version of the
> kernel yet, but will do so if it's requested. I could also have provided you
> with extensive information about my setup's, but I belive it's a minor
> problem with the reassembly of fragmented packets.
>
> ip_conntrack_core.c:798
>     /* Never happen */
>     if ((*pskb)->nh.iph->frag_off & htons(IP_OFFSET)) {
>         if (net_ratelimit()) {
>         printk(KERN_ERR "ip_conntrack_in: Frag of proto %u (hook=%u)\n",
>                (*pskb)->nh.iph->protocol, hooknum);
>         }
>         return NF_DROP;
>     }
>
> Does anybody have a solution for the problem exept making (manually) sure that
> any client does not request a r/wsize above 8192?

Could you test this patch? If it triggers we know that we still have
fragmented packets after defrag, which we shouldn't.

--- linux-2.6.6-rc3/net/ipv4/netfilter/ip_conntrack_standalone.c.orig	2004-05-07 12:22:36.000000000 +0200
+++ linux-2.6.6-rc3/net/ipv4/netfilter/ip_conntrack_standalone.c	2004-05-07 12:24:37.000000000 +0200
@@ -211,6 +211,10 @@
 		if (!*pskb)
 			return NF_STOLEN;
 	}
+
+	if ((*pskb)->nh.iph->frag_off & htons(IP_MF|IP_OFFSET))
+		printk(KERN_ERR "ip_conntrack_defrag: packet still fragmented after defrag!\n");
+
 	return NF_ACCEPT;
 }

/Martin

Re: 2.6.6-rc3 - "ip_conntrack_in: Frag of proto 17" (udp) with kNFS r/wsize > 8192

[Kenneth Aafløy]

On Friday 07 May 2004 12:30, Martin Josefsson wrote:
> On Fri, 7 May 2004, Kenneth Aafløy wrote:
> > I've come across some strange behavior with a nfs server running on
> > 2.6.6-rc3 today.
[snip]
> > NFS server not responding, still trying. NFS server OK.
[snip]
> Could you test this patch? If it triggers we know that we still have
> fragmented packets after defrag, which we shouldn't.

This patch does not trigger any suspicious behaviour. I also have done some 
additional testing (must have been half asleep last time), and I've found 
that I only end up in the "ip_conntrack_in: Frag of proto %u" code if I mount 
a nfs share locally, and that this local share will stall completly if the 
conntrack module is loaded. If I mount the share from a remote client, it 
will work just fine. Is this a bug or just me doing to little reading?

About the slowness of NFS from remote clients, this is just because the 
default r/wsize is to high for the wireless card I was using. Sorry for not 
checking more thoroughly and not reading the HOWTOs!

Kenneth