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 hang indefinitely Version-Release number of selected component (if applicable): How reproducible: Always 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 dmesg contains: 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. Additional info: 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 as inconsistent. 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: http://marc.theaimsgroup.com/?t=103762623600004&r=1&w=2 http://marc.theaimsgroup.com/?l=linux-nfs&m=102781264327764&w=2
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 happy.
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).