MediaTek MT7610E 5GHz radio not functional in 22.03.0-rc5

[lespinasse]

I am observing this issue on a tl-wr902ac device. When running 22.03.0-rc5, the device is unable to connect (as a wifi client) to my main AP over the 5GHz band. The 2GHz radio works fine, and the 5GHz radio functionality is restored if I go back to the 22.03.0-rc4 release.

I believe the issue is with the MT7610E support rather than the individual device - I have seem similar reports (https://forum.openwrt.org/t/openwrt-22-03-0-rc5-fifth-release-candidate/131652/9 and #10190) for other devices that use the same radio. In all 3 reports (counting this one), only the 5GHz radio is broken and the break happens when moving from 22.03.0-rc4 to 22.03.0-rc5.

Since the tl-wr902ac is a small-memory device (64M), I must mention that I am running very little on it, and see about 27MB free memory in normal usage under 22.03.0-rc4.

[lespinasse]

Still broken on tl-wr902ac in the 22.03.0-rc6 release.

[jaccc]

still broken on AC51U

[jaccc]

AC51U Log with Android phone, 2.4G disabled, free memory: 22 MB

Wed Aug 3 13:54:35 2022 daemon.info hostapd: wlan0: STA xx IEEE 802.11: authenticated
Wed Aug 3 13:54:35 2022 daemon.info hostapd: wlan0: STA xx IEEE 802.11: associated (aid 1)
Wed Aug 3 13:54:35 2022 daemon.notice hostapd: wlan0: AP-STA-CONNECTED xx
Wed Aug 3 13:54:35 2022 daemon.info hostapd: wlan0: STA xx WPA: pairwise key handshake completed (RSN)
Wed Aug 3 13:54:35 2022 daemon.notice hostapd: wlan0: EAPOL-4WAY-HS-COMPLETED xx
Wed Aug 3 13:54:39 2022 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) xx
Wed Aug 3 13:54:39 2022 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.143 xx
Wed Aug 3 13:54:39 2022 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) xx
Wed Aug 3 13:54:39 2022 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.143 xx
Wed Aug 3 13:54:39 2022 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.143 xx
Wed Aug 3 13:54:39 2022 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.143 xx Android
Wed Aug 3 13:54:43 2022 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx

[Ntemis]

MQmaker Witi MT7602EN & MT7612EN both radio same issue radios not functional(unable to connect) 22.03.0-rc6 release.

[lespinasse]

Still broken in the final 22.03.0 release (well, at least as much as the current tagged but not officially announced images count as a release).

[DragonBluep]

@lespinasse revert this commit can fix problem. It's a bug on mt76.
openwrt/mt76@d6ae350

[lespinasse]

I've never done binary openwrt builds (only image builds from packages). What would be the target to build after reverting the mt76 commit - are we talking a full kernel build or just rebuilding the mt76 package ?

[DragonBluep]

I've never done binary openwrt builds (only image builds from packages). What would be the target to build after reverting the mt76 commit - are we talking a full kernel build or just rebuilding the mt76 package ?

These kernel modules need to be compiled with the kernel at the same time. If this process is more challenging for you, you can open a new issue in the mt76 repository. Maybe the maintainers will soon notice.

[lespinasse]

I think the maintainers may not want to revert openwrt/mt76@d6ae350 because that would undo whatever this commit was supposed to achieve on mt7615, mt7915 and mt7921 hardware.

I wonder if this change may be more acceptable to them, preserving the behavior on that hardware while keeping the prior behavior on other hardware:

--- drivers/net/wireless/mediatek/mt76/mac80211.c
+++ drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -267,7 +267,8 @@ static void mt76_init_stream_cap(struct mt76_phy *phy,
        }
        vht_cap->vht_mcs.rx_mcs_map = cpu_to_le16(mcs_map);
        vht_cap->vht_mcs.tx_mcs_map = cpu_to_le16(mcs_map);
-       vht_cap->vht_mcs.tx_highest |=
+       if (ieee80211_hw_check(phy->hw, SUPPORTS_VHT_EXT_NSS_BW))
+               vht_cap->vht_mcs.tx_highest |=
                                cpu_to_le16(IEEE80211_VHT_EXT_NSS_BW_CAPABLE);
 }
 

I have not tested this - I did build it on x86, but can't test it there. I could probably figure out the openwrt build sometime... but if you could test if this fixes the issue on mt7610e, and if someone could test on mt7615, mt7915 or mt7921, this may be enough to try submitting the change upstream ?

[DragonBluep]

@lespinasse Your changes are not much different from reverting the entire commit. They need to cooperate with each other to work. I mean let the maintainers fix this, while keeping the feature. Since we are not familiar with this driver framework, reverting commits is only a temporary workaround.

[jaccc]

build scripts can probably revert commit for affected routers

[jaccc]

Release Notes:
Known issues
None so far.
It seems this breakage is intentional.