> - Issue #1:
>
> Yesterday I spent a couple hours scratching my head over why tcpdump (freshly
> built from source) was having such a hard time interpreting NFS traffic on
> Alpha Linux.
The problem may not be specific to Alpha Linux; it would happen on any
LP64 system where "rm_xid" is a "u_long", which may include other 64-bit
platforms and other glibc platforms such as the Hurd.
> I tracked the problem down to the size of the rm_xid field of
> struct rpc_msg. It's declared as a u_long, which is 8 bytes on Alpha, when
> it's only 4 bytes on the wire. This of course puts rm_direction and
> everything else at the wrong offset, confusing tcpdump.
>
> I already filed a glibc bug report about this. It's #2226 in the libc GNATS
> database, which you can get to from the glibc home page:
>
> http://www.gnu.org/software/libc/libc.html
>
> It seemed worth sending an e-mail to the tcpdump list as well, as this could
> be interpreted as a tcpdump bug. (Perhaps it's unsafe to assume that casting
> raw packet data to a struct rpc_msg * will work?)
If "struct rpc_msg" doesn't reflect what goes on the wire, it's unsafe
to assume that casting a pointer to raw packet data to a pointer to
"struct rpc_msg" will work.
We should probably define our own "rpc.h" header file - perhaps by
copying the file from BSD (which got it from Sun), as copying a GPLed
version would cause a clash of licenses - and have that define the
structures to match what's on the wire (i.e., no "u_long", as "u_long"
means different things on different platforms).
> - Issue #2:
>
> My particular situation necessitated some hacking the tcpdump code before I
> could even get to this problem. I'm working with a userland NFS server that
> operates on a non-standard port. tcpdump will normally only interpret UDP
> packets to/from port 2049 as NFS. Even with -T rpc, it fails to decode the
> packets properly.
"rpc" is, for requests, interpreted by tcpdump as meaning "portmapper",
rather than "generic RPC" - "-T rpc" means that packets that match the
filter expression will be interpreted as portmapper requests and NFS
replies (yes, that's a bit weird; at least there's an XXX for it).
> Eric Werme in our Tru64 UNIX group ([EMAIL PROTECTED]) had previously helped
> me debug a problem with this server by using tcpdump. When I asked him about
> this, it became clear that he's working with a separate codebase with some
> unique features:
>
> > When prototype NFS V3 code wandered in here, I immediately wrote decodes
> > for it and kept going with mount, NIS, etc, most of which have no fixed
> > port.
>
> > The original tcpdump only decoded NFS V2, and I'll readily believe it
> > keyed off 2049.
>
> > Our tcpdump keys off the RPC program number [...]
>
> > Feel free to mention to the tcpdump.org folks that I'm willing help
> > get this stuff into tcpdump.
>
> For my purposes, having the ability to automatically recognize NFS traffic on
> a port other than 2049 would be very helpful.
Sun's snoop, I suspect, recognizes all packets with particular values at
particular offsets as ONC RPC packets, and dissects them as particular
RPC protocols based on the program number in the request or, for
replies, the program number in the request that matches the reply.
Ethereal does that as well; it should run on Alpha Linux (and Digital
UNIX):
http://www.ethereal.com/
(it's free software; it's "ethereal.com" only because "ethereal.org" was
already taken).
Tcpdump should perhaps use a similar strategy; I assume, from "Our
tcpdump keys off the RPC program number", that the tcpdump Ric's using
does the latter of the two things I mention - I don't know whether it
looks for specific port numbers (111 and 2049) for RPC, with the
existing "-T" option, or if it uses a heuristic as I suspect snoop does
and know Ethereal does.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
