On 23 January 2014 13:20, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Thu, 2014-01-23 at 11:33 +0100, Michal Kazior wrote: > >> An extreme approach would to actually update AP IEs in mac80211. This >> way it would be possible to pull any interface into CSA implicitly if >> you're out of channels. This way single-channel multi-BSS AP could >> probably switch atomically without races and your multi-channel >> GO-possibly-follows-STA would still work. > > I don't really like updating IEs in mac80211 much. Asking userspace > shouldn't be *that* much slower. I'm not really fond the idea either. Though it's not about being slower but about the 'dragging other interfaces along' being possibly automatic when you're out of channels. >> > The CAC might take too long. If we have an AP1 and a STA and the STA >> > gets the CSA from its AP2 with a short count, AP1 may not have the time >> > to CAC. In this case, AP1 have two choices: trust that AP2 is doing the >> > right thing and moving to a usable DFS channel or shut itself down. >> >> That's the point. AP1 doesn't have time to perform CAC in this case, >> but it should still be possible for AP1 to _just_ beacon CSA as it's >> only a hint. AP1 could then be stopped to perform CAC, and once it's >> completed restart the AP1. > > I don't get this side discussion about CAC. There's no time to do CAC in > the middle of a CSA *anyway* since you can't be beaconing on the old > channel while doing CAC on the new channel, and if you stop beaconing > entirely for the time of the CAC then all clients will likely go away... You're right, but.. > I'm not sure I understand how you can ever do a CSA to a radar channel > that would still need CAC? You're supposed to fulfil a uniform channel usage spread which includes "usable" DFS channels. With CSA you're at least able to tell stations to stop Tx and should wait for you (the AP) on a different channel. Michał -- 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
