Fw: [Bug 133788] New: ip_conntrack_in: Frag of proto 17

[Harald Welte]

On Tue, Sep 28, 2004 at 01:05:12PM -0700, David S. Miller wrote:
 
> If this is true, we need to fix this soon.

Agreed.  

I think I've seen something similar in the past, though it was some
broken code in my experimental tree ;). ip_conntrack on an NFS server
has always had a bad history, I have to admit :(

Big question number 1:
First of all, why would a local loopback nfs mount do any fragmenting
in the first place?  'lo' has a MTU of 16k, so why would any piece of
code in the output path build fragments, even with rsize/wsize=8192?

The conntrack message basically means that at NF_IP_PRE_ROUTING we
suddenly see fragmented packets.  This "can never happen" since at the
same PRE_ROUTING hook we defragment just before
via ip_conntrack_defrag() -> ip_ct_gather_frags() -> ip_defrag()

Big question number 2:
How can a fragment survive ip_defrag() ?

Big question number 3:
What is this magic 8k limit?  ip_conntrack doesn't impose any arbitrary
size limitations to packets... and we just use the normal
defragmentation code.

I'm more than puzzled about this, need to do some testing.

-- 
- Harald Welte <laforge at netfilter.org>             http://www.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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/netfilter-devel/attachments/20040929/b939f39a/attachment.bin