Re: bandwidth by user or process id

[Rob Hasselbaum <rob () hasselbaum net>]

On Tue, Oct 5, 2010 at 5:46 AM, Gert Doering <gert () greenie muc de> wrote:

> Hi,
>
> On Tue, Oct 05, 2010 at 02:14:19AM -0700, Patrick Kurz wrote:
> > > For typical point-to-point IP traffic, the combination of local address,
> > > local port, remote address, remote port, and transport protocol (TCP or
> UDP)
> > > is the closest thing you have to a unique key.
> >
> > Are you saying, that this method cannot distinguish two different
> users/PIDs
> > downloading huge data from the same remote address to the same local
> address?
> > This was the key point of my original question, and if your method relies
> on
> > addresses and ports only, I have to search for a different solution.
>
> Two differnet local users will have to use different local ports.
>
> That's just the way TCP/UDP works, one of the 5 variables listed above
> has to be different for each parallel connection.
Right, generally, the local or remote port will be different for different
PIDs even if the IP addresses are the same. There is one catch, though. It
is possible on Linux to share sockets (network connections) between two or
more processes. For example, the openSSH daemon spawns a new process for
each new connection, and if you look at the "/proc/*/fd" tables of the
parent and child processes, you'll see the same socket appears to be owned
by both. When this happens. it's likely only one of them is actually using
the connection, but I have not found a way to tell which one, and I suspect
it's not possible in userland because even "netstat" balks at this case.
Socket Sentry addresses it by assigning the traffic to either the oldest or
the newest process in the group (user configurable) and sets a special flag
on the record to let its D-Bus clients know it's a shared socket.

This is an edge case, though. I've only seen a couple of programs do it on
my desktop. Maybe it's more common on servers.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.