https://stackoverflow.com/questions/17037907
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianI'm afraid that NDIS 6.3 does not support XP any more, is this true?
If you mean "will a driver that uses NDIS 6.3 work on Windows XP", the answer is "no", and has always been "no"; it's not a case of "any more".
A given version of Windows supports a given version of NDIS (not the other way around). "NT 5.x", i.e. Windows 2000, Windows XP, and their server equivalents, support NDIS 5; an NDIS 6 driver (even NDIS 6.0) won't work on those versions of Windows. An NDIS 6 driver requires "NT 6.x", i.e. Windows Vista and later.
If you look at Microsoft's MSDN documentation on network drivers, you'll notice that it has a section for "Network Drivers Starting with Windows Vista" and a section for "Network Drivers Prior to Windows Vista"; the first section is for NDIS 6 and the second section is for NDIS 5. (NDIS 4 is, I guess, considered too old to bother documenting any more; I don't know what the differences between NDIS 4 and NDIS 5 were, or whether WinPcap still supports NDIS 4.)
Your options, if you want to support NDIS 6 in WinPcap (for example, to support monitor mode on Wi-Fi devices) are:
- make a version of WinPcap that doesn't support Windows 2000 or Windows XP or their server versions, and that only supports NDIS 6;
- make separate versions of the WinPcap driver and packet.dll library for "NT 5" (W2K/WXP and their server versions) and "NT 6" (Vista, 7, 8 and their server versions), give the two versions of packet.dll the same API (with the "NT 5" version, for example, returning a failure indication for attempts to put the interface into monitor mode), and have wpcap.dll (i.e, the "libpcap" part of WinPcap) using that API, and have the installer figure out which one to install (which means you'd have to reinstall WinPcap to get the NDIS 6 features if you upgrade an "NT 5" system to "NT 6", e.g. upgrading Windows XP to Windows Vista, 7, or 8) or somehow have the right driver code run when the driver is loaded, if that's possible.
Note, by the way, that, if your goal is to support monitor mode on NDIS devices, you are VERY STRONGLY advised to implement the APIs that already exist in libpcap for monitor mode, i.e. the pcap_create()/pcap_activate() APIs for opening a device, the pcap_set_rfmon() API for requesting monitor mode, and the pcap_can_set_rfmon() API for checking whether monitor mode can be turned on, as those APIs are what programs such as tcpdump and Wireshark expect.
Note also that the pcap_create()/pcap_activate() APIs do not currently handle remote packet capture, so you'll either have to get rid of that capability or wait for me (or somebody) to add those capabilities to those APIs.
Note also that it has been reported that, whilst NDIS 6 has APIs to support monitor mode, not all Wi-Fi devices have NDIS 6 drivers, not all those that do have NDIS 6 drivers have NDIS 6 drivers that support Native Wi-Fi (and thus do not have NDIS 6 drivers that support monitor mode), and even those that do have NDIS 6 drivers that support Native 802.11 don't necessarily have NDIS 6 drivers free of bugs that make the Native 802.11 stuff work well.
And, in addition, note also that the "radio information" header supplied by Native 802.11 drivers in monitor mode is different from all of the existing "radio information" headers supported by pcap and pcap-ng, and you'll need to request a new LINKTYPE_/DLT_ value for that "radio information" header from tcpdump-workers@lists.tcpdump.org. Wireshark already has a dissector for it, as it can read 802.11 captures from Microsoft Network Monitor; tcpdump will need one.
(If you're doing this for some other reason, such as adding support for PPP devices or fixing the code to get the vendor's device description, that might also require making the NDIS 6 driver a lightweight filter driver or something such as that rather than a transport driver.)
