From owner-freebsd-fs@FreeBSD.ORG Sun Dec 5 14:17:45 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 175C0106564A for ; Sun, 5 Dec 2010 14:17:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C39C08FC08 for ; Sun, 5 Dec 2010 14:17:44 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAG4t+0yDaFvO/2dsb2JhbACDT6BTrR6PZYEhgzVzBIRfhg8 X-IronPort-AV: E=Sophos;i="4.59,302,1288584000"; d="scan'208";a="103115640" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Dec 2010 09:17:43 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A3EB1B3E95; Sun, 5 Dec 2010 09:17:43 -0500 (EST) Date: Sun, 5 Dec 2010 09:17:43 -0500 (EST) From: Rick Macklem To: =?utf-8?Q?Tom=C3=A1=C5=A1_Drbohlav?= Message-ID: <466626878.1184716.1291558663551.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4CF8CC96.3040901@karlov.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [174.114.46.215] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-fs@freebsd.org Subject: Re: Linux (client) - FreeBSD (server) NFS4 interoperability problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 14:17:45 -0000 > >> > >> Although I am not an nfs expert, when I opened the dump in > >> WireShark > >> it > >> seems to me, that server does not respond to packet #83, Compound > >> Call > >> containing OPEN opcode. That is probably the thing which disturbes > >> Linux > >> client. But why? It is beyond my capabilities. > >> > >> What can I do to make i work? Is it me or server, who si broken? > >> > > I'll take a look at the packet dump when I get home in a couple of > > days. > > Thank, we appreciate any help! > > > The main thing I'd suggest is trying a non-Kerberized NFSv4 > > mount from Linux->FreeBSD and see how that does? > > Looks almost the same to me. Attaching dump/ Ok, I took a look at the dump and it's kinda interesting. Here's what happens: - Linux client does a SetclientID (#51) specifying a callback via TCP at port 37372. - When client does an Open at #53, the server tries to establish a TCP connection for the callback. (See SYN packets #56, 58-64, 72) - The Linux client does not respond to these SYNs. - At #70, client gives up waiting for the Open reply (which hasn't happened yet because the server hasn't timed out on the TCP connect for the callback) and disconnects the main TCP NFS connection. So, I can think of a couple of ways this can be worked around. 1 - Figure out why the client isn't responding too the SYNs for the callback path and fix it so it connects. (Is port 37372 somehow blocked for the client?) 2 - Disable the server from attempting to do a callback connection even when the client advertises one. (At the moment this can only be done for Kerberized mounts by setting nfsrv_nogsscallback == 1 in sys/fs/nfsserver/nfs_nfsdstate.c. (Maybe I should add a sysctl to disable callback attempts?) 3 - Reconfiguring the client so that it doesn't advertise a callback path. (I have no idea how to do this for Linux, but there is a nfsv4@linux-nfs.org email list where someone might be able to help with doing this?) Basically, it's hard to say if the bug is the server trying to establish the callback TCP connection for too long or the client not waiting long enough for the Open Reply. (The server will eventually give up on trying to establish the callback TCP connection and will then reply to the client. It could also be argued that the server should reply NFS4ERR_DELAY to the Open request while it is trying to establish the TCP connection, if it doesn't happen quickly.) I'll look at the timeout for the callback TCP connect and see if I can make it smaller easily. Not having a callback path doesn't break NFSv4, it just disables issuing of delegations, which aren't currently enabled by default in the FreeBSD server at this time anyhow. If I can come up with a simple patch to reduce the timeout on the TCP connect for the callback, I'll email you that for testing. rick