-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Help] Driver Crash : ALFA AWUS036AXML #533
Comments
Several individuals with this adapter have experienced this. It appears that this is a problem caused by a change in bluetooth support which should have nothing to do with this adapter but it does for some reason. You can try deleting the bluetooth firmware: $ sudo rm /lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin Let me know if this helps. |
@morrownr and it still crash. then i tried:
|
I have almost exactly the same laptop that you have and it has an M.2 card with the mt7921 chip. I also have an AXML adapter so I will test here. I have seen a long thread where it appeared Mediatek devs were working on this and they were working on the bluetooth subsystem. I am not sure if the patch has gone in yet. I'm pretty sure or at least it seems that the AXML and one of the early Comfast adapters with the same chipset are the only adapters that show this problem. Yes, blacklisting bluetooth fixes the crash but kills all bluetooth which is not what we want so hopefully this is solved soon. |
ok, thanks |
@KaliAssistant have you tried monitor mode at this kernel? is it stable or crashing just as mine? how many networks did you get when you use air monitor because for me i made stand alone installation not using vm here for this kernel and getting about 20 percentage of what i am getting with kernel 6.8 at vm am trying to figure out what makes the performance that bad in my end |
@wellitsmez i tried hcxdumptool,and its good for me, no crash ,no errors |
@morrownr: I am also getting crazy with this Issue 😢. I originally purchased the Fenvi Adapter which more-or-less works OK. But then, sometimes, out of the blue, the Rock 5B SBC where this is installed completely crashes / disappears from the Network. Sometimes it works for like 1 Month or so. Sometimes it crashes after 10 Minutes. Last Night I managed to get it back running (apparently it was "just" the Mediatek Driver, without a Kernel Panic/Hang) simply by doing Now I was trying to get this fixed on a Raspberry Pi 2, since I don't want such critical piece of Network to go down because of a weird Driver / Firmware Issue. But also on the Raspberry Pi 2 with Raspbian it seems all Hell is breaking loose. I tried removing the Bluetooth Firmware as you recommended:
I blacklisted (all ?) the Relevant Drivers:
I forced the Raspberry Pi to Kernel 6.12 (since it would NOT let me update to anything else basically and I thought that the Issue was linked to poor Kernel 6.6 Support):
I also tried to installing the Nothing seems to Help. Is there some other troubleshooting Steps that I missed ? EDIT 1: On the Rock 5B it might also/sometimes be something related to USB Disconnection happening randomly. But once a crash/panic occurred, even if rebooting (by e.g. unpligging & replugging the Power Supply Cable), it will still crash within Seconds. The only Way to let it start is to unplug the Fenvi / mt7921u Adapter 😢. |
It happens.
Can you be specific about which Fenvi adapter you have?
Okay, let's concentrate on the RasPi2. We can come back to the Rock5B. Can you provide a link to the hardware specifics of the RasPi2 that you have? Can you also provide me with a link to the exact RasPiOS distro you are using?
I need to know what you are doing. Is this an AP mode setup? If so, what are the basics of your setup? hostapd? where is the internet connection coming from?
That solution is for a different problem that only happens on 3 adapters. I am not aware of it being an issue on the Fenvi adapters.
Kernel 6.6 is about as solid as it gets. I run an AP on my RasPi4B with RasPiOS 64 bit and it is really support solid.
I would not recommend that. You can install the newest firmware directly from the Linux Kernel Firmware repo:
Carefully answer my questions so that I know the situation and maybe I can help. |
Far too often 🤣
Sure. Pretty sure it was the one you reccomended in one of your Discussions/Pages/Issues a few Months ago: Note that the Driver is
Output of
I also tried to set the Raspberry Pi to deliver (up to) 1.2A (1200mA) of Current through the USB Power (Total Value, but I'm only using 1 USB Port anyways here). Contents of
I also tried to use Debian Backports
Not sure what you mean exactly. It was like 10 Years ago and the Seller removed the Article from their Website. The Email Invoice just says "Raspberry Pi 2 Model B - 1GB RAM". It seems to be a VERY old Version. Cannot know the Revision without taking the Case apart, but here is
Ignore the From https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#new-style-revision-codes-in-use we can indeed see that Revision
To be Honest not really. Because, when I tried to flash the most recent Version using Raspberry Pi Imager for a Raspberry Pi 2, it just would NOT boot at all. So I basically grabbed an oldish (6 Months out of Date ?) SD Card with Rasberry Pi OS Installed on that specific Raspberry Pi 2, applied all updates, and here I am. Yes, it boots with latest Updates and it's Stable If the Fenvi Adapter is NOT plugged In.
It is/was an AP mode setup using I tried disabling the
Uhm alright. I did NOT need Bluetooth, so it's OK to remove for me anyways.
Well that definitively is NOT my experience on the Rock 5B. It seems to work fine. Until it doesn't. And on the Raspberry Pi 2 it's consistently crashing, so totally unusable. I'd do this on a Raspberry Pi 3/4, but since I have still a lot of Raspberry Pi 2 laying around, I'd rather use those for such low-power Tasks, than having to buy a new one ...
Alright, I uninstalled #!/bin/bash
mkdir -p /lib/firmware/mediatek
cd /lib/firmware/mediatek
wget https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin -O WIFI_MT7961_patch_mcu_1_2_hdr.bin
wget https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/mediatek/WIFI_RAM_CODE_MT7961_1.bin -O WIFI_RAM_CODE_MT7961_1.bin
wget https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin -O BT_RAM_CODE_MT7961_1_2_hdr.bin Currently I'm rebuilding my Initramfs with I'm NOT very hopeful however based on previous Experiences ...
Thanks for your Help. Is there other Info you need ? Currently running Kernel:
EDIT 1: I must emphasize, at least on the Rock 5B, that the Fenvi USB Adapter (and possible the USB Hub that I'm using) seems to be EXTREMELY finicky: one light touch on the Rock 5B is enough to trigger a USB Disconnection (whereas my main worry would be the RJ45 Cable getting "ejected", since the retaining Tab on the Cable is broken). But nope, touch lightly the Rock 5B, and you can see USB Disconnection Messages in EDIT 2: with the Firmware installed from Linux Kernel
And my dumb Script to detect when the Crash occurs shows that the Raspberry Pi 2 still reboots quite soon:
|
Okay, you link shows the Fenvi FU-AX1800. The Plug and Play List also has a Fenvi FU-AX1801D. I am just trying to understand the situation. Your post should have been in a new Issue as this issue is about a different adapter.
I did a quick look around the site to see what I said but did not find where I said this. If you can point me to the problem, I can correct it.
I am trying to figure out the capabilities of your RasPi2B. It appears to me that this model is using a 32 bit cpu and is USB2 only. That means you have to use the 32 bit version of RasPiOS and it appears that you are. For me to test, I have a RasPi3B that is available, it is 64 bit but I could install the 32 bit version and I'll have to lock the use of the 64 bit kernel as RasPi has made it such that the 64 bit kernel will be used, even on 32 bit installations if the hardware is capable of 64 bit operation. It is curious why you did not have any success with a new 32 bit installation. I'll admit that I grow more skeptical of using 32 bit distros as time passes as 32 bit simply does not get the testing that it once did.
Do you have any other USB WiFi adapters available for testing? If so, please let me know what you have so we can pick out one or two for you to test.
Good information. Have you tested the Fenvi adapter on a desktop or laptop with x86_64/amd64 cpu and a recent mainstream distro such as Ubuntu 24.04 or 24.10. I'd like to rule out a manufacturing problem. Even testing on a Windows system would help eliminate a manufacturing problem.
Realtek?
I think the keys right now are you testing to eliminate a manufacturing problem and me testing a 32 bit RasPiOS installation. Let me know what you find out.
I think that you testing the adapter on a desktop/laptop system that is known to perform well, even if you need to do it on a Windows system is very important to this investigation. The issue is whether your adapter has a manufacturing problem.
Updating firmware is best performed with the method I outlined because the location is THE location where the new firmware is placed for distro maintainers to get the updates. Most maintainers of distros are not aggressive about getting updates of firmware. |
Damn I see that this morning I forgot to post the most important Comment (I was making an Edit of the Original Comment but never pressed Save) 😞. For some weird Reason Anyways, I thought I'd check the Watchdog Configuration and sure enough it was enabled and Which means, as soon as I plugged the Fenvi in the USB Port, after a few 15-seconds Attempts, the Watchdog would trigger a restart of the Raspberry Pi. Whereas if I now changed the Watchdog Monitor Interface to Still weird that, no Matter what I do, |
I think it would help.
I looked at the pic you posted and still do not understand. I did not mention the driver name at all. Tell me what you think should be changed.
I am not suggesting that you recycle it. I am trying to point out that as time passes, it may become more problematic getting some things to work on 32 bit. The mt7921au chip and it's driver came about long after we were solidly in a 64 bit world. Was the driver tested for 32 bit operation? Maybe. |
Hey @morrownr, steev from the kali team here. do you happen to know which unrelated bluetooth commit it is that breaks this? |
Hi @steev
I do not. I would dissected this problem but I have been very busy. I think it was about the time that kernel 6.7 was released that I got the first message about this problem. I have an AXML and can easily duplicate the problem here. I also have another adapter with the same chip that does not show the problem. There are 3 known adapters that show this problem: Alfa's AXML and AXM as well as the Comfast 953. None of the other adapters with the same chip show the problem. This is a problem that may be hard to solve without a dissection. I suspect that the bad adapters may have problematic eeproms in that they are showing bluetooth support when it is actually turned off. This leads to the BAD behavior in the bluetooth stack, which also kills wifi. This did not happen until around kernel 6.7 so something changed. Keep me posted if you find someone to dissect this problem. |
@steev hello steev the Bluetooth is not the only thing is broken here also the VIF mode under the monitor mode you can have a look at some work arounds in here #539 and also some discussion about what is broken when it comes to kernels bigger than 6.1 in here ZerBea/hcxdumptool#361 (comment) |
Checklist
uname
Linux KALIworkNB1 6.11.2-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.11.2-1kali1 (2024-10-15) x86_64 GNU/Linux
lsusb
rfkill
dkms
iw
What happened?
I have a ALFA AWUS036AXML, but when i plug in to my laptop (kali linux 6.11.2) USB3.0, driver crashed:
The text was updated successfully, but these errors were encountered: