Random disconnects using ALFA AWUS036ACM (mt76x2u driver) with RPi4

[zedrdave]

In order to improve on the RPi's subpar built-in Wifi capabilities, I bought an ALFA AWUS036ACM USB Wifi key (after reading here that it had one of the better-supported chipset for Linux)…

And I seem to have practically exactly the same problem as what is described in this issue: #92 … Except in my case, the RPi4b is set-up to as a client, not an AP (I connect to it via a Wifi router that is connected to my internet box… unfortunately in different rooms, so plugging the RPi directly to the router is not an option).

Aside from this, and the fact the RPi is running OSMC (I know: not ideal for debugging issues… but should be a fairly straightforward Debian distrib under the hood), I am encountering the exact same problem as described in #92: random and frequent disconnects (most often when under heavy traffic), that only get solved when I unplug/plug the Wifi key again:

> journalctl | grep mt76
Jan 20 12:09:37 framboise kernel: mt76x2u 2-2.1:1.0: ASIC revision: 76120044
Jan 20 12:09:38 framboise kernel: mt76x2u 2-2.1:1.0: ROM patch build: 20140408060640a
Jan 20 12:09:38 framboise kernel: mt76x2u 2-2.1:1.0: Firmware Version: 0.0.00
Jan 20 12:09:38 framboise kernel: mt76x2u 2-2.1:1.0: Build: 1
Jan 20 12:09:38 framboise kernel: mt76x2u 2-2.1:1.0: Build Time: 201406241830____
Jan 20 12:09:39 framboise kernel: usbcore: registered new interface driver mt76x2u
Jan 20 13:53:24 framboise kernel: mt76x2u 2-2.1:1.0: mac specific condition occurred
Jan 20 13:53:24 framboise kernel: mt76x2u 2-2.1:1.0: mac specific condition occurred
Jan 20 13:53:24 framboise kernel: mt76x2u 2-2.1:1.0: timed out waiting for pending tx
Jan 20 13:53:29 framboise kernel: mt76x2u 2-2.4:1.0: ASIC revision: 76120044
Jan 20 13:53:29 framboise kernel: mt76x2u 2-2.4:1.0: ROM patch build: 20140408060640a
Jan 20 13:53:29 framboise kernel: mt76x2u 2-2.4:1.0: Firmware Version: 0.0.00
Jan 20 13:53:29 framboise kernel: mt76x2u 2-2.4:1.0: Build: 1
Jan 20 13:53:29 framboise kernel: mt76x2u 2-2.4:1.0: Build Time: 201406241830____
Jan 20 16:09:28 framboise kernel: mt76x2u 2-2.4:1.0: ASIC revision: 76120044
Jan 20 16:09:28 framboise kernel: mt76x2u 2-2.4:1.0: ROM patch build: 20140408060640a
Jan 20 16:09:29 framboise kernel: mt76x2u 2-2.4:1.0: Firmware Version: 0.0.00
Jan 20 16:09:29 framboise kernel: mt76x2u 2-2.4:1.0: Build: 1
Jan 20 16:09:29 framboise kernel: mt76x2u 2-2.4:1.0: Build Time: 201406241830____
Jan 20 16:09:29 framboise kernel: usbcore: registered new interface driver mt76x2u

Same weird mac specific condition occurred errors. Although not sure if they are a cause or a symptom.

I tried all the solutions mentioned in the thread (without any significant improvement):

1. disabling USB scatter gather:

> cat /sys/module/mt76_usb/parameters/disable_usb_sg
Y

2. moving the Wifi dongle around: normally set-up with a powered USB hub. Tried directly plugged to the RPi (both USB3 and USB2), and switching with other devices plugged to the hub (previous person seemed to have some luck moving it around). No significant improvement. Possibly even worse in some cases (hard to measure).

3. Looked at firmware files and noticed something similar to the mess described here:
   driver files (mt7662u.bin and mt7662u_rom_patch.bin) in both /lib/firmware/ and /lib/firmware/mediatek…

From what I can remember, when I first did the set-up, the driver wouldn't load (and the key wouldn't be recognised), and some digging in the logs showed that it was looking in /lib/firmware/ and complaining about not finding mt7662u_rom_patch.bin there (I know you mentioned in that other thread that this is the location for the PCI chipset driver: it shouldn't be looking there, no idea what's going on). I think I merely copied the files over from /lib/firmware/mediatek (or might have redownloaded them from some other repo): the system seemed happy, the driver got loaded, and it kinda worked… until it started crashing every other hour.

This time: I made sure that the files in /lib/firmware/ were the exact copy of the files in /lib/firmware/mediatek (based on version string, these seem to be the latest available version)… Since that seemed to help the other user.

Unfortunately still no luck… 🥲

From reading your other comments, it seems like the conclusion is that I might save myself a lot of heartache getting a non-toy box instead of that RPi4, and that I'm never gonna get this thing to work properly… 😅
Short of that, I'm guessing switching back to a more vanilla OS (Raspbian or other) would greatly increase my chances… But since I'm using that box as a Media server, and OSMC is pretty much the only way to run a recent version of Kodi without another, different, world of pain… this is not much of a solution 😅

But if you have any suggestions on things I could do to debug and/or fix this annoying bug, I'd be eternally grateful.

[sha5672]

What kernel are you using?

[zedrdave]

> uname -r
5.10.78-7-osmc

[morrownr]

Hi @zedrdave

Let me move my adapter to a Pi and see what is going on. The ACM was rock solid on an x86_64 box but it is time to move it back to the Pi4B.

RPi is running OSMC

Explain this to me. What is OSMC?

Nick

[bjlockie]

You could try updating the raspberry pi4 firmware.

You can do this by opening a new terminal window and entering the command sudo rpi-eeprom-update.

What kernel is it?

[bjlockie]

That's a pretty old kernel. I have no idea if a new kernel will help. I'd install lubuntu-22.10 and see if that helps. Or install raspianOS which is a bit older than lubuntu but newer than osmc.

[zedrdave]

@morrownr OSMC is a repackaged Debian for Vero/RPi…

Its main selling point, is that it smoothly integrates a recent version of Kodi (which is otherwise a bit of a nightmare to compile and maintain on Raspbian). Tradeoff is that it insists on keeping control over kernel updates. For instance, doesn't seem possible to run rpi-eeprom…

I think I might finally bite the bullet and go back to a more vanilla OS and install Raspbian… Will report back if the problem persists.

[bjlockie]

You could install RaspbianOS on a spare SD card, do the firmware update, go back to OSMC. See if that makes a difference. I'm just grasping at straws since disabling scatter gather worked for me with the same wifi device.

[morrownr]

@zedrdave

I just had a thought. Exactly what all do you have plugged into usb ports? The Pi usb subsystem only supports up to 1200 mA of power. Have you checked your dmesg log to see if you see any low power conditions in it?

$ sudo dmesg

The ACM adapter does not use that much itself but if you have several other things plugged in, power could be a problem and it would show up just like you are describing.

Nick

[zedrdave]

@morrownr Regarding power usage: I had the dongle plugged to a self-powered USB, so shouldn't have been subject to the RPi's general lack of wattage… I did try any possible configuration though (ports on the Pi, different ports on the hub)…

@bjlockie I did end up doing this (flashing a raspbian card to upgrade the firmware). But when I went to boot back on OSMC, it failed. Which I took as a sign to move off OSMC and onto a more vanilla flavour of OS. So I am now all set-up on Raspbian…

The (kinda?) good news is that it seems ever so slightly stable… I am not noticing as many random disconnects over the few days I have it set up…

The less good news, is that I am still able to induce weird network crashes when stress-testing. But I am not 100% sure this is driver-related this time.

Putting large enough amount of traffic on the server, seems to lead to either:

1. [copying ~10GB file over NFS] network becoming silently available: nothing shows up in dmesg/journalctl, but the IP is no longer reachable, and the server is no longer able to access the internet. Opened ssh connections stay open, and running systemctl restart networking fixes the issue…

2. [stress testing with iperf] interface actually disconnects. But seems to reconnect by itself:

Jan 24 23:42:04 framboise dhcpcd[425]: wlan1: carrier lost
Jan 24 23:42:04 framboise kernel: wlan1: deauthenticated from 6c:cd:d6:aa:ea:e0 (Reason: 1=UNSPECIFIED)
Jan 24 23:42:04 framboise dhcpcd[425]: wlan1: deleting address fe80::6208:2529:f0b0:6f36
...
Jan 24 23:42:10 framboise kernel: wlan1: authenticate with 6c:cd:d6:aa:ea:e0
Jan 24 23:42:10 framboise kernel: wlan1: send auth to 6c:cd:d6:aa:ea:e0 (try 1/3)
Jan 24 23:42:10 framboise kernel: wlan1: send auth to 6c:cd:d6:aa:ea:e0 (try 2/3)
Jan 24 23:42:10 framboise kernel: wlan1: authenticated
Jan 24 23:42:10 framboise kernel: wlan1: associate with 6c:cd:d6:aa:ea:e0 (try 1/3)
Jan 24 23:42:10 framboise kernel: wlan1: RX AssocResp from 6c:cd:d6:aa:ea:e0 (capab=0x11 status=0 aid=27)
Jan 24 23:42:10 framboise kernel: wlan1: associated
Jan 24 23:42:10 framboise kernel: wlan1: Limiting TX power to 30 (30 - 0) dBm as advertised by 6c:cd:d6:aa:ea:e0
Jan 24 23:42:10 framboise dhcpcd[425]: wlan1: carrier acquired
Jan 24 23:42:10 framboise dhcpcd[425]: wlan1: IAID ca:b1:0e:8e
Jan 24 23:42:10 framboise dhcpcd[425]: wlan1: adding address fe80::6208:2529:f0b0:6f36

In either case, no mention of mt76x2u in the logs past the booting phase.

Unless you have any suggestions on debugging this, feel free to close the issue, since the remaining problems have to do with the RPI's network settings, rather than dongle itself.

[morrownr]

Regarding power usage: I had the dongle plugged to a self-powered USB

Oh! RasPi's are notorious for not working well with powered hubs. Take that powered hub out of the system and test.

[zedrdave]

@morrownr Wasn't aware of an issue dealing with any powered hub config. That's not going to make things easy to test, unfortunately, since the Pi basically cannot power even a single external HDD consistently (I've had issues in the past).

I'll try testing…

For now, though, the issues seem to have moved from USB, to some other layer 😞

[bjlockie]

I use a powered USB 3 hub and I have no problem. I have 4 things plugged in.

[zedrdave]

@bjlockie TBH, I have had no other problems with the powered USB hub (I have tonnes of problems trying to run things without the powered hub before).

The latest version of the problem mentioned above, does not strike me as a power-related issue (but still quite annoying)…

[zedrdave]

Hello again, just wanted to confirm: seeing the weird issue with or without Powered USB.

In a nutshell: still not working (on a fresh Raspbian install, with latest ROM), although the error messages in the log seems different.

Let me know if you have any suggestion… Otherwise I'll probably just go with the reasonable conclusion that the Pi isn't a great box for serious use and/or I might have got a faulty dongle… 😅

[morrownr]

Since I work on 5 Realtek drivers and try to support not only those users but folks using adapters with in-kernel drivers, I have seen a LOT of bug reports over the last few years. My thoughts on what you are seeing:

RasPi hardware is not without its faults. I consider the USB subsystem, especific on the Pi4B, to be problematic. The causes vary. The subsystem does not provide spec power levels in that 4 ports in this configuration should provide an overall power level of around 2800 mA but the Pi4B only provides 1200 mA so people regularly plug more things in than there is power available. There is also the issue of power from hubs backfeeding into Pi's because, I guess, RasPi did not put a diode in the Pi's to prevent this. I'll skip over a few things but one big that thing that contributes is USB3. USB3 is not mankinds greatest accomplishment. In fact, it is problematic and RasPi used a USB3 chipset that is questionable. You can only fix so much in software if the hardware is not good.

So, can we get good service with usb wifi adapters in a RasPi4B? Yes. Well made adapter with the following chipset work solidly: mt7610u, rtl8811cu and rtl8811au if you are looking for dual band. Those are all USB2 chipsets. If wanting to use a USB3 adapter, my experience is that adapters with mt7612u are about as good as it gets. The rtl8812au chipset is pretty good as well. The rtl8812bu chipset... not so much. In my guide on setting up an AP, I go so far as to tell folks running that chipset to lock it in USB2 mode or run it in a USB2 port. That is only in the RasPi4B. It works fine in everything else I have tested.

Interestingly, I have a cf-951ax adapter that uses the new mt7921au chipset. The current RasPiOS does not have the driver in it yet so I had to compile a new kernel but it was solid. No idea why.

I think the RasPi folks are very aware of the USB issues and have been tweaking the new releases on boards as time passes.

What are some things I do to get solid performance out of USB3 wifi adapters on a Pi4B:

• Plug the adapter directly into a port on the Pi. No extension cables or powered hubs.
• If wanting USB3, use the USB3 port that is on the same level as the main board.
• Try a USB2 port.
• Turn off scatter gather if using an adapter with mt7612u.
• Make sure to have a solid power supply for the Pi.

Nick