How does Windows Wi-Fi Supplicant work

NTDEV
1

Hi Everyone!

I am a communications engineering student, pretty interested in windows and have fair understanding of the windows networking stack. I have few queries:

  1. How does the Windows Wi-Fi supplicant work?
  2. Can we use open source supplicant like WPA-Supplicant on windows?
  3. If Yes, How does the binding to TCP/IP work? I came across this thread (http://www.osronline.com/showThread.cfm?link=162581) where the poster could not get TCP/IP binding despite emulating Native Wi-Fi Filter driver.

Thanks!

2

> I am a communications engineering student, pretty interested in windows and have fair understanding of the windows networking stack. I have few queries:

  1. How does the Windows Wi-Fi supplicant work?
  2. Can we use open source supplicant like WPA-Supplicant on windows?
  3. If Yes, How does the binding to TCP/IP work? I came across this thread (http://www.osronline.com/showThread.cfm?link=162581) where the poster could not get TCP/IP binding despite emulating Native Wi-Fi Filter driver.

There is good introductory material here:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms706556(v=vs.85).aspxandhttps://msdn.microsoft.com/en-us/library/windows/hardware/ff560689(v=vs.85).aspx
Answers to your questions in short form go basically like this:

  1. Like any supplicant might - it sends and receives EAPOL packets and interacts with the security subsystems. If you have a specific question about how a detailed part of it works perhaps you should focus your question. Otherwise you are sort of asking for a book. There is a good diagram (somewhere) in the reference material on MSDN that gives a block diagram picture. The key parts are:
  • NIC- NIC Vendor native WiFi Driver- Native WiFi Filter Driver- WiFi Service- NIC Vendor (optional) extensions (DLL)- EAPHOST and inbox + third-party EAP methods- WiFi UI (the Shell stuff)
  1. No, not really. That is the short answer. The long answer is that it is really quite difficult to take control of WiFi configuration and supplicant duties from Windows. Windows provides extension points for the native WiFi control and supplicant where most of what one might want to do (other than take over) can be accomplished. What are you trying to accomplish?
  2. So (2) was pretty much “no”. The reasons that TCPIP might not be binding depend on what you mean. Did you actually build something like this and find that TCPIP is not binding or are you asking about this old post?
    This begs the standard question #1 - what are you trying to do?
3

Hi Dave!

Thanks for the detailed response.

  1. The Links were good, I checked them. And yes, Thanks for the Wi-Fi stack diagram (text form).

The answer to your standard question #1 is: I want to write a simple Wi-Fi network connection utility which can co-exist with the default Windows 7 UI.
Even if I can make it work with Open Security, it will be a good starting point for me.

  1. I think It is possible.
    I got to see the Cisco AnyConnect which co-exists with the default windows Wi-Fi UI, but with the restriction that only one of these can be used at a time. So if I want to use Cisco AnyConnect for configuring a wi-fi profile, I can use it straightaway but if I want to use the Windows’ one, I have to Disable AnyConnect through a soft-switch they have put in their UI.

  2. I was asking about the older post. I now realize that the above glitch needs to be cleared first then only I can move to the protocol layer.

Thanks!
John

4

Good news, there is an API for that.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms706563(v=vs.85).a
spx

If you just want to implement your own EAP method then do so via EAPHOST
extensions and specify your EAP method in the WiFi Profile.

It is still not terribly clear to me what you want to do beyond have a
utility that sits between the User and the Native WiFi Facility that can
configure profiles and connect/disconnect profiles.

Is there some aspect of “utility” you wish to create that is not afforded by
the NWiFi API?

Is there some security interaction you wish to enable that is not afforded
by the EAPHOST API?

If so the last refuge is the IHV Extension mechanism intended for WiFi NIC
Vendors to expose and control NIC features.

https://msdn.microsoft.com/en-us/library/windows/hardware/ff560611(v=vs.85).
aspx

IHV Extensions are by design associated with the NIC (not the system) and
thus as a general purpose mechanism to get all sticky with NWiFi they are
not terribly friendly to work with (unless you happen to be the NIC vendor).

Please note that nothing involves writing a driver.

BTW, this is the diagram I was referring to:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff560683(v=vs.85).
aspx

Good Luck,
Dave Cattley

5

Hi Dave,

Apologies for not being very clear.
Actually I am trying something similar to the Cisco’s AnyConnect.

As for your queries, we have seen limitations on EAPHost API. For example, in Windows 8.1 with 3rd party network manager, we don’t get credentials prompt for a EAP-PEAP connection(it only works with saved username/password). And AFAIK, Credentials prompt is fully integrated into MSFT network manager and 3rd party apps (including netsh based commands) don’t get this prompt.

Thanks!
John

6

Adding up to the above…

I have already been able to insert a filter between NWiFi and Miniport NIC driver. Even been able to get a MAC level connectivity. However binding is not getting established for the adapter. Is there something I am missing??

Thanks!

7

>Actually I am trying something similar to the Cisco’s AnyConnect.

I was trying to get you to say affirmatively and precisely what that is as opposed to just saying what it is like.

I have never used AnyConnect. I can’t help you as I have no idea what you might be trying to accomplish.

Good Luck,
Dave Cattley

8

Hi Dave,

Sorry, I referred to a proprietary software (Cisco AnyConnect). But I think I had already mentioned in one of my replies what I am trying to do.

As for Cisco AnyConnect, it is a full fledged network manager which can co-exist with windows UI, with a condition that user can either use it or the windows UI to connect to an Access Point. Moreover, it does not have the limitations of EAPHost API for a EAP-PEAP connection as I had mentioned above.

I hope this makes it clear about what we are trying to achieve.

Thanks!
John