Sniffer for Windows That Shows Process ID?

[Will]

Can someone recommend a sniffer for Windows that will show the process ID
and name of the process sending or receiving each packet shown in the
sniffer?

I normally use ethereal or wireshark and didn't see a straightforward way to
include this information.

--
Will

 

[MowGreen [MVP]]

netstat for ports, not packets, though.

Displays protocol statistics and current TCP/IP network connections.

NETSTAT [-a] [-b] [-e] [-n] [-o] [-p proto] [-r] [-s] [-v] [interval]

-a Displays all connections and listening ports.
-b Displays the executable involved in creating each
connection or listening port. In some
cases well-known executables host
multiple independent components, and in these cases the
sequence of components involved in creating the connection
or listening port is displayed. In this case the executable
name is in [] at the bottom, on top is the component it called,
and so forth until TCP/IP was reached. Note that this option
can be time-consuming and will fail unless you have sufficient permissions.

-e Displays Ethernet statistics. This may be combined with
the -s option.

-n Displays addresses and port numbers in numerical form.
-o Displays the owning process ID associated with each
connection.

-p proto Shows connections for the protocol specified by proto
proto may be any of: TCP, UDP, TCPv6, or UDPv6. If used with the -s
option to display per-protocol statistics, proto may be any of: IP,
IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6.

-r Displays the routing table.
-s Displays per-protocol statistics. By default,
statistics are shown for IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, and
UDPv6 the -p option may be used to specify a subset of the default.

-v When used in conjunction with -b, will display sequence
of components involved in creating the connection
listening port for all executables.

interval Redisplays selected statistics, pausing interval seconds
between each display. Press CTRL+C to stop redisplaying
statistics. If omitted, netstat will print the current
configuration information once.


MowGreen [MVP 2003-2008]
===============
*-343-* FDNY
Never Forgotten
===============


Will wrote:

> Can someone recommend a sniffer for Windows that will show the process ID
> and name of the process sending or receiving each packet shown in the
> sniffer?
>
> I normally use ethereal or wireshark and didn't see a straightforward way to
> include this information.
>

 

[Will]

Netstat is not a *historical* trace of packets. It's totally unsuitable
as a sniffer replacement.

If your application is to associate a listening port with a process, netstat
is handy and I use it.

If your application is to ask the question "who sent out these packets at
3:07p today to a particular destination on a particular port, netstat is the
wrong tool. A sniffer is the right tool.

Morever, if the packets are UDP, I seem to remember that netstat only shows
UDP listeners, not outgoing traffic. So even if I executed netstat at
precisely the right moment, I still wouldn't see outgoing UDP traffic of
interest.

--
Will


"MowGreen [MVP]" <mowgreen@nowandzen.com> wrote in message
news:ufragj4CIHA.1056@TK2MSFTNGP03.phx.gbl...
> netstat for ports, not packets, though.
>
> Displays protocol statistics and current TCP/IP network connections.
>
> NETSTAT [-a] [-b] [-e] [-n] [-o] [-p proto] [-r] [-s] [-v] [interval]
>
> -a Displays all connections and listening ports.
> -b Displays the executable involved in creating each
> connection or listening port. In some cases well-known executables host
> multiple independent components, and in these cases the
> sequence of components involved in creating the connection
> or listening port is displayed. In this case the executable
> name is in [] at the bottom, on top is the component it called,
> and so forth until TCP/IP was reached. Note that this option
> can be time-consuming and will fail unless you have sufficient
> permissions.
>
> -e Displays Ethernet statistics. This may be combined with
> the -s option.
>
> -n Displays addresses and port numbers in numerical form.
> -o Displays the owning process ID associated with each
> connection.
>
> -p proto Shows connections for the protocol specified by proto
> proto may be any of: TCP, UDP, TCPv6, or UDPv6. If used with the -s
> option to display per-protocol statistics, proto may be any of: IP, IPv6,
> ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6.
>
> -r Displays the routing table.
> -s Displays per-protocol statistics. By default, statistics
> are shown for IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, and UDPv6 the -p
> option may be used to specify a subset of the default.
>
> -v When used in conjunction with -b, will display sequence of
> components involved in creating the connection listening port for all
> executables.
>
> interval Redisplays selected statistics, pausing interval seconds
> between each display. Press CTRL+C to stop redisplaying
> statistics. If omitted, netstat will print the current
> configuration information once.
>
>
> MowGreen [MVP 2003-2008]
> ===============
> *-343-* FDNY
> Never Forgotten
> ===============
>
>
> Will wrote:
>
>> Can someone recommend a sniffer for Windows that will show the process ID
>> and name of the process sending or receiving each packet shown in the
>> sniffer?
>>
>> I normally use ethereal or wireshark and didn't see a straightforward way
>> to include this information.
>>

 

[S. Pidgorny]

G'day:

"Will" <westes-usc@noemail.nospam> wrote in message
news:EaydncQoA_Z9xpDanZ2dnUVZ_s2tnZ2d@giganews.com...
> Netstat is not a *historical* trace of packets. It's totally
> unsuitable as a sniffer replacement.
>
> If your application is to associate a listening port with a process,
> netstat is handy and I use it.
>
> If your application is to ask the question "who sent out these packets at
> 3:07p today to a particular destination on a particular port, netstat is
> the wrong tool. A sniffer is the right tool.

I usually run netstat -ano and in a loop and protocol analyser in parallel.
You can do both if you can schedule tasks for 3:07p...

--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

 

[jameshanley39@yahoo.co.uk]

Will wrote:

> Can someone recommend a sniffer for Windows that will show the
> process ID and name of the process sending or receiving each packet
> shown in the sniffer?
>
> I normally use ethereal or wireshark and didn't see a straightforward
> way to include this information.


this is indeed a noble search ! I have looked for the same thing
myself.

netstat can see process id, but only offers a snapshot, it's
stateless, and as a result of it only doing a snapshot, it doesn't
record whether the packet is incoming or outgoing. And of course it's
only a snapshot style port status thing.

You said something like TCPView do what you want ""if you had the
patience of a saint?" But from what I remember, TCPView is not a packet
sniffer. You never see inside the packet.

I did find a port logger (software running on the machine of course,
it's necessary for this) that records process id , and whether the
packet is incoming or outgoing. But it's not a packet sniffer.
Sygate personal firewall, probably the last free version. Maybe
available from oldversion.com or elsewhere. You can turn off the
firewall feature leaving just the port logger. Though the last time i
installed it it crashed, maybe blocking outgoing , and so I removed it
and haven't tried it since.

Somebody should really write what you suggest. It'd be only a small
addition to Ethereal. Indeed, it's not purely a 'packet' thing, but in
a strict definition of packet, neither is TCP. TIME isn't a purely
packet thing either, by any definition, though ethereal displays it
alongside the packet. MS Word is popular because it draws pictures,
doesn't just allow the writing of words. I have to get into this silly
philosophical thing, since a post implied ethereal or a packet sniffer
*shouldn't* do it, so I think some people don't get it.

Somebody posted writing as if this was some personal problem Will has,
requesting they email in private (perhaps since he writes software and
sells it). OK. But It is not just his thing. It's as he described it.
A general thing.

I notice also xananews tried to set follow-up to
comp.dcom.net-management , so if anybody uses that, then be careful!

 

[Ben_]

Didn't check further if there is a product using this library:
"
When I capture a packet from a local machine, does the Packet Sniffer SDK
provide a process information (e.g. process id) related with the packet?
Yes, please use HNLBAdapter component.
"
(http://www.microolap.com/products/network/pssdk/faq/)

So, at worse you could create it yourself or have it created...

Or do more searches on the field of honeypots:
"
Sebek version 3 extends this functionality by intercepting a new set of
system calls. Additionally, it retrieves the parent process id (PPID) and
the inode associated with any file-related event.
"
(http://www.securityfocus.com/infocus/1855)

 

[weiming81@gmail.com]

On Oct 10, 3:26 pm, "Will" <westes-...@noemail.nospam> wrote:
> Can someone recommend a sniffer for Windows that will show the process ID
> and name of the process sending or receiving each packet shown in the
> sniffer?
>
> I normally use ethereal or wireshark and didn't see a straightforward way to
> include this information.
>
> --
> Will

Try Netpeeker

 

[Will]

<jameshanley39@yahoo.co.uk> wrote in message
news:470e2247$0$13931$fa0fcedb@news.zen.co.uk...
> Will wrote:
> > Can someone recommend a sniffer for Windows that will show the
> > process ID and name of the process sending or receiving each packet
> > shown in the sniffer?
> >
> > I normally use ethereal or wireshark and didn't see a straightforward
> > way to include this information.
>
> this is indeed a noble search ! I have looked for the same thing
> myself.
>
> netstat can see process id, but only offers a snapshot, it's
> stateless, and as a result of it only doing a snapshot, it doesn't
> record whether the packet is incoming or outgoing. And of course it's
> only a snapshot style port status thing.
>
> You said something like TCPView do what you want ""if you had the
> patience of a saint?" But from what I remember, TCPView is not a packet
> sniffer. You never see inside the packet.
>
> I did find a port logger (software running on the machine of course,
> it's necessary for this) that records process id , and whether the
> packet is incoming or outgoing. But it's not a packet sniffer.
> Sygate personal firewall, probably the last free version. Maybe
> available from oldversion.com or elsewhere. You can turn off the
> firewall feature leaving just the port logger. Though the last time i
> installed it it crashed, maybe blocking outgoing , and so I removed it
> and haven't tried it since.
>
> Somebody should really write what you suggest. It'd be only a small
> addition to Ethereal.

Can you expand on that last thought? Are you saying the developers of
Ethereal could do this easily, or did you mean that there is some add-on API
for Wireshark that would let us add this in?

--
Will

 

[jameshanley39@yahoo.co.uk]

On Oct 14, 10:00 am, "Will" <westes-...@noemail.nospam> wrote:
> <jameshanle...@yahoo.co.uk> wrote in message
>
> news:470e2247$0$13931$fa0fcedb@news.zen.co.uk...
>
>
>
>
>
> > Will wrote:
> > > Can someone recommend a sniffer for Windows that will show the
> > > process ID and name of the process sending or receiving each packet
> > > shown in the sniffer?
>
> > > I normally use ethereal or wireshark and didn't see a straightforward
> > > way to include this information.
>
> > this is indeed a noble search ! I have looked for the same thing
> > myself.
>
> > netstat can see process id, but only offers a snapshot, it's
> > stateless, and as a result of it only doing a snapshot, it doesn't
> > record whether the packet is incoming or outgoing. And of course it's
> > only a snapshot style port status thing.
>
> > You said something like TCPView do what you want ""if you had the
> > patience of a saint?" But from what I remember, TCPView is not a packet
> > sniffer. You never see inside the packet.
>
> > I did find a port logger (software running on the machine of course,
> > it's necessary for this) that records process id , and whether the
> > packet is incoming or outgoing. But it's not a packet sniffer.
> > Sygate personal firewall, probably the last free version. Maybe
> > available from oldversion.com or elsewhere. You can turn off the
> > firewall feature leaving just the port logger. Though the last time i
> > installed it it crashed, maybe blocking outgoing , and so I removed it
> > and haven't tried it since.
>
> > Somebody should really write what you suggest. It'd be only a small
> > addition to Ethereal.
>
> Can you expand on that last thought? Are you saying the developers of
> Ethereal could do this easily, or did you mean that there is some add-on API
> for Wireshark that would let us add this in?
>

I don't know C/C++ , but I'm saying that for developers it'd be easy.

netstat is a tiny program and does it.
sygate firewall had a very simple port logger program that did it.

So there would be an API. Not for Wireshark. But an API - presumably a
windows or linux one - that can be accessed by the language that
wireshark is written in. Wireshark or any program could access it.


when I say "did it", netstat or sygate firewall did it, i'm referring
to knowing it for 'connections'. Essentially that means it knows it
for packets. Worst case scenario, this shows that if sitting on a
client or server, the software can only know the process id when one
process is used for the entire connection(i've never even see more
than one used anyway. So even for a worst case scenario, 1 process is
a fair assumption to make). One doesn't know if one doesn't try it.
But either way, reasoning shows it's a simple , small thing.

 

[Vernon Schryver]

In article <1192380048.683646.295040@q3g2000prf.googlegroups.com>,
jameshanley39@yahoo.co.uk <jameshanley39@yahoo.co.uk> wrote:

>> > Somebody should really write what you suggest. It'd be only a small
>> > addition to Ethereal.
>>
>> Can you expand on that last thought? Are you saying the developers of
>> Ethereal could do this easily, or did you mean that there is some add-on API
>> for Wireshark that would let us add this in?
>>
>
>I don't know C/C++ , but I'm saying that for developers it'd be easy.

If you "don't know C/C++", how can you imagine that you might have any
idea what is easy or hard?


>netstat is a tiny program and does it.
>sygate firewall had a very simple port logger program that did it.
>
>So there would be an API. Not for Wireshark. But an API - presumably a
>windows or linux one - that can be accessed by the language that
>wireshark is written in. Wireshark or any program could access it.
>
>when I say "did it", netstat or sygate firewall did it, i'm referring
>to knowing it for 'connections'. Essentially that means it knows it
>for packets. Worst case scenario, this shows that if sitting on a
>client or server, the software can only know the process id when one
>process is used for the entire connection(i've never even see more
>than one used anyway. So even for a worst case scenario, 1 process is
>a fair assumption to make). One doesn't know if one doesn't try it.
>But either way, reasoning shows it's a simple , small thing.

That so called "reasoning" is silly nonsense based on willful ignorance.


You can write code to relate TCP or UDP connections to processes IDs by

1. look at all sockets (or equivalent) in the system and their
associated TSBs or other "connection" information until you find
the connection you care about based in its (addr,port,add,port)
4-tuple (or equivalent for a protocol other than TCP or UDP).

This is equivalent to `netstat -naA` on many systems.

2. look at all file descriptors (or equivalent) in the system until
you find one associated with the socket from step #1. Except
for wierd special cases in some systems, each file descriptor
will be owned by one *or more* prcoesses, which gives you your
PIDs (plural).
I often use `netstat -naA` and then `fstat | grep xxhexxxxx`

That works because every connection needs to be associated with a socket
(or equivalent) so that the system knows what to do with incoming
packets. Every socket needs to be associated with processes so that
the system knows to destroy the socket at the end the last process that
cares about it.

Packets (in non-trivial systems) are a whole other kettle of fish.
Processes do things such as sendto() system calls that dump packets
into queues to be sent and forget them. Packets need to last in the
system only until they are put on the wire. In normal situations, there
is no reason to spend the CPU cycles or memory that would be required
to remember which process created each packet sitting in a queue to be
sent.

The supposed "simple, small thing" of being able to find the process
that sent a packet is either the large thing of changing the operating
syustem to maintain PIDs or pointers in mbufs (or equivalents) or the
not so small thing of inserting a shim between all applications on the
system and all system calls that can send packets, and having the shim
maintain enough state (or logs) so that it can guess and pick a process
that probably sent a given packet. Other people have mentioned packages
that sound to me as if they do the latter.


Vernon Schryver vjs@rhyolite.com

 

[Will]

"Vernon Schryver" <vjs@calcite.rhyolite.com> wrote in message
news:fetpea$nds$1@calcite.rhyolite.com...
> Packets (in non-trivial systems) are a whole other kettle of fish.
> Processes do things such as sendto() system calls that dump packets
> into queues to be sent and forget them. Packets need to last in the
> system only until they are put on the wire. In normal situations, there
> is no reason to spend the CPU cycles or memory that would be required
> to remember which process created each packet sitting in a queue to be
> sent.
>
> The supposed "simple, small thing" of being able to find the process
> that sent a packet is either the large thing of changing the operating
> syustem to maintain PIDs or pointers in mbufs (or equivalents) or the
> not so small thing of inserting a shim between all applications on the
> system and all system calls that can send packets, and having the shim
> maintain enough state (or logs) so that it can guess and pick a process
> that probably sent a given packet. Other people have mentioned packages
> that sound to me as if they do the latter.

So the quick summary would be: tracking the process ID in a sniffer would
be relatively easy for connection oriented protocols like TCP since the
Windows OS has data structures that give strong clues about the sender and
receiver that could be parsed to match on address/port of sender and
receiver. Of course this approach would miss the rogue application that
fakes packets and tries to make them appear to come from a different
process. But it is a lot more than what we have today and would be very
useful.

The tracking of process ID in a sniffer would be extremely difficult for
datagrams since it would require either enhancements to the OS or the
installation of traps or filters for all of the various OS calls that allow
a datagram to be sent. Such filtering to track process IDs has overhead
associated with it, so it might be something that you would only want to
make active during a sniffer session.

Did you look at the MicroOlap Sniffer SDK another poster had mentioned at
http://www.microolap.com? Did you have any opinion on it?

--
Will

 

[Vernon Schryver]

In article <boednR8UIpWqGo_anZ2dnUVZ_vKunZ2d@giganews.com>,
Will <westes-usc@noemail.nospam> wrote:

>So the quick summary would be: tracking the process ID in a sniffer would
>be relatively easy for connection oriented protocols like TCP since the
>Windows OS has data structures that give strong clues about the sender and
>receiver that could be parsed to match on address/port of sender and
>receiver. Of course this approach would miss the rogue application that
>fakes packets and tries to make them appear to come from a different
>process. But it is a lot more than what we have today and would be very
>useful.

It is very useful, but it is not a lot more than we what we have in
UNIX-like operating systems. As I tried to say, I often find processes
with `netstat -A`, grep, and fuser, fstat, or one of the other active
file listers whose names I can never remember. (ldstat? liostat?)

I'm not a Windows expert, although I do ship code that uses TCP
and UDP on Windows 95 through XP.

Using grep and so forth is clumsy in UNIX, but some versions of
fuser eliminate that clumsiness. See
http://www.google.com/search?q=fuser+TCP
http://www.google.com/search?q=pid+process+TCP
http://techpubs.sgi.com/library/tpl...an&fname=/usr/share/catman/a_man/cat1/fuser.z
http://nixdoc.net/man-pages/Linux/fuser.1.html

>The tracking of process ID in a sniffer would be extremely difficult for
>datagrams since it would require either enhancements to the OS or the
>installation of traps or filters for all of the various OS calls that allow
>a datagram to be sent. Such filtering to track process IDs has overhead
>associated with it, so it might be something that you would only want to
>make active during a sniffer session.

That is a slight overstatement. If the application uses connected UDP
sockets, then there are almost the same clues to sender and receiver
as with TCP. Lately I've been using `netstat -A` etc. on UDP more than
TCP.

Note that talking about "tracking of process ID in a sniffer" gives me
pause. When I last looked, "Sniffer" was a registered trademark for a
family of boxes that plug into networks to snoop on passing packets.
Such boxes can have no notion even of whether the source and destination
of packets have a notion of process ID. That's why I always write
"packet snooping" or similar instead of "sniffing."


Vernon Schryver vjs@rhyolite.com

 

[jameshanley39@yahoo.co.uk]

On Oct 14, 8:07 pm, v...@calcite.rhyolite.com (Vernon Schryver) wrote:
> In article <1192380048.683646.295...@q3g2000prf.googlegroups.com>,
>
> jameshanle...@yahoo.co.uk <jameshanle...@yahoo.co.uk> wrote:
> >> > Somebody should really write what you suggest. It'd be only a small
> >> > addition to Ethereal.
>
> >> Can you expand on that last thought? Are you saying the developers of
> >> Ethereal could do this easily, or did you mean that there is some add-on API
> >> for Wireshark that would let us add this in?
>
> >I don't know C/C++ , but I'm saying that for developers it'd be easy.
>
> If you "don't know C/C++", how can you imagine that you might have any
> idea what is easy or hard?
>
> >netstat is a tiny program and does it.
> >sygate firewall had a very simple port logger program that did it.
>
> >So there would be an API. Not for Wireshark. But an API - presumably a
> >windows or linux one - that can be accessed by the language that
> >wireshark is written in. Wireshark or any program could access it.
>
> >when I say "did it", netstat or sygate firewall did it, i'm referring
> >to knowing it for 'connections'. Essentially that means it knows it
> >for packets. Worst case scenario, this shows that if sitting on a
> >client or server, the software can only know the process id when one
> >process is used for the entire connection(i've never even see more
> >than one used anyway. So even for a worst case scenario, 1 process is
> >a fair assumption to make). One doesn't know if one doesn't try it.
> >But either way, reasoning shows it's a simple , small thing.
>
> That so called "reasoning" is silly nonsense based on willful ignorance.
>
> You can write code to relate TCP or UDP connections to processes IDs by
>
> 1. look at all sockets (or equivalent) in the system and their
> associated TSBs or other "connection" information until you find
> the connection you care about based in its (addr,port,add,port)
> 4-tuple (or equivalent for a protocol other than TCP or UDP).
>
> This is equivalent to `netstat -naA` on many systems.
>
> 2. look at all file descriptors (or equivalent) in the system until
> you find one associated with the socket from step #1. Except
> for wierd special cases in some systems, each file descriptor
> will be owned by one *or more* prcoesses, which gives you your
> PIDs (plural).
> I often use `netstat -naA` and then `fstat | grep xxhexxxxx`
>
> That works because every connection needs to be associated with a socket
> (or equivalent) so that the system knows what to do with incoming
> packets. Every socket needs to be associated with processes so that
> the system knows to destroy the socket at the end the last process that
> cares about it.
>
> Packets (in non-trivial systems) are a whole other kettle of fish.
> Processes do things such as sendto() system calls that dump packets
> into queues to be sent and forget them. Packets need to last in the
> system only until they are put on the wire. In normal situations, there
> is no reason to spend the CPU cycles or memory that would be required
> to remember which process created each packet sitting in a queue to be
> sent.
>
> The supposed "simple, small thing" of being able to find the process
> that sent a packet is either the large thing of changing the operating
> syustem to maintain PIDs or pointers in mbufs (or equivalents) or the
> not so small thing of inserting a shim between all applications on the
> system and all system calls that can send packets, and having the shim
> maintain enough state (or logs) so that it can guess and pick a process
> that probably sent a given packet. Other people have mentioned packages
> that sound to me as if they do the latter.
>
> Vernon Schryver v...@rhyolite.com


I guess netstat -o does neither of those. It's a small program that
with that switch, associates process id with a connection.

No doubt the code to do it can be put into a function and accessed via
the function's interface. A simple thing.

Worst case, a program like ethereal could run netstat -o and find the
process id. And assume it applies to all packets within that
connection.

Better case, it uses the function that netstat uses. This was what I
referred to as a simple thing for a programmer. Simple conceptually.

 

[Neil Pike]

Will - CommView from Tamos

Neil Pike
Protech Computing Ltd

 

[kingthorin@gmail.com]

On Oct 10, 3:26 am, "Will" <westes-...@noemail.nospam> wrote:
> Can someone recommend a sniffer for Windows that will show the process ID
> and name of the process sending or receiving each packet shown in the
> sniffer?
>
> I normally use ethereal or wireshark and didn't see a straightforward way to
> include this information.
>
> --
> Will

In WindowsXP you can use "netstat -ao" to see connections and the
associated process ID (which you can then patch to process IDs/
processes in task manager).

"netstat -p TCP -ao" if you only wanna see TCP and not UDP.

Pipe it to find if you want something specific, ie:
C:\>netstat -p TCP -ao|find "slashdot"
TCP machinename:2939 slashdot.org:http ESTABLISHED
3444
TCP machinename:2940 images.slashdot.org:http
ESTABLISHED 3444
TCP machinename:2942 images.slashdot.org:http
ESTABLISHED 3444

 

[Steven L Umbach]

Though tdimon is not actually a packet sniffer it may help in conjunction
with running a packet sniffer. It will show name but not process ID and
show time. Port reporter may be something else that can be used along with a
packet sniffer.

Steve


"Will" <westes-usc@noemail.nospam> wrote in message
news:x8Gdnapt9fED45HanZ2dnUVZ_veinZ2d@giganews.com...
> Can someone recommend a sniffer for Windows that will show the process ID
> and name of the process sending or receiving each packet shown in the
> sniffer?
>
> I normally use ethereal or wireshark and didn't see a straightforward way
> to include this information.
>
> --
> Will
>

 

[kingthorin@gmail.com]

On Oct 26, 3:54 pm, kingtho...@gmail.com wrote:
> On Oct 10, 3:26 am, "Will" <westes-...@noemail.nospam> wrote:
>
> > Can someone recommend a sniffer for Windows that will show the process ID
> > and name of the process sending or receiving each packet shown in the
> > sniffer?
>
> > I normally use ethereal or wireshark and didn't see a straightforward way to
> > include this information.
>
> > --
> > Will
>
> In WindowsXP you can use "netstat -ao" to see connections and the
> associated process ID (which you can then patch to process IDs/
> processes in task manager).
>
> "netstat -p TCP -ao" if you only wanna see TCP and not UDP.
>
> Pipe it to find if you want something specific, ie:
> C:\>netstat -p TCP -ao|find "slashdot"
> TCP machinename:2939 slashdot.org:http ESTABLISHED
> 3444
> TCP machinename:2940 images.slashdot.org:http
> ESTABLISHED 3444
> TCP machinename:2942 images.slashdot.org:http
> ESTABLISHED 3444

DOH that shoulda said "match" not "patch"..."(which you can then match
to process IDs) processes in task manager)"