Re: [PATCH 1/4] cfg80211/nl80211: add channel switch started and failed notifications

[Luca Coelho <luca@coelho.fi>]

Finally got the time to come back to this...

On Wed, 2014-05-07 at 11:55 +0000, Peer, Ilan wrote:
> 
> 
> > -----Original Message-----
> > From: Johannes Berg [mailto:johannes@sipsolutions.net]
> > Sent: Wednesday, May 07, 2014 14:20
> > To: Peer, Ilan
> > Cc: Luca Coelho; linux-wireless@vger.kernel.org; michal.kazior@tieto.com;
> > Otcheretianski, Andrei
> > Subject: Re: [PATCH 1/4] cfg80211/nl80211: add channel switch started and
> > failed notifications
> > 
> > On Wed, 2014-05-07 at 10:27 +0000, Peer, Ilan wrote:
> > 
> > > > In the first case, there's no notification, nor any need for it. In
> > > > the second case, the scenario you suggest doesn't apply, and STOP_AP
> > > > has to happen anyway because the state is completely messed up,
> > > > clients will be in the process of switching etc.
> > > >
> > > > > Other than that, a STOP_AP might introduce some races, as
> > > > > wpa_supplicant/hostap will not know if the stop_ap was due to the
> > > > > failed CS or due to some other reason.
> > > >
> > > > I don't see why that would matter - even if the STOP_AP *was* for
> > > > some other reason, but happened in the middle of the CS flow, the
> > > > reaction would presumably be the same?
> > > >
> > >
> > > It can be beneficial to know that the STOP_AP was called due to
> > > failure of CS, as wpa_supplicant/hostap can tear down the AP and then
> > > (if possible) set it up again on the new channel or another channel.
> > 
> > Maybe that's more of an argument for adding a sort of "reason" or "cause" to
> > the STOP_AP? (Btw, no tear down needed in this case - that's already done)
> > 
> 
> Yes :)
> 
> > OTOH, what else are you thinking of doing? Why would you ever, under any
> > circumstances, not restart the AP if it was stopped by the device?
> 
> Actually this is the default today: on STOP_AP notification a GO interface is simply deleted, as the assumption is that something unrecoverable happened. In case of CS failure, it would be *nice* to know if the failure is recoverable or not.

Okay, so this is what I'll do:

* remove the failed notifications
* in a new patch, add a reason attribute to the STOP_AP notification;

--
Luca.