Wireshark mailing list archives
GSoC 2013: Process Information
From: Ashish <rasteashish () gmail com>
Date: Thu, 25 Apr 2013 22:10:42 +0800
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> 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> 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? Thanks! Best, -- Ashish
___________________________________________________________________________ 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
Current thread:
- GSoC 2013: Process Information Ashish (Apr 24)
- Re: GSoC 2013: Process Information Gerald Combs (Apr 24)
- Re: GSoC 2013: Process Information Anders Broman (Apr 24)
- Re: GSoC 2013: Process Information Guy Harris (Apr 24)
- Re: GSoC 2013: Process Information Guy Harris (Apr 24)
- Re: GSoC 2013: Process Information Anders Broman (Apr 24)
- <Possible follow-ups>
- GSoC 2013: Process Information Ashish (Apr 25)
- Re: GSoC 2013: Process Information Anders Broman (Apr 25)
- Re: GSoC 2013: Process Information Gerald Combs (Apr 24)