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
