Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v3] mac80211: fix scan blocked on DFS channels in ETSI
 domains
To:     Aaron Komisar <aaron.komisar@tandemg.com>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
References: <1570024728-17284-1-git-send-email-aaron.komisar@tandemg.com>
From:   Peter Oh <peter.oh@eero.com>
Message-ID: <02f58201-4b92-0a1e-d237-6838543a3513@eero.com>
Date:   Wed, 2 Oct 2019 10:46:46 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <1570024728-17284-1-git-send-email-aaron.komisar@tandemg.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk


On 10/2/19 6:59 AM, Aaron Komisar wrote:
> In non-ETSI reg domains scan is blocked when operating channel is a DFS ch.
> For ETSI domains, however, once DFS channel is marked as available afer
> the CAC, this channel will remain available even after leaving this channel.
> Therefore a new CAC will not be required when scan is done.
>
> In cfg80211 scan is not blocked for ETSI reg domains.
> This patch enables scan in mac80211 as well when operating channel is a radar
> channel for ETSI reg domains (unless CAC is in progress).
>
This is not the right approach to solve the problem.

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.

So to solve the issue, the right approach should be "check if DFS 
channels and check if CAC is done".

You may refer how "cfg80211_reg_can_beacon()" is doing for that.


Thanks,

Peter