On 7/14/2025 5:29 PM, Johannes Berg wrote:
> On Mon, 2025-07-14 at 16:16 +0800, Baochen Qiang wrote:
>> Hi,
>>
>> Recently I hit an IoT issue while connecting to an TP-LINK AP. As a station, the
>> connection with the AP initially succeeded, as indicated by the authentication and
>> association logs:
>>
>> [ 528.655093] wlan0: authenticate with 16:d8:64:56:ab:5b (local address=66:81:93:de:79:d8)
>> [ 528.655112] wlan0: send auth to 16:d8:64:56:ab:5b (try 1/3)
>> [ 528.720573] wlan0: authenticate with 16:d8:64:56:ab:5b (local address=66:81:93:de:79:d8)
>> [ 528.720584] wlan0: send auth to 16:d8:64:56:ab:5b (try 1/3)
>> [ 528.790413] wlan0: authenticated
>> [ 528.794115] wlan0: associate with 16:d8:64:56:ab:5b (try 1/3)
>> [ 528.831371] wlan0: RX AssocResp from 16:d8:64:56:ab:5b (capab=0x1911 status=0 aid=1024)
>> [ 528.858116] wlan0: [link 0] local address 9e:c1:c3:67:13:db, AP link address
>> 14:d8:64:4c:ab:5b
>> [ 528.858201] wlan0: [link 1] local address 66:81:93:de:79:d8, AP link address
>> 14:d8:64:4c:ab:5c (assoc)
>> [ 528.911598] wlan0: associated
>> [ 528.978910] wlan0: Limiting TX power to 35 (35 - 0) dBm as advertised by 14:d8:64:4c:ab:5c
>
> Clearly that was with EHT, otherwise you couldn't have two links.
Yeah, indeed.
>
>> However, the connection was later disrupted:
>>
>> [ 533.845338] wlan0: AP EHT information doesn't match HT/VHT/HE, disabling EHT
>> [ 533.845344] wlan0: [link 1] AP 14:d8:64:4c:ab:5c appears to change mode (expected EHT,
>> found HE) in beacon, disconnect
>>
>> with some logs added:
>>
>> ---
>> +static void cfg80211_dump_chan_def(const struct cfg80211_chan_def *def)
>> +{
>> + struct ieee80211_channel *chan = def->chan;
>> + pr_info("chan: [band %u center_freq %u freq_offset %u hw_value %u flags %u
>> max_antenna_gain %u max_power %u max_reg_power %u beacon_found %u orig_flags %u] width %u
>> center_freq1 %u center_freq2 %u freq1_offset %u punctured %u\n",
>> + chan->band, chan->center_freq, chan->freq_offset, chan->hw_value,
>> chan->flags, chan->max_antenna_gain, chan->max_power, chan->max_reg_power,
>> chan->beacon_found, chan->orig_flags,
>> + def->width, def->center_freq1, def->center_freq2, def->freq1_offset,
>> def->punctured);
>> +}
>> +
>> static const struct cfg80211_chan_def *
>> _cfg80211_chandef_compatible(const struct cfg80211_chan_def *c1,
>> const struct cfg80211_chan_def *c2)
>> {
>> const struct cfg80211_chan_def *ret;
>>
>> + cfg80211_dump_chan_def(c1);
>> + cfg80211_dump_chan_def(c2);
>> +
>> /* If they are identical, return */
>> ---
>>
>> The disconnection is caused by different 'punctured':
>>
>> [ 533.845311] chan: [band 1 center_freq 5180 freq_offset 0 hw_value 36 flags 524320
>> max_antenna_gain 6 max_power 24 max_reg_power 24 beacon_found 1 orig_flags 0] width 3
>> center_freq1 5210 center_freq2 0 freq1_offset 0 punctured 0
>> [ 533.845322] chan: [band 1 center_freq 5180 freq_offset 0 hw_value 36 flags 524320
>> max_antenna_gain 6 max_power 24 max_reg_power 24 beacon_found 1 orig_flags 0] width 3
>> center_freq1 5210 center_freq2 0 freq1_offset 0 punctured 8
>
> That message is a bit misleading then - we decided that the EHT wasn't
> valid and so that code fell back to reporting HE, and then that means it
> changed in a strange way.
>
>> 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.
>
> Of course the puncturing bitmap could've been elided before.
>
>> advertised in EHT Operation element contained in AP's beacon:
>>
>> Ext Tag: EHT Operation (802.11be D3.0)
>> Ext Tag length: 10 (Tag len: 11)
>> Ext Tag Number: EHT Operation (802.11be D3.0) (106)
>> EHT Operation Parameters: 0x03, EHT Operation Information Present, Disabled Subchannel
>> Bitmap Present
>> .... ...1 = EHT Operation Information Present: True
>> .... ..1. = Disabled Subchannel Bitmap Present: True
>> .... .0.. = EHT Default PE Duration: False
>> .... 0... = Group Addressed BU Indication Limit: False
>> ..00 .... = Group Addressed BU Indication Exponent: 0
>> 00.. .... = Reserved: 0x0
>> Basic EHT-MCS And Nss Set: 0x00000011
>> Control: 0x02, Channel Width: 80 MHz EHT BSS bandwidth
>> .... .010 = Channel Width: 80 MHz EHT BSS bandwidth (2)
>> 0000 0... = Reserved: 0x00
>> CCFS0: 0x0000002a
>> CCFS1: 0x00000000
>> Disabled Subchannel Bitmap: 0x0008
>>
>> Which fails the check in _cfg80211_chandef_compatible(), because the chandef's are not
>> identical but have the same width.
>
> Question is _which_ chandefs it's comparing.
>
> Can you show the rest of the operation fields? HT/VHT/HE.
IEEE 802.11 Wireless Management
Fixed parameters (12 bytes)
Tagged parameters (472 bytes)
Tag: SSID parameter set: "TP-LINK_BE3600"
Tag: Supported Rates 6(B), 9, 12(B), 18, 24(B), 36, 48, 54, [Mbit/sec]
Tag: DS Parameter set: Current Channel: 36
Tag: Traffic Indication Map (TIM): DTIM 0 of 1 bitmap
Tag: Country Information: Country Code CN, Environment All
Tag: Power Constraint: 0
Tag: TPC Report Transmit Power: 63 dBm
Tag: Tx Power Envelope
Tag: RM Enabled Capabilities (5 octets)
Tag: AP Channel Report: Operating Class 128, Channel List : 42, 58, 155,
Tag: RSN Information
Tag: HT Capabilities (802.11n D1.10)
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
.... 0... = Reduced Interframe Spacing (RIFS): Prohibited
0000 .... = Reserved: 0x0
HT Information Subset (2 of 3): 0x0005
.... .... .... ..01 = HT Protection: HT non-member protection mode (0x1)
.... .... .... .1.. = Non-greenfield STAs present: One or more associated
STAs are not greenfield capable
.... .... .... 0... = Reserved: 0x0
.... .... ...0 .... = OBSS non-HT STAs present: Use of protection for
non-HT STAs by overlapping BSSs is not needed
...0 0000 000. .... = Channel Center Frequency Segment 2: 0
000. .... .... .... = Reserved: 0x0
HT Information Subset (3 of 3): 0x0000
.... .... ..00 0000 = Reserved: 0x00
.... .... .0.. .... = Dual beacon: No second beacon is transmitted
.... .... 0... .... = Dual Clear To Send (CTS) protection: Not required
.... ...0 .... .... = Beacon ID: Primary beacon
.... ..0. .... .... = L-SIG TXOP Protection Full Support: One or more HT
STAs in the BSS do not support L-SIG TXOP protection
.... .0.. .... .... = Phased Coexistence Operation (PCO): Inactive
.... 0... .... .... = Phased Coexistence Operation (PCO) Phase: Switch to
or continue 20 MHz phase
0000 .... .... .... = Reserved: 0x0
Rx Supported Modulation and Coding Scheme Set: Basic MCS Set
Tag: VHT Capabilities
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
Basic MCS Map: 0xfffc
Tag: Extended Capabilities (8 octets)
Ext Tag: HE Capabilities
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
Ext Tag: Spatial Reuse Parameter Set
Ext Tag: MU EDCA Parameter Set
Tag: FILS Indication
Tag: Vendor Specific: Tp-Link Technologies Co.,Ltd.
Tag: Vendor Specific: Tp-Link Technologies Co.,Ltd.
Tag: Vendor Specific: Tp-Link Technologies Co.,Ltd.
Tag: RSN eXtension (1 octet)
Tag: Reduced Neighbor Report
Ext Tag: Multi-Link (802.11be D3.0)
Ext Tag: EHT Capabilities (802.11be D3.0)
Ext Tag: EHT Operation (802.11be D3.0)
Ext Tag length: 10 (Tag len: 11)
Ext Tag Number: EHT Operation (802.11be D3.0) (106)
EHT Operation Parameters: 0x03, EHT Operation Information Present, Disabled
Subchannel Bitmap Present
.... ...1 = EHT Operation Information Present: True
.... ..1. = Disabled Subchannel Bitmap Present: True
.... .0.. = EHT Default PE Duration: False
.... 0... = Group Addressed BU Indication Limit: False
..00 .... = Group Addressed BU Indication Exponent: 0
00.. .... = Reserved: 0x0
Basic EHT-MCS And Nss Set: 0x00000011
Control: 0x02, Channel Width: 80 MHz EHT BSS bandwidth
.... .010 = Channel Width: 80 MHz EHT BSS bandwidth (2)
0000 0... = Reserved: 0x00
CCFS0: 0x0000002a
CCFS1: 0x00000000
Disabled Subchannel Bitmap: 0x0008
Tag: Vendor Specific: MediaTek Inc
Tag: Vendor Specific: MediaTek Inc
Tag: Vendor Specific: Microsoft Corp.: WMM/WME: Parameter Element
Tag: Vendor Specific: MediaTek Inc
>
>> Is this AP misbehaving? or is cfg80211/mac80211 not doing correctly?
>>
>> I am not very familiar with Puncturing, want to hear professional opinions from your guys.
>
> 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?
> punctures it), which would explain the 'compatible' check failing (HE
> and EHT need to be compatible, of course.)
>
FYI I attached the pcapnp file, the last frame is the beacon frame in question (Note this
is not a regular air sniffer, but instead generated with WLAN RX packet dump in driver
log. So only frames from the AP can be seen)
> johannes
Attachment:
disconnection-with-puncture.pcapng
Description: Binary data
