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

[Ashish <rasteashish@xxxxxxxxx>]

Hi all,

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 etc.?

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 submitting it.

Thanks!

Best,

--

Ashish