Re: bandwidth by user or process id

[Patrick Kurz <kurzpatrick () ymail com>]

Thanks a lot for this detailed answer! I'll check if the dbus service does not 
add too much overhead. Then I could use your Sentry project instead.

One more question: which part of a line from /proc/net/tcp like the following 
has a unique counterpart in the packet captured with pcap?
> sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  
> timeout inode ref pointer drops
> 49: 00000000:0044 00000000:0000 07 00000000:00000000 00:00000000 00000000     
> 0        0 6703 2 ffff880123d0c000 0

Is it the "sl" hash slot? Where do I find the equivalent in the captured 
packets? local_address  and rem_address are not unique, or did I miss something?

Thanks
Patrick



________________________________
From: Rob Hasselbaum <rob () hasselbaum net>
To: tcpdump-workers () lists tcpdump org
Sent: Mon, October 4, 2010 3:51:39 PM
Subject: Re: [tcpdump-workers] bandwidth by user or process id

On Mon, Oct 4, 2010 at 8:49 AM, Patrick Kurz <kurzpatrick () ymail com> wrote:

> Dear all,
> I am looking for a solution to monitor bandwidth usage
> a) broken up by source and destination ip address
> b) broken up by either user or process (pid) which is causing the bandwidth
Yes, it is possible (on Linux, anyway), but not extremely easy. You can
correlate packet data to the kernel's network connection table and network
connections to inode values by reading "/proc/net/tcp*" and
"/proc/net/udp*". Then you can correlate the inodes to file descriptor
entries and get the owning process and user by iterating through the file
descriptor table of each process via "/proc/*/fd".

This is exactly what my project Socket Sentry does. It's a KDE Plasma widget
that displays current network traffic by user, process, etc. And for
developers and non-KDE users, it offers a service that can be accessed
through a DBUS interface to get the same data. There's a rudimentary command
line interface, as well, but it is mainly for testing at this point. The
project page is here:

http://code.google.com/p/socket-sentry/

You may wish to look at the ConnectionProcessCorrelator class in particular,
which implements the logic I'm talking about:

http://code.google.com/p/socket-sentry/source/browse/socketsentry-service/src/ConnectionProcessCorrelator.cpp


Good luck.
-Rob
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.



      -
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.