Wireless client mode broken on WAX206 post r22866

[Wiz]

Hello,

I haven't had any success trying to get the wax206 to access upstream networks when connected in client mode post r22866 release (kernel 5.15.110). The router connects to the AP but no traffic flows through the wifi/client interface regardless of whether it was connected via 20/40/80/160 and AC or AX.

This is happening on custom and firmware selector builds (standard and custom) and I can't pinpoint what the issue is but can confirm that it began around the same time mt7981 support was added (including any updates or changes to realtek/mac80211 that came with that).

Thanks
Wiz

Last known working build

[Wiz]

Attaching screenshots from a custom build I compiled today - unfortunately, no change.

@daniel Hi! Any clue to what's going on and can I send you the logs?

Thanks

[riodoro]

Hi,

I can confirm this misbehaviour running 23.05.0-rc1.
Client mode in 2,4 GHz is running fine.

Client mode in 5 GHz is broken:
Wifi connections is established
On the WAX206 I see the ingress traffic and the egress traffic with tcpdump.
But the egress traffic, i.e. BOOTP, never reaches the STA AP.
Any help?

[soxrok2212]

Looks related to https://github.com/openwrt/openwrt/issues/12905

[Wiz]

Indeed. I believe this is also related - MT7621: WDS with channel width > 20 MHz and AX not working in newer snapshots

[Wiz]

I think I may have narrowed down the culprit commit - f7665a0

@blocktrron There have been multiple reports of network connectivity issues with routers setup in mesh, WDS and wireless client modes (not sure about AP) since May 17/18th and I suspect some change in the commit you submitted was causing these issues. In my case, the impact was to mt7915E as mt7622 was functioning normally.

My router is setup in wireless client mode and was working fine with builds compiled prior to May 17th. I also tried compiling a new build with the latest mt76 updates (commit 901af27 but I'm still seeing the same issue reported in this and other related threads.

What are your thoughts and do you concur?

[soxrok2212]

Nice find! Probably ping @nbd too.

[Wiz]

My hunch was spot on!

Both mt76 update commits were reverted. I'm now trying to narrow it down even further to the problematic patch -

3 files changed, 343 insertions(+), 6 deletions(-)
 create mode 100644 package/kernel/mt76/patches/100-api_update.patch
 create mode 100644 package/kernel/mt76/patches/110-wifi-mt76-ignore-key-disable-commands.patch
 
  commit 22f1b777
  package/kernel/mt76/patches/100-api_update.patch
 (transmit related)
 
 --- a/tx.c
 +++ b/tx.c
 @@ -330,7 +330,7 @@ mt76_tx(struct mt76_phy *phy, struct iee
	  if ((dev->drv->drv_flags & MT_DRV_HW_MGMT_TXQ) &&
		  !(info->flags & IEEE80211_TX_CTL_HW_80211_ENCAP) &&
		  !ieee80211_is_data(hdr->frame_control) &&
 -	    !ieee80211_is_bufferable_mmpdu(hdr->frame_control)) {
 +	    !ieee80211_is_bufferable_mmpdu(skb)) {
		  qid = MT_TXQ_PSD;
	  }
 
 commit efa44cb5
 package/kernel/mt76/patches/110-wifi-mt76-ignore-key-disable-commands.patch
 (mt7915 related)
 
 --- a/mt7915/main.c
 +++ b/mt7915/main.c
 @@ -410,16 +410,15 @@ static int mt7915_set_key(struct ieee802
		  mt7915_mcu_add_bss_info(phy, vif, true);
	  }
 
 -	if (cmd == SET_KEY)
 +	if (cmd == SET_KEY) {
		  *wcid_keyidx = idx;
 -	else if (idx == *wcid_keyidx)
 -		*wcid_keyidx = -1;
 -	else
 +	} else {
 +		if (idx == *wcid_keyidx)
 +			*wcid_keyidx = -1;
		  goto out;
 +	}
 
 -	mt76_wcid_key_setup(&dev->mt76, wcid,
 -			    cmd == SET_KEY ? key : NULL);
 -
 +	mt76_wcid_key_setup(&dev->mt76, wcid, key);
	  err = mt76_connac_mcu_add_key(&dev->mt76, vif, &msta->bip,
						key, MCU_EXT_CMD(STA_REC_UPDATE),
						&msta->wcid, cmd);

[iamunknown]

Thank you @Wiz - I can confirm that a compiled image with reverted the mentioned commit WDS is working again using HE / AX and channel width > 20 MHz at my Zyxel WSM20 (mt7621).

[visualage]

Do we need to create an issue in mt76 to track this?

[visualage]

Just tested 23.05.0-rc2. Still the same.

[mattimat]

I can confirm, 802.11s mesh does not work.

[cmonroe]

I think you are probably running into mt76 #792.. I put a couple of possible workarounds in this comment. A more official fix is surely coming soon but hopefully this saves you some time.

[Wiz]

Great, thanks for sharing.

I'm now wondering if this is just limited to mt76 as I'm seeing a somewhat similar issue with qualcommax/160MHz (stuck transmit albeit at a different rate) as well and the first thing that comes to mind is mac80211 (shared subsystem).

Let's see.

[cmonroe]

When I was bisecting this down to the piece which broke inside the offending commit I found it was due to the fact that mt76 was no longer forcing LDPC enabled. In the AP case it works fine to get this from config.. in the STA case I'm not sure what the correct behavior is. The patch I linked from Ryder above will follow the config in AP mode but force LDPC enabled for all other interfaces modes (including STA).

I assume you could test something similar in ath11k.. or at least make sure LDPC is enabled in STA mode to rule this case out if ath11k enables it dynamically.

[soxrok2212]

Try this commit: https://github.com/openwrt/mt76/commit/c50be0b54cddba864637bc0a5b13be2d89494103

[Wiz]

Still seeing the same issue with the latest snapshot from today, though it is now impacting receive rates instead of transmit.

Reverting mt76 updates to pre-f7665a0 fixes both transmit and receive on the mt7915.

[ThiloteE]

i would suggest to report your findings at the mt76 repository.

[Borromini]

Especially since mt76 on 23.05 has been bumped as well, so we'll be seeing lots of complaints with the next RC.

@nbd Would you mind having a look?

[nbd]

@Wiz, what was the exact version of the snapshot that you tested?