Hi,
I'm new on this list, this is my first post.
I can see some interoperability problems between FreeBSD 8 and 9 stable
NFS servers and some Linux NFS clients when using Kerberized NFS.
I noticed that around nfs-utils 1.2.3 something must have changed on the
Linux side or the Linux became more agile to trigger a bug with the FreeBSD.
Maybe these issues have been reported or fixed, but on a current RHEL
6.3 and Ubuntu 12.04 LTS they still do exist.
When the Linux clients mount a FreeBSD NFS share (v3 or v4) sec=krb5*,
they sometimes get an access denied.
If they are able to mount anyway, then subsequent NFS I/O errors continue.
So far:
http://lists.freebsd.org/pipermail/freebsd-fs/2012-August/015047.html
http://lists.freebsd.org/pipermail/freebsd-fs/2012-September/015050.html
I have some questions. As this is an interop problem, I'd like to
clarify a few things.
This what I see on the wireshark trace during an NFSv4 mount -o
proto=tcp,sec=krb5:
The client is EL6 with a patched nfs-utils package as per:
https://bugzilla.redhat.com/show_bug.cgi?id=802469 and gssd started with
-l (legacy) option
TCP0: -> Linux NFS AUTH_NULL
TCP0: <- FreeBSD responds
TCP1: -> Linux sends RPCSEC_GSS_INIT
TCP1: <- FreeBSD responds by establishing GSS Context (it's a 16 byte token)
TCP1: -> Linux sends RPCSEC_GSS_DESTROY using the received 16 byte token
TCP0: -> Linux sends NFS:PUTROOTFS|GETATTR using the same 16 byte received gss context token
Re-using the gss context on the other tcp connection and immediately
destroying it looks like a bug in the Linux NFS layer?
Another worry I see, is that the RPCSEC_GSS_DESTROY when validated on
the FreeBSD side gss_verify_mic returns maj_stat = GSS_S_DEFECTIVE_TOKEN
- which is quite strange (this still can be a FreeBSD bug).
Kind regards,
Attila
--
Attila Bogár
Systems Administrator
Linguamatics - Cambridge, UK
http://www.linguamatics.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
