Wireshark mailing list archives
Re: GSoC 2013: Process Information
From: Anders Broman <a.broman () bredband net>
Date: Wed, 24 Apr 2013 21:10:58 +0200
Gerald Combs skrev 2013-04-24 20:20:
Process info is entirely useless when capturing of a mirror/pawn port so it should be an option to add it.On 4/24/13 3:26 AM, Ashish wrote: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/objectswhich can reveal the port information at Layer 3 or a packet's sourceinformation 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.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.
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. The project should also consider authorization. We've been trying to get people to stop running Wireshark as root for the better part of a decade and gathering process information shouldn't impede (much less reverse) that effort. ___________________________________________________________________________ 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
___________________________________________________________________________ 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)