NFS: rpcsec_gss with Linux clients

[Attila Bogár]

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/