Open whitslack opened 1 year ago
morrownr
commented
1 year ago What does lsusb -t show?
Bluetooth: hci0: Opcode 0x c03 failed: -110
I wonder what this is. I actually did not expect bluetooth as it has been turned off on previous adapters.
whitslack
commented
1 year ago What does
lsusb -tshow?
# lsusb -tv
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
ID 0424:9512 Microchip Technology, Inc. (formerly SMSC) SMC9512/9514 USB Hub
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) SMSC9512/9514 Fast Ethernet Adapter
|__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=r8188eu, 480M
ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
|__ Port 3: Dev 5, If 0, Class=Wireless, Driver=btusb, 480M
ID 0e8d:7961 MediaTek Inc.
|__ Port 3: Dev 5, If 1, Class=Wireless, Driver=btusb, 480M
ID 0e8d:7961 MediaTek Inc.
|__ Port 3: Dev 5, If 2, Class=Wireless, Driver=, 480M
ID 0e8d:7961 MediaTek Inc.
|__ Port 3: Dev 5, If 3, Class=Vendor Specific Class, Driver=mt7921u, 480M
ID 0e8d:7961 MediaTek Inc. The AWUS036AXML is "Dev 5" in the above tree. It has four interfaces, indeed as indicated by bNumInterfaces in the configuration descriptor. Interface 2 doesn't seem to have a driver claiming it.
Bluetooth: hci0: Opcode 0x c03 failed: -110
I wonder what this is.
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 ETIMEDOUT.
whitslack
commented
1 year ago Particularly disappointing on this card is:
valid interface combinations:
* #{ managed } <= 4, #{ AP } <= 1,
total <= 4, #channels <= 1, STA/AP BI must matchOnly one AP supported! :cry:
Indeed, when I try to run a secondary AP on the card, hostapd fails with:
Could not set interface wifi6-IoT flags (UP): Device or resource busyThe AWUS036AXML is the only Bluetooth device in the system. We'd have to find out what opcode 0xc03 is. Error code 110 is ETIMEDOUT.
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.
Port 3: Dev 5, If 3, Class=Vendor Specific Class, Driver=mt7921u, 480M ID 0e8d:7961 MediaTek Inc.
480M = USB2. Are you in a USB2 port?
Indeed, when I try to run a secondary AP on the card, hostapd fails...
I've never tried to run a secondary AP on one adapter so I am curious about your use case.
@morrownr
whitslack
commented
1 year ago Have you checked to see if it works?
No. I have no interest in Bluetooth and do not have the software installed to make use of it.
480M = USB2. Are you in a USB2 port?
Yes. The info dumps were obtained on a Raspberry Pi Model B Rev 2, which does not have USB3.
I've never tried to run a secondary AP on one adapter so I am curious about your use case.
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.
morrownr
commented
1 year ago I have no interest in Bluetooth and do not have the software installed to make use of it.
The easy way to shut it down:
sudo rm /lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
I have a primary subnet for trusted devices and a secondary subnet for untrusted devices...
I think this can be done with only one AP interface. I'll see what I can come up with.
morrownr
commented
1 year ago
{ managed } <= 4, #{ AP } <= 1, total <= 4, #channels <= 1, STA/AP BI must match
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?
bjlockie
commented
1 year ago Is it a hardware or driver limitation to one AP?
morrownr
commented
1 year ago driver
whitslack
commented
1 year ago I think this can be done with only one AP interface. I'll see what I can come up with.
@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.)
Is it a hardware or driver limitation to one AP?
@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:
interface combinations are not supported
For what it is worth, Linux is shutting Wireless Extentions WEXT support down starting with WiFi 7 and given that Intel and Mediatek are already adding WiFi 7 driver support to the kernel currently, I guess WiFi 7 is not that far off. It should not be the WiFi 6/WiFi 6e mess again but it will shut down Realtek and their WEXT drivers.
bjlockie
commented
1 year ago 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?
whitslack
commented
1 year ago 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.
morrownr
commented
1 year ago That'll let me use an AWUS036ACHM (high-power, long-range) to provide connectivity to IoT gadgets on a separate 2.4 GHz channel
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.
I think what I'll actually end up doing is moving to a three-card setup
That is cool. This is on a Pi, right? Be careful with the usb subsystem power limitations.
whitslack
commented
1 year ago 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 lsusb, so I couldn't conveniently get that dump on that system.
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.
morrownr
commented
1 year ago when I try to run a secondary AP on the card, hostapd fails...
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?
whitslack
commented
1 year ago 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.
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 ht_capab and vht_capab lines for hostapd configs, as well as a list of "Known Bugs." If I were a chip manufacturer, I would take an interest in seeing to it that a popular forum for disseminating information about Wi-Fi chipsets to technical users isn't advertising addressable shortcomings of my products. In other words, listing what's wrong with the chips here in an easily accessible format may motivate the manufacturers to do some "damage control."
morrownr
commented
1 year ago Been sick the last few days. Still pondering this.
morrownr
commented
1 year ago @whitslack
https://www.spinics.net/lists/hostap/msg07723.html
https://www.spinics.net/lists/hostap/msg09571.html
Have you tried the multiple bssid support in hostapd?
morrownr
commented
1 year ago ##### Multiple BSSID support ################################################
#
# Above configuration is using the default interface (wlan#, or multi-SSID VLAN
# interfaces). Other BSSIDs can be added by using separator 'bss' with
# default interface name to be allocated for the data packets of the new BSS.
#
# hostapd will generate BSSID mask based on the BSSIDs that are
# configured. hostapd will verify that dev_addr & MASK == dev_addr. If this is
# not the case, the MAC address of the radio must be changed before starting
# hostapd (ifconfig wlan0 hw ether <MAC addr>). If a BSSID is configured for
# every secondary BSS, this limitation is not applied at hostapd and other
# masks may be used if the driver supports them (e.g., swap the locally
# administered bit)
#
# BSSIDs are assigned in order to each BSS, unless an explicit BSSID is
# specified using the 'bssid' parameter.
# If an explicit BSSID is specified, it must be chosen such that it:
# - results in a valid MASK that covers it and the dev_addr
# - is not the same as the MAC address of the radio
# - is not the same as any other explicitly specified BSSID
#
# Alternatively, the 'use_driver_iface_addr' parameter can be used to request
# hostapd to use the driver auto-generated interface address (e.g., to use the
# exact MAC addresses allocated to the device).
#
# Not all drivers support multiple BSSes. The exact mechanism for determining
# the driver capabilities is driver specific. With the current (i.e., a recent
# kernel) drivers using nl80211, this information can be checked with "iw list"
# (search for "valid interface combinations").
#
# Please note that hostapd uses some of the values configured for the first BSS
# as the defaults for the following BSSes. However, it is recommended that all
# BSSes include explicit configuration of all relevant configuration items.
#
#bss=wlan0_0
#ssid=test2
# most of the above items can be used here (apart from radio interface specific
# items, like channel)
#bss=wlan0_1
#bssid=00:13:10:95:fe:0b
# ...
#
# Multiple BSSID Advertisement in IEEE 802.11ax
# IEEE Std 802.11ax-2021 added a feature where instead of multiple interfaces
# on a common radio transmitting individual Beacon frames, those interfaces can
# form a set with a common Beacon frame transmitted for all. The interface
# which is brought up first is called the transmitting profile of the MBSSID
# set which transmits the Beacon frames. The remaining interfaces are called
# the non-transmitting profiles and these are advertised inside the Multiple
# BSSID element in the Beacon and Probe Response frames from the first
# interface.
#
# The transmitting interface is visible to all stations in the vicinity, however
# the stations that do not support parsing of the Multiple BSSID element will
# not be able to connect to the non-transmitting interfaces.
#
# Enhanced Multiple BSSID Advertisements (EMA)
# When enabled, the non-transmitting interfaces are split into multiple
# Beacon frames. The number of Beacon frames required to cover all the
# non-transmitting profiles is called the profile periodicity.
#
# Refer to IEEE Std 802.11-2020 for details regarding the procedure and
# required MAC address assignment.
#
# Following configuration is per radio.
# 0 = Disabled (default)
# 1 = Multiple BSSID advertisement enabled.
# 2 = Enhanced multiple BSSID advertisement enabled.
#mbssid=0
#
# The transmitting interface should be added with the 'interface' option while
# the non-transmitting interfaces should be added using the 'bss' option.
# Security configuration should be added separately per interface, if required.
#
# Example:
#mbssid=2
#interface=wlan2
#ctrl_interface=/var/run/hostapd
#wpa_passphrase=0123456789
#ieee80211w=2
#sae_pwe=1
#auth_algs=1
#wpa=2
#wpa_pairwise=CCMP
#ssid=<SSID-0>
#bridge=br-lan
#wpa_key_mgmt=SAE
#bssid=00:03:7f:12:84:84
#
#bss=wlan2-1
#ctrl_interface=/var/run/hostapd
#wpa_passphrase=0123456789
#ieee80211w=2
#sae_pwe=1
#auth_algs=1
#wpa=2
#wpa_pairwise=CCMP
#ssid=<SSID-1>
#bridge=br-lan
#wpa_key_mgmt=SAE
#bssid=00:03:7f:12:84:85Okay, so this is not a work around. This lack of ability to support more than one AP is something that needs to be addressed.
whitslack
commented
1 year ago Have you tried the
multiple bssidsupport in hostapd?
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?
morrownr
commented
1 year ago 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?
whitslack
commented
1 year ago Should we put together a feature request and get it to the correct places?
@morrownr: Maybe let's get the thing working at all first before worrying about adding features. Fixed.
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.
morrownr
commented
1 year ago @whitslack
Maybe let's get the thing working at all first before worrying about adding features.
You lost me. I thought the issue was about not having two ap's. So, what is the issue?
whitslack
commented
1 year ago morrownr
commented
1 year ago 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 crash from the other thread noted above is something that I have not been able to duplicate. That can be figured out. This message is coming via a RasPi4B setup as an AP using an adapter with the same chipset as the AXML. It is very stable. However, until such time as the RasPi devs release a fully updated RasPiOS that includes at least kernel 5.19 and various other more modern components, there are several components that we need to compile for the RasPiOS to support WiFi 6. Actually I should not say WiFi 6, I should say for any adapters that use the mt7921au chipset.
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.
@morrownr
castr06
commented
1 year ago 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.
morrownr
commented
1 year ago Hi @castr06
this device works perfectly on my amd64 build of kali
Good to hear this.
now on my pinephone pro running kali arm64-6.1-rockchip it should work, its got all the drivers
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
castr06
commented
1 year ago @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. As for the firmware files I'll report back on that tomorrow as well.
castr06
commented
1 year ago 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. [ 1202.990024] usb usb5-port1: disabled by hub (EMI?), re-enabling...) but not entirely sure to be honest.
#dmesg Output on kali-rockchip-6.1 on Pinephone Pro:
[ 1138.467885] hub 6-0:1.0: USB hub found
[ 1138.467971] hub 6-0:1.0: 1 port detected
[ 1138.742013] usb 5-1: new high-speed USB device number 2 using xhci-hcd
[ 1138.894004] usb 5-1: New USB device found, idVendor=0e8d, idProduct=7961, bcdDevice= 1.00
[ 1138.894039] usb 5-1: New USB device strings: Mfr=6, Product=7, SerialNumber=8
[ 1138.894055] usb 5-1: Product: Wireless_Device
[ 1138.894068] usb 5-1: Manufacturer: MediaTek Inc.
[ 1138.907418] usb 5-1: can't set config # 1, error -71
[ 1157.608917] rk818-bat: changed: dsoc=88, rsoc=87, v=4004, ov=4243 c=-581, cap=2352, f=2708, st=charge off, hotdie=0
[ 1157.608970] rk818-bat: dl=97, rl=94, v=4086, halt=0, halt_n=0, max=0, init=0, sw=0, calib=0, below0=0, force=0
[ 1179.479769] usb 5-1: USB disconnect, device number 2
[ 1179.491789] typec-extcon typec-extcon: extcon changed sdp=0 cdp=0 dcp=0 usb=0 usb_host=0 dp=0
[ 1179.492300] xhci-hcd xhci-hcd.2.auto: remove, state 4
[ 1179.492330] usb usb6: USB disconnect, device number 1
[ 1179.494931] xhci-hcd xhci-hcd.2.auto: USB bus 6 deregistered
[ 1179.495463] xhci-hcd xhci-hcd.2.auto: remove, state 1
[ 1179.495543] usb usb5: USB disconnect, device number 1
[ 1188.391282] hub 5-0:1.0: USB hub found
[ 1188.391359] hub 5-0:1.0: 1 port detected
[ 1188.392645] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
[ 1188.392958] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.01
[ 1188.392980] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1188.392996] usb usb6: Product: xHCI Host Controller
[ 1188.393009] usb usb6: Manufacturer: Linux 6.1-rockchip xhci-hcd
[ 1188.393022] usb usb6: SerialNumber: xhci-hcd.2.auto
[ 1188.394422] hub 6-0:1.0: USB hub found
[ 1188.394496] hub 6-0:1.0: 1 port detected
[ 1188.668970] usb 5-1: new high-speed USB device number 2 using xhci-hcd
[ 1188.810766] usb 5-1: New USB device found, idVendor=0e8d, idProduct=7961, bcdDevice= 1.00
[ 1188.810792] usb 5-1: New USB device strings: Mfr=6, Product=7, SerialNumber=8
[ 1188.810804] usb 5-1: Product: Wireless_Device
[ 1188.810814] usb 5-1: Manufacturer: MediaTek Inc.
[ 1188.810824] usb 5-1: SerialNumber: 000000000
[ 1188.868637] usb usb5-port1: disabled by hub (EMI?), re-enabling...
[ 1188.883294] usb 5-1: USB disconnect, device number 2
[ 1199.075096] Bluetooth: hci1: Execution of wmt command timed out
[ 1199.081759] Bluetooth: hci1: Failed to send wmt patch dwnld (-110)
[ 1199.088874] Bluetooth: hci1: Failed to set up firmware (-110)
kflmiami420
commented
1 year ago 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
morrownr
commented
1 year ago 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?
kflmiami420
commented
1 year ago 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: @.***>
morrownr
commented
1 year ago 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?
kflmiami420
commented
1 year ago 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: @.***>
kflmiami420
commented
1 year ago 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: @.***>
kflmiami420
commented
1 year ago 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
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: @.***>
whitslack
commented
1 year ago I am thinking the AXML adapter need an extra external power supply like a powered hub
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.
5.15.44-Re4son-v8l+
That's too old. Support for the MT7921AU was added in Linux 5.18.
morrownr
commented
1 year ago 5.15.44-Re4son-v8l+. is the kernel it is on it
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.
morrownr
commented
1 year ago 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
I see a future where you take this statement back.
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.
I am thinking the AXML adapter need an extra external power supply like a powered hub
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.
morrownr
commented
1 year ago @whitslack
Have you seen anything about that AP mode patch you submitted?
whitslack
commented
1 year ago 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.
bjlockie
commented
1 year ago 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: @.***>
morrownr
commented
1 year ago 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.
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.
morrownr
commented
1 year ago @whitslack
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): wifi: mt76: mt7915: add support for MT7981
Ben Greear (1): wifi: mt76: mt7921: Support temp sensor
Bo Jiao (2): wifi: mt76: mt7915: disable WFDMA Tx/Rx during SER recovery wifi: mt76: mt7996: disable WFDMA Tx/Rx during SER recovery
Christian Marangi (2): wifi: mt76: split get_of_eeprom in subfunction wifi: mt76: add support for providing eeprom in nvmem cells
Daniel Golle (1): dt-bindings: net: wireless: mt76: add bindings for MT7981
Deren Wu (3): wifi: mt76: mt7921: do not support one stream on secondary antenna only wifi: mt76: mt7921e: report tx retries/failed counts in tx free event wifi: mt76: mt7921: fix skb leak by txs missing in AMSDU
Felix Fietkau (4): wifi: mt76: mt7915: fix capabilities in non-AP mode wifi: mt76: mt7915: remove VHT160 capability on MT7915 wifi: mt76: mt7603: fix beacon interval after disabling a single vif wifi: mt76: mt7603: fix tx filter/flush function
Howard Hsu (1): wifi: mt76: mt7996: increase tx token size
Lin Ma (1): wifi: mt76: testmode: add nla_policy for MT76_TM_ATTR_TX_LENGTH
Lorenzo Bianconi (49): wifi: mt76: mt7921: remove macro duplication in regs.h wifi: mt76: mt7915: move mib_stats structure in mt76.h wifi: mt76: mt7996: rely on mib_stats shared definition wifi: mt76: mt7921: rely on mib_stats shared definition wifi: mt76: mt7921: make mt7921_mac_sta_poll static mt76: mt7996: rely on mt76_sta_stats in mt76_wcid wifi: mt76: mt7921: get rid of MT7921_RESET_TIMEOUT marco wifi: mt76: mt7915: move sta_poll_list and sta_poll_lock in mt76_dev wifi: mt76: mt7603: rely on shared sta_poll_list and sta_poll_lock wifi: mt76: mt7615: rely on shared sta_poll_list and sta_poll_lock wifi: mt76: mt7996: rely on shared sta_poll_list and sta_poll_lock wifi: mt76: mt7921: rely on shared sta_poll_list and sta_poll_lock wifi: mt76: mt7915: move poll_list in mt76_wcid wifi: mt76: mt7603: rely on shared poll_list field wifi: mt76: mt7615: rely on shared poll_list field wifi: mt76: mt7996: rely on shared poll_list field wifi: mt76: mt7921: rely on shared poll_list field wifi: mt76: move ampdu_state in mt76_wcid mt76: connac: move more mt7921/mt7915 mac shared code in connac lib wifi: mt76: move rate info in mt76_vif wifi: mt76: connac: move connac3 definitions in mt76_connac3_mac.h wifi: mt76: connac: add connac3 mac library wifi: mt76: mt7921: move common register definition in mt792x_regs.h wifi: mt76: mt7921: convert acpisar and clc pointers to void wifi: mt76: mt7921: rename mt7921_vif in mt792x_vif wifi: mt76: mt7921: rename mt7921_sta in mt792x_sta wifi: mt76: mt7921: rename mt7921_phy in mt792x_phy wifi: mt76: mt7921: rename mt7921_dev in mt792x_dev wifi: mt76: mt7921: rename mt7921_hif_ops in mt792x_hif_ops wifi: mt76: mt792x: move shared structure definition in mt792x.h wifi: mt76: mt7921: move mt792xmutex{acquire/release} in mt792x.h wifi: mt76: mt7921: move mt792x_hw_dev in mt792x.h wifi: mt76: mt792x: introduce mt792x-lib module wifi: mt76: mt7921: move mac shared code in mt792x-lib module wifi: mt76: mt7921: move dma shared code in mt792x-lib module wifi: mt76: mt7921: move debugfs shared code in mt792x-lib module wifi: mt76: mt7921: move init shared code in mt792x-lib module wifi: mt76: mt792x: introduce mt792x_irq_map wifi: mt76: mt792x: move more dma shared code in mt792x_dma wifi: mt76: mt7921: move hif_ops macro in mt792x.h wifi: mt76: mt7921: move shared runtime-pm code on mt792x-lib wifi: mt76: mt7921: move runtime-pm pci code in mt792x-lib wifi: mt76: mt7921: move acpi_sar code in mt792x-lib module wifi: mt76: mt792x: introduce mt792x-usb module wifi: mt76: mt792x: move mt7921_load_firmware in mt792x-lib module wifi: mt76: mt76_connac3: move lmac queue enumeration in mt76_connac3_mac.h wifi: mt76: mt792x: move MT7921_PM_TIMEOUT and MT7921_HW_SCAN_TIMEOUT in common code wifi: mt76: mt7921: move mt7921_dma_init in pci.c wifi: mt76: mt7921: move mt7921u_disconnect mt792x-lib
Matt Whitlock (1): mt76: mt7921: don't assume adequate headroom for SDIO headers
MeiChia Chiu (1): wifi: mt76: mt7996: add muru support
Ming Yen Hsieh (1): wifi: mt76: mt7921: fix non-PSC channel scan fail
Peter Chiu (7): wifi: mt76: mt7915: rework tx packets counting when WED is active wifi: mt76: mt7915: rework tx bytes counting when WED is active wifi: mt76: report non-binding skb tx rate when WED is active wifi: mt76: connac: add support for dsp firmware download wifi: mt76: mt7996: fix bss wlan_idx when sending bss_info command wifi: mt76: mt7996: enable VHT extended NSS BW feature wifi: mt76: connac: add support to set ifs time by mcu command
Rafał Miłecki (1): dt-bindings: mt76: support pointing to EEPROM using NVMEM cell
Rany Hany (1): wifi: mt76: mt7915: fix command timeout in AP stop period
Ryder Lee (11): wifi: mt76: mt7996: fix header translation logic wifi: mt76: mt7996: enable BSS_CHANGED_MU_GROUPS support wifi: mt76: mt7615: enable BSS_CHANGED_MU_GROUPS support wifi: mt76: enable UNII-4 channel 177 support wifi: mt76: mt7915: report tx retries/failed counts for non-WED path wifi: mt76: mt7915: drop return in mt7915_sta_statistics wifi: mt76: mt7996: drop return in mt7996_sta_statistics wifi: mt76: add tx_nss histogram to ethtool stats wifi: mt76: mt7915: accumulate mu-mimo ofdma muru stats wifi: mt76: mt7915: fix tlv length of mt7915_mcu_get_chan_mib_info wifi: mt76: mt7915: fix power-limits while chan_switch
Shayne Chen (1): wifi: mt76: mt7996: move radio ctrl commands to proper functions
StanleyYP Wang (3): wifi: mt76: mt7915: fix background radar event being blocked wifi: mt76: mt7996: use correct phy for background radar event wifi: mt76: mt7996: fix WA event ring size
Yuanjun Gong (1): wifi: mt76: mt76x02: fix return value check in mt76x02_mac_process_rx
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
USregulatory domain:Revelant excerpts from kernel log (Linux 6.1.13):
87 #181