(info) Very low TX power on Alfa AWUS036ACHM

[silanosa]

Hi morrownr,

First of all, my sincere thanks for your dedication and commitment for the Linux community, I appreciate it a lot!

After reading your article about recommended USB WiFi adapters, I purchased a new Alfa AWUS036ACHM adapter, which works really well out-of-the-box on my 5.15.12-arch1-1 kernel, monitor mode included.

I was wondering about one peculiar thing though and as I could not find any information about it online, I thought that maybe this could be something in your area of expertise:

As displayed on your iw list output here, the output TX power for the AWUS036ACHM adapter is extremely low, only 2.0 dBm for the 2.4 GHz band. I get the exact same values on my laptop.

I have found TX power values online for other mt7610u adapters which were much higher, e.g. a TP-Link Archer T2UH with 20.0 dBm.

I know that lower TX power does not necessarily mean worse performance of the WiFi adapter, but I was still interested if you have an explanation on why the Alfa AWUS036ACHM has such low TX power values and if this could have a negative impact.

[morrownr]

Hi @silanosa

I have noticed the same thing but haven't said much about it because that is almost certainly a bug in what is being reported and not in the actually txpower. I say that because the performance in the 2.4 GHz band is very good.

Would you interested in helping me look around in the source to see if we can figure out what the problem is. If we can find it, we can submit a PR.

Regards

[silanosa]

Yeah, I would be happy to. Could you point me in the right direction, so I have a lead on where to start looking? :)

[usama7628674]

I was thinking maybe if we compile code from this link could fix tx-power issue.

[morrownr]

Hi @usama7628674

While that Mt76 repo is not exactly the same as the code as is in the kernel, it is close as it serves as a downstream for the code in the kernel. Patches seem to go upstream and come downstream between the two.

Check this out:

https://github.com/openwrt/mt76/issues/633

That is quite a discussion. I had not thought much about this because the performance of the ACHM is so good. I actually use two of the drivers in this repo with openWRT. They are available to install on OpenWRT as packages so you can take usb adapters that have mt761xu chipsets and plug them into your router running OpenWRT and you get extra radios. It is cool.

[amisix]

Nick, as discussed, I'm also having the same issue with my new ACHM. I haven't had much of a chance to run some tests on real-world transmission distance but I intend to in the next day or so. I'm no longer having DC power issues thanks to the powered hub I picked up (Jeaxin 4 Port 3.0 hub, GL3510 chipset).

Some troubleshooting I've done is changing country codes between 00-WORLD, US, DE, JP, BO etc. with no change. I tried manually setting the tx power via iw dev wlanX set txpower fixed 2000 with no change. I verified the Country Code that's set in Luci matches what's displayed in uci show wireless. As would be expected, however many adapters (MediaTek or otherwise) are plugged into the raspberry pi plays no part in the displayed tx power of another adapter (I didn't think it would although this was a good time to confirm). I'm only getting 2mW of power in managed mode and 15mW max tx power in AP mode. Abysmal if the numbers are accurate.

How do you suggest we proceed?

Here is my uci show wireless output:

root@RPi:~# uci show wireless.radio3
wireless.radio3=wifi-device
wireless.radio3.type='mac80211'
wireless.radio3.hwmode='11a'
wireless.radio3.path='platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.3/1-1.5.3:1.0'
wireless.radio3.htmode='VHT80'
wireless.radio3.channel='157'
wireless.radio3.cell_density='0'
wireless.radio3.country='US'

Here is my iwinfo output:

wlan3     ESSID: "YourWifiPasswordSucks"
          Access Point: 00:C0:CA:AE:67:FB
          Mode: Master  Channel: 157 (5.785 GHz)
          Center Channel 1: 155 2: unknown
          Tx-Power: 15 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: unknown
          Bit Rate: unknown
          Encryption: WPA2 PSK (CCMP)
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: unknown [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: yes  PHY name: phy3

Here is my iw dev info output

Interface wlan3
        ifindex 13
        wdev 0x300000002
        addr 00:c0:ca:ae:67:fb
        ssid YourWifiPasswordSucks
        type AP
        wiphy 3
        channel 157 (5785 MHz), width: 80 MHz, center1: 5775 MHz
        txpower 15.00 dBm
        multicast TXQ:
                qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                0       0       0       0       0       0       0       0               0

Here is my iw phy3 info output

root@RPi:~# iw phy3 info
Wiphy phy3
        wiphy index: 3
        max # scan SSIDs: 4
        max scan IEs length: 2243 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Device supports AP-side u-APSD.
        Device supports T-DLS.
        Available Antennas: TX 0x1 RX 0x1
        Configured Antennas: TX 0x1 RX 0x1
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 * mesh point
                 * P2P-client
                 * P2P-GO
        Band 1:
                Capabilities: 0x17e
                        HT20/HT40
                        SM Power Save disabled
                        RX Greenfield
                        RX HT20 SGI
                        RX HT40 SGI
                        RX STBC 1-stream
                        Max AMSDU length: 3839 bytes
                        No DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: No restriction (0x00)
                HT TX/RX MCS rate indexes supported: 0-7
                Frequencies:
                        * 2412 MHz [1] (4.0 dBm)
                        * 2417 MHz [2] (4.0 dBm)
                        * 2422 MHz [3] (4.0 dBm)
                        * 2427 MHz [4] (4.0 dBm)
                        * 2432 MHz [5] (4.0 dBm)
                        * 2437 MHz [6] (4.0 dBm)
                        * 2442 MHz [7] (4.0 dBm)
                        * 2447 MHz [8] (4.0 dBm)
                        * 2452 MHz [9] (4.0 dBm)
                        * 2457 MHz [10] (4.0 dBm)
                        * 2462 MHz [11] (4.0 dBm)
                        * 2467 MHz [12] (disabled)
                        * 2472 MHz [13] (disabled)
                        * 2484 MHz [14] (disabled)
        Band 2:
                Capabilities: 0x17e
                        HT20/HT40
                        SM Power Save disabled
                        RX Greenfield
                        RX HT20 SGI
                        RX HT40 SGI
                        RX STBC 1-stream
                        Max AMSDU length: 3839 bytes
                        No DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: No restriction (0x00)
                HT TX/RX MCS rate indexes supported: 0-7
                VHT Capabilities (0x31800120):
                        Max MPDU length: 3895
                        Supported Channel Width: neither 160 nor 80+80
                        short GI (80 MHz)
                        RX antenna pattern consistency
                        TX antenna pattern consistency
                VHT RX MCS set:
                        1 streams: MCS 0-9
                        2 streams: not supported
                        3 streams: not supported
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT RX highest supported: 0 Mbps
                VHT TX MCS set:
                        1 streams: MCS 0-9
                        2 streams: not supported
                        3 streams: not supported
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT TX highest supported: 0 Mbps
                Frequencies:
                        * 5180 MHz [36] (18.0 dBm)
                        * 5200 MHz [40] (18.0 dBm)
                        * 5220 MHz [44] (18.0 dBm)
                        * 5240 MHz [48] (18.0 dBm)
                        * 5260 MHz [52] (18.0 dBm) (radar detection)
                        * 5280 MHz [56] (18.0 dBm) (radar detection)
                        * 5300 MHz [60] (18.0 dBm) (radar detection)
                        * 5320 MHz [64] (18.0 dBm) (radar detection)
                        * 5500 MHz [100] (14.0 dBm) (radar detection)
                        * 5520 MHz [104] (14.0 dBm) (radar detection)
                        * 5540 MHz [108] (14.0 dBm) (radar detection)
                        * 5560 MHz [112] (14.0 dBm) (radar detection)
                        * 5580 MHz [116] (14.0 dBm) (radar detection)
                        * 5600 MHz [120] (14.0 dBm) (radar detection)
                        * 5620 MHz [124] (14.0 dBm) (radar detection)
                        * 5640 MHz [128] (14.0 dBm) (radar detection)
                        * 5660 MHz [132] (14.0 dBm) (radar detection)
                        * 5680 MHz [136] (14.0 dBm) (radar detection)
                        * 5700 MHz [140] (15.0 dBm) (radar detection)
                        * 5720 MHz [144] (15.0 dBm) (radar detection)
                        * 5745 MHz [149] (15.0 dBm)
                        * 5765 MHz [153] (15.0 dBm)
                        * 5785 MHz [157] (15.0 dBm)
                        * 5805 MHz [161] (15.0 dBm)
                        * 5825 MHz [165] (16.0 dBm)
                        * 5845 MHz [169] (disabled)
                        * 5865 MHz [173] (disabled)
        valid interface combinations:
                 * #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-GO } <= 2,
                   total <= 2, #channels <= 1, STA/AP BI must match
        HT Capability overrides:
                 * MCS: ff ff ff ff ff ff ff ff ff ff
                 * maximum A-MSDU length
                 * supported channel width
                 * short GI for 40 MHz
                 * max A-MPDU length exponent
                 * min MPDU start spacing
        max # scan plans: 1
        max scan plan interval: -1
        max scan plan iterations: 0
        Supported extended features:
                * [ VHT_IBSS ]: VHT-IBSS
                * [ RRM ]: RRM
                * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
                * [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
                * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
                * [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
                * [ AQL ]: Airtime Queue Limits (AQL)
                * [ SCAN_RANDOM_SN ]: use random sequence numbers in scans
                * [ SCAN_MIN_PREQ_CONTENT ]: use probe request with only rate IEs in scans
                * [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
                * [ DEL_IBSS_STA ]: deletion of IBSS station support
                * [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
                * [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support

Here is my hwinfo output:

41: USB 00.0: 0000 Unclassified device
  [Created at usb.122]
  Unique ID: gSaw.625lKgLaPb6
  Parent ID: VBUu.lRoCB54l1cE
  SysFS ID: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.3/1-1.5.3:1.0
  SysFS BusID: 1-1.5.3:1.0
  Hardware Class: unknown
  Model: "MediaTek WiFi"
  Hotplug: USB
  Vendor: usb 0x0e8d "MediaTek Inc."
  Device: usb 0x7610 "WiFi"
  Revision: "1.00"
  Serial ID: "1.0"
  Driver: "mt76x0u"
  Driver Modules: "mt76x0u"
  Speed: 480 Mbps
  Module Alias: "usb:v0E8Dp7610d0100dc00dsc00dp00icFFisc02ipFFin00"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #40 (Hub)

[morrownr]

Some troubleshooting I've done is changing country codes between 00-WORLD, US, DE, JP, BO etc. with no change. I tried manually setting the tx power via iw dev wlanX set txpower fixed 2000 with no change. I verified the Country Code that's set in Luci matches what's displayed in uci show wireless. As would be expected, however many adapters (MediaTek or otherwise) are plugged into the raspberry pi plays no part in the displayed tx power of another adapter (I didn't think it would although this was a good time to confirm). I'm only getting 2mW of power in managed mode and 15mW max tx power in AP mode. Abysmal if the numbers are accurate.

I generally don't pay much attention to the txpower numbers. I probably have adapters where I have never checked the numbers. I have used a lot of adapters and cards over the years. Maybe experience has taught me to check results, not numbers. I'm not an EE but I have read a lot of things written by EE's. Fully understanding radio waves and electricity is not easy. It is far more complicated than a simple number. Here is an interesting article:

https://metis.fi/en/2017/10/txpower/

I have other links if you are interested. My recommendation of the Alfa ACHM is not based on a txpower number. It is based on my use of the adapter and my testing. The results of testing show that it has impressive capabilities. The only adapter that comes close to it as far as range is concerned is the Alfa ACH. I have adapters that are made by companies besides Alfa. I just happen to be impressed with Alfa's products. Alfa has a history of producing adapters that are durable, have long range and last a long time. I look forward to the results of your tests.

Regards

[amisix]

Maybe experience has taught me to check results, not numbers.

I agree. How far away do you think I should be able to go and still achieve a good signal? When I tested this evening I was at -65dBm ~20 ft out my front door (~30ft away total) and I'm getting -37dBm upstairs, nearly directly above the router. That's at the 4dB, 2mW maximum (2.4GHZ) that's displayed in OpenWrt.

Fully understanding radio waves and electricity is not easy. It is far more complicated than a simple number. Here is an interesting article.

Thank you for the article, I appreciate it. Anymore I can learn is always good. If this were a home installation I can understand trying to be neighborly by not bathing my neighbors in rf energy although that is not the case for this application. I want to melt Hershey's bars.

My recommendation of the Alfa ACHM is not based on a txpower number. It is based on my use of the adapter and my testing. The results of testing show that it has impressive capabilities.

I have absolutely no doubt. Its speed is awesome in N and it keeps up with my other AC adapters too (at least for my 100Mb conn.) but transmission distance seems to be a significant issue in OpenWrt? Is my experience anecdotal and the discrepancy in txpower displayed in OpenWrt isn't actually impacting the real world transmission distance? Maybe. I still don't know although it seems like it's not performing as some had expected. So, bug or not? If it's a bug, where is it? Any suggestions for additional testing so we can rule out variables? I think it's helpful to have multiple people complete similar tests to rule out any subjectivity.

I just happen to be impressed with Alfa's products. Alfa has a history of producing adapters that are durable, have long range and last a long time

100% this. I've owned an AWUS036NH for years and years (ran it with Atheros drivers) and it's such a beast that when I started building this Frankenstein Pi I had to pick up another Alfa adapter and ended up with the 2 ACMs and the ACHM on your recommendation. All is working beautifully and I credit Alfa for being exactly as you say. Both of these MediaTek chipsets are awesome, along with the Ralink 3070 in the NH.

[morrownr]

How far away do you think I should be able to go and still achieve a good signal?

As noted in the article, it depends on the client. If you are using the ACHM as the AP and a phone to test, you are really mostly testing the range of the phone and not the ACHM. To get a good idea of what is performing better, you need multiple clients and at least one additional AP in the same spot as the ACHM. I have tested the ACHM against other adapters and a good WiFi router and it beat all of them in both bands. The actually distances varied depending on the client.

transmission distance seems to be a significant issue in OpenWrt? Is my experience anecdotal and the discrepancy in txpower displayed in OpenWrt isn't actually impacting the real world transmission distance? Maybe. I still don't know although it seems like it's not performing as some had expected. So, bug or not? If it's a bug, where is it? Any suggestions for additional testing so we can rule out variables?

Tell me what you are doing in OpenWRT and I will try to duplicate it.

I think it's helpful to have multiple people complete similar tests to rule out any subjectivity.

The more, the better. And it we can find and fix bugs, that is good also.

The following issue has some interesting data in that we were posting test data that included data from an ACHM:

https://github.com/morrownr/USB-WiFi/issues/29

If you read that issue, you will see that the ACHM and ACH performed best is what is basically a range test in monitor mode.

[amisix]

As noted in the article, it depends on the client

I'll test it further today with a Windows laptop & the TP-Link 8812BU adapter I have.

To get a good idea of what is performing better, you need multiple clients and at least one additional AP in the same spot as the ACHM

Ok. Not a problem, that's the current configuration I have. Asus RT-ACRH13 is sitting about 6 feet from where the OpenWRT router is. The AWUS036ACHM setup I have is also capable of running off battery, it may be helpful in testing as location isn't much of a problem anymore. My current testing is being completed while the router(s) are indoors but an outdoor test with no obstructions (windows/front doors) and less interference is possible. I do happen to be in a highly rf congested neighborhood.

Tell me what you are doing in OpenWRT and I will try to duplicate it. Nothing fancy whatsoever. AP mode, Country code US, Mode N, Frequency 2.4GHZ, Channel 9, Maximum Transmit Power set at the maximum of 4dBm (2mW), everything else default. Stock antenna. As close to out of the box config as I can get. No under voltage conditions, adequate power available (3.5amps AC wall adapter, 4.5amps on battery). All other adapters were disabled at the time of testing except for the Asus Router that's broadcasting N on channel 3 so there's no overlap with the ACHM (~6 feet apart).

On that note I saw that you recently helped someone reconfigure their /etc/config/wireless in order to achieve better speeds with the ACHM although I don't understand all that you did (VHT settings, etc) and I can't find the post anymore. Would you mind giving me that info so I can use it when not testing other things?

Regarding the thread you linked, it looks like the testing was done in something other than OpenWrt where we're seeing the (perceived?) restriction? Another thread that you linked went further in depth as to how the call was being made by OpenWrt to the adapter's firmware defined frequency settings and I though that was an interesting direction, although I could be ignorant of other variables.

There's so much good stuff in that thread though, I'll go through it further this evening, thanks for linking it. I very much like how the findings/data is presented.

[morrownr]

I do happen to be in a highly rf congested neighborhood.

Generally speaking, congestion should not hurt your range too much wifi is designed to share. What is will do is slow how fast data can be transferred. You might see if up to 200 Mb/s with iperf3 with the ACHM in 5 GHZ, 80 MHz channel width mode if there is no congestion. On the other hand, with congestion, your wifi has to share with others on the same channel so you will see slower transfer rates. I can't tell you what you will see because it depends on the level of congestion.

On that note I saw that you recently helped someone reconfigure their /etc/config/wireless in order to achieve better speeds with the ACHM although I don't understand all that you did (VHT settings, etc) and I can't find the post anymore. Would you mind giving me that info so I can use it when not testing other things?

hostapd was never designed as a normal user application. Normal users are generally lost at a terminal. hostapd was designed to do what it does... setup an AP. It is very widely used in wifi routers and in many situations. Since it is not and end-user application, we need to take our time and learn it. I will be glad to help you tune your AP. It would be best if you post your hostapd.conf and then let me reply with a optimized version. In fact, so that others can see it better, would you mind starting a new issue titled something like "Need help optimizing hostapd.conf for Alfa ACHM".

Regarding the thread you linked, it looks like the testing was done in something other than OpenWrt where we're seeing the (perceived?) restriction? Another thread that you linked went further in depth as to how the call was being made by OpenWrt to the adapter's firmware defined frequency settings and I though that was an interesting direction, although I could be ignorant of other variables.

Testing was done with a Dell Vostro desktop computer running Linux Mint 20.2. I'm hoping to expand on that testing as time allows as that specific type of testing is very telling about the capability of various adapters.

Some things to know: The MT76 driver maintained at OpenWRT is not the same driver as the one in Linux kernel MT76. The one at OpenWRT is a downstream of the Linux kernel MT76. They are very close to be the same though. Patches flow back and forth. OpenWRT have very demanding requirements and it cannot allow bloat as the devs at OpenWRT are dealing with hardware that has extremely limited ram and storage capability as well as slow processors so they have to cut out all the unneeded stuff. That does not apply much to MT76 as the MT76 drivers are lean to start with. Is it possible we see a bug in one driver and not the other? Certainly. It is also possible to report mt76 bugs at the OpenWRT repo and if that is taking too long, then bugs can be reported in accordance with Linux-Wireless guidelines.

Regards

[amisix]

Generally speaking, congestion should not hurt your range too much wifi is designed to share. What is will do is slow how fast data can be transferred.

Ok. Well, I'm certainly experiencing some throughput issues due to the congestion (~60-90Mbps). I see 24 access points in Windows and upwards of 3 dozen if I use nirsoft WifiInfoView. That's with either the ACMs or the ACHM as AP, doesn't matter. Interestingly the ACHM has no problem picking up a whole bunch of access points when scanning but when selecting tx power only allows 2mW - I'm under the impression tx power and rx power are symmetrical thus if it's capable of scanning many access points the tx power can't be as low as it displays in OpenWrt.

Since it is not and end-user application, we need to take our time and learn it. I will be glad to help you tune your AP.

Thanks much! Below is my hostapd-phy3.conf for the ACHM adapter in 2.4GHZ & 5GHZ configurations.

---------------------------- 2.4GHZ------------------------------------------------------

driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=US
ieee80211d=1
hw_mode=g
supported_rates=60 90 120 180 240 360 480 540
basic_rates=60 120 240
beacon_int=100
dtim_period=2
channel=9
chanlist=9
noscan=1

ieee80211n=1
ht_coex=0
ht_capab=[HT40-][SHORT-GI-20][SHORT-GI-40][RX-STBC1]

radio_config_id=d200e4fad5a7c9a41c19a1bb51e2fd3b
interface=wlan3
ctrl_interface=/var/run/hostapd
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=0
skip_inactivity_poll=0
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
utf8_ssid=1
multi_ap=0
wpa_passphrase=XXXXXXXX
wpa_psk_file=/var/run/hostapd-wlan3.psk
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=XXXXXXXX
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
dynamic_vlan=0
vlan_naming=1
vlan_no_bridge=1
vlan_file=/var/run/hostapd-wlan3.vlan
qos_map_set=0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56
config_id=734edba6badac60dbb9ad3541828abc8
bssid=00:c0:ca:XX:XX:XX

---------------------------------------------------- 5GHZ ---------------------------------------------------

driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=US
ieee80211d=1
ieee80211h=1
hw_mode=a
beacon_int=100
dtim_period=2
channel=48
chanlist=48
noscan=1

ieee80211n=1
ht_coex=0
ht_capab=[HT40-][SHORT-GI-20][SHORT-GI-40][RX-STBC1]

radio_config_id=00308ce14a76b5f0665508503d28a8fa
interface=wlan3
ctrl_interface=/var/run/hostapd
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=0
skip_inactivity_poll=0
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
utf8_ssid=1
multi_ap=0
wpa_passphrase=XXXXXX
wpa_psk_file=/var/run/hostapd-wlan3.psk
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=XXXXXXXX
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
dynamic_vlan=0
vlan_naming=1
vlan_no_bridge=1
vlan_file=/var/run/hostapd-wlan3.vlan
qos_map_set=0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56
config_id=734edba6badac60dbb9ad3541828abc8
bssid=00:c0:ca:XX:XX:XX

Is it possible we see a bug in one driver and not the other? Certainly. It is also possible to report mt76 bugs at the OpenWRT repo and if that is taking too long, then bugs can be reported in accordance with Linux-Wireless guidelines.

Thank you for going into further detail how this all works and how to get this rectified if it's determined it's actually an issue.

[amisix]

Sorry, @silanosa I mucked up and hijacked your thread. I'll start the "Need help optimizing hostapd.conf for Alfa ACHM" as requested.

[pauly617]

Ill tell you why its only 2dBm its because that adapter ACHM has internal Power amp where the TP link one dosent. 2dBm powered thru an Amp gives 30dBi thats why you see amazing coverage at only 2dBm

[usama7628674]

Which tp-link adapter has mt7610 chipset?

[usama7628674]

@pauly617

[usama7628674]

TP-Link Archer T2UH?

[Genxster1998]

@usama7628674 check deviwiki for all devices or source file for USB vid pid

[morrownr]

Which tp-link adapter has mt7610 chipset?

I don't know off the top of my head but I can look around if you want. It will hurt because I normally don't have anything to do with TP-Link due to their abysmal Linux support.

[amisix]

@pauly617

Ill tell you why its only 2dBm its because that adapter ACHM has internal Power amp where the TP link one dosent. 2dBm powered thru an Amp gives 30dBi thats why you see amazing coverage at only 2dBm

I was skeptical at first but having had the opportunity to use this adapter over the past few weeks has convinced me of its capabilities. @morrownr said to pay attention to real world usage instead of just numbers and so far that's panned out for me with the ACHM.

[morrownr]

@amisix

After I initially purchased my ACHM, I just used it for general purpose things and did not pay attention to things like txpower. It just worked. Then about a year ago someone had ask if I could do a performance test that included a few adapters so that we could see how they compared. I happened to include the mild-mannered ACHM in the test. The results opened my eyes. I repeated the tests several times.

As @pauly617 points out, you need a good amp to get the results you get from the ACHM but it also takes a good, high quality antenna because it takes both to extend range. If I had to guess why the twpower reading is low is that an error in firmware may be causing us to see only txpower as it relates to the main chipset and is not taking into account what the amp is doing.

[morrownr]

TP-Link Archer T2UH?

amazon.com/TP-Link-Archer-T2UH-Wireless-Adapter/dp/B00P115WMY

Ouch. There seem to be versions with Realtek and Mediatek chipsets so good luck getting the right one.

TP-LINK Archer T2U

http://en.techinfodepot.shoutwiki.com/wiki/TP-LINK_Archer_T2U

There are several versions of this model. Some have Realtek chipsets and some have Mediatek chipsets. I'm not sure if this is a good product even if you can figure out how to get the version with the chipset you want.

TP-LINK Archer T2UHP

This is probably the one I would get if bought TP-Link wifi products, which I don't.

amazon.com/TP-Link-Wireless-Adapter-Archer-T2UHP/dp/B072FK6V9M

It is end of life according to TP-Link and it is not clear how many versions were released so good luck with that.

Overall: I realize people in different parts of the world do not have access to all of the products that are available. As you can see from my remarks about TP-Link in the main README, I try not to buy TP-Link products and one of the big reasons is that it is VERY difficult to be sure of what you are getting. TP-Link has a long history of changing the chipsets while keeping the same model number and packaging. If I were to include TP-Link products in the adapter links here, I would spent most of my time sorting out the problems people would have. I don't have time to deal with that so TP-Link is blacklisted.

[amisix]

What about this one for a mt7610u chipset? I have no knowledge of its quality etc, just found it. https://smartguyscomputers.com/product/mediatek-11ac-usb-wireless-adapter-mt7610u/

Edit: lol. nevermind, just tried checking out and they want $22 shipping and handling

[morrownr]

What about this one for a mt7610u chipset? I have no knowledge of its quality etc, just found it. https://smartguyscomputers.com/product/mediatek-11ac-usb-wireless-adapter-mt7610u/

Edit: lol. nevermind, just tried checking out and they want $22 shipping and handling

Ouch! I've seen that adapter on several sites. I don't own one but I have not run across complaints.

I'm hoping that ALFA bring a new 7610u adapter on the market this year. When I contacted them with ideas for new products they seemed very receptive and a new adapter like the ALFA ACS but uses a 7610u was on the list I sent in.

[amisix]

I like that idea - 7610u capabilities in a smaller package.

In regards to the ACHM and yet to be released Alfa adapters - What are your thoughts regarding USB 2 vs. USB 3 given the maximum throughput of the chipset is just shy of the theoretical maximum for USB 2.0? I would have preferred the ACHM to be USB 3 capable if just for the use of a USB micro connector instead of a mini connector.

Although it's moot if they come out with a 7610u similar to the ACS..

[Antozzz]

Hi morrownr,

First of all, my sincere thanks for your dedication and commitment for the Linux community, I appreciate it a lot!

After reading your article about recommended USB WiFi adapters, I purchased a new Alfa AWUS036ACHM adapter, which works really well out-of-the-box on my 5.15.12-arch1-1 kernel, monitor mode included.

I was wondering about one peculiar thing though and as I could not find any information about it online, I thought that maybe this could be something in your area of expertise:

As displayed on your iw list output here, the output TX power for the AWUS036ACHM adapter is extremely low, only 2.0 dBm for the 2.4 GHz band. I get the exact same values on my laptop.

I have found TX power values online for other mt7610u adapters which were much higher, e.g. a TP-Link Archer T2UH with 20.0 dBm.

I know that lower TX power does not necessarily mean worse performance of the WiFi adapter, but I was still interested if you have an explanation on why the Alfa AWUS036ACHM has such low TX power values and if this could have a negative impact.

Hi, silanosa! I also tried all available ways to raise tx power on my ACHM! Did you manage to find a working way to raise the TX power of the ACHM adapter ?!

[amisix]

@Antozzz - I messaged Alfa Technical Support ~2 months ago and they said it's a known bug. They said this:

This is a known bug in the driver which inaccurately reports the power. It is not really 2mW, this would not even be able to power the signal beyond 10 feet. I will check on when we expect this could be fixed via new driver release and let you know.

Someone said somewhere that it's 2mW connected to a booster/internal amp that raises the tx power to 1000mW. To be fair, my TP-Link Archer T4U Plus (rtl8812bu) gets quite a few more access points when I do a scan than the ACHM. But the TP-Link Archer T4U doesn't work for my distro and its capabilities are lacking compared to the ACHM (AP, injection, etc)

I've been tempted to hook the ACHM up to a 2500mW powered booster but you have to set tx power for the ACHM from 31mW to 100mW and I can't do that with the current drivers and I don't want to blow up an expensive booster. So, no go there too.

[morrownr]

Hi @Antozzz

Like @amisix says. This is a known issue. I am pushing to see if we can find out where the problem as that would determine who needs to fix it. The problem could be in firmware (closed part of the driver) which means Mediatek needs to fix it. The problem could be in the open source part of the driver which means the Mediatek kernel devs need to fix it. Or it could be an issue created by ALFA when they added an internal amp. The bottom line is that the issue is cosmetic because performance in my experience is excellent. I ignore twpower here.

@amisix You said you have seen better scan performance on another adapter. Would you mind providing details so that I can do a little testing when I have time... what band, what app did the scanning, etc.

Regards

[Antozzz]

Amisix, morrownr ! Thanks!

I also made a request to Alfa Network, they wrote me the instructions that I had previously tried! If you be have any fresh news on troubleshooting, please let me know ! I have no great desire to use this adapter until the problem is fixed! :(

[abalmos]

@Antozzz I use this adapter with great success and encourage you give it a shot.

Are there other issues, or is it just iw's false reporting of power? The device is transmitting with more then 2dB power. If it was 2dB, then it wouldn't work even tens of feet away from the other radio.

I would encourage you to make your judgment based on the receivers data transfer performance in your target physical configurations. There is much more to the system then just transmit power in terms of quality and long range radio.

[amisix]

@morrownr Yeah, sure. OS: Windows 10 Software: Nirsoft WifiInfoView Adapter 1: TP-Link Archer T4U Plus (rtl8812bu) Adapter 2: Alfa ACHM (mt7610u, stock antenna) Band: 2.4Ghz & 5Ghz Scan Time: 2 minutes Link to test 1 Link to test 2

The TP-Link Archer T4U Plus did identify more APs but that's where it ends. The Alfa ACHM did significantly better in regards to RSSI and signal quality (in blue highlight). Obviously those numbers are not attainable with just 2dB. It's clear to me the Alfa ACHM is a far better adapter despite concerns regarding inaccurate tx power display.

[amisix]

@morrownr I re-ran the tests in Raspbian Bullseye with airodrump and came out with different numbers. I used your driver for the TP-Link Archer T4U Plus and it worked great, thanks! The Alfa ACHM found 6 more APs than the TP-Link Archer T4U Plus, different than my first tests in Windows.

OS: Raspbian Bullseye Software: airodump-ng Adapter 1: TP-Link Archer T4U Plus (rtl8812bu, stock antennas) Adapter 2: Alfa ACHM (mt7610u, stock antenna) Band: 2.4Ghz & 5Ghz Scan Time: 2 minutes Link to test

[morrownr]

Hey @amisix , how is it going?

I was still pondering your previous test results. I've never tested in Windows.

The results of this test are very close to what I have seen on my tests. Generally speaking, the ACHM detects more APs and is able to inject more at a higher rate. There are so many adapters on the market with the 8812bu chipset that results will end up all over the place. This is mostly due to there being a lot of cheap, low end products with the 8812bu chipset. The results I see with you T4U tells me it is a good adapter.

Adapter 2: Alfa ACHM (mt7612u, stock antenna)

The ACHM has a mt7610u chipset.

Regards

[amisix]

Thanks for the correction, I've become such a fan of both MediaTek chipsets they've become jumbled in my head (edited as necessary).

I was glad to see the airodump results, they make more sense to me and what we've discussed. I found it odd that in Windows the TP-Link adapter found so many more APs but the Alfa ACHM had far better RSSI & signal quality. But it's Windows. So I had to run something in Linux ofc - in comes your driver. Again, thanks for that and the instruction set. The Alfa ACHM also outperformed the TP-Link Archer in other metrics we've discussed. But, for a $25 adapter the TP-Link Archer T4U does pretty well imo too. I'm happy with both adapters for different reasons!

Now that I've got some good system images of Raspbian and OpenWrt I can play around a bit more.

Thanks

[Antozzz]

@Antozzz I use this adapter with great success and encourage you give it a shot.

Are there other issues, or is it just iw's false reporting of power? The device is transmitting with more then 2dB power. If it was 2dB, then it wouldn't work even tens of feet away from the other radio.

I would encourage you to make your judgment based on the receivers data transfer performance in your target physical configurations. There is much more to the system then just transmit power in terms of quality and long range radio.

Hello , abalmos! I understand that the TX power adjustment function is blocked on this adapter. What do you think is the average tx Power of the ACHM adapter?

[katzenheinz]

hello morrownr and all other contributors,

did anyone find a solution to change the txpower on the AWUS036ACHM adapter? Got the same problem, latest arch, mt76/mt76x0u driver. even if I change the region to for example BZ (iw reg set BZ), there is no difference, iw still reports txpower to be 2.0 dbm. Still i got the same experience, that this reported value cant be true - the adapter performs quite well.

best regards

[morrownr]

Hi @katzenheinz

this reported value cant be true - the adapter performs quite well.

This has to be a reporting error as tests that I have completed on the ACHM show that its range is much longer than that of most other adapters.

[deutrino]

It's worth noting that there are still problems with txpower with the AWUS036ACHM on OpenWRT latest SNAPSHOT at the time I write this.

[morrownr]

It's worth noting that there are still problems with txpower with the AWUS036ACHM on OpenWRT latest SNAPSHOT at the time I write this.

This does need to be investigated but it is an indication problem, not an actual txpower problem. I'm testing the following PCIe card right now: #261

$ iw dev

phy#0
    Interface wlp3s0
        ifindex 3
        wdev 0x1
        addr e8:fb:1c:7e:4d:cb
        ssid Bass
        type managed
        channel 100 (5500 MHz), width: 80 MHz, center1: 5530 MHz
        txpower 3.00 dBm
        multicast TXQ:
            qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes    tx-packets
            0   0   0   0   0   0   0   0       0

$ iperf3 -c 192.168.1.1

Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.127 port 51218 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  66.1 MBytes   555 Mbits/sec    0   1.78 MBytes       
[  5]   1.00-2.00   sec  71.2 MBytes   598 Mbits/sec    0   1.89 MBytes       
[  5]   2.00-3.00   sec  73.8 MBytes   619 Mbits/sec    0   1.89 MBytes       
[  5]   3.00-4.00   sec  72.5 MBytes   608 Mbits/sec    0   1.89 MBytes       
[  5]   4.00-5.00   sec  70.0 MBytes   587 Mbits/sec    0   1.89 MBytes       
[  5]   5.00-6.00   sec  73.8 MBytes   619 Mbits/sec    0   1.89 MBytes       
[  5]   6.00-7.00   sec  73.8 MBytes   619 Mbits/sec    0   1.89 MBytes       
[  5]   7.00-8.00   sec  72.5 MBytes   608 Mbits/sec    0   1.89 MBytes       
[  5]   8.00-9.00   sec  72.5 MBytes   608 Mbits/sec    0   1.89 MBytes       
[  5]   9.00-10.00  sec  72.5 MBytes   608 Mbits/sec    0   1.89 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   719 MBytes   603 Mbits/sec    0             sender
[  5]   0.00-10.01  sec   716 MBytes   600 Mbits/sec                  receiver

So, the above card is showing over 600 Mb/s and txpower of 3 dBm through 3 walls and about 10 meters of distance. I don't think so. I wish this was fixed but it is just an indicator problem. How is the range with the ACHM?

Regards

[deutrino]

I still have yet to test the actual range, but if I do, I'll do my best to report back.

I saw it suggested elsewhere that the ACHM has an additional amplifier which may have something to do with what's indicated vs behavior seen in reality.

[morrownr]

I still have yet to test the actual range, but if I do, I'll do my best to report back.

I saw it suggested elsewhere that the ACHM has an additional amplifier which may have something to do with what's indicated vs behavior seen in reality.

I think you will find that the ACHM has excllent range. In my testing, the ACHM has shown the longest range of any modern dual band adapter. Let me know what you find.

[fzn13]

Hello All,

My ALFA AWUS036ACHM is no longer working after using it on hcxdumptool.

I have recently bought an ALFA AWUS036ACHM (Already have ALFA AWUS036H and AWUS036NHA, TPLINK TL-WN722N V2/V3). I have just started learning about hcxdumptool / hashcat and am now familiar with basic usage. It was the day when I got my AWUS036ACHM and tested it on Kali Linux (6.1.0-kali9-amd64) on a Virtual machine setup. I am using hcxdumptool version 6.2.9. I used below command: └─# hcxdumptool -i wlan0 -o 110623_2.pcapng --enable_status=15 --active_beacon --filterlist_ap=Protection_List_Skip_1 --filtermode=15

After running for a few hours (working on hcxdumptool as expected) it stopped working (unfortunately I could have the logs) and I noticed it became very (very) hot. And after that, it stopped working. The day I started using it, it stopped working.

I believe it's a hardware failure in my card.

As I read about this adaptor on the internet and was not able to find any such abnormality (the adaptor becomes super hot and stopped working). All I read about this card were only positive reviews, and now not able to figure out what went wrong.

I use ALFA AWUS036H, AWUS036NHA, and TPLINK TL-WN722N in the same environment and never noticed any abnormality. Even ran hcxdumptool for 24 hours with these adaptors and never noticed any HEAT ISSUE.

Just wanted to know if a similar issue was reported with ALFA AWUS036ACHM ?

Thanks.

[morrownr]

Just wanted to know if a similar issue was reported with ALFA AWUS036ACHM ?

I've had my ACHM for a few years and I cannot remember it getting warm, even when pushed with extended testing with iperf3. I can't recall any reports about the ACHM getting hot.

Manufacturing issues happen. You might want to talk to your dealer or to Alfa. It could be a faulty adapter.

[fzn13]

Just wanted to know if a similar issue was reported with ALFA AWUS036ACHM ?

I've had my ACHM for a few years and I cannot remember it getting warm, even when pushed with extended testing with iperf3. I can't recall any reports about the ACHM getting hot.

Manufacturing issues happen. You might want to talk to your dealer or to Alfa. It could be a faulty adapter.

@morrownr Thanks for your quick response.

I was very confused and annoyed that how this could happen with such a renowned brand adaptor. You are right, this seems to be a manufacturing defect.

I will contact the dealer for a replacement.

BTW, can you tell me how long I can run ACHM adaptor on hcxdumptool monitoring? Is it okay to run continuously for long hours (24 hours....)?

I have never noticed any issue with ALFA AWUS036H and AWUS036NHA while running 24/7 on hcxdumptool. Is ACHM reliable in such a similar performance?

Thanks

[morrownr]

I was very confused and annoyed that how this could happen with such a renowned brand adaptor.

I understand. I have several Alfa adapters and not a single one has failed over the years. I think Alfa does a better job than most manufacturers and they seem to use better quality parts than most makers but it would be cost prohibitive to do lengthy full function tests on each product so it is common to do sampling and adjust/investigate based on the number of bad samples and returns. No maker produces 100% perfect products. Not Intel. Not AMD. Nobody. It is the nature of the business.

BTW, can you tell me how long I can run ACHM adaptor on hcxdumptool monitoring? Is it okay to run continuously for long hours (24 hours....)?

I am not familiar with hcxdumptool but probably should be. My recommendation is that you contact the author of hcxdumptool. In fact, you might want to do that before asking the dealer for a replacement.

Good luck and keep us posted.

[John23ee]

@morrowner Does this issue still exist, and is there any solution for it?

I recently purchased an Alfa ACHM, and the Tx power is 3 dBm. Is there any solution or command that can help me fix this issue in Linux, please?

What is the actual range of Alfa ACHM?

Last question, please, I notic that there is a noisy sound when I am close to Alfa ACHM. Is this normal or not? Please help me.

[morrownr]

Hi @John23ee

< Does this issue still exist

Yes

< is there any solution for it?

No, let me see about elevating this issue to see if we can get some action. The Mediatek devs have been extremely busy but they managed to get the new mt7925 driver in kernel 6.7 so maybe they can find time to work this issue.

Is there any solution or command that can help me fix this issue in Linux, please?

It seems you are assuming there is a real problem. There is not. It is simply an indication problem.

What is the actual range of Alfa ACHM?

Very long. The following is a link to a range test I did a few years ago:

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

Note that the ACHM won.

I notic that there is a noisy sound when I am close to Alfa ACHM. Is this normal or not? Please help me.

It is very rare but I have seen two reports of this over the last few years. I think the resolution was Alfa sending a new adapter but it has been a while since I saw this. You should probably contact Alfa with the details and see how they want to handle it:

https://www.alfa.com.tw/

@morrownr

[John23ee]

@morrownr Thanks for your quick response and your time.

I just mean if I want to decrease or edit TX power, I can't because I cannot see the actual TX power. That seems confusing to me.