Silently capturing traffic shouldn't cause any problems, but setting a OID_GEN_CURRENT_PACKET_FILTER does theoretically perturb the state of the system, so it could theoretically break something that wasn't expecting it.Īlso, 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. You should test it a bit to make sure that your LWF doesn't break things.
But before you rush out and do that - be advised that a VF stack is not quite the usual TCPIP stack. Example: FilterMediaTypes=ethernet,bluetooth,iovvf. I believe you'd only have to append iovvf to your INF's FilterMediaTypes. If you want, you can modify the LWF's INF to bind to VF adapters too. But a VF has UpperRange=ndisvf and LowerRange=iovvf. Usually an Ethernet adapter would have UpperRange=ndis5 (ignore the name it's not actually NDIS 5.x) and LowerRange=ethernet. This is accomplished by setting the UpperRange and LowerRange in a VF's INF to distinct tokens. 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.īecause 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. netvsc exposes the VF's traffic up through its own datapath. 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). Ah this is sort of by design, at least from the OS's point of view.
0 kommentar(er)
