Re: Sniffer for Windows That Shows Process ID?
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