wps_enrollee-20071029

[Ted Merrill]

And i forgot to mention that, when scanning for eligible APs prior to doing a 
WPS operation, special WPS probe information elements are supposed to be 
used... another feature to add to wpa_supplicant.....
-Ted

On Tuesday 06 November 2007 20:41:35 Ted Merrill wrote:
> Jouni,
>
> Thank you very much, that is valuable information to have.
> I haven't thought this through too far, but perhaps the way it should work
> then is:
> -- wpa_supplicant already running
> -- separate software determines which wireless interface is being
>  configured, the ssid to use for configuration as well as the security
>  mode to use (push button or pin)
> -- the separate software sends a wpa_ctrl request to begin WPS with the
> given parameters.
> -- wpa_supplicant then switches to using an open mode configuration with
> the parameters passed
> -- when associated, wpa_supplicant supports the WPS state machine until
> final success or failure.
> -- on failure, wpa_supplicant puts all back the way it was.
> -- 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 ...
>
> -Ted
>
> On Tuesday 06 November 2007 20:23:55 Jouni Malinen wrote:
> > On Mon, Nov 05, 2007 at 04:57:11PM -0800, Ted Merrill wrote:
> > > After reviewing Atheros' wps_enrollee code plus the lastest hostap
> > > code, i've come to the conclusion that i should be using the wpa_ctrl
> > > interface in my rewrite of wps_enrollee.
> >
> > ctrl_iface is useful for number of cases, but I'm not sure that
> > wps_enrollee should be a completely separate program..
> >
> > > Here is how it would work:
> > > -- wpa_supplicant already running
> > > -- separate software determines which writeless interface is being
> > > configured, the ssid to use for configuration as well as the security
> > > mode to use (push button or pin)
> > > -- wps_enrollee is run, being passed this information.
> > > -- wps_enrollee registers (via wpa_ctrl) to be called on assocation
> > > with ap. -- wps_enrollee tells wpa_supplicant (via wpa_ctrl interface)
> > > to associate the interface in open mode (required for WPS).
> > > -- on association with ap, wps_enrollee state machine runs
> > > -- when wps state machine is done and new configuration established,
> > > wps_enrollee optionally writes to file and optionally tells
> > > wps_supplicant directly the new parameters (via wpa_ctrl).
> >
> > What are the benefits of keeping wps_enrollee separate? As far as I can
> > tell, it seems to share lots of functionality and implementation with
> > wpa_supplicant and as such, it would likely add extra work for
> > maintaining the code and extra cost in program size if it were to remain
> > separate.
> >
> > There may be some limits on resources that make it difficult to run two
> > programs that process EAPOL frames at the same time. For example,
> > NDISUIO on Windows XP does not support more than one program at a time
> > for receiving frames. Consequently, wpa_supplicant and wps_enrollee
> > could not use l2_packet_ndis.c at the same time.
> >
> > --
> > Jouni Malinen                                            PGP id EFC895FA