wps_enrollee-20071029

[Ted Merrill]

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.
According to how the code is compiled, this can use pipe files, unix sockets, 
localhost sockets or dbus, so it should match any situation.
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).

How does that sound?
-Ted


On Thursday 01 November 2007 12:50:45 Dan Williams wrote:
> 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