Missing traffic in Npcap Loopback Adapter

[Simran-B]

• Npcap 0.99-r6
• Wireshark 2.6.1 64-bit
• Windows 10 Pro 1803 64-bit

I used the Npcap 0.99-r6 installer and ticked the options for the loopback adapter and compatibility mode. Also reinstalled Wireshark to make sure it recognizes Npcap (it previously used WinPCap, but I removed it together with Wireshark before reinstallation).

The adapter is listed in ipconfig:

Ethernet-Adapter Npcap Loopback Adapter:

   Verbindungsspezifisches DNS-Suffix:
   Verbindungslokale IPv6-Adresse  . : fe80::147b:3104:db9:6f2%9
   IPv4-Adresse (Auto. Konfiguration): 169.254.6.242
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . . :

The service is running fine:

C:\WINDOWS\system32>sc query npf

SERVICE_NAME: npf
        TYPE               : 1  KERNEL_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

I can capture "normal" internet traffic on "Ethernet 2" adapter, and also saw some traffic on the loopback adapter:

but if I run something simple like ping 127.0.0.1 it doesn't show up.

I also tried a web interface of a database system (localhost) and a Minecraft server (127.0.0.1:25565). Pinging my network IP or the loopback adapter doesn't show either. Also rebooted and tried again with and without promiscuous mode, but with the same result. Am I missing something obvious?

Log files: Npcap_logs.zip

[dmiller-nmap]

@Simran-B Thanks for the report. I can confirm this happens when Npcap is installed in WinPcap API-compatibility mode, which is caused by Wireshark preferring WinPcap over Npcap. WinPcap did not offer loopback capture, so Npcap's WinPcap-compatible API does not, either. The Npcap native API is installed alongside the WinPcap API, and can still properly capture loopback traffic (I tested this using Nmap and the targets-sniffer NSE script).

So here are the 2 causes and ways ahead:

1. Wireshark uses WinPcap when it finds it instead of Npcap. We are working with the Wireshark developers to change this, since Npcap has become much more stable and WinPcap is no longer supported.
2. Npcap in WinPcap API-compatible mode does not provide loopback traffic capture. We are not going to put effort towards fixing this since WinPcap API-compatible mode is a temporary shim to allow the ongoing use of software which has not been updated to use Npcap directly. Wireshark does use Npcap directly when it is the only installed option, so that is the preferred configuration.

[Simran-B]

@dmiller-nmap Thanks for your response. So Wireshark prefers WinPcap over Npcap if both are installed, do you understand that right? And if there is only Npcap without compatibility mode enabled, will Wireshark detect and use Npcap and thus loopback capturing work?

[dmiller-nmap]

@Simran-B Yes, that's correct. If WinPcap (or Npcap in WinPcap API-compatible mode) is not installed, Wireshark will correctly use Npcap and permit loopback capture.

[Simran-B]

Thanks again, ping 127.0.0.1 traffic shows up now that I re-installed Npcap without WinPcap compatibility as well as Wireshark to pick up Npcap correctly:

[dmiller-nmap]

We have added a fix for this and a workaround is available: https://github.com/nmap/nmap/issues/1213#issuecomment-402850154

However, it is not guaranteed that loopback traffic capture will be supported in WinPcap mode in the future. Software developers are encouraged to use Npcap directly.

[reidmefirst]

I've recently installed Wireshark 3.0 and npcap 0.9.9-r9 on Win7x64sp1 (specifically installed npcap with no winpcap api support, and wireshark recognized it as installed when I installed wireshark), and I'm seeing the original behavior in this thread: on the npcap loopback interface I see packets with a destination address of 127.255.255.255 as well as traffic with a multicast destination, but I never see any traffic where both src and dst ip 127.0.0.1, such as icmp echo requests/replies to localhost or tcp/udp connections to localhost. It's almost like there is a capture filter automatically happening that filters packets with localhost as the destination IP or destination mac address.

Just figured I'd ask here since it seems some folks have dug into into this in the past, I wonder if some related loopback capture bug may been recently introduced...if not then I suppose I'll start over with a fresh VM =).

[Simran-B]

I ran it natively, i.e. not virtualized IIRC. In a VM it might be vastly different. Doesn't VirtualBox come with its own pseudo-adapter and pipe data between host and guest somehow? It might also affect local traffic inside the VM, but I'm guessing wildly here...

[travnick]

@reidmefirst Same behavior here. Win10 pro. Tested with few combinations of: npcap 992, 991, 99-r7 (WinPcap compatibility disabled) wireshark 3.0.0, 3.0.1, 2.6.3 full remove, restarts, nothing helps, ping 127.0.0.1 is not visible

note: Few times I've checked the WinPcap compatibility, but it was about 10 reinstallations and restarts ago).

--edit: Wow .... I realized that after all of this, there are many interfaces created (Ethernet 2, Ethernet 3, Npcap Loopback Adapter) with description "Npcap Loopback Adapter" When capturing on "Ethernet 3" then there are all packets ...

I would not expect that there are some rubbish network interfaces left after uninstalations

[Simran-B]

Well, I tried Pritunl as a replacement for OpenVPN recently, but didn't work with my VPN configuration, so I uninstalled it. Then I realized that it had uninstalled the adapter used for VPN. I had to reinstall OpenVPN to make it usable again. Therefore I don't mind some extra virtual adapters which I can remove manually rather than having to reinstall to get an adapter back which was automatically removed.

[eben-roux]

Thanks @travnick !

I had the same. The "Npcap Loopback Adapter" was not capturing my 127.0.0.1 traffic but instead my "Ethernet 5" was capturing it.