none
How to get process ID of NON-TCP/UDP packet with WFP architecture RRS feed

  • Question

  • Hi,

    I have implemented a WFP kernel driver to capture relation between process ID and outbound packet. I get process ID via the "meta data" data structure from  ALE layers, and it works well for TCP/UDP protocol. but for NON-TCP/UDP protocol, e.g. ICMP or ICMPv6, I encounter some issues:

    Scenario:ping  IP address (IPv4 or IPv6) with ping.exe, I found ALE_AUTH_CONNECT layer interrupt the command, but inMetaValues->processId is 4(for system) not process ID of ping.  I tries to use PsGetCurrentProcessId to replace the process ID, but obviously it is error, sometimes current process ID is for random process.

    I tested Microsoft Network Monitor tool, and it also can't identify ID of process, it cite"unknown".

    I want to know whether it is a bug? and how to implement the function(to get process ID of sending NON-TCP/UDP packet), please help me.

    Thanks,

    Rick Wang

    Monday, January 7, 2013 3:58 AM

Answers

  • This is by design.  Ping.exe uses ICMP's native socket, which is owned by the system.  If you were to create your own app using RAW ICMP, then the PID would be for that app.

    Hope this helps,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------


    Monday, January 7, 2013 4:06 PM
    Moderator

All replies

  • This is by design.  Ping.exe uses ICMP's native socket, which is owned by the system.  If you were to create your own app using RAW ICMP, then the PID would be for that app.

    Hope this helps,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------


    Monday, January 7, 2013 4:06 PM
    Moderator
  • Thanks, Dusty.
    Tuesday, January 8, 2013 6:20 AM