Re: GSoC 2013: Process Information

[Anders Broman <anders.broman () ericsson com>]

From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Ashish
Sent: den 25 april 2013 16:11
To: wireshark-dev () wireshark org
Subject: [Wireshark-dev] GSoC 2013: Process Information

Hi,
By mistake I sent a reply to wireshark-dev without editing the subject. Please find my reply below.



On Apr 24, 2013, at 11:20 AM, Gerald Combs <gerald () wireshark org<mailto:gerald () wireshark org>> wrote:

> Polling the system's TCP and UDP connection tables is trivial but its
> usefulness is limited since it assumes that your interesting traffic has
> a corresponding table entry at the instant you poll. This may not be the
> case for short-lived connections such as DNS or DHCP and it certainly
> won't be the case for ICMP or non-IP protocols.

I am approaching this problem from Linux point of view. Is it okay if I propose a solution to this problem from Linux 
perspective(for some cases) and extend it to Windows/Mac wherever applicable?

1. Assuming that the short-lived connections of DNS/DHCP have their traffic between a pair of polling period of 
netstat, can we read those packet's data from the kernel for correlating their sockets? And hence following an approach 
where any new packet's(which is not attributed to a process yet) process information is taken from netstat and for a 
packet in a non-correlated flow should have its data be read from the kernel?
I am sceptical on attributing a short-lived packet to a correlated flow and a non-correlated flow and not sure whether 
this approach is feasible for ICMP or non-IP protocols as you mentioned.
> System event tracing (e.g. Event Tracing for Windows, dtrace, or
> whatever happens to be popular on Linux this month) or Guy's suggestion
> of exposing process information through libpcap would be better, but
> neither are trivial.

Exposing it through libpcap requires a way to get it on the underlying OS, which, again, should involve watching for 
PCB (Process Control Block) creation and destruction rather than polling the tables if at all possible.

It would probably be best if the platform-dependent stuff were done in libpcap, if possible, so that it only has to be 
done in the library, not every application (libpcap's main role in life is to hide platform dependencies from 
applications, after all), but that wouldn't, by itself, let you get notified of the creation and destruction of PCBs.
I didn't think in this direction. Thanks! Is this method applicable for short-lived packets?


On Apr 24, 2013, at 12:10 PM, Anders Broman <a.broman () bredband net<mailto:a.broman () bredband net>> wrote:

> Process info is entirely useless when capturing of a mirror/pawn port

...or in monitor mode on Wi-Fi, or in promiscuous mode on a non-switched Ethernet, or with some type of passive tapping 
hardware (Endace DAG cards, etc.)...

> so it should be an option to add it.

Yes.

There are, at some level, two modes for using a packet sniffer:

        1) watching traffic to and from the machine on which the sniffer is running;

        2) passively watching third-party traffic.

Process information is only available, in the general case, in the first of those modes.

> I am assuming that this project applies to first mode as stated by Guy Harris above. Is it okay if we do not discuss 
> (in our >proposal) about watching third-party traffic as that part needs a method to get the information on processes 
> running on other >systems?
I was trying to make the point that this feature should be configurable e.g. possible to turn off.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe