From owner-freebsd-fs@FreeBSD.ORG Mon Sep 24 12:38:52 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 346241065672 for ; Mon, 24 Sep 2012 12:38:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id E0F468FC0A for ; Mon, 24 Sep 2012 12:38:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKpTYFCDaFvO/2dsb2JhbABFhgu5OoIgAQEBAwEBAiAEUgUWBxECAg0ZAiovBogSBgulR5IzgSGPE4ESA5M4gi2JN4ZsgwOBew X-IronPort-AV: E=Sophos;i="4.80,475,1344225600"; d="scan'208";a="182962344" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 24 Sep 2012 08:38:19 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 782A0B4031; Mon, 24 Sep 2012 08:38:19 -0400 (EDT) Date: Mon, 24 Sep 2012 08:38:19 -0400 (EDT) From: Rick Macklem To: =?utf-8?Q?Attila_Bog=C3=A1r?= Message-ID: <1411662865.1073866.1348490299472.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <5060440B.2020009@linguamatics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) 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 12:38:52 -0000 Attila Bogar wrote: > Hi Rick, >=20 > On 02/09/12 00:57, Rick Macklem wrote: >=20 >=20 > 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 >=20 > I'm going to open a bug with Red Hat and test the upstream linux > kernel + nfs-utils against this bug. >=20 > 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. >=20 > 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. >=20 >=20 >=20 > 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. >=20 Ok, thanks for testing it. I am waiting for a review from dfr@, but will get it committed soon. Have a good week, rick > Attila > -- > Attila Bog=C3=A1r > Systems Administrator > Linguamatics - Cambridge, UK http://www.linguamatics.com/