hostapd/wpa_supplicant - new development release v0.3.1

Jouni Malinen jkmaline
Mon Dec 13 23:44:55 PST 2004

On Mon, Dec 13, 2004 at 10:37:10AM -0800, Mark Wilson wrote:

> NdisMIndicateStatus is a Miniport Driver fcn that calls ProtocolStatus(...) 
> in all attached Protocol Drivers. In order to take this approach you would 
> have to write and install a custom Protocol Driver (ala winpcap). Instead I 
> would suggest looking at the Windows Management Instrumentation (WMI) 
> interface. Use IWbemServices::ExecNotificationQueryAsync to register the 
> events you wish to receive and supply a IWbemObjectSink derived consumer 
> object for the events that WMI will then forward to you.

I found out about WMI over the weekend and hoped that there would be an
alternative, light-weight C API for getting the status events. I would
just like to get the StatusBuffer that the driver is passing to
NdisMIndicateStatus() and get it using something that I could wait in a
select() loop..

I used to think that Linux netlink is complex, but after looking a bit
more into what WMI is, I may have to change my mind. Talk about
including everything but the kitchen sink.. Something SQL-like to
register the notification receiver and then notification wrapped in
IWbemClassObject in format that I don't know how to parse, i.e., some
kind of Ole Automation.. I don't really want to learn more about Windows
internals, I just want to get this little supplicant thing working.. ;-)

It should be ok for some experimenting to write a small C++ program to
receive these events and then pass them to wpa_supplicant over a socket
connection.. I found an example program from Platform SDK (TempConsumer)
that was doing something close enough and I was able to get it to
register couple of notification listeners. MSNdis_StatusMediaConnect and
MSNdis_StatusMediaDisconnect are ok, but getting proper data out of
MSNdis_StatusMediaSpecificIndication seems to be somewhat complex..

I can enumerate through the VARIANTs in IWbemClassObject. Integer values
are fine, so I can get the correct buffer length for the data I'm
interested in (i.e., StatusBufferSize from the NumberElements variant).
However, I don't know where to find the correct pointer to data from
StatusBuffer. It should be in NdisStatusMediaSpecificIndication variant,
which I can see, but it is of vtType 0x8209 which seems to include
reserved bits.. I tried to get pbVal, V_UNKNOWN(), V_UNKNOWNREF(), and
number of other combinations.. They seem to having valid looking pointer
values, but the memory they point does not have the expected data
(starts with 01 00 80 00 01 00 ... whereas it should be 02 00 00 00 01
00 ...).

Another variant, InstanceName, seems to have proper wchar data at the
pointer retrieved using the same mechanism that did not work with
NdisStatusMediaSpecificIndication, but then again, it has different
vtType (0x8). Is that 0x0009 a clue that it would be IDispatch? If yes,
how is that supposed to be used and what were they thinking when
designing this? ;-)

I'm trying to get PMKID candicate list from the driver and the event
itself seems to be correct. The length of the data (NumberElements) is
correct, so I would just need to get the pointer to the data somehow..
If you (or anyone else) happens to know how to use these Ole
Automation/VARIANT/whatever thingies, please let me know how to get that
small piece of data to find piece of mind (and a way of implementing
RSN pre-authentication without having to poll driver for scan results).

Jouni Malinen                                            PGP id EFC895FA

More information about the Hostap mailing list