pop-os / linux-firmware

Pop!_OS fork of https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-firmware
Other
38 stars 12 forks source link

Mediatek MT7922 wireless adapter 5GHz connectivity issue #47

Open JohnyTucker opened 1 year ago

JohnyTucker commented 1 year ago

Distribution (run cat /etc/os-release):

NAME="Pop!_OS" VERSION="22.04 LTS" ID=pop ID_LIKE="ubuntu debian" PRETTY_NAME="Pop!_OS 22.04 LTS" VERSION_ID="22.04" HOME_URL="https://pop.system76.com" SUPPORT_URL="https://support.system76.com" BUG_REPORT_URL="https://github.com/pop-os/pop/issues" PRIVACY_POLICY_URL="https://system76.com/privacy" VERSION_CODENAME=jammy UBUNTU_CODENAME=jammy LOGO=distributor-logo-pop-os

Related Application and/or Package Version (run apt policy $PACKAGE NAME): NetworkManager

Issue/Bug Description: 5Ghz wifi doesnt work properly on kernel 6.2 and up with Mediatek MT7922 wireless adapter (Asus Proart x670e). Currently running latest default 6.4.6-76060406-generic and the issue hasn't been resolved. If i downgrade to kernel 6.1.X, the issue is gone. What happens is u can connect to 2GHz network w/o problem, but when you try to connect to 5Ghz one, u keep getting authorization required prompts. Most of the time it takes around 20 confirmations (clicking on "connect" button) before it goes thru. Dmesg is showing handshake timeout when this happens. Once it goes thru, the connection seems stable. I checked available firmwares and seems like the current default 6.4 kernel already contains the latest one as far as i can tell (20230627143946).

Steps to reproduce (if you know): Connecting to 5GHz wifi network using Mediatek MT7922 with MT7921e driver on stable kernel 6.2. and newer will result in issues. When downgrade to 6.1.X, no issues.

Expected behavior: NetworkManager should connect to 5GHz network automatically as it does to 2GHz with Mediatek MT7922 wireless adapters.

Other Notes: I tried clean install, no change. The issue is repeatable with current kernel on mentioned card. Something changed between the kernel 6.1 and 6.2 versions that broke the functionality.

helderjnpinto commented 1 year ago

i have the same issue here some logs. i downgrade to 6.1 to check if will be fixed the issue.

Nov 11 17:57:07 tuf-15 systemd[1]: systemd-timedated.service: Deactivated successfully. Nov 11 17:58:38 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:39 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:41 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:42 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:43 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:45 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:46 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:47 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:48 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:50 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:51 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:52 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:53 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:54 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:56 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:57 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:58 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:59 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:59:00 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:59:02 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:59:03 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:59:03 tuf-15 kernel: mt7921e 0000:03:00.0: chip reset failed Nov 11 17:59:03 tuf-15 kernel: wlp3s0: Driver requested disconnection from AP cc:19:a8:25:48:41

ziswiler commented 1 year ago

Could it be that you are trying to connect to a hidden SSID? I do see the same issue but only on hidden SSIDs. I can connect to regular SSIDs on 5 GHz just fine. And yes, on 2.4 GHz also hidden SSIDs work.

przembot commented 1 year ago

When I force wpa supplicant to connect to 5GHz AP:

[  134.919899] wlp10s0: authenticate with xx
[  134.953477] wlp10s0: send auth to xx (try 1/3)
[  134.955751] wlp10s0: authenticated
[  134.956255] wlp10s0: associate with xx (try 1/3)
[  135.013477] wlp10s0: RX AssocResp from xx (capab=0x511 status=0 aid=5)
[  135.038884] wlp10s0: associated
[  135.067731] wlp10s0: Limiting TX power to 14 (17 - 3) dBm as advertised by xx
[  136.046326] wlp10s0: deauthenticated from xx (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)
[  160.464084] wlp10s0: authenticate with xx
[  160.497675] wlp10s0: send auth to xx (try 1/3)
[  160.499938] wlp10s0: authenticated
[  160.501256] wlp10s0: associate with xx (try 1/3)
[  160.556787] wlp10s0: RX AssocResp from xx (capab=0x511 status=0 aid=5)
[  160.583573] wlp10s0: associated
[  160.668553] wlp10s0: Limiting TX power to 14 (17 - 3) dBm as advertised by xx
[  161.592186] wlp10s0: deauthenticated from xx (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)
[  187.727726] wlp10s0: authenticate with xx
[  187.761114] wlp10s0: send auth to xx (try 1/3)
[  187.763392] wlp10s0: authenticated
[  187.764262] wlp10s0: associate with xx (try 1/3)
[  187.821058] wlp10s0: RX AssocResp from xx (capab=0x511 status=0 aid=5)
[  187.848823] wlp10s0: associated
[  187.915097] wlp10s0: Limiting TX power to 14 (17 - 3) dBm as advertised by xx

it depends on luck, sometimes it connects in one go, sometimes in 10 minutes. With 2.4GHz AP there are no issues, so likely it's a driver issue (not using pop os)

JohnyTucker commented 12 months ago

Hi everyone, i dont wanna jinx it, but looks like i found a solution. No need to downgrade the kernel anymore (im running kernel 6.5.6 now as thats the default Pop_OS kernel after periodic update), just replace the Mediatek MT7922 firmware in /lib/firmware/mediatek/ (patch mcu and ram code) with older one from Mediatek firmware repository, specifically the version 2022-04-19 works for me so far, havent had a single error connecting to 5G network yet. Hope it helps!

mmstick commented 11 months ago

@JohnyTucker Which particular firmware did you revert? That may be something we can revert if it's a widespread issue with this card.

JohnyTucker commented 11 months ago

@mmstick It is ver. 20220322164011 from 2022-04-19 Screenshot from 2023-12-04 18-39-34 I can confirm it works in terms of being able to connect to 5Ghz WIFI, however i did find some further issues. I noticed significant latency at times so i tested and it seems that the combination of older firmware with newer kernel is not as good as using the older (long-term) 6.1.x kernel. For instance, with the old firmware and the new kernel combo, I'm unable to use the ping tool, it just hangs (just like loading some websites from time to time). This doesn't happen with kernel 6.1.x. Interestingly enough, the issue is not present even if i upgraded the firmware to the newest version (20231120183441) while staying on the older kernel. So essentially, while the older firmware fixes the original issue for someone who prefers to be on a new kernel, which is why i closed it, its still not ideal. Something changed in kernel 6.2 and higher causing issues with MT7922 cards.

bvup commented 11 months ago

@JohnyTucker Can you please reopen this issue, because loading the old firmware is just a workaround. The driver/kernel/whatever should get a proper fix.

BTW I have the same problem with a new Lenovo Yoga having an MT7922 adapter. The issue is not tied to Pop!_OS, I have reproduced it with Manjaro, with Debian and derivatives like Mint-LMDE and Ubuntu. The problem occurs with any kernel newer than 6.1, even with 6.6.3.

Not all 5GHz connections are affected, I can connect to my smartphone without any problems, but not to my WiFi router. I never had any issues connecting to this router with any device so far, only with this Yoga.

Made a capture with a wireless sniffer, the 4-way handshake process breaks at message 3:

Key Message 1 is transmitted from the AP to the client Key Message 2 is transmitted from the client to the AP Key Message 3 is transmitted from the AP to the client Key Message 3 is re-transmitted from the AP to the client Key Message 3 is re-transmitted from the AP to the client Key Message 3 is re-transmitted.. ..

wpa_supplicant confirms that messages 1 and 2 gets processed, message 3 is not showing up anywhere in the debug, wpa_supplicant runs into a timeout. So far I could not dive deeper, could not test with a proper AP to see if manipulating eg. WMM makes any difference.

JohnyTucker commented 11 months ago

@bvup Ok, reopening.

PavelNedelchev commented 10 months ago

Is there any resolution to this problem, besides downgrading the kernel? I'm facing the same issue, as described here

mmstick commented 10 months ago

Someone who works at Mediatek, or at least has some knowledge of their hardware, has to submit the fixes to the kernel.

helderjnpinto commented 8 months ago

i have the same issue here some logs. i downgrade to 6.1 to check if will be fixed the issue.

Nov 11 17:57:07 tuf-15 systemd[1]: systemd-timedated.service: Deactivated successfully. Nov 11 17:58:38 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:39 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:41 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:42 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:43 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:45 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:46 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:47 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:48 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:50 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:51 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:52 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:53 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:54 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:56 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:57 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:58:58 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:58:59 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:59:00 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:59:02 tuf-15 kernel: mt7921e 0000:03:00.0: driver own failed Nov 11 17:59:03 tuf-15 kernel: mt7921e 0000:03:00.0: Timeout for driver own Nov 11 17:59:03 tuf-15 kernel: mt7921e 0000:03:00.0: chip reset failed Nov 11 17:59:03 tuf-15 kernel: wlp3s0: Driver requested disconnection from AP cc:19:a8:25:48:41

Just to update my last comment here, I noticed after some time other issues and I found via RAM test is one of the RAMs with memory issues that randomly cause errors on the system. Right now I'm using Kernel 6.6.10-76060610-generic and POP OS 22. After I replace the RAM i not have any issues.

Technochip commented 7 months ago

is this issue solved cause all distros have this issue with this specific mediatek chipset

marcelbeumer commented 5 months ago

what worked for me on fresh install of fedora 40 on a Asus Zenbook 14 UM3702 is to just copy over the entire mediatek folder of the latest linux firmware.

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek to /lib/firmware/mediatek

reboot and 5ghz worked. I think the firmware was patched recently

mmstick commented 5 months ago

I've recently packaged linux-firmware 20240610 which you could test. The packages haven't built yet, but you can add the repository with

sudo apt-manage add popdev:firmware-20240610

You can remove the repository with

sudo apt-manage remove popdev-firmware-20240610