From: "J. Bruce Fields" <bfields@fieldses.org>
To: Sven Geggus <sven@geggus.net>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Kernel update 3.5.7 -> 3.6.3 breaks NFS4
Date: Mon, 29 Oct 2012 11:02:03 -0400 [thread overview]
Message-ID: <20121029150203.GB9502@fieldses.org> (raw)
In-Reply-To: <20121029094038.GA14836@geggus.net>
Re-adding linux-nfs to cc:
On Mon, Oct 29, 2012 at 10:40:38AM +0100, Sven Geggus wrote:
> J. Bruce Fields schrieb am Freitag, den 26. Oktober um 19:15 Uhr:
>
> > Could I see a network trace?
>
> Shure. I can also do one with the working kernel.
>
> > tcpdump -s0 -wtmp.pcap 'host <myclient> && host <myserver>'
> >
> > then try the mount, then kill tcpdump and send me a copy of tmp.pcap.
>
> pcap file attached.
Thanks. So running "wireshark nfs4.pcap", I see:
frame 13, 15: create a gss context with handle 0x01000000
frame 17, 18: client sends a DESTROY for context 0x01000000 and
a TCP FIN. The RPC is malformed in that it has no verifier
field. The server doesn't respond.
frame 19: client sends a PUTROOTFH using context 0x01000000.
frame 25-31: a minute has passed, the client gives up, closes
the connection and retries the PUTROOTFH, again with the
same context.
That DESTROY is sent over the same connection as the context creation,
so must have been done by gssd. So gssd has a bug. Well, two: first,
the DESTROY is malformed, second, it shouldn't be sending it anyway.
I don't understand why the server is dropping requests instead of
returning errors. I actually would have expected it to return BADVERF
to the DESTROY request and then accept the PUTROOTFH normally, which
might have allowed the mount to succeed despite the bizarre rpc.gssd
behavior.
I'd be curious to understand what changed on the server to make a
difference. I can't think of anything. Looking at a network trace from
a successful mount with 3.5.7 might be useful.
--b.
>
> This is what I called:
> mount -t nfs4 -v -o sec=krb5 centauri:/storage /mnt
>
> Client ist venus (10.1.7.30), server is centauri (10.1.7.67) kerberos realm
> (AD) is PC.IITB.FHG.DE
>
> What I should probably also metion is that the machine is a redundant system
> using drbd. The IP-address 10.1.7.67 can be migrated to the the slave
> machine in case of a hardware failure. So if something seems to be missing I
> can also create a capture file including the other IP-address of the
> server system.
>
> Regards
>
> Sven
>
> --
> "Those who do not understand Unix are condemned to reinvent it, poorly"
> (Henry Spencer)
>
> /me is giggls@ircnet, http://sven.gegg.us/ on the Web
next prev parent reply other threads:[~2012-10-29 15:02 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-26 15:58 Kernel update 3.5.7 -> 3.6.3 breaks NFS4 Sven Geggus
2012-10-26 16:39 ` VDR User
2012-10-31 12:47 ` Sven Geggus
2012-10-26 17:15 ` J. Bruce Fields
[not found] ` <20121029094038.GA14836@geggus.net>
2012-10-29 15:02 ` J. Bruce Fields [this message]
2012-10-29 16:33 ` Sven Geggus
2012-10-29 22:09 ` J. Bruce Fields
2012-10-31 12:52 ` Sven Geggus
2012-10-31 14:28 ` VDR User
2012-10-31 15:33 ` Sven Geggus
2012-10-31 17:43 ` VDR User
2012-11-05 14:45 ` Sven Geggus
2012-11-05 16:55 ` Sven Geggus
2012-11-09 18:45 ` Sven Geggus
2012-11-09 20:07 ` J. Bruce Fields
2012-11-09 20:09 ` J. Bruce Fields
2012-11-09 22:45 ` Sven Geggus
2012-11-09 23:24 ` J. Bruce Fields
2012-11-12 9:17 ` Sven Geggus
2012-11-13 22:40 ` J. Bruce Fields
2012-11-14 0:58 ` J. Bruce Fields
2012-11-14 16:07 ` J. Bruce Fields
2012-11-14 16:08 ` J. Bruce Fields
2012-11-15 16:58 ` Sven Geggus
2012-11-16 19:19 ` J. Bruce Fields
2012-12-12 11:15 ` Sven Geggus
2012-12-12 18:57 ` J. Bruce Fields
2012-11-14 22:26 ` Eldad Zack
2012-11-09 23:17 ` Eldad Zack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121029150203.GB9502@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=sven@geggus.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.