Re: [tcpdump-workers] bandwidth by user or process id
From: Rob Hasselbaum To: tcpdump-workers@lists.tcpdump.org Sent: Mon, October 4, 2010 10:35:02 PM Subject: Re: [tcpdump-workers] bandwidth by user or process id >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. Thanks Patrick - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bandwidth by user or process id
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. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bandwidth by user or process id
On Tue, Oct 5, 2010 at 5:46 AM, Gert Doering 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.
Re: [tcpdump-workers] bandwidth by user or process id
On Mon, 4 Oct 2010 09:51:39 -0400 Rob Hasselbaum wrote:
> 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
Isn't that unreliable? The connection might be short-lived and disappear
from /proc/net/{tc,ud}p* before you have a chance to find it.
Since you are assuming Linux anyway, have you considered using iptables?
If you don't have a huge number of users, you can create a rule like this
for each uid:
iptables -I OUTPUT -m owner --uid-owner -j ACCEPT
and then just monitor the packet & byte counters on these rules.
-Phil
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bandwidth by user or process id
Phil Vandry wrote:
> On Mon, 4 Oct 2010 09:51:39 -0400 Rob Hasselbaum wrote:
>> 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
>
> Isn't that unreliable? The connection might be short-lived and disappear
> from /proc/net/{tc,ud}p* before you have a chance to find it.
>
> Since you are assuming Linux anyway, have you considered using iptables?
>
> If you don't have a huge number of users, you can create a rule like this
> for each uid:
>
> iptables -I OUTPUT -m owner --uid-owner -j ACCEPT
>
> and then just monitor the packet & byte counters on these rules.
You can also catch events using SystemTap's netdev.transmit and
netdev.receive probes.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
