MT7921u: Driver doesn't support chan-switch with channel contexts (please help test this...) #283
Comments
|
I noticed the DFS issue is listed in AP mode. I'm experiencing it in client mode, so the kernel driver does not support DFS at all, in any mode. This must be noted as it can be a serious problem for typical users. |
Thanks for the report. The DFS problem in the pinned issue is a result of the support intentionally not being there. Same with the mt7612u and mt7610u chipsets. DFS for AP mode requires separate testing and FCC approvals and I suspect Mediatek management simply did not think it was a capability that needed to be in usb adapters. I am simply trying to get Mediatek's attention to the fact that 5 GHz AP mode DFS support is and will continue to be important and is feature we want. Now, the issue you are reporting really needs its own separate bug report in the pinning issue and if we can get others to confirm it and tighten it down, that will help. I have the ability to test and will start doing so soon. I love a good bug hunt. If we can tighten it down to something very repeatable on multiple distros, it will be time to report it to those who work these issues... or if we can develop a patch, we can submit the patch. I will say this, my main 5 GHz radio on my main wifi router is set to a DFS channel and I have not noticed this but I have not been specifically looking for it and I am likely using a different setup than you so work to be done. |
morrownr
changed the title
|
I started the bug hunt on my end today. My wifi router is a dual band Zyxel running OpenWRT 23.05 rc1. 5 GHz is running with channel 128 and 80 MHz channel width. My client is on my main dev box running Ubuntu 23.04 x80_64. The adapter is a CF-951AX. First run of operf3: I looked around in dmesg and clean so far. My understanding is that my router that is on a DFS channel needs to initiate a channel change and that should trigger a drop, right? I'll just work as usual and if drops don't show up, I will start changing the chennal until hopefully I trigger a drop. One possibly major difference in our client systems is that I am not running wpa_supplicant as Ubuntu changed over to IWD. |
|
Yes, everything works fine until the AP decides to change the channel. At that point the connection drops, the syslog shows the "driver doesn't support chan-switch with channel contexts" message and it reconnects again in the new channel. It is just a matter of 2 - 3 seconds. |
Okay, good information. So, when the AP changes channel, there is a drop but the drop only last 2-3 seconds before the connection is reestablished. Question: You are only seeing this with DFS channels? I have a little lab so I can, given enough time, test many adapters on many distros. One thing I have to say is that there are a LOT of patches flowing into linux-wireless currently and have been for a while. The wireless stack is getting a lot of new features so it is possible that the stack has a new feature and the driver simply has not added the feature yet. I am actually amazed at how solid the mt7921u/e/s drivers are at this point given the very large size required for WiFi 6/6e support. Oh, I can also test a mt7922e client as I have a PCIe card based on the mt7922 chipset. It uses the same mt7921 driver as the mt7921 chipsets. It uses different firmware but the same driver. |
It is hard to answer this. Here where I live (Spain) only the first four channels are DFS Free (36, 40, 44 and 48) and they are so crowded we usually configure our APs in auto channel mode. The problem is channel jump can be a rare event (one in two or three days) or very very common (dozens in just an hour) So channel changes can occur jumping into a DFS one, or jumping out of a DFS one. I will keep an eye to track the channels my AP is using. |
|
Yo intiendo todo. I understand. We can report back here as we have additional information. |
|
Hello! This afternoon I had a channel switch. From channel 100 (DFS) to channel 52 (also DFS) Syslog: As you can see in timestamps, it all was in about 5 seconds. |
|
And while I was writting the previous message, I had another channel change, from 52 (DFS) to 36 (no DFS). Same syslog sequence as you can see: And this time reconnection was done in 6 seconds. |
|
And now from channel 36 (no DFS) to channel 100 (DFS). Same syslog sequence, so I will not repeat it here. No matter what channels are involved (DFS or not DFS) , there is a connection drop every time the AP changes the channel. |
|
I was not seeing anything here for the first 2-3 days of testing most likely because my AP was not seeing any need to switch channels. Therefore I decided to manually switch channels. I run OpenWRT. I did a few times using DFS and non-DFS channels with a consistent result.: The connection would drop but would not recover. The only way to get the connection going again was to cycle wifi off and back on. Now I need to look at the logs. This does seem to indicate the problem is with my client. FYI: My client system currently has a PCIe adapters with a mt7922e chipset and a USB WiFi adapter with the mt7921au chipset. Both showed exactly the same result... which is probably what we should expect since the driver for both share a lot of code. The key line you are seeing in your log is? : driver doesn't support chan-switch with channel contexts I think some research is in order. Rsearch into that message and research into what the expected outcome should be. |
Yes, a quick search in syslog files must be enough to see is the problem is present or not. The string is present in net/mac80211/mlme.c, for example: https://github.com/torvalds/linux/blob/master/net/mac80211/mlme.c#L1963 and as you can see, the action after syslogging the message is to drop the connection. Using kernel 6.3.7 and loading these firmware files: |
|
I've been seeing the same thing on my Raspberry Pi running Ubuntu Lunar for months. In my case, the RPI is running headless, so when this occurs, I must go connect via ethernet to restart WiFi or power cycle. A real pain. Jul 18 06:58:23 Vancouver systemd-networkd[1033]: wlxe0e1a9368b21: Lost carrier I'm located in the Bay Area in California, so I imagine there are quite a few sources of DFS strikes nearby, ergo this becomes a tedious daily, or sometimes multiple times a day occurrence. Has anyone reached out to the mediatek mailing list to ask them to fix this? I suppose I will this evening, now that I've found this discussion, and know that it's not likely caused by some configuration error on my part. updateA quick search of the mediatek mailing list archive shows that there has been some work in the past year to handle this on a sister mediatek chipset. I suggest that we join that discussion to flag that similar work needs to be done on the 7921 & 7922. see: |
|
Hi @mike-silva
Not that I am aware of. I monitor linux-wireless and not the Mediatek list. Obviously this needs to get some attention. Maybe you guys can collaborate on a good [bug report] and post it accordingly. There is the downstead mt76 repo: https://github.com/openwrt/mt76 No matter where this is reported, include a link to this thread for background. I'm not sure that the 2 links provided about the 7915 driver will be much help. |
|
Thanks @morrownr for your reply and your work here tracking these devices on Github. I'm about to post to the mediatek list, and for sure will reference the excellent reports here, so they can see it's a common problem that needs addressing. If anyone wants a handy link to peruse an archive of the mediatek specific mailing list for linux-wireless, it's here: If you search there for the terms "mt76 dfs" or "mt76 radar", you'll see that there are several threads about fixing such issues on other chipsets...just not the ones we care about here. And, of course, it probably wouldn't hurt if folks here keep an eye on my report on the list, and pipe up if there is additional relevant info or corroboration needed. Thanks! |
|
Mike, I saw your bug report on the Mediatek list this morning. Hopefully this is fixed soon. I also run a couple of Pi's headless and they connect to a DFS channel. I think the difference is that I live in an area where DFS switching is just not triggered on the channel I use. Keep us posted on anything you find out. |
|
Yah, I'm a bit worried, because I seemed to have some bad luck in my bug report timing. If you noticed, last night there were like 80 or so patches that hit the list. Hopefully, my report doesn't get lost in the shuffle. No response as of now. I'll give them until the weekend, since things seem busy, then bump it if I haven't heard back. Or, if folks here want to pipe up with their own logs and corroboration, I'm guessing that can't hurt. Just sayin'. |
|
Unfortunately, I've gotten no response to my mailing list bug report. But, I just CC'd the mediatek development team and linux wifi lead maintainer directly, as their emails are listed on the linux-wireless documentation site. Hopefully, this will bring some visibility. To be fair, the list has been incredibly busy this week, for obvious reasons with the new in development linux kernel being open to changes. |
They also have numerous new drivers for WiFi 7 in progress as if they need more to do. Remember to be very kind and not push too hard so that you don't end up in the penalty box. |
|
Yup, noticed that too. Plus, a bunch of SOC work for Single Board Computers. I'm a software/network engineer. I'm pretty good about pinging, without being a dick. :-) But, I'm persistent. And, I'll hit up Comfast at some point too. Vendor requests for support from their chipset makers pull a lot more weight. It's an egregious enough bug. You don't support WIFI 6 by any stretch, if you're not properly handling DFS...nor even trying. |
Yes it is and speaking of egregious bugs... somebody made the decision to backport something from kernel 6.5 and patch it into everything back to and including kernel 6.1.39 so I am trying to patch six Realtek drivers in a way that results in the least damage. There is no good fix. |
|
Just to be clear, you know that Realtek sold a few of their chipsets to Mediatek a year or two ago, right? Thus, some of the upheaval in the codebase. It seems like Mediatek is trying to clean up some technical debt, but they definitely carried over old Realtek bugs. And, when they then derived new chipsets from the IP they bought, carried it forward to those derivatives. (And to make the situation more comical, one is now suing the other for monopoly business practices, squeezing them out of vendor contracts.) My main point though, is if there are silly Realtek issues, you might want to hit up that mailing list/dev team instead. If they are still true Realtek chipsets. I think at this point the chipsets bought by Mediatek have had their driver/firmware files/directories renamed to be prefixed with mt rather than rt. Edit to add... On the bright side, I hope that the continued deriving of additional chipsets and that they seem to have them sharing the mt7961 driver means the 7921 & 7922 don't become ship it and forget it abandonware, at least from a driver perspective. |
|
Maybe Mediatek can counter sue Realtek for making sh*tty drivers. :-)
|
|
Sorry to gum up the git with blather, but I have to say that your comment just made me spit-take my coffee. |
I'm all for it. That is what makes life worth living. Leave it to a Canadian to stir things up. I spent a lot of time in Canada earlier in my life and I grew fond of the Canadian sense of humor. Now back to business,,, That link is just to add to the discussion. A quick google and you can get numerous articles about the same topic.
I have not seen anything to verify that, I have suspected some things having to do with anti competitive business practices were happening between the two companies but that was not one of them. Mediatek is somewhat dominant in wifi for TV's and that seems to be what started this problem but then Realtek is dominant in usb wifi and I suspect Realtek is trying to lock down buyers of its usb chipsets in exclusive contracts, which would also be illegal in the US. Mediatek got the IP for its wifi from Ralink when it bought them in 2013 and that includes up to the mt7612u chipset. Mediatek beat Realtek to the usb wifi market for 6 GHz by around 2 years. Search for Mediatek and Samsung. These cases take forever to go to court, if they go to court so the cat fight will likely continue for a few years. But I do like the idea of suing Realtek for their sh*tty drivers. We would have standing in this case but I don't think Mediatek would. |
|
Ah crap. I guess I misremembered and confused Ralink and Realtek. I'll double check tonight. Sorry. On second thought, what am I saying, if anyone is going to know who acquired what chipsets, it's gonna be you @morrownr. Ars also did a good piece on the anti-competitive practice suit: And, hosts a PDF of the legal filing: |
|
I haven't had a lot of time to look yet, nor have I heard anything directly from the Mediatek folks, but these 2 patches from Mediatek today look promising. Cursory take on the run: kinda hard to support channel switch with channel contexts, if your driver can't see that your chipset supports it. |
Wait until you are my age. The misremembering happens more frequently.
We can look forward to seeing where this goes and what it fixes. |
|
Those two patches cleared testing by a member of the Chrome OS team. I'm expecting them to be released in the next few days, at which point I'll start testing them. I'll add a comment here, letting everyone know when the binaries are available. |
|
Well, nothing has been released yet. To be frank, I'm not sure exactly what the linux firmware team's release management methodology/schedule is. In the past, I've seen patches hit the mediatek mailing list, then hit the binary firmware releases in git.kernel.org in 2-3 days. I'll ping back here when it happens. |
Hello!
After using a Comfast CF-953AX for about 10 days I noticed disconnections from time to time.
Looking into syslog I found for every disconnection this:
kernel: driver doesn't support chan-switch with channel contexts
wpa_supplicant: CTRL-EVENT-DISCONNECTED bssid=a6:64:xx:xx:xx:xx reason=4 locally_generated=1
After a quick search in the kernel tree, this happens when the AP issues a frequency / channel change because of DFS (using 802.11h: IEEE80211_HW_CHANCTX_STA_CSA) and the kernel driver does not handle it. The action in response is to disconnect the link.
So... in the current status of MT7921u driver is it does not handle DFS issues, so expect frequent link disconnections while working in the 5 GHz band. Keep it in mind if you need a rock solid connection to your AP.
Probably this must be added to the known issues list, because it can be a no-go for many users.
Tested using Debian Sid with kernel 6.3.7
The text was updated successfully, but these errors were encountered: