wps_enrollee-20071029

[Dan Williams]

On Mon, 2007-11-26 at 12:19 -0800, Ted Merrill wrote:
> 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.

This seems like overkill.  Ideally, wpa_supplicant _always_ requests
that the driver do the WPS probe, and returns the WPS results if WPS is
available, otherwise not.  For example, it's certainly valid to
interpret the WPA IEs and return them even if your card _can't_ do
WPA.  

On the WEXT side, we should make a new capability for WPS and make
wpa_supplicant read that before trying WPS.  I don't really like having
duplicate commands, because there's no reason the driver shouldn't know
if WPS is supported or not.

Alternatively, if I just don't understand the flow of WPS, do you _not_
always want to know the WPS IEs?  Do you only ever want to see the WPS
IEs on demand?  If so, then we should add a flag to the WEXT scan
command to request WPS probes, but the results should always return WPS
IEs if available.

I think the WPS stuff should be an additional option to the scan command
in the wpa_supplicant control interface, not a separate command.

Thoughts?

Dan

> -- 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
> 
>