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.
There's two levels of tests. One is to determine if something is an
RPC message. The other decides what sort of RPC program it's calling.
E.g., both get done here for calls:
case CALL:
prog = msg.rm_call.cb_prog;
vers = msg.rm_call.cb_vers;
proc = msg.rm_call.cb_proc;
if (msg.rm_call.cb_rpcvers != RPC_MSG_VERSION ||
vers > 4 || proc > 30 || (prog % 50000) > 69)
return FALSE;
rpc_map_enter(&msg, proto, src, sport, dst, dport);
rpc_id(&msg, length, src, dst, prog, vers);
if (proc == 0) {
printf("null");
return TRUE;
}
switch (prog) {
case RPC_NFSPROG:
switch (vers) {
case 2:
nfsreq_print(rp, length, ip, proc);
break;
case 3:
nfs3req_print(proc);
break;
default:
goto unknown;
}
break;
case RPC_PMAPPROG:
pmapreq_print(vers, proc);
break;
case RPC_MOUNTPROG:
mountreq_print(vers, proc);
break;
case RPC_NETLOCKPROG:
nlmreq_print(vers, proc);
break;
Actually, that's a good code snippet - it shows tcpdump reading directly out
of the RPC msg struct, the heuristic of picking out what's an RPC call, and
then a proper dispatch based on program. The only reason that NFS V2/V3 is
checked for is that I kept the original Mogul (et al?) NFS V2 and added my
own "control string" decoding for V3 and everything else.
My code still looks at the byte stream for the RPC direction:
direction = (enum msg_type)ntohl(rp->rm_direction);
if (!udprpc_recv(rp, snapend - (unsigned char *) rp,
&msg, &xprtp, direction))
return FALSE;
but the udprpc_recv() routine does a normal ONC-RPC decode of the msg
struct.
-Ric Werme
-
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
