News: Mediatek June Firmware Updates

[morrownr]

2023-06-12 linux-firmware: update firmware for MT7922 WiFi device 2023-06-12 linux-firmware: update firmware for MT7921 WiFi device 2023-06-12 linux-firmware: update firmware for mediatek bluetooth chip (MT7922) 2023-06-12 linux-firmware: update firmware for mediatek bluetooth chip (MT7921)

The above list is shown and updated at the following kernel.org site:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/mediatek

Many of the more popular Linux distros supply updated firmware releases via their distro update system but it can take time so if you are experiencing any issues, you can update the firmware yourself. A tutorial is provided on the Main Menu but here is a direct link:

https://github.com/morrownr/USB-WiFi/blob/main/home/How_to_Install_Firmware_for_Mediatek_based_USB_WiFi_adapters.md

Questions?

[Astrako]

Why devs doesn't specify a proper changelog, just an "Update binary firmware...."?

[morrownr]

Hi @Astrako

Each company has to determine what needs to remain secret and what can be open source. A lot of money is used to develop new technology and allowing certain information to be open source would be handing competitors costly information for free. Many hardware developers do a good job allowing us a lot of open source ability but even telling what has been changed in firmware could give away information to competitors.

Once firmware is mature, it rarely changes. The wifi 6e chipsets have been seeing new firmware often for most of the last year and it is likely due to the incredible complexity of the drivers required for wifi 6e. I suspect we are getting close to the firmware maturing.

Hope this helps.

[LINGTIANJIAO]

I try to use the MT7922 in raspberry pi cm4. Do you know how to set it? : )

[whitslack]

A lot of money is used to develop new technology and allowing certain information to be open source would be handing competitors costly information for free.

Be that as it may, there's no reason they couldn't operate a public bug tracker. As things stand, there is no mechanism to carry feedback from users to firmware devs, so the development cycle is effectively "open-loop," and we don't see fixes for long-standing issues. It's conceivable that the Mediatek devs aren't even aware of the myriad USB protocol desync issues in their firmware and driver.

[morrownr]

It's conceivable that the Mediatek devs aren't even aware of the myriad USB protocol desync issues in their firmware and driver.

Not really. There are Mediatek devs in the pinned issue here. The patch that was recently posted is a giveaway. Additionally I send a copy of the top message in the pinned issue to the Mediatek devs once in a while so that they are aware of the most pressing issues. I try not to be pushy as I watch the workload they have with trying to bring many new drivers online while still trying to fix issues. Many of their SoCs require Linux drivers. We may not pay much attention to this work but it is still there and much of that work is Linux only as there is no need for a Windows driver or others.

The Mediatek teams Linux website is: https://wireless.wiki.kernel.org/en/users/drivers/mediatek

You can post bugs to linux-wireless: {bug] wifi: mt76: mt7921u AP mode problem with...

There is the downstream testing location at:

https://github.com/openwrt/mt76

Mediatek devs take care of that downstream test site and AP mode is about as on topic as it gets there.

There is also a kernel bug reporting location. I see Mediatek devs posting patching as a sresult of bugs posted there.

I agree that having a good plave to test and interact is a good idea. I certainly do not have the perfect idea. What do you propose?

AP mode is problematic because of the numerous ways and different softwares that can be used to set up AP mode.

@morrownr

[whitslack]

@morrownr: Thanks for your responses and for your efforts to keep our issues visible to Mediatek.

The Mediatek teams Linux website is: https://wireless.wiki.kernel.org/en/users/drivers/mediatek

I was aware of that page, but it's not a Mediatek page; it's a community wiki page. It is basically a stub and has no links to any bug trackers. It does show four email addresses within the mediatek.com domain, so that's possibly something, but private email is a rather poor venue for engaging in discussion about software bugs, as by its nature it is not an open forum where the public can keep informed of progress. For example, I have no way of knowing if anyone has emailed Ryder Lee, Shayne Chen, Sean Wang, or Deren Wu about the transaction timeout issue in the mt7921u driver, so I don't know if emailing them about it myself would be helpful or a counter-productive nuisance.

You can post bugs to linux-wireless: {bug] wifi: mt76: mt7921u AP mode problem with...

I might, but there is no telling whether Mediatek devs would actually see posts to that list. Judging by how long it took to accept the patch that I submitted by email, it doesn't appear that they engage much with those email lists.

https://github.com/openwrt/mt76

OpenWrt is even further away from Mediatek than the Linux kernel. That's like suggesting that I go to Hertz about a problem that's affecting my Chevy Cruze just because Hertz happens to have some Cruzes in their rental fleet. Even if they were experiencing the same problem as I am, they can't do any more about it than I can.

Mediatek devs take care of that downstream test site and AP mode is about as on topic as it gets there.

So what would you suggest? That I redesign my home network around OpenWrt and reproduce the issues on that platform? That wouldn't prove anything, as the problem is not in OpenWrt but in the kernel/firmware. I can't post a bug report to an OpenWrt bug tracker if I'm not using OpenWrt (which I'm not).

There is also a kernel bug reporting location. I see Mediatek devs posting patching as a result of bugs posted there.

If you mean the kernel Bugzilla, then that surprises me. The usual explanation I read is that the kernel devs basically ignore the kernel Bugzilla, and my own experience with posting bug reports there supports that notion. Nothing there ever gets commented on by anyone who knows anything about the kernel; it's only users crying into the void.

I agree that having a good place to test and interact is a good idea. I certainly do not have the perfect idea. What do you propose?

A "bugs.mediatek.com" would be nice. 😅 An official, upstream forum where the issues can be cataloged and debugging progress tracked.

AP mode is problematic because of the numerous ways and different softwares that can be used to set up AP mode.

Does anyone actually know any way of setting up AP mode on this chipset that is stable? If that were so, then we could start to make progress toward identifying the root issues. With the problem being in the firmware and/or kernel driver, it doesn't make a lick of difference what userspace veneer you're using to engage the kernel driver; the problem exists in kernel space and will be present irrespective of variations in userland. In other words, it makes no difference whether you're running OpenWrt, DD-WRT, Bloody Tomato, NetworkManager, or your own shell scripts; everybody is running hostapd atop the Linux kernel, and those are the relevant components.

We never hear anything from the Mediatek devs. It would be super helpful if anyone could say "recompile your kernel with W debugging option enabled, reboot into it with X command line parameter, write Y to debugfs node Z when the hang occurs, and post the contents of kernel log," but nobody ever provides any steps to collect any more information about the issue, so no progress toward resolving it can be made.

[morrownr]

Does anyone actually know any way of setting up AP mode on this chipset that is stable?

Yes, two ways in fact. One way is with OpenWRT on my main AP/router. OpenWRT has a package for the driver mt7921u driver/firmware. The router has a usb3 port. WiFi 6 is supported. The second way is using my AP guide and a RasPi4B with RasPiOS 23-10-10. The guide should work on Debian 12 on x86_64 but I have not tested yet. This is a bridged setup. I'm using the WiFi 6 hostapd.conf example that I also have up in a separate document. WiFi 6 works well in both setups.

A few weeks ago when a discussion about AP mode started in the pinned issue, I started abusing my RasPi AP setup to see if I could find any problems. I'm still abusing it but have come up with nothing. No drops. No this, No that. I'll give it a 24/7/365 rating.

My AP guide was recently modified a little to fall more in line with recent RasPiOS changes. The only 3 things I use to setup the AP are:

hostapd (needs to be installed and enabled) systemd-networkd (just needs to be enabled) systemd-resolved (needs to be installed and enabled)

No need to compile anything with the latest RasPiOS.

That is it. Rock solid and stable.

[whitslack]

I'm still 99% certain that the userspace software is irrelevant, as the bug is in the kernel and/or device firmware. ("99% certain" means that I would wager $99 to win $1 if I'm right.) The reason I can be so certain is that the userspace software does not sit inline with the packet flow. Once the kernel driver has been set up, the userspace software does essentially nothing (aside from authenticating clients and setting their cryptographic keys). So when the network interface hangs, it's not because the driver is waiting for userspace to do something; it's because there's a bug in the driver's state machine (or possibly in that of the device's firmware).

That said, there may be something different about how systemd is configuring the kernel versus the traditional approach. I don't think systemd really does anything to configure 802.11, though; I think it's just responsible for configuring the network interface (link state, IP addresses, netmasks, routes, bridging, bonding, tunneling, etc.), and the way it does so would be by talking to the kernel over rtnetlink in exactly the same way as iproute2 does, so from the perspective of the kernel, systemd and iproute2 should be indistinguishable.

One potentially significant difference between our setups that I see immediately is that I'm using USB 2.0 because the mini-ITX machine I'm using as my router is many years old and predates USB 3. Even if it had a USB 3 port, though, I'm not sure I would use it, as USB 3 seems to have many stability issues, and the 480 Mbps of USB 2.0 is plenty of throughput for my Wi-Fi network's needs. For the longest time that was faster than my Internet connection, though I did just upgrade to symmetrical gigabit fiber last week.

Another potentially significant difference is that I'm running on the 2.4 GHz band, and two of my client stations are only 802.11n (not ac or ax). With the fiber upgrade last week, I relocated my networking equipment to a more central location in the house, so I may try putting the AXML on the 5 GHz band, though I wouldn't expect that would have any bearing on the driver's USB protocol synchronization.

One thing that I'm beginning to suspect is the extended power saving mode. Do you have wnm_sleep_mode=1 in your hostapd config, and are you testing with any clients that support WNM sleep? I am wondering if maybe the Mediatek firmware is deferring/enqueuing outgoing packets while a client station (in my case a OnePlus 5T Android phone) is in extended sleep, and possibly the driver isn't written to expect such a scenario, possibly because no one at Mediatek ever tested AP mode with a battery-powered client that will enter WNM sleep if the AP advertises support for it, which is not the default in hostapd. If you're only testing using mains-powered clients, then likely you're not exercising the various power-saving modes that 802.11 provides for.