MT7921u: Driver doesn't support chan-switch with channel contexts (please help test this...)

[ea4eoz]

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

[ea4eoz]

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.

[morrownr]

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

[morrownr]

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:

$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.185 port 56756 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  66.6 MBytes   559 Mbits/sec    0   1.84 MBytes       
[  5]   1.00-2.00   sec  73.8 MBytes   619 Mbits/sec    0   1.84 MBytes       
[  5]   2.00-3.00   sec  72.5 MBytes   608 Mbits/sec    0   1.84 MBytes       
[  5]   3.00-4.00   sec  72.5 MBytes   608 Mbits/sec    0   1.84 MBytes       
[  5]   4.00-5.00   sec  73.8 MBytes   619 Mbits/sec    0   1.84 MBytes       
[  5]   5.00-6.00   sec  72.5 MBytes   608 Mbits/sec    0   1.84 MBytes       
[  5]   6.00-7.00   sec  73.8 MBytes   619 Mbits/sec    0   1.84 MBytes       
[  5]   7.00-8.00   sec  72.5 MBytes   608 Mbits/sec    0   1.84 MBytes       
[  5]   8.00-9.00   sec  70.0 MBytes   587 Mbits/sec    0   1.84 MBytes       
[  5]   9.00-10.00  sec  72.5 MBytes   608 Mbits/sec    0   1.84 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   720 MBytes   604 Mbits/sec    0             sender
[  5]   0.00-10.01  sec   719 MBytes   602 Mbits/sec                  receiver

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.

[ea4eoz]

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.

[morrownr]

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.

[ea4eoz]

Question: You are only seeing this with DFS channels?

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.

[morrownr]

Yo intiendo todo. I understand.

We can report back here as we have additional information.

[ea4eoz]

Hello!

This afternoon I had a channel switch. From channel 100 (DFS) to channel 52 (also DFS)

Syslog:

2023-06-22T17:19:05.116988+02:00 waterhole kernel: [14767.476589] wlxe0e1a9xxxxxx: driver doesn't support chan-switch with channel contexts
2023-06-22T17:19:05.279291+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-DISCONNECTED bssid=a6:64:xx:xx:xx:xx reason=4 locally_generated=1
2023-06-22T17:19:05.314159+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
2023-06-22T17:19:05.320777+02:00 waterhole NetworkManager[674]: <info>  [1687447145.3199] device (wlxe0e1a9xxxxxx): supplicant interface state: completed -> disconnected
2023-06-22T17:19:05.385264+02:00 waterhole NetworkManager[674]: <info>  [1687447145.3849] device (wlxe0e1a9xxxxxx): supplicant interface state: disconnected -> scanning
2023-06-22T17:19:06.555420+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
2023-06-22T17:19:06.735184+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
2023-06-22T17:19:06.873886+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
2023-06-22T17:19:09.131325+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: SME: Trying to authenticate with a6:64:xx:xx:xx:xx (SSID='Wireless' freq=5260 MHz)
2023-06-22T17:19:09.132906+02:00 waterhole kernel: [14771.493950] wlxe0e1a9xxxxxx: authenticate with a6:64:xx:xx:xx:xx
2023-06-22T17:19:09.652956+02:00 waterhole kernel: [14772.012046] wlxe0e1a9xxxxxx: send auth to a6:64:xx:xx:xx:xx (try 1/3)
2023-06-22T17:19:09.652985+02:00 waterhole kernel: [14772.015234] wlxe0e1a9xxxxxx: authenticated
2023-06-22T17:19:09.653269+02:00 waterhole NetworkManager[674]: <info>  [1687447149.6522] device (wlxe0e1a9xxxxxx): supplicant interface state: scanning -> authenticating
2023-06-22T17:19:09.655549+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: Trying to associate with a6:64:xx:xx:xx:xx (SSID='Wireless' freq=5260 MHz)
2023-06-22T17:19:09.659929+02:00 waterhole NetworkManager[674]: <info>  [1687447149.6598] device (wlxe0e1a9xxxxxx): supplicant interface state: authenticating -> associating
2023-06-22T17:19:09.660902+02:00 waterhole kernel: [14772.019974] wlxe0e1a9xxxxxx: associate with a6:64:xx:xx:xx:xx (try 1/3)
2023-06-22T17:19:09.668909+02:00 waterhole kernel: [14772.029590] wlxe0e1a9xxxxxx: RX AssocResp from a6:64:xx:xx:xx:xx (capab=0x511 status=0 aid=80)
2023-06-22T17:19:09.700988+02:00 waterhole kernel: [14772.060620] wlxe0e1a9xxxxxx: associated
2023-06-22T17:19:09.857516+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: Associated with a6:64:xx:xx:xx:xx
2023-06-22T17:19:09.857748+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
2023-06-22T17:19:09.858026+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=ES
2023-06-22T17:19:09.863827+02:00 waterhole NetworkManager[674]: <info>  [1687447149.8635] device (wlxe0e1a9xxxxxx): supplicant interface state: associating -> associated
2023-06-22T17:19:09.929016+02:00 waterhole kernel: [14772.289621] wlxe0e1a9xxxxxx: Limiting TX power to 23 (23 - 0) dBm as advertised by a6:64:xx:xx:xx:xx
2023-06-22T17:19:10.759322+02:00 waterhole NetworkManager[674]: <info>  [1687447150.7584] device (wlxe0e1a9xxxxxx): supplicant interface state: associated -> 4way_handshake
2023-06-22T17:19:10.824847+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: WPA: Key negotiation completed with a6:64:xx:xx:xx:xx [PTK=CCMP GTK=CCMP]
2023-06-22T17:19:10.825130+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-CONNECTED - Connection to a6:64:xx:xx:xx:xx completed [id=0 id_str=]

As you can see in timestamps, it all was in about 5 seconds.

[ea4eoz]

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:

2023-06-22T18:29:29.712949+02:00 waterhole kernel: [18992.145011] wlxe0e1a9xxxxxx: driver doesn't support chan-switch with channel contexts
2023-06-22T18:29:29.893858+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-DISCONNECTED bssid=a6:64:xx:xx:xx:xx reason=4 locally_generated=1
2023-06-22T18:29:29.932674+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
2023-06-22T18:29:29.939286+02:00 waterhole NetworkManager[674]: <info>  [1687451369.9384] device (wlxe0e1a9xxxxxx): supplicant interface state: completed -> disconnected
2023-06-22T18:29:29.999804+02:00 waterhole NetworkManager[674]: <info>  [1687451369.9994] device (wlxe0e1a9xxxxxx): supplicant interface state: disconnected -> scanning
2023-06-22T18:29:31.072845+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
2023-06-22T18:29:31.366126+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
2023-06-22T18:29:33.671828+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: SME: Trying to authenticate with a6:64:xx:xx:xx:xx (SSID='Wireless' freq=5180 MHz)
2023-06-22T18:29:33.672902+02:00 waterhole kernel: [18996.105029] wlxe0e1a9xxxxxx: authenticate with a6:64:xx:xx:xx:xx
2023-06-22T18:29:34.184962+02:00 waterhole kernel: [18996.616730] wlxe0e1a9xxxxxx: send auth to a6:64:xx:xx:xx:xx (try 1/3)
2023-06-22T18:29:34.187128+02:00 waterhole NetworkManager[674]: <info>  [1687451374.1862] device (wlxe0e1a9xxxxxx): supplicant interface state: scanning -> authenticating
2023-06-22T18:29:34.188902+02:00 waterhole kernel: [18996.621383] wlxe0e1a9xxxxxx: authenticated
2023-06-22T18:29:34.190418+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: Trying to associate with a6:64:xx:xx:xx:xx (SSID='Wireless' freq=5180 MHz)
2023-06-22T18:29:34.196079+02:00 waterhole NetworkManager[674]: <info>  [1687451374.1959] device (wlxe0e1a9xxxxxx): supplicant interface state: authenticating -> associating
2023-06-22T18:29:34.196921+02:00 waterhole kernel: [18996.626607] wlxe0e1a9xxxxxx: associate with a6:64:xx:xx:xx:xx (try 1/3)
2023-06-22T18:29:34.204931+02:00 waterhole kernel: [18996.636098] wlxe0e1a9xxxxxx: RX AssocResp from a6:64:xx:xx:xx:xx (capab=0x511 status=0 aid=81)
2023-06-22T18:29:34.232945+02:00 waterhole kernel: [18996.666164] wlxe0e1a9xxxxxx: associated
2023-06-22T18:29:34.232970+02:00 waterhole kernel: [18996.666500] wlxe0e1a9xxxxxx: Limiting TX power to 23 (23 - 0) dBm as advertised by a6:64:xx:xx:xx:xx
2023-06-22T18:29:34.390878+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: Associated with a6:64:xx:xx:xx:xx
2023-06-22T18:29:34.391123+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
2023-06-22T18:29:34.391373+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=ES
2023-06-22T18:29:34.397233+02:00 waterhole NetworkManager[674]: <info>  [1687451374.3970] device (wlxe0e1a9xxxxxx): supplicant interface state: associating -> associated
2023-06-22T18:29:35.297810+02:00 waterhole NetworkManager[674]: <info>  [1687451375.2969] device (wlxe0e1a9xxxxxx): supplicant interface state: associated -> 4way_handshake
2023-06-22T18:29:35.381020+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: WPA: Key negotiation completed with a6:64:xx:xx:xx:xx [PTK=CCMP GTK=CCMP]
2023-06-22T18:29:35.381255+02:00 waterhole wpa_supplicant[676]: wlxe0e1a9xxxxxx: CTRL-EVENT-CONNECTED - Connection to a6:64:xx:xx:xx:xx completed [id=0 id_str=]

And this time reconnection was done in 6 seconds.

[ea4eoz]

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.

[morrownr]

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.:

[  5]   8.00-9.00   sec  71.2 MBytes   598 Mbits/sec    0   1.50 MBytes       
[  5]   9.00-10.00  sec  73.8 MBytes   619 Mbits/sec    0   1.59 MBytes       
[  5]  10.00-11.00  sec  71.2 MBytes   598 Mbits/sec    0   1.67 MBytes       
[  5]  11.00-12.00  sec  73.8 MBytes   619 Mbits/sec    0   1.72 MBytes       
[  5]  12.00-13.00  sec  60.0 MBytes   503 Mbits/sec    0   1.75 MBytes       
[  5]  13.00-14.00  sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes       
[  5]  14.00-15.00  sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  5]  15.00-16.00  sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes       
[  5]  16.00-17.00  sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  5]  17.00-18.00  sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes 

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.

[ea4eoz]

The key line you are seeing in your log is? : driver doesn't support chan-switch with channel contexts

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

if (local->use_chanctx &&
    !ieee80211_hw_check(&local->hw, CHANCTX_STA_CSA)) {
    sdata_info(sdata,
           "driver doesn't support chan-switch with channel contexts\n");
    goto drop_connection;
}

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:

kernel: [ 1304.469711] usb 2-4: new SuperSpeed USB device number 6 using xhci_hcd
kernel: [ 1304.497670] usb 2-4: New USB device found, idVendor=3574, idProduct=6211, bcdDevice= 1.00
kernel: [ 1304.497677] usb 2-4: New USB device strings: Mfr=2, Product=3, SerialNumber=4
kernel: [ 1304.497679] usb 2-4: Product: Wireless_Device
kernel: [ 1304.497680] usb 2-4: Manufacturer: MediaTek Inc.
kernel: [ 1304.497681] usb 2-4: SerialNumber: 000000000
kernel: [ 1304.503517] mt7921u 2-4:1.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7961_1.bin
kernel: [ 1304.630234] usb 2-4: reset SuperSpeed USB device number 6 using xhci_hcd
kernel: [ 1304.788356] mt7921u 2-4:1.0: firmware: direct-loading firmware mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
kernel: [ 1304.788375] mt7921u 2-4:1.0: HW/SW Version: 0x8a108a10, Build Time: 20230302150916a
kernel: [ 1304.798222] mt7921u 2-4:1.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7961_1.bin
kernel: [ 1304.798241] mt7921u 2-4:1.0: WM Firmware Version: ____010000, Build Time: 20230302150956

[mike-silva]

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 Jul 18 06:58:23 Vancouver kernel: wlxe0e1a9368b21: driver doesn't support chan-switch with channel contexts

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.

update

A 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: https://lore.kernel.org/linux-mediatek/b55fec95a7708491a78027cc9a30ba7faa0dd18b.1646106090.git.evelyn.tsai@mediatek.com/ and: https://lore.kernel.org/linux-mediatek/20220124032811.47087-1-xing.song@mediatek.com/

[morrownr]

Hi @mike-silva

Has anyone reached out to the mediatek mailing list to ask them to fix this?

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.

[mike-silva]

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: https://lore.kernel.org/linux-mediatek/

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!

[morrownr]

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.

@morrownr

[mike-silva]

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'.

[mike-silva]

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.

[morrownr]

To be fair, the list has been incredibly busy this week...

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.

[mike-silva]

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.

[morrownr]

It's an egregious enough bug.

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.

[mike-silva]

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.

[bjlockie]

Maybe Mediatek can counter sue Realtek for making sh*tty drivers. :-)

[mike-silva]

Sorry to gum up the git with blather, but I have to say that your comment just made me spit-take my coffee.

[morrownr]

Sorry to gum up the git with blather,

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,,,

https://www.reuters.com/legal/realtek-sues-semiconductor-rival-mediatek-over-patent-bounty-agreement-2023-06-06/

That link is just to add to the discussion. A quick google and you can get numerous articles about the same topic.

you know that Realtek sold a few of their chipsets to Mediatek a year or two ago, right?

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.

[mike-silva]

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: https://arstechnica.com/tech-policy/2023/06/smart-tv-industry-rocked-by-alleged-patent-conspiracy-from-chip-maker/

And, hosts a PDF of the legal filing: https://cdn.arstechnica.net/wp-content/uploads/2023/06/Realtek-v-MediaTek-5-23-cv-02774-SK-6-6-2023.pdf

[mike-silva]

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.

https://lore.kernel.org/linux-mediatek/8fd42ac8e1c97246f6e65225a14fc8a029ac3aaa.1690232804.git.objelf@gmail.com/T/#t

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.

[morrownr]

Ah crap. I guess I misremembered and confused Ralink and Realtek.

Wait until you are my age. The misremembering happens more frequently.

Cursory take on the run: kinda hard to support changing channel switch with channel contexts, if your driver can't see that your chipset supports it.

We can look forward to seeing where this goes and what it fixes.

[mike-silva]

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.

[mike-silva]

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.