wps_enrollee-20071029

[Dan Williams]

On Wed, 2007-10-31 at 21:32 -0700, Ted Merrill wrote:
> On Wednesday 31 October 2007 20:14:57 Jouni Malinen wrote:
> > On Mon, Oct 29, 2007 at 03:07:41PM -0700, Ted Merrill wrote:
> > > Here is the wps enrollee code that Atheros is currently developing.
> > > It was based upon the simpleconfig code i last sent you as well as the
> > > wpa_supplicant code.
> > > It could use some restructuring and is incorrect in places... i've noted
> > > some of the problems in the README file.
> > > It is not ready for use at this point, but may be close.
> >
> > Thanks!
> >
> > > Anyway, i'd appreciate if you could post this and then if we discuss how
> > > this could be re-architected to fit into the hostap tree.
> >
> > It is now available at http://w1.fi/contrib/wps_enrollee-20071029.tgz
> >
> > I took only a quick look at it now and will need to spend some more time
> > to be able to discuss in more details what would be best way to
> > integrate WPS functinality into the main tree.
> 
> Thanks
> 
> >
> > If I understood correctly, this is taking in just the parts of
> > wpa_supplicant that is needed to implements WPS and the end result
> > (e.g., SSID + WPA PSK) would be used with another program.
> 
> Right, the end result is a wlan profile which can be used by wpa_supplicant, 
> hostapd, and wsccmd (since a device can be sometimes a client and sometimes a 
> server).
> The code has been written to automatically start up these programs when 
> appropriate.
> 
> >
> > Is this design (and/or future goals for it) limited to only using WPS
> > over EAP transport and only act as an enrollee in IEEE 802.1X
> > supplicant? Personally, I kind of like the idea of tightly integrated
> > WPS enrollee in wpa_supplicant, but I would expect large parts of the
> > WPS implementation to be re-usable for other transports and usage
> > scenarios.
> >
> 
> This wps_enrollee program is simply designed for the WPS enrollee situation, 
> and is run with wpa_supplicant NOT running.
> In this situation, a client needs to not use any other wlan profiles it might 
> have and just use an "open system" profile... an AP which advertises WPS 
> capability should allow the enrollee to associate without authentication or 
> encryption, although the packets exchanged must be limited by the AP to WPS.
> The approach this program takes is that wpa_supplicant should not be running;
> this program handles the open system association and when done it writes a 
> configuration file for wps_supplicant and starts wps_supplicant up.
> Integrating this into the wpa_supplicant program itself certainly seems 
> doable, although i'm not aware of a strong advantage to doing so.

Is this meant mostly for embedded setups?  What we're doing with
NetworkManager and desktop/server on Linux is to run wpa_supplicant
_all_ the time and communicate with it over the D-Bus interface.  So to
do WPS in that situation we'd need to be able to feed that information
to wpa_supplicant over the control interface long after it's started up.
We don't even give wpa_supplicant a configuration file, and all
interfaces are added and removed after wpa_supplicant starts up.  The
command line is essentially "wpa_supplicant -u".  So whatever
information WPS needs ought be able to be added after-the-fact as a
network configuration block or something, hopefully.

If this usage is completely irrelevant to the discussion, please
ignore...

Thanks,
Dan

> I'm working on a cleanup of the wps_enrollee code and could be done with that 
> in a few weeks (i want to get the hostapd patches for WPS server to you soon, 
> perhaps tomorrow).
> 
> -Ted Merrill
> 
> 
> 
> 
> 
> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap