detection and naming of available interfaces unusable on Windows 10

[sindy39]

Hello,

I've given a try to npcap-nmap-0.06-r7 downloaded from here as an installer (I am unable to compile from source) as a replacement (i.e. no coexistence mode) to WinPcap 4.1.3 which came along with Wireshark 2.0.2. My OS is a 64-bit Win10 (Czech language version and a result of upgrade from Win 7 if that may matter).

Two issues, which may or may not be related to each other, exist when detecting and naming network interfaces on Win 10.

First, in Win10, the interface names shown at the GUI are completely unrelated to the names shown using ipconfig (see below & attached screenshot), so the interface names presented in Wireshark are totally inconsistent with those shown in the GUI list. The "human-readable" ones given by ipconfig are not really useful as they are just "local network interface N" and there is no clue regarding their relationship to the "physical" interfaces. It may actually be a Win10 issue but it seems that WinPcap has managed to overcome it somehow.

Second, much worse, is that when a physical interface is part of a software bridge, npcap does not report any of the two to the querying application, which means that it is impossible to capture on either of them. This was not a problem with WinPcap on Win 7; I cannot say at the moment whether it was the Win 7 -> Win 10 change or the WinPcap -> npcap change which has broken this.

What additional information do you need from me to help identify the issue?

>"c:\Program Files\Wireshark\dumpcap.exe" -D 1. \Device\NPF_{5DA27B50-00C1-4524-9099-21B3B108AD7E} (Připojení k místní síti* 11) 2. \Device\NPF_{FB07DEB9-1926-4370-8395-0B9369D7BA04} (Bezdrátové připojení k síti) 3. \Device\NPF_{28D70F40-9ACB-440A-8462-4D54F7A371D2} (Připojení k místní síti* 2) 4. \Device\NPF_{A30ACB87-2138-4BB9-AAB9-50E4607A3A4D} (Připojení k místní síti* 13) 5. \Device\NPF_{DAFB87ED-6299-4F52-9DCA-94D031827F93} (Připojení k místní síti* 12) 6. \Device\NPF_{FC88C8FA-231B-4A82-97B7-34B92E9BBAD8} (Připojení k místní síti* 5) 7. \Device\NPF_{DEAE2170-9327-4CCE-967D-7A1AFF31A5EA} (Síťové připojení Bluetooth) 8. \Device\NPF_{01CABFD8-5D7D-4A57-9958-5098213B1AE4} (Npcap Loopback Adapter)

`> ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : sindelka-HP Primary Dns Suffix . . . . . . . : sindelka-HP Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : sindelka-HP

Wireless LAN adapter Připojení k místní síti* 2:

Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter Physical Address. . . . . . . . . : 8C-70-5A-4C-43-65 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Připojení k místní síti* 5:

Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft Hosted Network Virtual Adapter Physical Address. . . . . . . . . : 8E-70-5A-4C-43-65 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes

Ethernet adapter Npcap Loopback Adapter:

Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Npcap Loopback Adapter Physical Address. . . . . . . . . : 02-00-4C-4F-4F-50 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::eccf:dc7c:114e:aedf%12(Preferred) Autoconfiguration IPv4 Address. . : 169.254.174.223(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : DHCPv6 IAID . . . . . . . . . . . : 201457740 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-8A-F4-4D-A0-B3-CC-CC-7C-70 DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Síťový most:

Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft Network Adapter Multiplexor Driver Physical Address. . . . . . . . . : A0-B3-CC-CC-7C-70 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::b905:3c14:99d7:e306%9(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.10.90(Preferred) Subnet Mask . . . . . . . . . . . : 255.0.0.0 Lease Obtained. . . . . . . . . . : 14. března 2016 15:44:40 Lease Expires . . . . . . . . . . : 17. března 2016 15:44:39 Default Gateway . . . . . . . . . : 192.168.10.1 DHCP Server . . . . . . . . . . . : 192.168.10.1 DHCPv6 IAID . . . . . . . . . . . : 161526732 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-8A-F4-4D-A0-B3-CC-CC-7C-70 DNS Servers . . . . . . . . . . . : 81.19.34.2 81.19.33.2 NetBIOS over Tcpip. . . . . . . . : Enabled

Wireless LAN adapter Bezdrátové připojení k síti:

Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : lan Description . . . . . . . . . . . : Intel(R) Centrino(R) Advanced-N 6205 Physical Address. . . . . . . . . : 8C-70-5A-4C-43-64 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes

Ethernet adapter Síťové připojení Bluetooth:

Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Zařízení Bluetooth (síť PAN) Physical Address. . . . . . . . . : C0-18-85-F1-77-8C DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.{01CABFD8-5D7D-4A57-9958-5098213B1AE4}:

Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft ISATAP Adapter nmap/nmap#4 Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.{2F713036-D16D-46AE-BDAC-1BACFCD651BD}:

Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft ISATAP Adapter nmap/nmap#5 Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes`

[hsluoyz]

Hi Pavel,

First, in Win10, the interface names shown at the GUI are completely unrelated to the names shown using ipconfig (see below & attached screenshot), so the interface names presented in Wireshark are totally inconsistent with those shown in the GUI list. The "human-readable" ones given by ipconfig are not really useful as they are just "local network interface N" and there is no clue regarding their relationship to the "physical" interfaces. It may actually be a Win10 issue but it seems that WinPcap has managed to overcome it somehow.

The adapter names issue happens one time before, friendly names are not displayed at that time. And that issue has been solved by the commit: https://github.com/nmap/npcap/commit/fe9aec81b3a3d4213616a526adf007fc1355d4dc

Currently my Win10 doesn't show the unfriendly names any more. So I want to ask have you installed any network drivers that can possibly be incompatible with Npcap?

Second, much worse, is that when a physical interface is part of a software bridge, npcap does not report any of the two to the querying application, which means that it is impossible to capture on either of them. This was not a problem with WinPcap on Win 7; I cannot say at the moment whether it was the Win 7 -> Win 10 change or the WinPcap -> npcap change which has broken this.

How to make a software bridge?

[gvanem]

How to make a software bridge?

Select 2 adapters, right click and select Create bridge for those 2 adapters. Like:

In Norwegian: bro == bridge.

But the situation is even worse when considering tcpdump names + descriptions. From tcpdump -D:

1. \\BlueToothDevice\#1
2. \\.\airpcap00
3. \Device\NPF_{E069AC87-4219-4F7E-9CA5-DE3FBA031CEF}
4. \Device\NPF_{990D25A5-6071-4C67-AC14-A5380B0FFDEC}
5. \Device\NPF_{7BA27187-146B-4FB6-B4BA-DC5D218FB607}

Versus dumpcap -D:

1. \\BlueToothDevice\#1 (BlueTooth Device nmap/nmap#1)
2. \\.\airpcap00 (AirPcap USB wireless capture adapter nr. 00)
3. \Device\NPF_{E069AC87-4219-4F7E-9CA5-DE3FBA031CEF} (Wi-Fi)
4. \Device\NPF_{990D25A5-6071-4C67-AC14-A5380B0FFDEC} (Bluetooth Network Connection)
5. \Device\NPF_{7BA27187-146B-4FB6-B4BA-DC5D218FB607} (Ethernet)

dumpcap has another idea of adapter descriptions than libpcap has.

[sindy39]

@gvanem, what difference do you have in mind? The mapping of item numbers (1.-5.) to hashed names (\Device\NPF_{cryptic-hex-string}) is the same in both cases, the only difference between them is that dumpcap shows the friendly names while tcpdump doesn't, and I would hesitate to blame Npcap for this as it may as well be a tcpdump issue.

[gvanem]

.. and I would hesitate to blame Npcap for this..

I wasn't blaming Npcap. Just a general observation.

[sindy39]

@hsluoyz , to answer your first question: the b-dy Win10 actually seems to hide some interfaces in one view while it shows them in the other one. So disabled interfaces are shown in the GUI list but not listed by ipconfig, while special purpose interfaces (like Wi-Fi Direct Virtual adapter) are listed by ipconfig but not in the GUI list.

That has confused me in combination with the fact that the physical Ethernet was hidden while it was part of the bridge. So after deleting the bridge, I've got an additional item in dumpcap -D output, representing the physical interface, and its friendly name is the same for both the ipconfig and the GUI. The bunch of "ipconfig names" which have no identifiable counterparts among the "GUI names" continues to exist too, though.

Additional point - as Windows do not let you create a bridge over a single interface (which is logical in one way but not so much in another as you can then remove a member interface from an existing bridge and the bridge continues to exist), I had to connect the USB 3.0 Gigabit Ethernet adaptor in order to be able to set up the bridge again. This has highlighted the fact that Npcap ignores this interface completely - with or without a bridge configured, and regardless the total number of interfaces available (I was suspecting some limit, so I've disabled the onboard Ethernet and although dumpcap -D doesn't show it any more, the USB adaptor hasn't popped up either). In the USB adapter settings, Npcap is ticked in the list of attached drivers. Is this worth a separate issue?

[hsluoyz]

@sindy39

Additional point - as Windows do not let you create a bridge over a single interface (which is logical in one way but not so much in another as you can then remove a member interface from an existing bridge and the bridge continues to exist), I had to connect the USB 3.0 Gigabit Ethernet adaptor in order to be able to set up the bridge again. This has highlighted the fact that Npcap ignores this interface completely - with or without a bridge configured, and regardless the total number of interfaces available (I was suspecting some limit, so I've disabled the onboard Ethernet and although dumpcap -D doesn't show it any more, the USB adaptor hasn't popped up either).

It's not surprising if Npcap doesn't support a USB adapter. Because I don't have one and have never tested Npcap on that.

Actually the adapter list used by Npcap is from registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318} You can see if your missing adapters (the bridged ones and the USB one) are there. If they don't exist in that registry key, then Npcap has no way to show them.

Another thing I want to know if how WinPcap behaves in all the conditions you said? Npcap attempts to implement at least all the functions of WinPcap. So for example, if WinPcap doesn't support a USB adapter, then it's understandable that Npcap doesn't support it either. In fact, I know a software called USBPCap, it's especially for USB capturing.

[sindy39]

Hi Yang,

I hate mysteries. At some stage of disabling various unstoppable NDIS drivers in the registry and rebooting, npcap started showing the USB GigE adaptor and even the software bridge and can capture on them (although it is also affected by nmap/nmap#335 ), but as I wasn't expecting that to happen, I have only noticed it by chance so I am unable to say after which exact step this has happened.

What I do know for sure is that I've first switched the machine off when the USB adaptor was already running, then started it again with the USB adaptor plugged in, and npcap still did not show it. So the reboot alone is not the reason for it to miraculously come up => the exercises with drivers had to affect it somehow.

As for the existence of the bridge affecting the availability of the member adaptors: this zip file contains the exports of my registry (.reg and .txt) with and without the bridge (which is represented by item 0025). The bridge is made of the USB adaptor (item 0007, ASIX AX88179 USB 3.0 to Gigabit Ethernet Adapter) and the onboard Ethernet adaptor (item 0002, Intel(R) 82579V Gigabit Network Connection).

As the WinPcap shows both adaptors regardless whether they are members of the bridge or not (this is a reply to your question), while Npcap shows only non-members (once the bridge has been created, you may modify the member list), I suppose there is some attribute in the registry which makes your analysis conclude that an adaptor in this state is not worth using.

As for USBPcap - yes, I do use it as well for other purposes, but there is no point in dissecting the USB packets to see the Ethernet traffic as the USB GigE adaptor driver seems to create a virtual NIC to which a network driver is attached. The InstalledDriversList doesn't show any group for that driver, but that doesn't seem to matter to npcap.

[hsluoyz]

Hi @sindy39 ,

I bridged two network adapters (an Ethernet adapter and Npcap Loopback Adapter). Then BSoD occurs. It seems that Npcap still has compatible issue with the bridging.

[sindy39]

It seems I am more lucky in this regard. I've only managed to kill the machine by starting Wireshark so that it would show the list of available interfaces, then renaming the bridge from Ethernet to Ethernet bridge, and then pressing F5 in Wireshark. Immediately I've got an announcement that the machine has to be rebooted due to an unrecoverable error. Modifications of the list of bridge members were safe from this point of view.

I haven't tried to make the Npcap Loopback Adapter a member interface of a bridge because I cannot see other purpose in doing so than testing how Npcap handles bridging. In Wireshark, you don't need to put two interfaces to a bridge so that you could capture on both of them: you can capture on several interfaces simultaneously, and npcap seems to handle that nicely.

The purpose of using a network bridge together with *pcap which is important for me (and probably others too) is that sometimes you need to capture in the field and as hubs have been long gone, the only thing you can do is to insert the monitoring device "into the cable" between the device under analysis an the switch. And a USB "tail" is much more handy to carry around than a manageable switch capable of traffic monitoring.

For your testing purposes, bridging of a wireless interface with a wired one should be BSoD-safe. If your test machine has just a single wired Ethernet interface, it should be enough to plug in a USB (or ExpressCard) Ethernet card only once, create the bridge, and return the add-on card to the owner. Once created, the bridge survives subsequent reboots even with a single member interface.

Or, if comparison of the two sets of registry information yields a good candidate parameter to ignore when choosing interfaces to be reported, I'm ready to test another release.

For me the possibility to use the loopback interface was not the primary motivation to give Npcap a try, although I'm sure I'll use it too as I already did have use cases for it in the past. For some time it seemed that Npcap will be the only *pcap to work at Win10, so I wanted to give it a try even after finding out that WinPcap works fine on my PC even after the upgrade. I suspect it is related to the fact that the currently available drivers for my hardware do not use the NDIS 6 model so it may change in future.

[hsluoyz]

Hi,

Let's solve the issues one by one.

The dumpcap -D output of Npcap is unfriendly.

In fact, I didn't encounter this issue. Npcap shows the same names as WinPcap. You need to provide reproduce steps for me to confirm it.

Npcap doesn't show the bridge.

The answer is, try to restart the Npcap driver (net stop npf and net start npf). Then the bridge will show up in Wireshark. I tried this by myself.

Npcap doesn't show the USB adapter.

I have just released Npcap 0.06 R7.2. It enlarges the range of supported adapters, like VMnet adapters. I guess a USB adapter is the same condition. You can try R7.2 then provide me the feedback.

https://github.com/nmap/npcap/releases

Cheers, Yang

[hsluoyz]

Hi,

Now the bridge will not cause BSoD of Npcap. Try lastest Npcap 0.06 R8 at: https://github.com/nmap/npcap/releases

[sindy39]

Hi Yang,

I'll deal with the misunderstandings one by one. I apologize for not being clear.

sindy39: The dumpcap -D output of Npcap is unfriendly. hsluoyz: In fact, I didn't encounter this issue. Npcap shows the same names as WinPcap. You need to provide reproduce steps for me to confirm it.

You are right that the format of information is the same for both Npcap and WinPcap, and I didn't complain about that. But my issue was that the contents is not - interfaces which are currently members of a bridge are listed by WinPcap but not by Npcap. The bridge interface itself is shown by both.

And this is still true with R8.

The reason why I ask for the possibility to capture at a physical interface which is a member of a bridge, and not at the virtual one which represents the bridge to the higher layers of the network stack, is that I was never brave enough to believe that capturing on the bridge, even in promiscuous mode, would show me all packets being forwarded from one member interface to another. And typically I am interested exactly in the transit traffic, not the one terminating/originating at the capturing PC.

sindy39: Npcap doesn't show the bridge. sindy39: Npcap doesn't show the USB adapter. hsluoyz: The answer is, try to restart the Npcap driver (net stop npf and net start npf). Then the bridge will show up in Wireshark. I tried this by myself.

This was true for both the bridge and the USB adapter already before R8, but the point is that in my case, the first reboot (or npcap service restart) was not sufficient for that, while now, no reboot or npcap service restart was needed at all, it worked right after installation. There is some mystery (means: an undiscovered combination of factors or sequence of steps) in it which I cannot reproduce, but I'd suggest to treat this part as a resolved one. If I can eventually identify and describe the scenario, I'll open a new issue on it.

Thank you Pavel

[hsluoyz]

Hi @sindy39 ,

You are right that the format of information is the same for both Npcap and WinPcap, and I didn't complain about that. But my issue was that the contents is not - interfaces which are currently members of a bridge are listed by WinPcap but not by Npcap. The bridge interface itself is shown by both.

I confirmed that WinPcap still shows the member adapters. But it doesn't show the bridge itself. On the contrary, Npcap only shows the bridge. I think this is a binding layer question. I will see if this behavior can be changed.

I have posted a question here: http://stackoverflow.com/questions/36096987/how-to-bind-a-ndis-6-filter-driver-below-the-built-in-ndis-mux-driver

This was true for both the bridge and the USB adapter already before R8, but the point is that in my case, the first reboot (or npcap service restart) was not sufficient for that, while now, no reboot or npcap service restart was needed at all, it worked right after installation. There is some mystery (means: an undiscovered combination of factors or sequence of steps) in it which I cannot reproduce, but I'd suggest to treat this part as a resolved one. If I can eventually identify and describe the scenario, I'll open a new issue on it.

For a service like Npcap driver, you can simply see it has 4 actions:

1. Install
2. Start
3. Stop
4. Uninstall

If you install Npcap, it will install and start the service. So you can see a new installation already includes the same effect as restarting the service using the net command.

Cheers, Yang

[sindy39]

Hi Yang,

just FYI, I've given a try to Microsoft Network Monitor (in order to check the capabilities of my notebook's WiFi hardware & driver for monitoring mode, which came out to be none), and I've noticed that the NetMon also hides interfaces which are members of a bridge and only offers for capturing the interface representing the bridge. So I was moderately optimistic and I've set up a lab focused on capturing the transit traffic on the virtual bridge (mux) interface set to promiscuous mode.

The result is that capturing of transit traffic on the interface representing the virtual bridge, even if done in promiscuous mode, is impossible. For some weird reason a couple of transit packets has made it through but that was all.

The good side effect of it is that I now know a method to make Npcap miss a bridge interface. I have excluded one of the two ethernet interfaces from the bridge in order to be able to access some of its additional settings (which later turned out not to be necessary as the additional settings are accessible even if the interface is a member of a bridge). After I've finished with the first interface, I went configuring the bridge again, and I have ticked the then-non-member interface, then unticked the other interface, and then pressed "apply". Unexpectedly, doing so has made Windows delete the bridge and create a new one with a new name and ID.

And since then, after pressing F5 in Wireshark (which should be equivalent to dumpcap -D), neither the old bridge nor the new one had been visible.in the interface list. To make the new bridge appear in the list, it was necessary to use net stop npf followed by net start npf as you've suggested earlier. So I've tried to delete the existing bridge intentionally and create it again - same result, npf restart is necessary to make Npcap notice a bridge created while it has already been running.

But this is not the case with the USB GigE - a freshly inserted USB GigE appears in the output of the next dumpcap -D without need to restart the Npcap service, except if there is a bridge which remembers the USB GigE as its member. So I assume that when I was inserting the USB GigE for the first time ever after installing Npcap, it may have been invisible because the bridge, which had existed for months by then, may have remembered it as a member.

Off-topic, just to make the picture complete: I've also tried to capture the USB GigE communication using USBPcap to see whether it could be a workaround until you manage to attach Npcap to bridge members, and it was a complete fail too. Leaving aside that it was a separate adventure to make USBPcap identify the USB3.0 root hub (it is actually easy but not really documented), the conclusion is that there is (currently) no dissector capable of interpreting the payload of the USB frames as Ethernet frames.

[hsluoyz]

Hi @sindy39 ,

just FYI, I've given a try to Microsoft Network Monitor (in order to check the capabilities of my notebook's WiFi hardware & driver for monitoring mode, which came out to be none), and I've noticed that the NetMon also hides interfaces which are members of a bridge and only offers for capturing the interface representing the bridge. So I was moderately optimistic and I've set up a lab focused on capturing the transit traffic on the virtual bridge (mux) interface set to promiscuous mode.

Network Monitor 3 (NM3) is just the same LWF driver like Npcap. The only difference in binding aspect is that it binds to failover layer instead of Npcap's compression layer. But this doesn't make much difference against the bridge. The bridge driver Microsoft Network Adapter Multiplexor Driver seems to be able to bind below any LWF drivers.

If Npcap can bind below to the bridge driver, then Npcap can see the bridge members instead of the virtual bridge itself. But currently I see no way to achieve this.

The result is that capturing of transit traffic on the interface representing the virtual bridge, even if done in promiscuous mode, is impossible. For some weird reason a couple of transit packets has made it through but that was all.

You mean losing some packets when capturing on the bridge? Will WinPcap or Win10Pcap lose traffic too?

Off-topic, just to make the picture complete: I've also tried to capture the USB GigE communication using USBPcap to see whether it could be a workaround until you manage to attach Npcap to bridge members, and it was a complete fail too. Leaving aside that it was a separate adventure to make USBPcap identify the USB3.0 root hub (it is actually easy but not really documented), the conclusion is that there is (currently) no dissector capable of interpreting the payload of the USB frames as Ethernet frames.

You can fire a bug on Wireshark's dev list to report the missing dissector. They are very likely to improve this.

Cheers, Yang

[sindy39]

Hi Yang,

You mean losing some packets when capturing on the bridge? Will WinPcap or Win10Pcap lose traffic too?

No, the other way round, I mean catching some traffic which was not supposed to reach an unrelated interface of a bridge. In particular, several retransmissions of the same TCP packet which should have traversed the software bridge from physical interface A to physical interface B made it through to virtual interface C, which can be explained by no response to them to come from their intended recipient - so the bridge was broadcasting them to all interfaces until the first response which has updated its MAC tables' contents, after which it returned back to sending them only to the interface to which the recipient was connected. In another words, the virtual bridge is doing exactly what it should be doing, and the virtual interface called "bridge" actually represents just one of the bridge's ports, also as expected. This also implies that capturing in promiscuous mode at this interface cannot cause transit traffic to be visible, as the bridge won't deliver a frame to this virtual interface unless its destination MAC address matches that interface's one, or one of its multicast MAC addresses, or a broadcast MAC address.

WinPcap doesn't hook itself to the virtual interface of the bridge, so with WinPcap installed I've only checked, by capturing at one of the physical interfaces, that my mobile phone browser's access to my printer's web interface really passes through the bridge.

Win10Pcap behaves exactly like Npcap in this regard, i.e. the virtual interface of the virtual bridge hides the physical interface from the list.

Win10Pcap behaves slightly better than Npcap in two aspects:

• it does not need to be restarted in order to show a newly created bridge
• it has a certificate of a Microsoft-recognized vendor so it doesn't annoy the user with the confirmation question during installation (this is not a complaint!)

Win10Pcap behaves worse than Npcap in terms that it lacks the loopback capturing functionality (this is an appreciation).

If Npcap can bind below to the bridge driver, then Npcap can see the bridge members instead of the virtual bridge itself. But currently I see no way to achieve this.

If you want to adhere to NDIS6 which was the primary goal of Npcap, I understand it may be impossible. Just an idea without understanding the details, as you've managed to modify the Microsoft loopback adaptor, maybe you could also be able to modify the "system bridge NDIS mux" so that it would either provide a "traffic mirror" interface (like physical switches may be configured to do) or to allow for insertion of a LWF between itself and one of the physical interfaces?

You can fire a bug on Wireshark's dev list to report the missing dissector. They are very likely to improve this.

It may not be that easy as

• the format of the USB payload may not comply to any standard (I even think none exists) so it may change in future if the manufacturer eventually opts to do so
• the format of the USB payload is weird. The payload of each USB frame contains one or more Ethernet frames. If there is more than one Ethernet frame in a USB frame, the USB payload always begins with the first Ethernet frame without any preamble or length indicator, but there are some bytes of unknown meaning between the end of the first Ethernet frame and the beginning of the next one, which may even be bit-structured, and the last frame is followed by data which do not seem to be another Ethernet frame. Therefore, I cannot imagine how to properly parse the payload to reliably identify starts and ends of the individual Ethernet frames.

Also, bugs which seem much more important to me hang there unresolved for months, so I don't think anyone has enough time to deal with such a niche issue.

[hsluoyz]

Hi @sindy39 ,

WinPcap doesn't hook itself to the virtual interface of the bridge, so with WinPcap installed I've only checked, by capturing at one of the physical interfaces, that my mobile phone browser's access to my printer's web interface really passes through the bridge.

I didn't find the inserting position of WinPcap. The registry only shows the info about NDIS 6 drivers. If it's like you said that it can see bridge members, then it should be bound to very low level of the driver stack. It's a NDIS 5 behavior and I found no way for NDIS 6 driver to do the same.

it does not need to be restarted in order to show a newly created bridge

It shouldn't be possible based on the working way of NDIS LWF. However, I will not go further into this because this is not a big issue.

it has a certificate of a Microsoft-recognized vendor so it doesn't annoy the user with the confirmation question during installation (this is not a complaint!)

This is up to Nmap's decision that if they want to provide an EV cert to sign Npcap. An EV cert is much more expensive than a normal one.

If you want to adhere to NDIS6 which was the primary goal of Npcap, I understand it may be impossible. Just an idea without understanding the details, as you've managed to modify the Microsoft loopback adaptor, maybe you could also be able to modify the "system bridge NDIS mux" so that it would either provide a "traffic mirror" interface (like physical switches may be configured to do) or to allow for insertion of a LWF between itself and one of the physical interfaces?

This is no documented way to do this on MSDN or Google. This is why I posted on Stackoverflow: http://stackoverflow.com/questions/36096987/how-to-bind-a-ndis-6-filter-driver-below-the-built-in-ndis-mux-driver, however, still no answers.

Cheers, Yang

[hsluoyz]

I also posted a thread at MSDN: https://social.msdn.microsoft.com/Forums/windowshardware/en-US/33f2ee35-dcd2-4017-83e2-23b4eab01b05/how-to-bind-a-ndis-6-filter-driver-below-the-builtin-ndis-mux-driver?forum=wdk

If still no answers, I will close the issue.

[sindy39]

Hi Yang,

could it be as simple as that it would be sufficient to modify the following section of your .inf file?

[NdisImPlatformBindingOptions.reg] ; By default, when an LBFO team or Bridge is created, all filters will be ; unbound from the underlying members and bound to the TNic(s). This keyword ; allows a component to opt out of the default behavior ; To prevent binding this filter to the TNic(s): ; HKR, Parameters, NdisImPlatformBindingOptions,0x00010001,1 ; Do not bind to TNic ; To prevent unbinding this filter from underlying members: ; HKR, Parameters, NdisImPlatformBindingOptions,0x00010001,2 ; Do not unbind from Members ; To prevent both binding to TNic and unbinding from members: ; HKR, Parameters, NdisImPlatformBindingOptions,0x00010001,3 ; Do not bind to TNic or unbind from Members HKR, Parameters, NdisImPlatformBindingOptions,0x00010001,0 ; Subscribe to default behavior

I.e. you would have to change the BindingOptions to 2 (or even 3)? I have tried to change this value in the registry and it hasn't changed anything, but maybe this setting is only taken into account for values of upper range and lower range for which it makes sense, e. g. LowerRange = ethernet and UpperRange = ndis5 ?

Also, I am a bit surprised that in your .inf file, you declare the filter as Modifying, is there a reason for that?

; For a Monitoring filter, use this: ; HKR, Ndi,FilterType,0x00010001, 1 ; Monitoring filter ; For a Modifying filter, use this: ; HKR, Ndi,FilterType,0x00010001, 2 ; Modifying filter HKR, Ndi,FilterType,0x00010001,2

[hsluoyz]

Hi @sindy39 ,

could it be as simple as that it would be sufficient to modify the following section of your .inf file?

Good found! Literally this is what I'm looking for. I built an installer after modifying the NdisImPlatformBindingOptions to 2. You can see npcap-nmap-0.06-r13-bridge.exe in https://github.com/nmap/npcap/releases/. I didn't test it successfully in Win10 though, you can give a try too.

Also, I am a bit surprised that in your .inf file, you declare the filter as Modifying, is there a reason for that?

This is because Npcap is a packet capturing and sending library like WinPcap. Sending packets need the Modifying option.

Cheers, Yang

[hsluoyz]

Still no answers on https://social.msdn.microsoft.com/Forums/windowshardware/en-US/33f2ee35-dcd2-4017-83e2-23b4eab01b05/how-to-bind-a-ndis-6-filter-driver-below-the-builtin-ndis-mux-driver?forum=wdk.

I will close this issue.