Thanks a lot for that detailed explanation.
Indeed wireshark dissected these correctly when using "decode as.. RPC"


On 9/5/07, Guy Harris <[EMAIL PROTECTED]> wrote:
> Alex Still wrote:
> > We're using tcpdump to try to diagnose an NFS performance problem.
> > We're seeing a lot of these :
> > [..]
> > 16:01:19.890794 IP nfs_server.nfs > client_46.1205729087: reply ERR 1448
> > 16:01:19.890831 IP nfs_server.nfs > client_46.3664003007: reply ERR 1448
> > [..]
> >
> > That seems to be an RPC error,
> It seems to be one, but it isn't necessarily one.
> The code to print that printed "reply OK {length}" if the field in the
> packet that, *IF* it contains the beginning of an ONC RPC reply, would
> be the reply code is 0, and "reply ERR {length}" if it's not zero.
> However, not all packets from an ONC RPC server (such as an NFS server)
> necessarily contain the beginning of an ONC RPC reply, as a reply (or
> request) can require more than one link-layer packet - for example, an
> NFS READ reply that returns more bytes that fit in one Ethernet packet
> will, when sent over Ethernet, take more than one Ethernet packet.


This is the tcpdump-workers list.
Visit to unsubscribe.

Reply via email to