Wireshark · Wireshark-dev: Re: [Wireshark-dev] GSoC 2013: Process Information

[Anders Broman <anders.broman@xxxxxxxxxxxx>]

 

 

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Ashish
Sent: den 25 april 2013 16:11
To: wireshark-dev@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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.