Reading monitor mode packets in Native Wi-Fi

I have a finished (hopefully) a Windows 7 Wi-Fi miniport driver based on the C:\WinDDK\7600.16385.1\src\network\ndis\athwifi\driver code. Using the Native Wi-Fi framework in user-mode I am able to manipulate my NIC to my heart?s content. I can go into monitor mode and back to extensible station mode at will.

What I haven?t been able to do is read packets in a way that is compliant with the framework. Under XP, my driver could get the NIC into monitor mode. I had a custom protocol driver to which my user-mode code could get a handle. Once I had a handle, I would first get a list of available channels. I would select a channel and put the NIC in monitor mode. Then using ReadFile(), I would gather all packets that came in on that channel.

I want to do the same thing under Windows 7, but with Native Wi-Fi there are restrictions. The handle that I have been using with WlanOpenHandle() is not valid with ReadFile(). Do I need to get a new handle to the miniport via CreateFile() and perform a read that way? What I have been looking for is a WlanRead(), but it doesn?t exist. I see that WlanQueryInterface() has an opcode of wlan_intf_opcode_channel_number. Is there a means of getting all available channels via the framework?

I have to read packets while in monitor mode via the framework. Using the XP method, reading packets while in monitor mode under windows 7 fails. Reading packets while in Station mode succeeds. Getting the channel list, and the card?s temperature and the card?s interface type can be accomplished via the custom protocol driver. I would like to use the framework, but need guidance with what amounts to custom OIDs.

I?m very happy with how I can manipulate my NIC via the framework under Windows 7. How do I read packets while in monitor mode under Windows 7? I have used the SDK sample, C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\netds\wlan\autoconfig to learn the framework. Is there more than this? What am I missing?

Thanks for any help? Paul

Thanks to Thomas F. Divine for cluing me in that an LWF is required. Hind sight is 20/20 which led me to the following Mobile Broadband (MB) comment in the WDK docs:

“Semantics
Strictly speaking, the MB Service component in user mode cannot directly exchange data with MB miniport drivers in kernel mode. Intermediaries such as WMI or lightweight filter (LWF) drivers are required. For simplicity, these intermediaries are not explicitly discussed in this documentation. However, this omission does not mean that the MB Service and MB miniport drivers can engage in direct data exchanges.”