-------- Forwarded Message --------
Subject: Re: [PATCH v2 2/4] cfg80211: validate RU puncturing bitmap
Date: Thu, 24 Mar 2022 09:35:27 -0700
From: Aloka Dixit <quic_alokad@xxxxxxxxxxx>
To: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>,
linux-wireless@xxxxxxxxxxxxxxx
On 3/24/2022 3:37 AM, Johannes Berg wrote:
(and also, you included all kinds of random other things in these
patches, specifically in nl80211.h, so there's no way I can apply them
as is anyway)
I had added the other nl80211 parts to match local user-space
nl80211 order during testing, forgot to take it out.
Let's discuss once your client side version is sent out.
Thanks.
9.4.2.45 Multiple BSSID element (excerpts from Draft 2.0 version)
The Timestamp and Beacon Interval fields, TIM, DSSS Parameter Set, IBSS
Parameter Set, Coun
try, Channel Switch Announcement, Extended Channel Switch Announcement,
Wide Bandwidth Channel Switch, Transmit Power Envelope, Supported
Operating Classes, IBSS DFS, ERP Informa
tion, HT Capabilities, HT Operation, VHT Capabilities, and VHT
Operation, S1G Beacon Compati
bility, Short Beacon Interval, S1G Capabilities, and S1G Operation, HE
Capabilities, HE 6 GHz Band Capabilities, HE Operation, BSS Color Change
Announcement,
and Spatial Reuse Parameter Set , EHT Capabilities, and EHT Operation
elements are not included in the Nontransmitted BSSID Profile
subelement; the values of these elements for each nontransmitted BSSID
are always the same as the corresponding transmitted BSSID element values.
Hi Johannes,
I am looking at the change in design and i see the below concerns.
While a BSS level RU puncturing gives the flexibility of configuring
different puncturing bitmaps in MBSSID scenario, the same cannot be
advertised on a per BSS basis over the beacon to the stations trying to
associate with the AP. (with reference to text above from Spec)
1. There is a only one EHT operation element (which holds the disabled
subchannel bitmap) that can be announced in a MBSSID beacon.
The spec doesn't allow to announce EHT operation on a per BSS basis.
2. Having a ru_puncturing_bitmap at the chandef level for the AP mode
could also help us decide easily whether DFS is needed or not (Skip DFS
if the dfs channels are punctured) . Having RU puncturing at BSS level
could again lead to confusion if certain BSSes of a single phy are
configured with different RU puncturing bitmaps some including the DFS
channel and some puncturing out all the DFS channels.
Shall we retain the RU puncturing bitmap at chandef level for the AP
mode and keep the RU puncturing bitmap at BSS level for the STA scenarios?
From: Johannes
that's probably a discussion better had on the mailing list, rather than
long-form chat here? :)
not sure it's easy to do with AP/client modes different since we also
have AP + client concurrency scenarios
Hi Johannes,
I have captured the offline discussions above to set the context for others.
Even in the AP & STA concurrent scenario, i believe this approach should
work.
1. In the STA case, The STA shall use the puncture pattern from its
BSS conf for all transmission to its connected AP.
2. In the AP case ( MBSSID case as well), the AP shall use the
puncture pattern from the chandef while it transmits frame to its
connected stations.
The chandef ru_punct_bitmap ultimately gets assigned to the
virtual interfaces at the driver when virtual interfaces are created.
The AP vif shall use the value to control the transmissions to
all its connected stations.
Since the ru_punct_bitmap is announced over EHT Operation IE,
the connected stations would limit its transmission only to the
non-punctured channels.
Could you please share your comments on the above approach?
Thanks
Maha
