On Thu, 2019-10-03 at 08:13 +0000, Aaron Komisar wrote: > > The real reason of scan failure is because mac80211 checks if it's DFS > > channel, but it doesn't check if CAC is done or not. > > The problem is that scan request is blocked in ETSI reg domains. In non-ETSI > reg domains the behavior is fine. > > cfg80211 blocks scan in non-ETSI reg domains and allows leaving the channel > in ETSI reg domains. I think that if we add a function in mac80211, which > checks if we can leave the operating channel this function should also take > into account the reg domain for completeness. > > So to solve the issue, the right approach should be "check if DFS > > channels and check if CAC is done". > > We can't scan while CAC is in progress but why must we verify that CAC was done > in order to perform a scan operation? I agree that'd be weird - if CAC wasn't done we shouldn't be operating on that channel to start with? Peter, can you clarify your objection? Just to be sure - we're talking here about the channel we're currently operating on, not any channel that we might want to scan on. I also note that regulatory_pre_cac_allowed() is named a bit confusingly in this context, but I understand it - maybe a comment would be worthwhile where this function is used, saying e.g. /* * If pre-CAC is allowed, we can also briefly leave the channel * for scanning purposes. */ or something like that. I do wonder if we should pull up the check for "cac_started" into cfg80211? But then if we do that, we could maybe even pull *all* of the checks up? But maybe not because of the tracking which channels we're on etc. But at least the "cac_started" seems feasible? Thanks, johannes
