mailing list archives
GSoC 2013: Process Information
From: Ashish <rasteashish () gmail com>
Date: Wed, 24 Apr 2013 18:26:11 +0800
This mail is in reply to the mail sent (below) by Kostadin.
I'm contacting you with an intent to request some further info about the
task "Process Information" as found on the Wireshark's Google Summer of
Code 2013 project page.
After a short research on the matter, I cant help but suspect/am getting
drawn to the conclusion that this task is too simple for a full project
commitment, which is then again challenged by the thought I might be
overlooking the complexity of it.
I'm interested to work on this project and I'm going to apply for it. Even
I thought it to be a simple task when I read it on the ideas page for the
first time. But after going through some related literature, I understand
that it would take a decent summer time to complete that task.
This task seems like it can be done feasibly well by making a call in C to
the commands netstat and tasklist on Windows and netstat or ss on Linux and
looking up the port given in the Layer 4 packet info in Wireshark in the
command output. But I dont know the time efficiency of this, so maybe a
direct kernel access would be prefered?
However I noticed that when looking up the port of an UDP packet, the port
often closes quicky and cant be found in the table (I recall someone
adressing this issue in the bug page given as a reference), so I suppose a
solution to this could be a working set data structure, which remembers the
set of recently used ports and their PIDs - as to reduce memory
consumption. I would appreciate feedback on this idea.
Yes, remembering the port in a struct form would be one task but you can't
just correlate a recently used port to any packet that comes within a
millisecond or a lesser time interval. Pardon me if I have understood your
"remembering" part wrong.
Also the methods of making a method to call netstat won't be efficient,
from my knowledge, since I believe that netstat relies polling mechanisms
which you can't rely on to capture short bursts of packets. Reason? The
same as above.
@others: Can anyone confirm that the Packet Information task is not so
simple (as it looks) as in just having a struct with a port number of a
network socket and pulling in info from existing tools like netstat, lsof
I feel that packets should be handled at the kernel level i.e using
Netfilter's hooks and other kernel structures/objects
which can reveal the port information at Layer 3 or a packet's source
information at Layer 4.
It would be really grateful if someone brainstorms (with me) on this idea
so that it would be helpful for me to revise/update my proposal before
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
- GSoC 2013: Process Information Ashish (Apr 24)