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.
> 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.
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.
> 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
punctures it), which would explain the 'compatible' check failing (HE
and EHT need to be compatible, of course.)
johannes
