> ...which means "port 111 or 2049" won't work as a way to identify RPC
> requests; the heuristic I used in another program was:
stuff deleted: CALL/RPC version/known RPC program number or REPLY/XID
This is the method tcpdump uses for the dissection. It is the right way.
The other way from dissect_udp() to dissect_rpc() is the port number:
udp_hash_add(UDP_PORT_NFS, dissect_rpc);
udp_hash_add(UDP_PORT_RPCB, dissect_rpc);
This does not really work, because 2049 (UDP_PORT_NFS) is often the bigger
port number and wont be used to distinguish the dissect routines. This has
something to do with the way tftp is dissected at the end of dissect_udp().
The other RPC services (YP, mount, lock etc.) dont have a fixed port, so the
best way is to use the heuristic method or even better, remember the replies
from portmapper getport/getaddr/dump. The problem with this is only, that
udp_hash_add() is global over all hosts and these replies are host specific.
A colleage of mine just implemented this feature in tcpdump for ReliantUNIX.
> ... I was just a bit nervous that "0 at offset XXX, 2 at offset
> YYY" wasn't sufficient to avoid false hits.
Exactly. We have to check the program number too.
> Note also that, of course, you'll also have to remember calls - not only
> to recognize RPC replies, but also to *dissect* RPC replies, as RPC
> replies have only the XID of the request, they don't have the program,
> version, or procedure number of the request.
Thanks for the hint but allow me a short note: I work full time on the NFS
implementation for ReliantUNIX. I know RPC.
> (This is similar to what the SMB dissector will have to do for TRANSACT2
> replies; you might want to talk with Richard Sharpe here.
Thanks for the name and yes, a general routine might be better.
> Note that
> whatever table you use to remember calls should, of course, remember the
> network-layer address and port number whence the request came, as XIDs
> aren't globally unique.)
It is even worse. For example PC NFS starts after each PC reboot (which is
often) with XID 1. This can severely confuse the duplicate transaction
mechanism on a NFS server because the first function call is also always the
same (FSINFO or something similar).
