I'm investigating an issue with a process that performs IPC via a socket. The socket is served on the local machine's NIC's IP, and the connection is made to the local machine's NIC's IP from another process on the local machine.
I expected that this would drop down the Windows networking stack at least far enough that Wireshark could see the packets. However, it appears that this is not the case. Therefore, I can conclude that socket IPC takes place higher in the stack [would be interesting to see if any windows event tracing (ETW) facilities would see the traffic as an IP frame]. This isn't important to this question (since this isn't stackoverflow).
Where does WinPcap/Npcap "live" in the networking stack to listen for and pass packets to wireshark?
I'm focused on modern Windows OS versions (client: 7+, 10+; server: 2008+, 2012+, 2016+). Specifically, this client is Windows 10.
I effectively want to know where in the network stack the decision is made to "loop back" the packets to the host instead of sending them down the stack.
Thanks
It is at the IP layer, unless Fast Loopback is enabled, then it is at the TCP layer. Applications such as Network Monitor or Wireshark don't work due to the Microsoft network stack is not instrumented for capturing loopback traffic.
"The default behavior of the TCP loopback interface is to move local TCP traffic through most of the network stack, including AFD (which is essentially the kernel mode representation of a user mode TCP socket), as well as the layers corresponding to TCP and IP protocol layers."
https://blogs.technet.microsoft.com/wincat/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path/
As an alternative, you may be able to capture on the Windows Filtering Platform (WFP) layer using Microsoft Message Analyzer:
https://blogs.msdn.microsoft.com/winsdk/2014/08/15/rejoice-we-can-now-capture-loopback-traffic/