none
Wi-Fi in NetMon: Dealing with broken monitor mode implementations in the drivers

    Question

  • Hi,

    I'm an old-time user of NetMon and a few commercial Wi-Fi network analyzers. Because commercial analyzers are expensive and because NetMon comes with far better parsers than any of them, my colleagues and I would really love to use NetMon, but there is a huge heap of technical problems with Wi-Fi network monitoring using NetMon. I hope someone from Microsoft could shed some light on this situation.

    Problem #1.  MSDN describes monitor mode (DOT11_OPERATION_MODE_NETWORK_MONITOR) in great detail, but there are simply no correct implementations of it in Windows drivers. About 95% of all modern Wi-Fi adapters are based on the chipsets by four vendors: Intel, Broadcom, Atheros, and Ralink. Wi-Fi adapters come with drivers supplied by these chipset vendors or, sometimes, with rebranded drivers by adapter vendors (e.g. D-Link drivers fully based on Ralink ones). Despite the fact that they are almost always WHQL-certified, monitor mode is broken to some extent in all of them. For example, Ralink drivers always report the same signal level (-50 dBm) and don't report correct CRC values. Broadcom drivers don't work with 5 GHz channels in monitor mode. In Intel drivers, monitor mode is completely broken since version 14 of their drivers. If you need a proof of that, just look at some technical notes on Wi-Fi monitoring by commercial Wi-Fi sniffer vendors, for example this one: http://www.tamos.com/products/commwifi/technotes.php . And these are just a few problems; there are many more, e.g. no driver reports HT rates correctly.

    Problem #2. Even if all of the bugs in the DOT11_OPERATION_MODE_NETWORK_MONITOR implementations are fixed, the current Microsoft specifications for this mode are way behind the current state of 802.11 technologies. Native Wi-Fi API does not allow monitoring 40 MHz channels, which renders NetMon totally useless in case of 802.11n network monitoring. Native Wi-Fi API doesn't provide a way of specifying the secondary channel in case of 40 MHz channels, i.e. whether the user wants to monitor channel 6 and 2 or channel 6 and 10. Native Wi-Fi API doesn't provide a way of getting noise floor level. Hey, 802.11ac is coming soon, but the API can't even handle 802.11n correctly, and 802.11n was ratified years ago!

    All of the above brings me to a question: What's the point of spending time and money on developing NetMon (at least the Wi-Fi part of it) if it doesn't work? It looks like the NetMon development team turns a blind eye to the fact that the chipset vendors blatantly ignore the NDIS 6 specs, sometimes on purpose (while we are at it, here a good post by Aerohive chief architect about why Intel broke monitor mode in the their latest drivers: http://devinator.tumblr.com/post/18881155974/intel-really-really ). Is there any communication between the Microsoft department that certifies drivers and the department that develops NetMon? Can't you guys *enforce* strict compliance with your own specs and refuse to WHQL-certify the drivers that don't pass comprehensive monitor mode testing? Can't you simply ask chipset vendors to correct the errors? I would think that with the level of influence on the industry that Microsoft possesses, it would be a piece of cake to convince those chipset vendors to comply.

    And finally, is Microsoft going to do something about the limitations of the Native WiFi API? Nobody uses 20 MHz channels these days, you know…
    DOT11_OPERATION_MODE_NETWORK_MONITOR was a great idea, really. When Microsoft came up with it, Wi-Fi professionals rejoiced because that was a path to low-cost or free WLAN analysis. But the reality is gloomy. Microsoft's good intentions have been derailed  by Intel & Co.

    I'd like to hear comments from Microsoft. Thank you.

    Regards,
    Andy


    Wednesday, May 23, 2012 12:54 PM

All replies

  • Andy, I just wanted to say that I'm currently trying to do some research to understand if there's something we can do to fix this problem.  We are not the group that actually enforces or created the Native WiFi standard.  We just decided to expose this functionality, but I'm hoping to contact that group and see if there's some plans for the future that we can take advantage of.

    Thanks,

    Paul

    Thursday, May 31, 2012 7:31 PM
  • Paul,

    That would be great. I realize that you're not the group that enforces or created the Native WiFi standard, but you're probably the only group in Microsoft that actually uses the DOT11_OPERATION_MODE_NETWORK_MONITOR mode. I don't know how to convey the message from us, suffering developers, to that group directly, but I sincerely hope that being a Microsoft employee, you can easily do that. Like I wrote, the current state of affairs is totally unacceptable. Ralink, Atheros, Broadcom and especially Intel undermine your and our work, and the fact the Microsoft does not enforce compliance with the standard is probably the most important factor. When you talk to that Microsoft group, please do mention our concerns regarding the current status and, or course, regarding the future of the Native WiFi standard (40 MHz channels in 802.11n,  40-60-80-160 MHz channels in 802.11ac, a proper set of constants for reporting HT data rates, and, if possible, noise floor).

    Thank you!

    Andy

    Friday, June 01, 2012 11:44 AM
  • Hi,

    Do you know which USB wireless adapters are fully supported?

    I tried Edimax and as Ralink the dBm is always the same signal.
    Netmon couldn't even perform channel hopping.

    These are the qualities that matter to me the most.

    Regards

    Roey.

    Wednesday, November 13, 2013 1:26 PM
  • I don't have an ongoing list of supported adapters, but in the past none of the USB adapters supported this feature, so I'm doubtful. 

    Paul

    Friday, November 15, 2013 7:03 PM