|
Posted by jameshanley39@yahoo.co.uk on October 14, 2007, 6:44 pm
If you were Registered and logged in, you could reply and use other advanced thread options
On Oct 14, 8:07 pm, v...@calcite.rhyolite.com (Vernon Schryver) 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.
| 
XML site map