On Mon, 2025-07-14 at 18:09 +0800, Baochen Qiang wrote:
> > > This 'punctured' is suddenly (I mean even 'EHT Operation' was not seen in previous
> > > beacons)
> >
> > Pretty sure there must've been EHT operation before, otherwise we
> > couldn't connect with EHT, and you had multi-link.
>
> Sorry for misleading, I was not clear. I was trying to say 'EHT Operation Parameters' in
> beacon was always 0 AFTER AssocResp, until this sudden 'punctured' frame.
>
> Of course 'EHT operation' was always seen in the beacon frames.
Right, OK.
[snip]
AP information:
> Tag: HT Information (802.11n D1.10)
> Tag Number: HT Information (802.11n D1.10) (61)
> Tag length: 22
> Primary Channel: 36
> HT Information Subset (1 of 3): 0x05
> .... ..01 = Secondary channel offset: Secondary channel is above the
> primary channel (0x1)
> .... .1.. = Supported channel width: Channel of any width supported
So HT is 40 MHz, that's of course fine.
> Tag: VHT Operation
> Tag Number: VHT Operation (192)
> Tag length: 5
> VHT Operation Info
> Channel Width: 80 MHz, 160 MHz or 80+80 MHz BSS Bandwidth (1)
> Channel Center Segment 0: 42
> Channel Center Segment 1: 0
VHT is 80 MHz (the 160 thing there is misleading) if the primary channel
is 36 and the overall center is 42:
| 36 | 40 | 44 | 48 |
42
> Ext Tag: HE Operation
> Ext Tag length: 6 (Tag len: 7)
> Ext Tag Number: HE Operation (36)
> HE Operation Parameters: 0x003ff4
> .... .... .... .... .... .100 = Default PE Duration: 4
> .... .... .... .... .... 0... = TWT Required: Not required
> .... .... ..11 1111 1111 .... = TXOP Duration RTS Threshold: 1023
> .... .... .0.. .... .... .... = VHT Operation Information Present: False
> .... .... 0... .... .... .... = Co-Hosted BSS: False
> .... ...0 .... .... .... .... = ER SU Disable: False
> .... ..0. .... .... .... .... = 6 GHz Operation Information Present: False
> 0000 00.. .... .... .... .... = Reserved: 0x00
> BSS Color Information: 0x36
> Basic HE-MCS and NSS Set: 0xfffc
He doesn't say anything but it actually cannot unless it were on 6 GHz,
so that's fine.
So yeah, the AP is misbehaving. Now you might argue that as we have EHT
we shouldn't care? Dunno. But basically we don't want to initially
_connect_ to such an AP that's confusing itself with puncturing ... we'd
connect with HE since there it says no puncturing. But while maintaining
the connection because of the code structure it suddenly looks like it
"lost" EHT because the EHT was not well-implemented and we ignore it ...
> > I don't know. I have a feeling that perhaps the AP is misbehaving and
> > setting HE operation to 80 MHz as well (which is invalid if EHT
>
> So what's the expected bandwidth in HE Operation? 40 MHz or less?
Whatever narrowing of the bandwidth is needed to not include the
subchannels disabled by puncturing. Could be 40, or could perhaps even
be 20 if the puncturing bitmap was 0x2 instead of 0x8.
After all, an HE client knows nothing about puncturing, so it will
always use the full bandwidth advertised, if something is punctured in
the HE part of the channel that's the entirely wrong thing for it to do.
Btw, this is also covered by the spec (I have P802.11be/D7.0 at hand
right now):
35.15.1 Basic EHT BSS operation
[...]
If a BSS operating channel width is announced in the EHT Operation
element, then an EHT AP shall announce the BSS operating channel
width(s) to non-EHT non-AP STAs with the following restrictions:
- [...]
- If the Disabled Subchannel Bitmap subfield in the EHT Operation
element is present, the announced BSS operating channel width(s) to
non-EHT non-AP STAs is the maximum width including the primary channel
without covering any punctured 20 MHz subchannel indicated in the
Disabled Subchannel Bitmap subfield in the EHT Operation element as
defined in 35.15.2 (Preamble puncturing operation).
johannes
