From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 11:35:29 2012 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 776121065670 for ; Mon, 24 Sep 2012 11:35:29 +0000 (UTC) (envelope-from attila.bogar@linguamatics.com) Received: from mail.linguamatics.com (mail.linguamatics.com [188.39.80.203]) by mx1.freebsd.org (Postfix) with ESMTP id E89218FC17 for ; Mon, 24 Sep 2012 11:35:28 +0000 (UTC) Received: from [10.252.10.232] (random.linguamatics.com [10.252.10.232]) by mail.linguamatics.com (Postfix) with ESMTPSA id 3966FEFB450; Mon, 24 Sep 2012 12:29:14 +0100 (BST) Message-ID: <5060440B.2020009@linguamatics.com> Date: Mon, 24 Sep 2012 12:29:15 +0100 From: =?UTF-8?B?QXR0aWxhIEJvZ8Ohcg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Rick Macklem References: <817398955.1415204.1346543870350.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <817398955.1415204.1346543870350.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@FreeBSD.org Subject: Re: NFS: rpcsec_gss with Linux clients 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: Mon, 24 Sep 2012 11:35:29 -0000 Hi Rick, On 02/09/12 00:57, Rick Macklem wrote: > This certainly sounds bogus. I can see an argument for 2 TCP > connections for trunking, but since a security context should only be > destroyed when the client is done with it, doing a DESTROY doesn't > make sense? (There is something in the RPC header called a "handle". > It identifies the security context, and it would be nice to check the > wireshark trace to see if it the same as the one being used on the > other connection?) The Linux guys say this is a bug in Linux: http://www.spinics.net/lists/linux-nfs/msg32466.html I'm going to open a bug with Red Hat and test the upstream linux kernel + nfs-utils against this bug. As per their message it's also interesting why the rpcsec destroy mic evaluates to GSS_S_DEFECTIVE_TOKEN. This is the 2nd root of the original problem. > That would indicate the encrypted checksum isn't correct. It > might be using an algorithm only supported by the newer RPCSEC_GSS_V3? If I check the trace with wireshark 1.4.6 it reports rpc malformed packet. However if I check the trace with the newest 1.8.2 it's OK (could be a bug in wireshark, though). Anyway it says rpc version 2 and gss version 1. > I've attached a small patch with disables setting client->cl_state to > CLIENT_STALE for this case, which you could try, to see if it helps? Yep, it works perfectly. Confirmed. Please go ahead to commit and merge to stable. Attila -- Attila Bogár Systems Administrator Linguamatics - Cambridge, UK http://www.linguamatics.com/