-
Notifications
You must be signed in to change notification settings - Fork 178
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
ALFA AWUS036AXML photos and information dumps #222
Comments
What does
I wonder what this is. I actually did not expect bluetooth as it has been turned off on previous adapters. |
The AWUS036AXML is "Dev 5" in the above tree. It has four interfaces, indeed as indicated by
I wonder too. That's why I included it in my kernel log excerpts. The AWUS036AXML is the only Bluetooth device in the system. We'd have to find out what opcode 0xc03 is. Error code 110 is |
Particularly disappointing on this card is:
Only one AP supported! 😢 Indeed, when I try to run a secondary AP on the card, hostapd fails with:
|
Have you checked to see if it works? Bluetooth has a lot of settings nd more than one manager. It depends on the distro. I am not an expert.
480M = USB2. Are you in a USB2 port?
I've never tried to run a secondary AP on one adapter so I am curious about your use case. |
No. I have no interest in Bluetooth and do not have the software installed to make use of it.
Yes. The info dumps were obtained on a Raspberry Pi Model B Rev 2, which does not have USB3.
I have a primary subnet for trusted devices and a secondary subnet for untrusted devices, mainly IoT gadgets with opaque/unauditable firmwares. Both subnets are served by the same router, which is also the default gateway for both, but the router's firewall is configured to reject (i.e., not forward but rather reply with ICMP "administratively prohibited") connections from devices in the secondary subnet to devices in the primary subnet. The other direction (primary to secondary) is allowed so that my trusted devices can issue commands directly to IoT gadgets. I have a primary SSID (on both 2.4 GHz and 5 GHz) that is bridged to the primary subnet and a secondary SSID (on 2.4 GHz only) that is on the secondary subnet. (There is no wired infrastructure for the secondary subnet, so there is no Ethernet bridge needed.) I'm trying to upgrade my 2.4 GHz network from 802.11n to 802.11ax with this new AWUS036AXML, but it looks like I will have to continue using the old 802.11n radio for my secondary SSID since the AXML doesn't support multiple APs. |
The easy way to shut it down: sudo rm /lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
I think this can be done with only one AP interface. I'll see what I can come up with. |
For what it is worth, that is not an issue with the AXML, that is a mt7921u issue. Alll adapters with the mt7921au and cards with the mt7921 or mt7921k will show the same thing. Maybe time to lobby the Mediatek devs? |
Is it a hardware or driver limitation to one AP?
|
driver |
@morrownr: I appreciate your enthusiasm, but I don't think it's possible to achieve similar results using a single SSID. For one thing, either I would have to maintain a "roster" of trusted/untrusted MAC addresses (which I'd prefer not to do), or I would have to switch to 802.1x authentication, which dumb IoT devices probably couldn't cope with anyway. And then, even if I could tell which devices were supposed to be on which subnet despite them all appearing on the same interface, there would be the issue that I want the untrusted devices to be unable to contact the trusted devices directly (i.e., without being routed). If everything is in the same broadcast domain, then the untrusted devices would be able to reach the trusted devices directly simply by adding themselves to the trusted subnet (i.e., without involving the DHCP server). If you can figure out a way to have the two tiers of devices be on separate broadcast domains despite being associated to the same AP, I'd be interested. (I think there may be a way to do it with AP isolation and ebtables, but again, I really don't want to have to maintain MAC rosters.)
@bjlockie: "Both," with the caveat that these chipsets are largely software-defined radios, and it's the firmware blob that implements most of the logic, so possibly a new firmware could add multi-AP support to this chipset. Regardless, the driver is reporting that it supports only 1 AP: static const struct ieee80211_iface_limit if_limits[] = {
{
.max = MT7921_MAX_INTERFACES,
.types = BIT(NL80211_IFTYPE_STATION)
},
{
.max = 1,
.types = BIT(NL80211_IFTYPE_AP)
}
}; |
I guess maybe we should make chipset part of the filenames. The CF-951AX file has been there for some time and it shows only one AP capability. Interestingly, the mt7612u and the mt7610u chipsets have the 2 AP capability. They don't have AX capability. @bjlockie Let me clarify the hardware vs driver limitation thing. You are seeing two answers and both are basically correct. I consider hardware to be what is in silicone or is otherwise fixed and unchangeable. The firmware, closed source, and driver, open source, in my mind, are not hardware. Maybe firmware that is on ROM and is located in the device should be considered hardware. In fact, I consider the firmware and driver as two parts of the driver as the consequence of one being missing is the same from a user perspective... the adapter won't work. Can the capability to have 2 APs be changed? The answer is highly likely to be yes. Maybe the capability can happen. Unfortunately, the specific capabilities in this case simply do not exist in current USB adapter drivers. Realtek has this to say about it in their rtl8852bu driver:
For what it is worth, Linux is shutting |
Maybe it's worth emailing the wireless mailing list to get the attention of the MediaTek devs.
Maybe the driver is limited by what the hardware can do now but adding support in the firmware blob for multiple APs is doable.
Can you use the 7612u device for your iot stuff and the 7921au for your lan?
|
@bjlockie: I might do that, but I was hoping to have 802.11ax on 2.4 GHz, which I can't do if the 7921 is serving the 5 GHz band. I think what I'll actually end up doing is moving to a three-card setup: the 7921 serving 802.11ax on 2.4 GHz, the 7612 serving 802.11ac on 5 GHz, and a 7610 serving 802.11n on a different channel of the 2.4 GHz band. That'll let me use an AWUS036ACHM (high-power, long-range) to provide connectivity to IoT gadgets on a separate 2.4 GHz channel from my high-throughput 802.11ax network on 2.4 GHz. The 7612 is already working great on 5 GHz, and I'd like to leave it there rather than "wasting" its 802.11ac capability by running it on 2.4 GHz, where it can only provide 802.11n. |
That is what I was thinking but I did not know you had an achm. Darn thing can do range. It won't win races but IoT things seem to generally be low throughput.
That is cool. This is on a Pi, right? Be careful with the usb subsystem power limitations. |
Nah, I only used a Pi to get the information dumps because I knew its OS would have all the firmware blobs and every kernel option enabled. My actual router is a mini-ITX system with dual Ethernet ports and an extremely barebones software load, all compiled from source (including the kernel) by yours truly. It doesn't even have Thank you for the warning, though! I'm well aware of the Pi's power limitations. If I were going to be running multiple Wi-Fi adapters on a Pi, I'd use an externally powered USB hub. |
I was pondering this issue. I wonder if adding a new Main Menu item that is a list of features that we want added and bugs we want fixed would help. There are adapter makers and devs from chipset makers that stop by here and read up on the happenings. Consolidating that information in a single location might get results... not next week but in the long run. Thoughts? |
It couldn't hurt, but I'd expect the Linux Bugzilla would be a better place for bug reports about drivers. Bug reports and feature requests concerning hardware will fall on deaf ears regardless of where they're posted since there's just too much inertia in hardware to make any changes (within any existing product model). The only thing that might be beneficial to collect here would be bug reports and feature requests about the firmware, which would be useless to the kernel developers since they have no visibility into the firmware blobs but could be useful to the manufacturers since they can (and arguably should) improve their firmwares to gain more market share and better reputation. Maybe a good way to do it would be to make a page for each chipset, enumerating the technical features of the chipset, such as supported interface combinations and |
Been sick the last few days. Still pondering this. |
https://www.spinics.net/lists/hostap/msg07723.html https://www.spinics.net/lists/hostap/msg09571.html Have you tried the |
Okay, so this is not a work around. This lack of ability to support more than one AP is something that needs to be addressed. |
Yes, that's what I've been talking about. I don't know of any other way to run multiple APs concurrently on a single adapter. Do you? |
Per my last post, I thought I had recalled that hostapd has a way around this but I was mistaken. Should we put together a feature request and get it to the correct places? |
@morrownr: Rokland customer support said they have contacts at MediaTek that they'll reach out to about the kernel crash that occurs when the MT7921U is used as a bridged AP. |
You lost me. I thought the issue was about not having two ap's. So, what is the issue? |
To all: This lack of 2 AP's being available is simply a design choice by the Mediatek driver devs and they should be able to change that if we submit a feature request with a good explanation of why this is needed. The Here is a file showing how to upgrade the latest release of the RasPiOS to kernel 6.1: Start with a fresh installation of RasPiOS: (the latest release was in Feb. but it is not as modern as we need yet to support the newer mt7921au chipset adapters. https://www.raspberrypi.com/software/ I use the 64 bit version as it works on my Pi3B and my Pi4B. Those are the only 2 Pi's that I have. Then upgrade to kernel 6.1 via the following guide: The instructions for upgrading or adding the 2 required firmware files are shown as item 8 here in the Main Menu. If running the Pi as an access point, you will need to compile a new version of hostapd: If you need WPA3 support, you will also need to compile wpa_supplicant and I can post a guide for that as well on request. The Raspberry Pi OS (RasPiOS) is not ready for the new WiFi6 and WiFi 6e adapters but we can get it up to speed for WiFi 6 with some work. Hopefully this changes after the new Debian is released around the middle of this year. RasPiOS and Kali would then soon rebase on the new Debian and things will be much better. There is a reason that I say in Main Menu item 2 that if anyone needs plug and play, they need to skip on down to the AC1200 section. This is still true. There is light at the end of the tunnel for those that do not want to compile their way into the future: I downloaded the Ubuntu Daily (testing version) yesterday, which will turn into Ubuntu 23.04 and will be released in April. I installed it and am happy to report that my adapter based on the mt7921au chipset was PLUG and PLAY. It was so cool. The light at the end of the tunnel is not a train. I'll do my best to help anyone with the Alfa AXML, Netgear A8000, Comfast CF-953AX or any of the other adapters with the mt7921au chipset. Just keep in mind, this is the FIRST ever usb WiFi adapter chipset that has had a driver in the Linux kernel BEFORE the products started shipping. This is amazing progress but that does not mean that everything is immediately in place and things are working perfectly and this is not just a Linux issue. There are 3 MAJOR additions to the world of WiFi going on at the same time and all 3 are astoundingly complicated... WPA3, WiFi 6 and WiFi 6e. If anyone thinks I need to add any of the guides I posted above to the Main Menu, let me know. |
interesting problem ive just encountered with this adapter, im not sure if this is the problem to address it in but we can see and lll make a new request if necessary. Basically this device works perfectly on my amd64 build of kali, beautiful works great on a fresh install, now on my pinephone pro running kali arm64-6.1-rockchip it should work, its got all the drivers, but it only shows up in lsusb as "mediatek inc. wireless_device" (which it does also on my amd64 machine) and nowhere else, not in iw dev, not in ifconfig or iwconfig, just nowhere only lsusb. any thoughts? just realized i havent attempted running it off of a powered usb hub, may try that soon when i can get my hands on one. |
Hi @castr06
Good to hear this.
I believe you but let's go over the driver anyway: In-kernel drivers have multiple parts. There is the file that we normally call the driver... mt7921u.ko. Also needed for wifi functionality for the mt7921au chipset is two more files that are commonly referred to as firmware. mt7921u.ko is part of the kernel. The firmware files are not part of the kernel, they are part of the distro. It is the distro maintainers job to make sure the up to date firmware files are included in the distro. Regarding the amd64 Kali distro, it sounds like the maintainer is on the ball. Maybe it is time to see if the arm64 distro maintainer is on the ball and if not, maybe a bug report is in order. You obviously know where USB-WiFi is so scroll down into the Main Menu and look for item 8. It goes over checking and installing firmware. The section you are looking for is section 2. The firmware for the mt7921 has been getting upgrades about once per month for the last 5-6 months as features are added and bugs are fixed so you might want to upgrade the amd64 install as well if it is needed. Let us know if that helps... and I am still looking for someone to write a review on this adapter for the plug and play list. |
@morrownr in regards to the review i'd be glad to help, i've got time tomorrow and can knock that out at least for Kali on hardware and some VM's etc. ill do some tests to make sure all is well, ive already made minor configurations to the way it runs on my machine to optimize performance, but i can make documentation about that as well. |
Hello! @morrownr so i got around to installing the firmware as the guide describes, after reboot i plugged in the adapter directly into the phones USB-C port and checked dmesg, this was the output, unplugged then plugged in again. not super well versed in this level of software so i dont know what exactly anything means, but it seems there's not enough power or for some reason the internal hub (usb port, i guess?) keeps disconnecting the adapter (e.g. #dmesg Output on kali-rockchip-6.1 on Pinephone Pro:
|
Has anyone managed to the get the AXML Alfa wifi adapter to work on a Raspberry Pi 4 on either the USB3 or USB2 ports on Kali Linux last release as of May 2023 . it shows up when I use the lsusb but when I run ifconfig only the onboard wifi adapater registers |
Hi @kflmiami420
Yes but I am using the 64 bit RasPiOS 2023-05-03. In fact, it is plug and play.
Can you give me a direct url to the iso you are using? I'll throw it on a sd card and see what the problem is. I suspect the Pi version of Kali is either using an old kernel or doesn't have the firmware installed. What kernel is it using? |
The iso i am using is the one provided by the raspberry pi imager - in the section other specific purpose OS - Raspberry pi 2,3,4 and 400 (32bit) released 2023-05-24 I read you said it worked on your 64 bit version . I am going to re-format and try the 64 bit version . I will let you you if it works ThanksSent from my iPhoneOn Jun 16, 2023, at 1:40 PM, morrownr ***@***.***> wrote:
Hi @kflmiami420
Has anyone managed to the get the AXML Alfa wifi adapter to work on a Raspberry Pi 4...
Yes but I am using the 64 bit RasPiOS 2023-05-03. In fact, it is plug and play.
on either the USB3 or USB2 ports on Kali Linux last release as of May 2023
Can you give me a direct url to the iso you are using? I'll throw it on a sd card and see what the problem is.
I suspect the Pi version of Kali is either using an old kernel or doesn't have the firmware installed. What kernel is it using?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
I looked in the imager and I see it. No info that we need.
On the 64 bit version of the Raspberry Pi OS, not Kali. I have not tested Kali.
You did not answer my question. $ uname -r I have been told that this adapter is plug and play on the latest x86_64/AMD64 version of Kali but I have no idea what is in Kali for RasPi. I run headless...does Kali for the RasPi have a VNC server? |
5.15.44-Re4son-v8l+. is the kernel it is on it does not work on 64 bit kali either Sent from my iPhoneOn Jun 16, 2023, at 9:00 PM, morrownr ***@***.***> wrote:
The iso i am using is the one provided by the raspberry pi imager - in the section other specific purpose OS - Raspberry pi 2,3,4 and 400 (32bit) released 2023-05-24
I looked in the imager and I see it. No info that we need.
I read you said it worked on your 64 bit version .
On the 64 bit version of the Raspberry Pi OS, not Kali. I have not tested Kali.
What kernel is it using?
You did not answer my question.
$ uname -r
I have been told that this adapter is plug and play on the latest x86_64/AMD64 version of Kali but I have no idea what is in Kali for RasPi. I run headless...does Kali for the RasPi have a VNC server?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
No VNC. i just SSH into the pi , I also have extra power into the pi 4. running the factory 3 amp power supply into the usb-c port and via the gpio a pimoroni lipo shim providing an extra 1.5 amps into the pi . I am thinking the AXML adapter need an extra external power supply like a powered hub i am reformating a new card with Debian Buster in 64 bit to try Sent from my iPhoneOn Jun 16, 2023, at 9:00 PM, morrownr ***@***.***> wrote:
The iso i am using is the one provided by the raspberry pi imager - in the section other specific purpose OS - Raspberry pi 2,3,4 and 400 (32bit) released 2023-05-24
I looked in the imager and I see it. No info that we need.
I read you said it worked on your 64 bit version .
On the 64 bit version of the Raspberry Pi OS, not Kali. I have not tested Kali.
What kernel is it using?
You did not answer my question.
$ uname -r
I have been told that this adapter is plug and play on the latest x86_64/AMD64 version of Kali but I have no idea what is in Kali for RasPi. I run headless...does Kali for the RasPi have a VNC server?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Confirmed it does work on Raspberry Pi Debian Buster 64 bit I wish it would have worked like my other AWUS036ACH cards where i git install the rt88xx driver and they work in kali linux on monitor mode Sent from my iPhoneOn Jun 16, 2023, at 9:36 PM, kfl miami420 ***@***.***> wrote:No VNC. i just SSH into the pi , I also have extra power into the pi 4. running the factory 3 amp power supply into the usb-c port and via the gpio a pimoroni lipo shim providing an extra 1.5 amps into the pi . I am thinking the AXML adapter need an extra external power supply like a powered hub i am reformating a new card with Debian Buster in 64 bit to try <image0.jpeg>Sent from my iPhoneOn Jun 16, 2023, at 9:00 PM, morrownr ***@***.***> wrote:
The iso i am using is the one provided by the raspberry pi imager - in the section other specific purpose OS - Raspberry pi 2,3,4 and 400 (32bit) released 2023-05-24
I looked in the imager and I see it. No info that we need.
I read you said it worked on your 64 bit version .
On the 64 bit version of the Raspberry Pi OS, not Kali. I have not tested Kali.
What kernel is it using?
You did not answer my question.
$ uname -r
I have been told that this adapter is plug and play on the latest x86_64/AMD64 version of Kali but I have no idea what is in Kali for RasPi. I run headless...does Kali for the RasPi have a VNC server?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
It definitely does not. I can run the AXML on my Raspberry Pi 1 (Model B), plugged directly into the USB port, and the Pi 1 has very little USB power to give. The AXML does not seem to be that power-hungry. Allegedly hubs tend to cause problems for Raspberry Pis.
That's too old. Support for the MT7921AU was added in Linux 5.18. |
The driver for the mt7921au chipset first appeared in kernel 5.18 so kernel 5.15 won't cut it. I installed the new Debian 12 today. The AXML was plug and play on it. I mean Debian for crying out loud, the most challenging distro on the planet for having wifi work plug and play and it works. Glad Debian came off of their firmware ban. I don't know how often Kali updates their ARM distro so you might want to ask that in a Kali forum. |
I see a future where you take this statement back.
Had a recent discussion on here somewhere recently where a couple of us used I think it was $ lsusb -vv to see what the AXML was asking for as far as power was concerned and it said 160 mA. I found that hard to believe at first but it would explain the lack of heat produced.
Powered hub on a Pi 4? Oh, avoid it. I've been helping usb wifi users the last few years and I can tell you from experience that powered hubs on a Pi 4 plus a usb wifi adapter are trouble more often than not. |
Have you seen anything about that AP mode patch you submitted? |
Not a peep. It's still in "State: New" on Patchwork, delegated to Felix Fietkau, who appears to be ignoring it. |
On 2023-06-16 22:07, morrownr wrote:
The AXML does not seem to be that power-hungry.
Had a recent discussion on here somewhere recently where a couple of
us used I think it was $ lsusb -vv to see what the AXML was asking for
as far as power was concerned and it said 160 mA. I found that hard to
believe at first but it would explain the lack of heat produced.
My Comfast CF-953 says:
MaxPower 100mA
… Message ID: ***@***.***>
|
I doubt he is ignoring it for any reason other than lack of time. He is the Mediatek gatekeeper. Anything Mediatek wireless related goes through him. His contact info is at: https://wireless.wiki.kernel.org/en/users/drivers/mediatek You could consider posting the patch to the downsteam repo as well. Felix hangs out there as well: https://github.com/openwrt/mt76 At that repo it might get some attention so that others test and push it. AP mode is what they do there...OpenWRT. |
Felix submitted his first batch of patches for kernel 6.6 this morning. Your patch is included. mt76 patches for 6.6
Alexander Couzens (1): Ben Greear (1): Bo Jiao (2): Christian Marangi (2): Daniel Golle (1): Deren Wu (3): Felix Fietkau (4): Howard Hsu (1): Lin Ma (1): Lorenzo Bianconi (49): Matt Whitlock (1): MeiChia Chiu (1): Ming Yen Hsieh (1): Peter Chiu (7): Rafał Miłecki (1): Rany Hany (1): Ryder Lee (11): Shayne Chen (1): StanleyYP Wang (3): Yuanjun Gong (1): |
Manufacturer's product page: https://www.alfa.com.tw/products/awus036axml
Purchased from: https://store.rokland.com/collections/wifi-6-6e/products/alfa-awus036axml-802-11ax-wifi-6-1800-mbps-tri-band-wifi-usb-adapter-w-bluetooth
After loading the
US
regulatory domain:Revelant excerpts from kernel log (Linux 6.1.13):
#87 #181
The text was updated successfully, but these errors were encountered: