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@xxxxxxxxxxxxxxxx] > > Sent: Wednesday, May 07, 2014 14:20 > > To: Peer, Ilan > > Cc: Luca Coelho; linux-wireless@xxxxxxxxxxxxxxx; michal.kazior@xxxxxxxxx; > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
