I have been looking around for a way to match packets to processes as well. For Windows XP there is the IP Helper API which uses TcpEx (EX for extended) and UdpEx functions that can get process id and socket pairs. With this and some decoding of packets one can then look at the protocol and port and determine which process sent or received the frame. For Win2k I have not been able to find the equivalent functionality. I tried an application (the one that is from http://www.codeproject.com/csharp/iphlpapi.asp- see the original message) that uses IP Helper API. On WinXP it works fine but the extended calls do not work on Win2k- they produce amessage about "DLL entry point not found."

I did find one email message somewhere that said that TcpView used SNMP on Win2k but I have not been able to verify that. One bit of information that supports this theory is the the fact that the IP Helper API uses "MIB_" in the naming scheme and SNMP uses mibs so maybe. A list of SNMP mibs supported under win2k is available but I have not walked through the list to see if the information needed is available. MIB list is at- http://www.microsoft.com/resources/documentation/windows/2000/server/reskit/en-us/tcpip/part4/tcpappg.mspx
Terry



Marcin ZajÄczkowski wrote:

Dnia 2004-09-01 20:06, UÅytkownik Guy Harris napisaÅ:

On Sep 1, 2004, at 9:17 AM, Gianluca Varenni wrote:

From: "Marcin ZajÂczkowski" <[EMAIL PROTECTED]>

I want to ask is it possible to determinate using WinPcap which
application on local machine sent/received captured packet?


No, winpcap is not able to understand this.

I know that tcpview (www.sysinternals.com) is able to display such info,


What it appears to do is enumerate TCP and UDP sockets on the machine on which it's run, and show the process on that machine that owns the socket, so it doesn't even give that information on a per-packet basis - it gives it on a per-*socket* basis.

WinPcap could give you the raw packet data, and if some WinPcap application could *also* get the information that TCPView gets, that application could try to figure out whether a given IP packet would have been sent on or delivered to a particular socket, figure out the process to which that socket belongs, and get the process's executable image name, but I don't know how TCPView gets that information (the Sysinternals people say that the "netstatp" sample program to which they supply source *doesn't* show process names).


Thanks for answers.
I've looked into this source and indeed process names aren't showed. But it gave me used function names (especially pCreateToolhelp32Snapshot and AllocateAndGetTcpExTableFromStack). With this I found interesting ???.
http://www.codeproject.com/internet/enetstatasp.asp?df=100&forumid=26194&exp=0&select=792017


http://www.codeproject.com/csharp/iphlpapi.asp?target=netstat
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/perfmon/base/process32first.asp


This allow me to modify netstatp sources and I can see process names.

I think Winpcap allows to get source and destination port and address, so with this I could count transferred data to display each connection speed. Am I right?
Unfortunately I'm going to write soft which allow me to display transfer rate of specific process (aplication) and with ability to limit every connection to pointed speed like:
NetLimiter - http://www.netlimiter.com/
NetPeeker - http://www.net-peeker.com/


I'm afraid that to do this I have to write my own driver (NDIS or TDI). Maybe watching abilities could be done by Winpcap and to control I could use my driver? But I'm not sure is it sense to spread this functions.
Maybe You can recommend some good sites with tutorials about network drivers and the way to exchange information between them and user level applications to present informations?


Regards
Marcin




================================================================= This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/

To unsubscribe use
mailto: [EMAIL PROTECTED]
=================================================================

Reply via email to