Re: [PATCH v2] wifi: support ap-mode with wpa_supplicant

[Dan Williams <dcbw redhat com>]

On Tue, 2012-09-25 at 10:40 +0200, Jan Lübbe wrote:
> On Mon, 2012-09-24 at 11:16 -0500, Dan Williams wrote:
> > On Mon, 2012-09-24 at 12:21 +0200, Jan Lübbe wrote:
> > > On Mon, 2012-09-24 at 12:10 +0200, Jan Lübbe wrote:
> > > > I noticed that for checking if wpa_supplicants supports AP mode, NM
> > > > needs a wpa_supplicant build from their master branch (not 1.0).
> > > > 
> > > > When using it with this wpa_supplicant, AP mode still works for me.
> > > 
> > > If I revert 6d726622069338652326d9a0057b07b100d4f79a (wifi: detect
> > > whether supplicant supports AP mode or not), it also works with
> > > wpa_supplicant 1.0.
> > 
> > Darn, I'd hoped 1.0 would indicate its capabilities, but I unfortunately
> > didn't check.  I suppose what we do here instead is use the "has_apmode"
> > variable to fine-tune the error message, but still allow AP connections
> > to be attempted even if we don't know for sure that the supplicant
> > supports them.  If it doesn't, we just can't return a more specific
> > error, but I guess that's the best we can do.
> 
> I've seen your patches on the hostap list (dbus: add global capabilities
> property, supplicant: set state to DISCONNECTED on AP creation errors).
> If you have a matching NM patch for the capabilities property, I could
> test it here with an updated wpa_supplicant 1.0.

Not yet; that's just to improve the situation a year or two from now if
we decide we can drop support for hostap-1.0 at some point.  Until then
we still have to work with older supplicants and thus we'll have to just
try to start the AP and then fail if the supplicant doesn't support it.
But if encounter a supplicant with the patches I've submitted, then we
can fail more gracefully and ideally provide the user with feedback
saying that the supplicant doesn't support AP mode, rather than some
completely unhelpful generic error.

Dan