mailing list archives
Re: Wireshark-dev Digest, Vol 83, Issue 53
From: Ashish <rasteashish () gmail com>
Date: Thu, 25 Apr 2013 22:02:15 +0800
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.
I didn't think in this direction. Thanks! Is this method applicable for
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.
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,
so it should be an option to add it.
There are, at some level, two modes for using a packet sniffer:
1) watching traffic to and from the machine on which the sniffer
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's system?
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
- Re: Wireshark-dev Digest, Vol 83, Issue 53 Ashish (Apr 25)