npcap 1.31 (back to at least 0.9987) does not capture all packets from windows 10 network bridge

[misterti]

When creating a network bridge in Win 10, many packets are missing from capture. Tests done:
WinPcap 4.1.3:

• created network bridge with 2 physical interfaces, Wireshark shows both bridged interfaces, not a network bridge, as available adapters. When starting capture on any of bridged interfaces, i can see all traffic properly.

npcap 0.9987:

• created same network bridge, Wireshark shows network bridge adapter, but not any of the adapters in the bridge. Started capture on network bridge, many packets are missing, like tcp, ntp, ... simply missing, and RTP packets just stop appearing randomly, or with a big delay.

The test is done with a device, a sip telephone, booting from one side of the bridge, where it does multiple network connections in the boot process, dhcp, ntp, http, tcp and finally sip and rtp. Tried also npcap in winpcap compatible mode, same results.

[fyodor]

I think this might be a duplicate of #116 and #117 (which have now been resolved). If you are still experiencing the problem with Npcap 0.9991 please post the details and this can be re-opened.

[mirozitnansky]

@fyodor this issue is still not resolved, as I understand it.
Even with version Ncap 1.1, there is still no way to capture packets going through windows bridged physical adapters,
while WinPcap allows you to capture packets on physical adapters event though they were bridged. Ncap doesn't see physical interfaces, only virtual windows bridge.
And on bridge it doesn't capture packets send over bridge, but not originated on pc on which bridge is configured.

Meaning you cannot sniff, what is external device connected to one of the physical ethernet port in bridge sending or receiving.

Will similar feature, as was on WinPcap capturing on bridged physical interfarces, implemented to Ncap in future? I found more questions like this unresolved with Ncap, i.e. https://ask.wireshark.org/question/1073/help-to-set-up-a-pass-through-bridge-sniffer/?answer=1082#post-id-1082

[misterti]

Tested on npcap 1.31, still missing a lot of packets, they simply do not show up in wireshark, Everything else is the same as OP

[misterti]

I'm requesting issue reopen.

[fyodor]

Thanks for the updates @misterti and @mirozitnansky . I'm re-opening. I'll change the title to note Npcap 1.31.

[mirozitnansky]

I just checked on version 1.55, behaviour is still the same on windows bridge adapter.

[dmiller-nmap]

This is an interesting problem. The cause is almost certainly a difference in how Windows routes traffic through the NDIS stack, since Npcap is a NDIS 6 Lightweight Filter Driver and WinPcap is a NDIS 5 Protocol Driver. But I cannot find any documentation on what a "network bridge" is within the NDIS environment. Lots of guides on how to create one with the Network Connections window or netsh.exe, but no info on how the adapters are modified or what kind of adapter the bridge itself is. NDIS or WFP docs would be best, but Powershell, .NET, or WMI docs would be great, too. I imagine I'll have to set one up and just poke at it for a while.

One potential suggestion: the original network adapters may be able to be opened for capture, even if they don't show up in Wireshark's listing. Try this procedure to see if it works (dumpcap.exe can be found in %ProgramFiles%\Wireshark\):

1. Before setting up the bridge, copy the names (e.g. "\Device\NPF_{228E384E-2D7D-442F-AA8A-48670412F016}") of the original adapters from the output of dumpcap.exe -D.
2. Set up the bridge as before.
3. Try to capture traffic from the original adapters using the names copied in step 1: dumpcap.exe -i "\Device\NPF_{228E384E-2D7D-442F-AA8A-48670412F016}" -w out.pcapng
4. Kill (Ctrl+C) the dumpcap.exe capture and open out.pcapng in Wireshark to see if any traffic was captured.

If that works, then the Npcap driver is capable of capturing on the adapter just like (though probably faster than) WinPcap did. The problem then becomes how to communicate that capability to libpcap and Wireshark. If it doesn't work, then we will probably have to look into it as part of #516, using WFP to capture this traffic instead, with a much longer fix timeline.

[mirozitnansky]

Ok I'll try as you suggested.
Also I noticed same behavior, when I am running virtual machine (in virtual box) which has bridge adapter configured/attached, with IP from LAN router on it.
When I try to sniff packet from virtual machine (LAN IP) and host computer (IP from same LAN) there is nothing caught.
All communication is running over one host physical interface but wireshark doesn't see it.

[mirozitnansky]

Ok I've tested it.
Before bridge configuration device list contained 2 physical devices

9. \Device\NPF_{03D160CC-12F2-47E2-AFA5-53AA9818BBA9} (Ethernet 2)
10. \Device\NPF_{9F95C33F-13C7-45C9-B225-2BABBE8D7863} (Ethernet)

After bridge configuration, these 2 are missing, 1 new appeared
8. \Device\NPF_{37644733-BFCE-4D84-B780-0A6C93D8405E} (Network Bridge)

dumpcap gives an error

PS C:\Program Files\Wireshark> .\dumpcap.exe -i "\Device\NPF_{03D160CC-12F2-47E2-AFA5-53AA9818BBA9}"
Capturing on '\Device\NPF_{03D160CC-12F2-47E2-AFA5-53AA9818BBA9}'
dumpcap: The capture session could not be initiated on capture device "\Device\NPF_{03D160CC-12F2-47E2-AFA5-53AA9818BBA9}" (Error opening adapter: The system cannot find the device specified.  (20)).
Please check that you have the proper interface or pipe specified. 

Npcap updated to 1.60, still not able to sniff communication from Ethernet2 to router, which is part of the bridge.

[Konstantin-Glukhov]

It's regrettable that npcap is unable to capture full traffic on the bridge on any bridged interface. This feature is really useful to creating taps without additional hardware (or installing WinPcap instead). Please make it work if possible.

[guyharris]

The system cannot find the device specified. (20)).

Error 20 is ERROR_BAD_UNIT. OSR's handy table of NT status to Windows error code mappings doesn't show any NT status that maps to ERROR_BAD_UNIT, which suggests that this isn't a driver error (as driver errors are NT status codes, not Windows error codes).

The packet32.dll code will return ERROR_BAD_UNIT if PacketGetNetInfoEx() doesn't find the adapter GUID in the list returned by GetAdaptersAddresses().

The error message in question comes from a call to PacketOpenAdapter(); I'm not being any immediately obvious way in which PacketGetNetInfoEx()` gets called in that case.