Re: ip_conntrack_in: Frag of proto 17

[Sander Smeenk <ssmeenk+netfilter@freshdot.net>]

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