Re: [chip@debian.org: Debian Bug#203918 - statd request on eth interface, not localhost?]

[Chip Salzenberg <chip@debian.org>]

According to Jordi Mallach:
> I have never used tcpdump more than to play a little, so I could use
> some pointers about what I should look at.

First you use 'rpcinfo -p' to see which ports statd is listening to
on the machine where statd is complaining:

   $ rpcinfo -p | grep status
       100024    1   udp    936  status
       100024    1   tcp    939  status

That's udp port 936 and tcp port 939.  Then you want to watch all
traffic to/from those ports:

   # tcpdump udp port 936 or tcp port 939

You may also need to specify "-i eth1" or whatever if the IP address
you're seeing isn't on your eth0.

Then you sit and watch.  A combination of "screen" and "script" may
also be helpful.  The man page for tcpdump, section "OUTPUT FORMAT",
explains how to interpret the output.

The key thing is the source IP and port of whoever's talking to statd.
Then you go to the source machine and use 'lsof' to see what program
has bound to that port.  If the program is gone by the time you get
there, you'll need to prevent statd from answering the request, which
will entail compiling a custom statd or perhaps using iptables to kill
any outgoing answer packets.
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs