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.
>
> There's no sign of a 4-byte big-endian integer with "8" in it in front
> of that string, so, if the packet is supposed to be an NFS V2 LOOKUP
> request, it looks malformed.
>
> What OS are the client and server running?
Both client and server are running Linux 2.2.14-pre10. Linux is definitely
known for having a not-so-good NFS implementation.
I've been using Ethereal today specifically to debug strange NFS problem
at work. I thought there might be some VFS bug in the Linux kernel, but it
didn't even dawn on my to consider malformed packets!
--gilbert
