On Fri, Dec 03, 1999 at 03:43:06PM -0600, Guy Harris wrote:
>
>
> > This small trace file shows a small bug in the NFS filename or RPC string
> > handling of NFS v2 packets.
>
> "snoop" doesn't like frame 8, either:
>
> RPC: ----- SUN RPC Header -----
> RPC:
> RPC: Transaction id = 2187714176
> RPC: Type = 0 (Call)
> RPC: RPC version = 2
> RPC: Program = 100003 (NFS), version = 2, procedure = 4
> RPC: Credentials: Flavor = 1 (Unix), len = 44 bytes
> RPC: Time = 1966
> RPC: Hostname = louie.dev.tivoli.com
> RPC: Uid = 4462, Gid = 40
> RPC: Groups = 40
> RPC: Verifier : Flavor = 0 (None), len = 0 bytes
> RPC:
> NFS: ----- Sun NFS -----
> NFS:
> NFS: Proc = 4 (Look up file name)
> NFS: File handle = CABAEBFE94B900005972000001080000
> NFS: 01080000718F0000C773890B00000000
> NFS: ---- short frame ---
>
> and it has a similar complaint about frame 14.
Thanks! I think you've narrowed down my search for the Linux NFS bug.
I went back to my 14MB trace file (I sure am glad you put that
"Save only displayed frames" feature in!) and for all my successful
compilations over NFS, LOOKUPs had good filenames.
(I'm filtering on rpc.procedure == 100003 && nfs.name, BTW, to look at
the 2164 different LOOKUPs and filenames).
During some compilatoins over NFS, the assembler failed to find
a directory already there. That failure coincides with the bad
LOOKUP packet.
I'll do a bit more investigation, and send a note to Alan Cox.
--gilbert
