Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Wireshark is not able to see ethernet adapters after changing from WinPCAP to NPCAP on Windows server 2016 #1899
Wireshark is not able to see ethernet adapters after changing from WinPCAP to NPCAP on Windows server 2016 for Broadcom Netextreme Virtual Function ethernet adapter.
Attached is the Diagreport. I can reproduce on a fresh empty VM and provide remote access if desired.
C:\Program Files\Wireshark>dumpcap.exe -D
Network Adapter(s) Info:
Name InterfaceDescription ifIndex Status MacAddress LinkSpeed
Ethernet Broadcom NetXtreme-E Virtual Function 3 Up 00-00-17-02-79-0E 25 Gbps
Caption :  Broadcom NetXtreme-E Virtual Function
We've confirmed this issue, but we don't know why it's happening. Neither Npcap nor the "NDIS Sample LightWeight Filter" driver from Microsoft/Window-driver-samples can bind to the VF adapter. I can't debug the system where we're seeing this currently, so I don't know if our FilterAttach function is even being called. I'm hoping to reach out to more knowledgeable NDIS people to see if there's something obvious I'm missing. (CC @jtippet)
Ah this is sort of by design, at least from the OS's point of view. The VF doesn't bind directly to most drivers -- instead, it slots into a purpose-built protocol driver that is bundled with netvsc (the Hyper-V network adapter). netvsc exposes the VF's traffic up through its own datapath. It does this so it can provide seamless and transparent failover if the VM is migrated to a host that doesn't have a VF.
Because it isn't just a regular Ethernet+TCPIP situation, the VF's network interface is designed to not bind all the usual filters by default.
This is accomplished by setting the UpperRange and LowerRange in a VF's INF to distinct tokens. Usually an Ethernet adapter would have
If you want, you can modify the LWF's INF to bind to VF adapters too. I believe you'd only have to append
Silently capturing traffic shouldn't cause any problems, but setting a
Also, @pc500, keep in mind that even without any changes to npcap, you can still capture traffic from the VF right now: just attach to the netvsc (Hyper-V) interface. The netvsc adapter will show all the traffic to/from the VF. In other words, this is your network architecture looks like this (zoomed in from here):
You're asking to capture packets at point (B), which is reasonable, but requires a change to the npcap driver INF. Capturing at point (A) would give you largely the same results as capturing at point (B), but can be done right now. The only real difference between (A) and (B) is that, if the VF is revoked, (A) will continue to show traffic while (B) will show a dead link.
Hi @jtippet The guest operating system cannot see the netsvc interface. This is not actually running on Hyper-V, although it is a virtual machine guest. I can only see one ("single") interface on the VM.
My understanding is it's a virtual function mapped directly from the hardware NIC, and only that PCI address is exposed to the guest OS. The hypervisor passes through the VF function as hardware and is otherwise not involved in the networking, similar to the following:
We have 2 ways forward that we may pursue, but they will require lots more development and testing:
@pc500 - Oh, that's interesting. I honestly have no idea how a VF would look if it was exposed from another hypervisor. The VF architecture in Windows is (for better or worse) somewhat coupled to netvsc, to provide seamless failover. My comments about INFs and bindings may or may not apply, depending on how Broadcom and RedHat decided to expose the VF to the guest OS. You can check quickly by looking at the registry key:
@dmiller-nmap - I don't want to discourage you from binding to iovvf interfaces. I'm just saying that you should try it out before committing a PR that adds a claim that the LWF supports iovvf. In general, we add distinct binding tokens when there's something different about the interface that LWFs may have to take into consideration. But, if the LWF doesn't really interact with the NIC much, it's often a non-event. For comparison, ndiscap, the built-in packet capture LWF, binds to