wps_enrollee-20071029

[Ted Merrill]

I have patches to the hostap almost ready (some bugs i want to work out first) 
that embed WPS into wpa_supplicant will allow a GUI to drive wpa_supplicant.
And of course i'll need to address issues that Jouni has or may have.

The modifications to the wpa_ctrl commands (in my patch) are:

-- In the "flags" part of scan results, it prints out [WPS] if the AP is WPS 
capable.  If the AP has been activated to do WPS then it instead prints out 
[WPS-PB-ready] or [WPS-PIN-ready] according to the activated mode.

-- There is a new command "WPS_SCAN" which is the same as the regular "SCAN" 
except for the following differences:
It adds appropriate WPS information element to probe requests during scanning 
(and removes it after done scanning), as required (strongly suggested?) by 
the WPS standard.
It filters the results to only those which indicated activated WPS in the 
right mode (normally there should be exactly one).
The results are reported asyncronously.

-- There is a new command "WPS" which does the actual message protocol 
exchange and reports the results asyncronously (via wpa_supplicant messages) 
when done... it is up to the GUI or etc. to make use of the results and e.g. 
reconfigure wpa_supplicant.

To support this, i've added a new driver ops function pointer 
*set_wps_probe_req_ie() 
to get a WPS probe request information element added to probe requests during 
WPS scanning,
and actual support for this for madwifi... i don't feel responsible for 
getting it to work for other hardware.

Also the scan result structure has two new fields,
        u8 wps_ie[SSID_MAX_WPS_IE_LEN];
        size_t wps_ie_len;
... just like what is done for wpa/rsn ; this is supported in driver_wext.c 
which is used for various (although not all) hardware.
I'm not sure why  Johannes thinks a kernel API change is required.

I'm curious if people have WPS capable access points available to them for 
testing... i might be able to do something about that if that is an issue.

More to come,

-Ted Merrill
Atheros Communications






On Monday 26 November 2007 07:07:23 Dan Williams wrote:
> On Thu, 2007-11-22 at 00:57 +0100, Johannes Berg wrote:
> > [steps snipped]
> >
> > That looks like it would be very usable from GUI programs like network
> > manager too.
> >
> > > -- on success it gets a little more complicated... typically we will
> > > want to save the new configuration to a file for later use, and begin
> > > using it immediately as well, probably in preference to anything
> > > existing... but there could be exceptions...
> > >
> > > Also of course note that determining the ssid to use is best done by
> > > scanning, filtering the results to find those that are "wps ready", and
> > > getting user OK to proceed... presumeably this would use wpa_ctrl ...
> >
> > As you said, I also think that most of the code to do WPS should be in
> > wpa_supplicant. I guess for testing there should also be a simple
> > command-line wpa_cli-like program that does the UI steps of wps and
> > simply outputs a configuration file to stdout or so. This could be used
> > in scripts etc., it would probably take the SSID, pin and other
> > configuration on the command line. Afterwards, the user would have to
> > take this configuration file and feed it back to wpa_supplicant.
> >
> > On the other hand, when using network manager, the WPS command line tool
> > wouldn't be used but NM would instruct wpa_supplicant directly to do
> > WPS. That way, NM could offer a simple UI for doing WPS. Instead of
> > writing a config file it would store the settings and change the running
> > wpa_supplicant to use them if desired.
>
> Right.
>
> > Right now there is probably no way to determine whether an AP is "WPS
> > ready" without changing the kernel API... But with nl80211 I'll probably
> > just embed the information elements in the scan result so userspace can
> > parse from it whatever it needs.
>
> Ideally, wpa_supplicant can find out whether the AP supports WPS from
> the IEs and advertise that in the scan results it provides over the
> control interfaces.
>
> Dan