Red Hat Bugzilla – Bug 58084
NFS client hangs
Last modified: 2007-04-18 12:38:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226
Description of problem:
When connecting to a OpenBSD 3.0 NFS server, writes to NFS mounted files will
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Mount a OpenBSD exported NFS volume
2.Attempt to write to a files
Actual Results: The write blocks with the process stuck in a 'D' state. The
nfs: server shitei not responding, still trying
nfs: task 16 can't get a request slot
(shitei being my NFS server)
Nothing is logged at the server end.
Expected Results: The write should complete normally.
Redhat 6.2 doesn't have this problem.
Forgot to mention, I am using kernel-2.4.9-13.i686.rpm
I eventually figured this out: Linux NFS sends fragmented UDP packets with the
DontFragment bit set. OpenBSD's packet filter (rightly IMO) drops these packets
The workaround is to turn off packet normalisation for effected hosts. Another
is to turn off pmtu discovery on the Linux end.
The fix would be to make Linux NFS send consistent packets.
Some threads discussing this:
fragmented UDP packets with the DF flag set are completely valid and actually
the only way to do pmtu discovery over udp......
No, this is incorrect. RFC1191 even explicitly talks about the NFS case:
Also, since a single NFS operation cannot be split across several UDP
datagrams, certain operations (primarily, those operating on file
names and directories) require a minimum datagram size that may be
larger than the PMTU. NFS implementations should not reduce the
datagram size below this threshold, even if PMTU Discovery suggests a
lower value. (Of course, in this case datagrams should not be sent
with DF set.)
(section 6.5, page 14)
RFCs are not laws that cannot be broken when common sense must
prevail. For example, nobody currently ships a system that
does RFC compliant URG handling, you wouldn't be able to talk
to any other stack if that were the case.
And common sense here dictates that without being able to set
DF on fragmented frames, UDP path mtu discovery is basically
impossible and at best useless.
The behavior stands, and it will not be changed. These weird BSD firewalls are
the only systems blocking these packets, and I'm not going to
give up UDP pmtu discovery for the sake of making these systems
Based on your feedback, OpenBSD's packet filter has been changed so fragments with DF can be passed, even if normalization/reassembly is enabled.
The option is disabled by default, as fragments with DF are not unanimously accepted as legitimate and unambiguous traffic. But we acknowledge that they are used with certain UDP protocols (when PMTU discovery is used) and recommend enabling the option to pass them selectively.
With release 3.0 to 3.2, the fragments can be passed by disabling normalization/reassembly ('scrub') for the relevant UDP traffic, and future releases include the option to pass such fragments in all combinations with scrub.
Further questions can be directed to the OpenBSD mailing lists (http://www.openbsd.org/mail.html).