none
Wi-Fi in NetMon: Running on Microsoft Surface Pro RRS feed

  • General discussion

  • Hello,

    The question of poor implementation of monitor mode in Wi-Fi drivers has been discussed on this forum before (for example, see this thread). Paul E Long promised to bring up this issue with the Microsoft group that dealt with Wi-Fi drivers back in May 2012. I was hoping that things would change, so after I unpacked my new Microsoft Surface Pro, I immediately installed my favorite network analysis tool, Microsoft NetMon. Surface Pro is an ideal device for Wi-Fi sniffing due to is form factor.

    Anyway, NetMon detected the Wi-Fi adapter, which was Marvell Avastar 350N. The driver is, of course, WHQL-certified by Microsoft. So far so good. Now, I enabled monitor mode and began sniffing. Surprise, surprise. Another broken implementation of DOT11_OPERATION_MODE_NETWORK_MONITOR: the signal level is always reported as "-98 dBm", regardless of the actual signal strength. The rate is always reported as "unknown". Totally unusable.

    What kills me is that the tablet was made by Microsoft. One would expect FULL compliance of all the components with the Microsoft specs. But that is not the case.

    Should we pronounce Native Wi-Fi API dead? It appears that even Microsoft has no interest in enforcing the standard.

    Regards,
    Andy

     


    Tuesday, March 12, 2013 11:29 AM

All replies

  • First, I want to apologize on dropping the ball on your previous request.  I have been able to find the appropriate folks at MS to discuss further and I'm trying to get complete answer.

    Thanks,

    Paul

    Tuesday, March 26, 2013 9:09 PM
  • Andy, I’ve had few discussions and while I’m sure the answers aren’t satisfying, I hope that help explain the current state of things.  One original intent was to provide a standardized way to analyze wireless networks using off the shelf hardware.  These means defining a standard and providing certification for hardware.  But, as I’m sure you already know, there are limits to how useful standards are to delivering an experience.  Certification does help, but it also has limits in terms of resources and how much testing must be done to deliver a consistent experience.  We all had great intentions, but reality is that priorities don’t allow us to provide a %100 compatibility for all hardware and scenarios.  At the start it did give us some high value, but as technologies advanced and the value propositions play out, resources are allocated to the most important priorities.

    For the Surface, the goal was not to target a wifi troubleshooting tool.  So no effort was done testing that experience.  But to that end, I think we can drive some effort into addressing specific bugs with that hardware and hopefully delivering something that works moving forward.  I will follow up with the WiFi teams at Microsoft and try to make that experience one that works.

    Paul

    Friday, April 26, 2013 2:09 PM
  • Paul,

    Thanks for the update. Indeed, the news are not very promising.

    I think that providing a standardized way to analyze wireless networks was (and still is) a terrific idea that should not be abandoned. The problem is that as it is now, it's half-baked. First, the API is lagging behind the current state of affairs, e.g. no way to use it to capture on 40 MHz 802.11n channels or  80 MHz 802.11ac channels. Second, the implementation in vendor drivers is mostly awful. Third, compliance validation by Microsoft is non-existent.  Two out of these three issues are in Microsoft's control. And if you address the third issue, the second issue will be addressed by the vendors. So rather than fixing specific bugs in that Marvell Avastar driver, if I were the boss, I would address the general issues. I mean, adding a couple of constants to the current API to enable handling of 802.11n/ac channels and data rates is not a huge amount of work. Creating an automated test that checks all new WHQL driver submissions for compliance is a matter of one day!

    With very little effort, you'd solve a huge problem. Wi-Fi is a *hot* technology. Laptops don't even have Ethernet ports these days. How are engineers going to do packet analysis and site surveys without the proper API and compliant Wi-Fi drivers? We either have to pay considerable amounts of money for the tools like CommView for WiFi or AirMagnet Analyzer or, heaven forbid, use Linux, where Wi-Fi monitor mode actually works.

    If you agree, please convey this to the Microsoft Wi-Fi team. The industry needs your help.

    Andy

    Thursday, May 9, 2013 5:35 PM
  • Hello,

    I was first reluctant to bring back such an old thread, but it seems they aren't that many available :/ 6 years have passed, NetMon was replaced by MMA, and WiFi drivers for Windows are... meh, still what they were in 2013: inconsistent (Have a look at that magnificent graph from the guys behind nmap: https://secwiki.org/w/Npcap/WiFi_adapters)

    It wasn't said officially, but as of today "Microsoft Message Analyser" seems so dead it's hard to think it's not... No content added since 2016 (https://blogs.technet.microsoft.com/messageanalyzer/), crashes way too often.

    It makes sense though, following new Microsoft spirit of being much closer to OpenSource that they used to be (Buying GitHub :P). Let's be honest: MMA is (very) far from being as complete as Wireshark. It's quite understandable (though it would have been nice to announce it) that Microsoft dropped its development. (Maybe that's not the case ? Feel free to tell me some secret overhauls are coming soon :D )

    Could we by any change have announcements/updates regarding MMA? If the project is abandoned, how about releasing its source code? Powershell has never been developed as actively as since it's open source :D Maybe at least the driver, (Windows-NDIS-PacketCapture) so that we can use it in our tools ? (Please don't tell me I should use the plugin mode to develop an app...) It would follow the encouraging spirit I've mentioned above, and help develop the open source tools that remain. You may also be aware that Winpcap has recently been deprecated, meaning the up-to-date alternatives are shrinking :/

    I am not actually expecting much from such a request: you have probably no power of deciding what to do of this, and Microsoft is free to keep it private. That's probably how corporations work ^^ I won't be disappointed if the answer is no

    I thank you a lot for the work you have done, and hope to get an answer soon :)

    Regards,

    Gabriel



    • Edited by gpotter2 Saturday, March 2, 2019 5:35 PM
    Saturday, March 2, 2019 5:25 PM