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.

@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

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

I'm requesting issue reopen.

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

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

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.

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.

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.

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.

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.

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.

That matters only in the Wireshark GUI, as it doesn't let you specify an arbitrary string to be handed to libpcap as a device name to open. The command-line tools don't have that limitation, and dumpcap is a command-line too, so the scenario in this earlier comment isn't a case of "Wireshark doesn't know about the device", it's a case of "Npcap won't let you open that device".

As that scenario says:

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)

which indicates that pcap_findalldevs() is finding the two Ethernets before bridge configuration and not finding the, but finding the bridge device, after bridge configuration. That means that PacketGetAdapterNames() isn't finding the Ethernet devices after bridge configuration. In the current Npcap repository code, the code path for PacketGetAdapterNames() involves getting a list of adapters with GetAdaptersAddresses() and adding them to the list iff PacketGetAdapterHandle() succeeds. So it appears that either 1) GetAdaptersAddresses() isn't finding the Ethernet devices or 2) it finds them but PacketGetAdapterHandle() fails on them; my guess is that it's 2).

I believe we can resolve this behavior by modifying the NdisImPlatformBindingOptions parameter in npcap.inf, based on this OSR post by @jtippet. It sounds as if a value of 2 here would allow Npcap to see both the physical NICs as well as the bridge. @hsluoyz tried this back in 2016 without success, but we have made a lot of improvements to Npcap since then that may help.

Is it possible to test this modifying installed c:\Program Files\Npcap\npcap.inf directly?
If so, is restart or any other kind of "refresh" required?

I would also be interested in testing those changes.

This may be related to #534. Although I tested 1.71 release and it doesn't seem solved.