[PATCH 1/3] Added wpa_config_get_all function

[Dan Williams]

On Tue, 2009-11-10 at 15:38 +0200, Jouni Malinen wrote:
> On Mon, Nov 09, 2009 at 10:23:57PM -0800, Dan Williams wrote:
> > At the moment, the D-Bus interface is restricted to 'root' only.  This
> > is done by the D-Bus permissions config file (dbus-wpa_supplicant.conf).
> 
> OK.
> 
> > I think the idea here was to ensure that an external program (like NM)
> > could get the actual key used to connect to the network after the WPS
> > exchange had succeeded.  Otherwise, how would we know what PSK to send
> > back to the supplicant the next time we connect?
> > 
> > We can't really send out a signal (since signals are usually readable by
> > anyone) thus the original method of caching the response and using
> > properties to get it.  If you don't like that (you didn't) then we can
> > let the supplicant update the network block in the in-memory config, and
> > then add a method to allow NM to read back the updated network block
> > (which I think you are now objecting to as well :).  Not sure how we're
> > supposed to get out the negotiated PSK then?
> 
> There were two reasons for me not liking the caching of WPS credentials:
> I did not know why it was needed (this explanation on signal readability
> seems to explain that) and it not working very well (at least in theory)
> should there be multiple new credentials being received close to
> each other with the latest one replacing the older ones which may or may
> not have been fetched.
> 
> The original patches introduced both mechanisms (access to full config
> and caching of WPS credentials). Why? Would only one of them be enough?
> Or to be more specific, would caching of WPS credentials be enough?

The end goal is to get the final PSK used to connect to the AP out of
the supplicant.  How that happens I don't really care :)  I think
caching the WPS credentials themselves was actually just for API
completeness (ie, if the caller dies or quits, it could pick up right
where it left off by asking for the current supplicant state instead of
having to torpedo whatever was going on and restart it).

But for now, all I care about is getting the PSK back.  We could just
cache the negotiated PSK for a specific WPS request and that would work
too, if you really don't want to provide access to the full network
blocks.  The D-Bus API returns a request-id to the caller when starting
a WPS request, so the caller could use that request-id later to grab the
PSK out when needed.

Dan