Re: Linux client mount fails with Gluster NFSv3 server

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Sep 01, 2009 at 08:26:37AM -0400, Trond Myklebust wrote:
> On Tue, 2009-09-01 at 12:09 +0530, Shehjar Tikoo wrote:
> > I am able to view the packets just fine using wireshark Version 1.0.6.
> > It is possible that the default options for you for TCP and RPC are
> > not same as the ones below.
> > Could you please try viewing the dump with the following options set 
> > in the wireshark Protocol preferences pane.
> > 
> > Press <Ctrl> + <Shift> + p to bring up the protocol preferences
> > window.
> > 
> > First, expand the "Protocol" section header in the window that pops
> > up. Then look for "TCP" section. In the TCP section, please check the 
> > following option:
> > 
> > "Allow subdissector to reassemble TCP streams"
> > 
> > Then, search for the "RPC" section under "Protocols". For RPC, please
> > check the following option:
> > 
> > "Reassemble RPC over TCP message spanning multiple TCP segments"
> > 
> > This should make the RPC records visible properly.
> 
> I always run with those options enabled, and they were able to
> reconstruct most of the RPC records correctly, but not the reply to the
> FSINFO call.

Same here--both options set, and I don't normally have this problem.
The segments look OK, though (the sequence numbers are what you'd
expect, anyway)--if the xdr was screwed up you'd think wireshark would
still attempt to parse it.  I'm using 1.0.7 (from 1.0.7-1ubuntu1), but
too lazy to try to debug wireshark....

--b.

> Furthermore, when I looked at the binary contents, it seemed to me that
> the post-op attributes contained some fishy information, such as
> nlink==0. That alone would cause the NFS client to give up.