Date: Mon, 24 Sep 2012 12:29:15 +0100 From: =?UTF-8?B?QXR0aWxhIEJvZ8Ohcg==?= <attila.bogar@linguamatics.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs@FreeBSD.org Subject: Re: NFS: rpcsec_gss with Linux clients Message-ID: <5060440B.2020009@linguamatics.com> In-Reply-To: <817398955.1415204.1346543870350.JavaMail.root@erie.cs.uoguelph.ca> References: <817398955.1415204.1346543870350.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5060440B.2020009>