Re: bandwidth by user or process id

[Rob Hasselbaum <rob () hasselbaum net>]

On Mon, Oct 4, 2010 at 4:35 PM, Rob Hasselbaum <rob () hasselbaum net> wrote:

> On Mon, Oct 4, 2010 at 10:53 AM, Patrick Kurz <kurzpatrick () ymail com>wrote:
>
> > 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
>
> 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. To get those fields out of
> the raw packet data, you have to implement some decoding of the packets.
> Socket Sentry does this based loosely on code from tcpdump. (See
> DataLinkPacketDecoder and its subclasses as well as the
> InternetProtocolDecoder class.) Alternatively, you could just use tcpdump.
> ;-)

One subtle point worth mentioning: Decoding the packets will tell you the
source/destination IP addresses and ports, but often won't tell you which
one is local and which one is remote (i.e. the direction of the traffic).
Socket Sentry looks at the data link layer headers to try to determine this
or--failing that--compares the IP addresses with the host's interface
addresses. If you choose to roll your own solution, you'll need to solve
that problem, too.

I say that decoding _often_ won't tell you the direction of traffic because
there is at least one exception: If you capture traffic using the "any"
pseudo-device on Linux, the "cooked" data link layer header that pcap
delivers to you actually _does_ tell you the direction of traffic, which is
nice.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.