Re: [PATCH] scan: limit COLOCATED_6GHZ flag to 6ghz devices

[James Prestwood <prestwoj@gmail.com>]

Hi Keith,

On 1/3/24 6:42 PM, KeithG wrote:
> On Wed, Jan 3, 2024 at 9:01 AM James Prestwood <prestwoj@gmail.com> wrote:
>> Hi Keith,
>>
>> On 1/3/24 6:57 AM, KeithG wrote:
>>> On Wed, Jan 3, 2024 at 6:58 AM James Prestwood <prestwoj@gmail.com> wrote:
>>>> Hi Keith,
>>>>
>>>> On 1/3/24 4:56 AM, James Prestwood wrote:
>>>>> It was seen that this flag seems to cause issues when in AP mode on
>>>>> brcmfmac devices (e.g. the raspberry Pi 3). When in AP mode an a
>>>>> scan is issued clients will disconnect. After testing this behavior
>>>>> was isolated to the use of the COLOCATED_6GHZ flag.
>>>>>
>>>>> Besides working around the problem on this specific hardware the
>>>>> patch itself makes sense as a non-6GHz capable device shouldn't use
>>>>> this flag anyways.
>>>>>
>>>>> As stated in the patch comment, this isn't really a catch all
>>>>> workaround since the flag is still used for devices supporting 6GHz.
>>>>> If additional hardware exhibits this behavior we may need additional
>>>>> changes like a hardware blacklist or an explicit option to disable
>>>>> the flag.
>>>>>
>>>>> Reported-By: Keith G <ys3al35l@gmail.com>
>>>> Could you double check it still fixes the issue you were seeing on brcmfmac?
>>>>
>>>> Thanks,
>>>>
>>>> James
>>>>
>>>>> ---
>>>>>     src/scan.c | 15 ++++++++++++++-
>>>>>     1 file changed, 14 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/src/scan.c b/src/scan.c
>>>>> index f48ffdef..8c6fdc08 100644
>>>>> --- a/src/scan.c
>>>>> +++ b/src/scan.c
>>>>> @@ -394,7 +394,20 @@ static struct l_genl_msg *scan_build_cmd(struct scan_context *sc,
>>>>>         if (params->ap_scan)
>>>>>                 flags |= NL80211_SCAN_FLAG_AP;
>>>>>
>>>>> -     flags |= NL80211_SCAN_FLAG_COLOCATED_6GHZ;
>>>>> +     /*
>>>>> +      * TODO: This flag appears to cause some undesired behavior on brcmfmac
>>>>> +      *       when the device is in AP mode, or has a secondary AP interface
>>>>> +      *       running, causing clients to disconnect when a scan is issued.
>>>>> +      *
>>>>> +      *       Only using this flag for 6GHz capable devices will limit this
>>>>> +      *       behavior to only 6GHz devices and in reality makes sense
>>>>> +      *       because a non-6GHz device shouldn't use this flag anyways. If
>>>>> +      *       more issues still are seen related to this we may need an
>>>>> +      *       explicit workaround, either brcmfmac-specific or a disable
>>>>> +      *       option.
>>>>> +      */
>>>>> +     if (wiphy_band_is_disabled(sc->wiphy, BAND_FREQ_6_GHZ) != -ENOTSUP)
>>>>> +             flags |= NL80211_SCAN_FLAG_COLOCATED_6GHZ;
>>>>>
>>>>>         if (flags)
>>>>>                 l_genl_msg_append_attr(msg, NL80211_ATTR_SCAN_FLAGS, 4, &flags);
>>> James,
>>>
>>> I will do this tonight. I was playing a lot with iwd that I had
>>> patched with your suggestion last night. I was trying to resolve a
>>> related problem and I did note that it was significantly more stable
>>> with this patch, but I was still getting disconnected periodically. I
>>> do not yet know if those disconnects were due to me or iwd and am
>>> still investigating. I will continue this investigation with this new
>>> patch applied. SHould this patch be against HEAD or can I safely patch
>>> 2.12?

So here is what I found. If I have just a single interface, AP mode, I 
can connect and scan (in AP mode) just fine without resulting in a 
disconnect. If I even create a secondary interface I can no longer 
connect what-so-ever. I see the SSID on my client (Android) device and 
try and connect but see no attempt on the AP side of things. This even 
happens if the second interface is left down, which is really odd to me. 
Could you include exactly how you're setting things up? What interfaces 
you create, etc.

Whats odd is the patch I gave you to privately simply commented out that 
flag and you said that worked, maybe spoke too soon? This patch would 
have no functional difference since the raspi doesn't support 6GHz.

Thanks,

James