Re: Tracking network traffic
Re: Tracking network traffic
- Subject: Re: Tracking network traffic
- From: Vincent Lubet <email@hidden>
- Date: Tue, 3 Jun 2008 09:31:32 -0700
I have to add a standard disclaimer about using dtrace. While dtrace
is a very useful debugging and troubleshooting tool, dtrace enables
access to private kernel data structures that absolutely not part of a
supported API. The private kernel data structures may change with any
build of the OS. That means it would be unwise to rely on this kind of
dtrace script in any released product.
Vincent
On Jun 3, 2008, at 5:22 AM, Quinn wrote:
At 12:31 +0100 2/6/08, Mark Thomas wrote:
I was wondering if anybody know's of what the best way of tracking
down,
if a rogue process is sending out some bad traffic. As I need to
find out
which OS or Appl process is sending out a particular packet, which
seems to
be upsetting some routers in market place.
I can get Ethernet trace via 'tcpdump', but that doesn't tell which
process is sending it, although I can match this up with 'lsof',
however I
only get this as a snapshot in time of execution, not dynamically
as I'm
told this can happen over 5 minute period.
Any thoughts on the best way to track this down.
You haven't posted enough info to give a concrete answer. Even in
theory this problem is hard to solve in general case. To solve it
in practice you will have to make some simplifying assumptions. I'm
assuming the following:
o That the traffic is actually being sent explicitly, rather than
being spontaneously generated by the networking stack (ICMP, for
example).
o That we're talking about TCP over IPv4.
o That you can determine the source port number of the traffic from
your network trace (even if it's post-facto).
o That the source port is anonymous (things would be much easier if
the source port was always the same :-).
o That various wacky programming techniques (for example, descriptor
passing) are /not/ being used.
If all of these assumptions apply then it should be straightforward
to debug this using DTrace. The following DTrace script prints the
source and destination port of all TCP-over-IPv4 connections made
from user space [1].
---------------------------------------------------------------------------
#! /usr/sbin/dtrace -C -q -s
/*
Mac OS X currently does not support byte swapping in DTrace
<rdar://problem/5235209>, so we do it the hard way. This assumes
you're running on Intel. If not, you'll have to toggle
Q_BIG_ENDIAN.
*/
#define Q_BIG_ENDIAN 0
#if Q_BIG_ENDIAN
#define ntohs(x) ((short)x)
#else
#define ntohs(x) ((short) (((((short)(x)) & 0x0FF) << 8) |
((((short)(x)) >> 8) & 0x0FF)))
#endif
inline int AF_INET = 2;
syscall::connect:entry,
syscall::connect_nocancel:entry
/
! self->trace
/
{
/* printf(" s >connect\n", execname); */
self->connectFD = arg0;
self->sock = ((socket_t) (curproc->p_fd->fd_ofiles[self-
>connectFD]->f_fglob->fg_data));
self->trace = 1;
}
syscall::connect:return,
syscall::connect_nocancel:return
/
self->trace
&& ((errno == 0) || (errno == EINPROGRESS))
&& (self->sock->so_proto->pr_domain->dom_family == AF_INET)
/
{
pcb = (struct inpcb *) self->sock->so_pcb;
localPort = (uint16_t) pcb->inp_lport;
remotePort = (uint16_t) pcb->inp_fport;
printf(" s connect %u -> %u\n", execname, ntohs(localPort),
ntohs(remotePort));
}
syscall::connect:return,
syscall::connect_nocancel:return
/
self->trace
/
{
/* printf(" s <connect %d\n", execname, errno); */
self->connectFD = 0;
self->sock = 0;
self->trace = 0;
}
---------------------------------------------------------------------------
Put this in a file called "ConnectSnoop.d" and then run it using:
$ chmod +x ConnectSnoop.d
$ sudo ./ConnectSnoop.d
As with most DTrace explorations, you'll probably want to refine
this script as you learn more about the problem. For example, if
you discover that the connection is not coming from user space, you
can use the DTrace "fbt" provider to look for the in-kernel culprit.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/
>
Apple Developer Relations, Developer Technical Support, Core OS/
Hardware
[1] Ideally it should only print info about successful connections.
That's hard to do because of the non-blocking case. The script
currently prints info about all successful blocking connections and
all non-blocking connections that are successful started
(EINPROGRESS).
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden