WPS patch from Ted Merrill, 20071203

[Ted Merrill]

Hi Jouni

I've sent hostap-wps-20071203.patch by separate email to you since it would 
otherwise not survive the hostap mail list filter due to size.

This patch includes all of my pending changes for WPS.
It is not well tested but i wanted to get this to you so we can discuss.
[CONFIG_]EAP_WSC is yours, and [CONFIG_]EAP_WPS is mine.

For hostapd, 
I removed the use of WLAN_STA_WPS... flags entirely along with use of "sta" 
that you found objectionable in the hostap code (this was from the Intel 
modifications to hostapd).  I'm not 100% this is the right thing to do but i 
was unable to determine what useful function these flags actually provided.

I added WPS_SCAN and WPS commands to ctrl_iface.c for wpa_supplicant.
WPS_SCAN differs from the old SCAN command in two respects: it sets 
appropriate information elements in probe requests (if possible) and it does 
not return old stale scan results but instead asyncronously sends new scan 
results.
The WPS command does the core WPS algorithm (passing M1 .. M8 messages).

There is a  new value for "proto" : "WPS" which bypasses some checks that 
would not allow wpa_supplicant to try to associate in open mode with e.g. a 
WPA2 AP.
The "WPS" command disables any existing "network" definitions and essentially 
defines and activates one like:
network={
    ssid="some_ssid"
    key_mgmt=NONE
    auth_alg=OPEN
    proto=WPS
}
The WPS-capable AP will accept an open connection (for WPS purposes only) even 
though it does not advertise this in information elements other than the WPS 
information element; proto=WPS attempts to make wpa_supplicant happy with 
this (see kernel driver issue below).

There are two programs for wps:
wps_enrollee is intended for automated or at least non-interactive 
operation... it will do scanning if you don't give it an ssid, but will is 
not as flexible or friendly as wps_wizard.
wps_wizard is an interactive program that could serve as the inspiration for a 
gui wizard...
These programs use wpa_ctrl to use the WPS_SCAN and WPS commands.

There are some issues that you have noted that i have not addressed yet, 
including:
-- Uses l2_packet
-- Doesn't use hmac_sha256_vector yet
-- I haven't looked into using openssl yet, works only with internal crypto
By separate email i'm giving feedback to your latest email.

Finally, there are some serious Linux kernel driver issues to deal with:

WPS_SCAN only works if the kernel driver reports WPS information elements to 
user space.  Unfortunately, the latest driver from madwifi doesn't do that.
I used a patch from https://www.saice-wpsnfc.bz which patches a somewhat out 
of date version of the madwifi driver, which in turn does not work with the 
latest linux (it worked for me with Linux 2.6.15 which i happened to have 
lying around).
Unfortunately, the madwifi driver has been written only to report certain 
known i.e.s to user space (the above mentioned patch adds WPS to the list)... 
it really should be redesigned to report ALL information elements.
In browsing the madwifi pages i did not get any idea that any sort of fix for 
this problem is in the works...  and of course this is not the only kernel 
driver to worry about...

There is also a problem with associating with the AP for which i've found only 
a poor workaround.
Typically, a WPS capable or ready AP will advertise e.g. WPA2 capability in 
the probe responses but will actually associate in open mode (as required) 
with a firewall of sorts so that open mode associations can be used only for 
WPS purposes.
For some reason, the ioctls that driver_wext uses do not reliably result in 
getting an open connection ... sometimes it works and usually it doesn't.
My work around with my Intel Pro 2200BG is (while the WPS job in 
wpa_supplicant is waiting to get associated) to issue the following command:
    iwconfig eth1 key open
This typically results in immediate association.
Unfortunately, the same command fails when using madwifi driver with my 
Atheros wifi card (ath0 of course)... i can do "iwconfig ath0 key off" but 
that is not the same thing.
(I have access to the drivers that Atheros uses internally but have not yet 
released, and i can see if the problem occurs with them).

I'm able to use my ath0 (with LInux 2.6.15 with patched madwifi driver) to 
demonstrate that scanning works using wps_wizard, and i'm able to use eth1 to 
demonstrate that the core WPS algorithm works using wps_enrollee:
wps_enrollee ssid=some_ssid ifname=eth1



-Ted Merrill