Fw: [Bug 133788] New: ip_conntrack_in: Frag of proto 17
laforge at netfilter.org
Wed Sep 29 00:05:32 CEST 2004
On Tue, Sep 28, 2004 at 01:05:12PM -0700, David S. Miller wrote:
> If this is true, we need to fix this soon.
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
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
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/netfilter-devel/attachments/20040929/b939f39a/attachment.bin
More information about the netfilter-devel