> -----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. Regards, Ilan. ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
