All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Harald Welte <laforge@gnumonks.org>
Cc: William Stearns <wstearns@pobox.com>,
	ML-netfilter-devel <netfilter-devel@lists.netfilter.org>,
	Lars Knudsen <gandalfit@virgilio.it>
Subject: Re: Bug with netfilter and NFS server on same machine (fwd)
Date: Fri, 06 Dec 2002 01:56:18 +0100	[thread overview]
Message-ID: <3DEFF5B2.1050106@trash.net> (raw)
In-Reply-To: <20021205202119.GH11068@naboo.club.berlin.ccc.de>

Hi,

Harald Welte wrote:

>On Sat, Nov 23, 2002 at 01:44:45PM -0500, William Stearns wrote:
>  
>
>>Good day, Lars,
>>	Whether or not the netfilter list was able to find an answer, it 
>>might still make sense to CC that list.
>>    
>>
>
>yup, definitely.
>
>  
>
>>The problem is this: A machine running linux 2.4.18 or 2.4.19 works just 
>>fine when running just the kernel nfsd. A single client connected to the 
>>server with 100Mbit ethernet sees throughput of 5-10MByte/sec even after 
>>an hour or two of continous transfers. If the nfs server is also running 
>>iptables the throughput is initially the same (5-10MByte/sec) but after 
>>a while (200MByte-500MByte total transfer) the client starts reporting 
>>"nfs server not responding" followed after a while by "nfs server OK" 
>>and of course the transfer rate goes way down (< 1MByte/sec). Using 
>>tcpdump on the client seems to indicate that some packets have their 
>>headers garbled - wrong fragment ids being the typical error.
>>    
>>
>
>this sounds like a problem with nfs's exceptionally large packet size
>(up to 8k) and the resulting udp fragments, which need to get
>defragmented and refragmented while conntrack is done.
>
I experienced the same problem since almost 6 months with nfs and netfilter,
nfs was veery slow, it wasn't even possible to listen to mp3s over nfs.
removing the conntrack module made it work normal again.
the client ringbuffers fills with
UDP: short packet: 192.168.0.1:55258 58191/236 to 192.168.0.23:55789
UDP: short packet: 192.168.0.1:12966 57456/236 to 192.168.0.23:1590
UDP: short packet: 192.168.0.1:41383 20796/236 to 192.168.0.23:32904
while conntrack module is loaded.
i placed a lot of printk's in conntrack and ip_fragment but couldn find 
any pointers
where the problem might be. interesting might be that changing the mtu 
of the
interface to 1486 works well, even with conntrack loaded .. while 
without conntrack 1500 is ok.

>
>Apart from that I don't have any idea.  I run lots of linux nfs servers
>on machines which have conntrack running, without ever encountering the
>problem you are describing.  There has to be something special about
>your setup(s) we are missing here.
>
>Any idea?
>
>Thanks.
>
>  
>
>>\Lars Knudsen
>>    
>>
>
>  
>
bye,
patrick

  reply	other threads:[~2002-12-06  0:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-23 18:44 Bug with netfilter and NFS server on same machine (fwd) William Stearns
2002-12-05 20:21 ` Harald Welte
2002-12-06  0:56   ` Patrick McHardy [this message]
2002-12-09 14:18     ` Harald Welte
2002-12-09 15:17       ` Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DEFF5B2.1050106@trash.net \
    --to=kaber@trash.net \
    --cc=gandalfit@virgilio.it \
    --cc=laforge@gnumonks.org \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=wstearns@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.