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
___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe
