Windows doesn't, which is why WinPcap was created - it adds kernel-mode code (the driver) and a user-mode library to communicate with the driver, and adds a file to libpcap to do packet capture on Windows, calling the user-mode library. On UN*Xes, the OS provides a packet capture mechanism, and libpcap uses that. the Npcap driver and the packet.dll user-mode library that uses it.the libpcap library, which provides the APIs to callers and implements all the stuff that's not packet capture atop the NT kernel code.I guess the least bad fix would be to check for 0圎00000BB in pcap-npf.c and just ignore it "promiscuous" doesn't apply to non-broadcast networks. Microsoft might want to explain to the driver developers for their device what the word "mandatory" means in the text i n the page about the OID_GEN_CURRENT_PACKET_FILTER OID. This is a giant bag of annoying - it returns some random private error code, so there's precisely zero explanation of why it rejects attempts to set the OID_GEN_CURRENT_PACKET_FILTER OID. Is this Microsoft's way of saying "hey, we market the device under our name, and did at least some of the hardware design work, but didn't write the driver, it's not our fault*? Īnd footnote 3 says "All NTSTATUS values that are used by Microsoft have the C bit clear." This bit is set for customer-defined values and clear for Microsoft-defined values. This specifies if the value is customer- or Microsoft-defined.
If so, as per the layout of NTSTATUS values, that's STATUS_SEVERITY_ERROR plus the C bit:Ĭ (1 bit): Customer. That looks suspiciously like an NT error status, rather than a Windows error status.
0 kommentar(er)
