[PLUG] Ports and Processes

Steve Bonds 1s7k8uhcd001 at sneakemail.com
Fri Jul 26 20:03:38 UTC 2002


Shannon:

If you're quick, you might be able to get an lsof listing to show you the
offending program.  Since your program completes so quickly, this will
just be a matter of luck on getting lsof to be running when the program
opens its connection.  I find that a nice "while true" loop does a decent
job, though it's kind of hard on the system.

If you can afford to disrupt the traffic, an invalid static route for the
destination of those mystery packets sometimes helps hold the connection
open long enough for lsof to collect the information.  (I.e. the packet
gets dropped and the TCP connection needs to time out, keeping it open
longer than if it completed successfully.)

The other option (which is *way* more hackerly) would be to modify the
tcp_output.c portion of the kernel to log all connect() calls and build a
new tcp-logging kernel.  This is probably best done from the console.  
;-)  The hard part would be figuring out how to get access to the calling
program's process table structures from within the TCP kernel code.

Good luck!

  -- Steve

On Fri, 26 Jul 2002, Shannon C. Dealy dealy at deatech.com XXXXXXXXXXXXXXXXXXX wrote:

> 
> I've been trying to determine why some packets are going back and forth
> across my internet links, and find I need some information that I can't
> seem to find an easy way to acquire.  Before I resort to writing software,
> does anyone know of a way to track which process (or even user id) last
> used a given port (primarily udp and tcp).  The problem is that I'll see a
> packet go out from a dynamically allocated port, but once the transaction
> completes (in well under a second), the port is freed, so I have no way of
> telling what process/user was generating the packets.  Packet sniffers and
> iplogger are helpful, but don't appear to provide a means of connecting
> the packets back to the source process/program on the local system, or did
> I miss something?
> 
> Anyone got any ideas?
> 
> Shannon C. Dealy      |               DeaTech Research Inc.
> dealy at deatech.com     |          - Custom Software Development -
>                       |    Embedded Systems, Real-time, Device Drivers
> Phone: (800) 467-5820 | Networking, Scientific & Engineering Applications
>    or: (541) 451-5177 |                  www.deatech.com
> 
> 
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
> 






More information about the PLUG mailing list