ip_conntrack_in: Frag of proto 17

ip_conntrack_in: Frag of proto 17

[Tim Rhodes]

Is there any additional information/understanding of this condition. 
I've found some hits of 2.6.x kernels generating this message for
nfs/sfs.  I'm running a couple of systems (now running 2.6.7 kernel)
that run JBoss with replication.  These UDP connections are generating
these messages.  

One note referenced exceeding the block size that conntrack can handle.
Is there and if so, what's the limit.  The ip_conntrack_core.c code that
generates this message ANDs the frag offset with 8191.
-- 
.. Tim Rhodes  ........................................  Tim.Rhodes@vt.edu
.. NIS-Systems Support, Virginia Tech  ..  http://rhodes.cc.vt.edu/~rhodes

Re: ip_conntrack_in: Frag of proto 17

[Sander Smeenk]

Quoting Tim Rhodes (rhodes@vt.edu):

> Is there any additional information/understanding of this condition. 

It has to do with the size of UDP packets, as I understood. The packets
can not exceed 8K in size or ip_conntrack_in starts messing up.

You can test this by mounting an nfs share locally, and play with
rsize/wsize parameters.

> Is there and if so, what's the limit.

There is. 8K. Exceed that and it will fail.

What I don't understand is WHY this limit suddenly appeared, and why
there's so little discussion about it. I think this is a really big
problem, since not all tools that do UDP can (easily) be told to use
blocks of <= 8192 bytes. For example, my sfs shares are now completely
useless, which bites me ever since I switched to kernels >2.6.5.

Yet, nobody knows why this change was made, or what can be done to work
around it. I *HAD* a working solution: no udp tracking:
	ipv4 -t raw -A PREROUTING -p udp -j NOTRACK
	ipv4 -A FORWARD -m state --state UNTRACKED -j ACCEPT
but that stopped working with kernels >2.6.7.

So, can anyone from the netfilter-dev team shed some light?

Thanks,
Sander.
-- 
| There's nothing like waking up with your Dickin's Cider!
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8  9BDB D463 7E41 08CE C94D