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. -- 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
