Comcast CF-953AX: Device not responding to setup address

[snod4]

Hi,

I just bought the Comcast CF-953AX for use with my Arch setup.

When I plugged it in and ran ip link, I saw no new interface.

I then tried lsusb. Nothing there as well.

Upon running dmseg, I got the following output

I also checked it if was registered on windows and got this weird, middle-ground answer where it wasn't listed as a wifi adapter. It is listed under Other Devices as Wifi_lf.

I'm unsure if the device is DOA or if there is some hope.

[morrownr]

I saw something strange like this yesterday on one of my boxes that has an adapters with the same chipset.

Can you post the results of

$ lsusb

...so we can confirm the vid-pid?

What kernel are you using?

$ uname -r

[snod4]

Thanks for the quick response!

Here's the output of lsusb:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 13d3:3533 IMC Networks Bluetooth Radio Bus 001 Device 003: ID 048d:5702 Integrated Technology Express, Inc. RGB LED Controller Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub Bus 003 Device 003: ID 1038:220e SteelSeries ApS Arctis 7+ Bus 003 Device 004: ID 046d:c099 Logitech, Inc. G502 X Bus 003 Device 005: ID 0951:16e6 Kingston Technology HyperX Alloy Origins Core Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 004 Device 002: ID 05e3:0626 Genesys Logic, Inc. Hub

The wifi-adapter is plugged in to the PC directly, not via an external USB hub.

The output of uname -r is: 6.7.5-arch1-1

[morrownr]

I was looking for something like the following but I don't see it.

Bus 002 Device 002: ID 0e8d:7961 MediaTek Inc. Wireless_Device

Showing up in the lsusb output does not require the driver or firmware so this is likely a connection issue. Keep trying different usb ports (usb2 and usb3) and running lsusb until you see the adapter. Hopefully you can get. If not, it could be a faulty adapter. It happens. You might try to test the adapter in a different system or two just to see if the results are different.

[PythonNut]

This recently started happening to me. I have two CF953AXs, and one of them stopped working (the other was not in use). I swapped it out for the other one, which failed in the same way. Then I swapped the machine out for a different one and got the same error again. I also tried multiple ports (but I don't have any USB2 ports). This was working for me until very recently (say a week or two).

For the record, here's the error I receive:

[ 7059.312184] usb 2-2: new SuperSpeed USB device number 3 using xhci_hcd
[ 7059.327802] usb 2-2: New USB device found, idVendor=0e8d, idProduct=7961, bcdDevice= 1.00
[ 7059.328115] usb 2-2: New USB device strings: Mfr=6, Product=7, SerialNumber=8
[ 7059.328372] usb 2-2: Product: Wireless_Device
[ 7059.328537] usb 2-2: Manufacturer: MediaTek Inc.
[ 7059.328735] usb 2-2: SerialNumber: 000000000
[ 7059.335738] probe of 2-2:1.0 returned 0 after 385 usecs
[ 7059.336503] probe of 2-2:1.2 returned 19 after 227 usecs
[ 7059.336949] probe of 2-2 returned 0 after 7773 usecs
[ 7059.361901] Bluetooth: hci1: HW/SW Version: 0x008a008a, Build Time: 20231109191416
[ 7060.002991] calling  ieee80211_init+0x0/0x80 [mac80211] @ 118453
[ 7060.003097] initcall ieee80211_init+0x0/0x80 [mac80211] returned 0 after 14 usecs
[ 7060.021166] calling  mt7921u_driver_init+0x0/0xfc0 [mt7921u] @ 118453
[ 7062.024380] Bluetooth: hci1: Device setup in 2625554 usecs
[ 7062.024586] Bluetooth: hci1: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[ 7064.053280] Bluetooth: hci1: Opcode 0x0c03 failed: -110
[ 7066.101359] Bluetooth: hci1: Failed to read MSFT supported features (-110)
[ 7071.541662] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7077.173848] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7077.381833] usb 2-2: device not accepting address 3, error -62
[ 7082.807044] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7085.640125] workqueue: delayed_fput hogged CPU for >10000us 16 times, consider switching to WQ_UNBOUND
[ 7088.438267] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7088.646263] usb 2-2: device not accepting address 3, error -62
[ 7094.070507] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7099.702728] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7099.910733] usb 2-2: device not accepting address 3, error -62
[ 7105.334987] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7110.967314] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7111.175185] usb 2-2: device not accepting address 3, error -62
[ 7111.191211] usb 2-2: USB disconnect, device number 3
[ 7111.191364] mt7921u: probe of 2-2:1.3 failed with error -5
[ 7111.191605] probe of 2-2:1.3 returned 5 after 51168326 usecs
[ 7111.191670] usbcore: registered new interface driver mt7921u
[ 7111.191860] initcall mt7921u_driver_init+0x0/0xfc0 [mt7921u] returned 0 after 51168595 usecs
[ 7116.599419] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7122.231746] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7122.440303] usb 2-2: device not accepting address 4, error -62
[ 7127.863948] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7133.497107] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7133.704097] usb 2-2: device not accepting address 5, error -62
[ 7133.712145] usb usb2-port2: attempt power cycle
[ 7139.641390] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7145.272667] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7145.480598] usb 2-2: device not accepting address 6, error -62
[ 7150.904825] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7156.537063] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 7156.746041] usb 2-2: device not accepting address 7, error -62
[ 7156.754076] usb usb2-port2: unable to enumerate USB device

I'm pressed for time right now but when I have a moment I'll check some other kernel versions and report back.

[morrownr]

I've a couple of similar reports in other issues so something is wrong. I'll investigate but more info would help... distro, kernel, firmware versions.

[snod4]

Which firmware do you mean?

Bios:

Disto: Arch Kernel: 6.7.9-arch1-1

[morrownr]

The USB WiFi adapter firmware:

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

Linux in-kernel driver consist of 2 or more parts. What we think of as the driver is part of the kernel. However, in-kernel driver require firmware files in order to work. These firmware files are part of the distro, not the kernel.

[gordboy]

The latest bluetooth firmware for mt7921u is broken. This caused the same problems for me.

I deleted the offending file

/lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin

and all is well again. Of course there is a message about missing firmware, but I can live with this until things are fixed in a later firmware release.

[morrownr]

Delete the bluetooth firmware as shown below:

$ sudo rm /lib/firmware/mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin

As gordboy, there will be an error msg in your log but that will have to wait new BT firmware. It causes no problems and your wifi should work.

[muxator]

Hi, I can confirm that removing the bluetooth firmware (on fedora 39 /lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin.xz) indeed solves the problem with Comcast CF-953AX. Thanks @morrownr and @gordboy!

I distinctly remember that the adapter worked flawlessly some months ago. I guess the regression in linux-firmware, right?

I'd like to research if the developers of that subsystem were informed, since it's surprising that this regression survived a number of kernel release cycles now.

[muxator]

Update:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=3b128b6069267b60a46a4074c383183177ee6e6d was integrated yesterday, updating mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin from 20231109191416 to 20240219111427.

The source PR appears to be this https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/173 (the relevant commit hash matches).

I am not versed in the kernel release dynamics enough to predict in which linux-firmware version this change will end up.

It is possible that this upstream change may influence this issue. We can't know for sure, because those opaque binary blobs do not help very much, and the commit message is not very helpful :cry:

I guess the new firmware could be manually tried following instructions on https://github.com/morrownr/USB-WiFi/blob/main/home/How_to_Install_Firmware_for_Mediatek_based_USB_WiFi_adapters.md

[muxator]

Good news: it seems that going back to the the old firmware solves the problem.

Passes to reproduce on Fedora 39, kernel 6.7.9, as root:

mkdir /tmp/firmware
cd /tmp/firmware

# download firmware 20240219111427 and verify its contents
curl --remote-name https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin?id=3b128b6069267b60a46a4074c383183177ee6e6d && ((echo "03afd3e322987348e94ec1cc8f5ef5dc  BT_RAM_CODE_MT7961_1_2_hdr.bin" | md5sum -c ) && echo "Download verified" ) || (echo "ERROR downloading firmware" ; exit 1)

# compress the file in xz
xz BT_RAM_CODE_MT7961_1_2_hdr.bin

cd /lib/firmware/mediatek/

# remove old firmware
rm BT_RAM_CODE_MT7961_1_2_hdr.bin.xz

# replace the firmware with the new one
cp /tmp/firmware/BT_RAM_CODE_MT7961_1_2_hdr.bin.xz .

# copy the selinux context from another random blob
chcon --reference=mt7662u.bin.xz BT_RAM_CODE_MT7961_1_2_hdr.bin.xz

I did not have time to do the same on Arch Linux, but I am confident this would work there, too.

[morrownr]

I distinctly remember that the adapter worked flawlessly some months ago. I guess the regression in linux-firmware, right?

I can give you solid maybe. The problem could be in a patch to the bluetooth stack. It will take some work to figure it out.

I am not versed in the kernel release dynamics enough to predict in which linux-firmware version this change will end up.

Okay, I did not see that the old bt firmware had been reloaded to replace the new version. Yes, the links you posted show the Nov. 2023 release as being uploaded again to replace the new Feb. 24 version. What does this tell us? That Mediatek is aware of the problem and that it is severe enough to take drastic action.

You can follow the firmware guide just for the bluetooth firmware. It will copy (cp) the old file over the new one. Then you could see if the problem is better. I'm sure an emergency fix is being worked on.

I guess the new firmware could be manually tried following instructions on...

Yes, that is correct. Remember to use section 3 and only the bluetooth file.

Here are words about firmware for Linux hardware. I know it is not obvious how this stuff works.

Companies want to and need to keep some code a secret as they have a lot of money invested in the product they are selling. In an open system like Linux, this means what we commonly call drivers come in 2 or more files. I'll go count:

I'm back. I ran the following:

$ lsmod | grep mt7
mt7921e                24576  0
mt7921_common          86016  1 mt7921e
mt792x_lib             69632  2 mt7921e,mt7921_common
mt76_connac_lib        98304  3 mt792x_lib,mt7921e,mt7921_common
mt76                  131072  4 mt792x_lib,mt7921e,mt7921_common,mt76_connac_lib
mac80211             1400832  4 mt792x_lib,mt76,mt7921_common,mt76_connac_lib
cfg80211             1347584  5 mt76,8812au,mac80211,mt7921_common,mt76_connac_lib

This is actually for a PCIe card with the mt7922 chipset but almost the same as the mt7921au chipset. Close enough to get the idea. The primary driver is mt7921e. The primary driver for our usb adapters with the mt7921au chipset is called mt7921u. My adapter is busy on another system and I am lazy so this is close but not perfect.

Notice how many files are supporting mt7921e. Yeah, the driver consist of a lot of files and the firmware is not shown. Remember that the driver files are part of the kernel. If an updated kernel flows into your system, you are getting a new driver as well...automatically. However, firmware is not part of the kernel, it is part of the distro so it is updated when your distro maintainer decides or when you update it like we are talking about here. It takes both the driver files and the firmware files to make things go.

Things used to be more simple. WiFi has become very complicated as we keep piling more capabilities into our WiFi devices. Hopefully this problem is fixed soon.

@morrownr

[morrownr]

> # remove old firmware
> rm BT_RAM_CODE_MT7961_1_2_hdr.bin.xz

This step is unnecessary as the cp command in Linux will overwrite existing files of the same name.

the new firmware seems to solve the problem.

You might want to reword this...

...the old firmware seems to solve the problem.

[snod4]

Thanks everyone. I was able to get the adapter to show up in lsusb and am able to set it up to 'connect' to wifi via wpa_cli. However, even though it says it's connected, I cannot actually access the internet. I can't even access my router's login page. This may not be the place to ask, but I was wondering if anyone had any ideas.

This is the general output when connecting:

This is the status:

[morrownr]

Find a way to get into that router: I recommend you set the router to using AES install of TKIP. This is a security issue.

Maybe someone else can see something I am not.

[bjlockie]

Are you using dhcp? My router blocks IPs it doesn't know about. It was easiest for me to use DHCP and make "static" IPs through DHCP.

[snod4]

I figured out the wifi issue as well. My systemd-network config only matched on my old wifi interface. I had to allow it to match on the new one as well.