Two AWUS036ACM not working

[zaphod24]

I am trying to setup an AP using a raspberry pi and 2 AWUS036ACM, one for 2.4ghz and one for 5ghz. I've tried both a raspberry pi 2 and a 3 with both 5.4.83-v7+ and 5.10.63-v7+ kernels. In each case, after some network usage the 5ghz device stops working and the following is in dmesg:

Mon Nov 29 16:46:21 2021] mt76x2u 1-1.4:1.0: rx urb failed: -71 [Mon Nov 29 16:46:21 2021] mt76x2u 1-1.4:1.0: tx urb failed: -71 [Mon Nov 29 16:46:21 2021] mt76x2u 1-1.4:1.0: error: mt76x02u_mcu_wait_resp failed with -71 [Mon Nov 29 16:46:21 2021] mt76x2u 1-1.4:1.0: rx urb failed: -71

[Mon Nov 29 16:46:21 2021] mt76x2u 1-1.4:1.0: vendor request req:07 off:1798 failed:-71

[Mon Nov 29 16:46:21 2021] usb 1-1.4: USB disconnect, device number 4

[Mon Nov 29 16:46:21 2021] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 7 [Mon Nov 29 16:46:21 2021] mt76x2u 1-1.4:1.0: mac specific condition occurred [Mon Nov 29 16:46:21 2021] mt76x2u 1-1.4:1.0: mac specific condition occurred [Mon Nov 29 16:46:21 2021] mt76x2u 1-1.4:1.0: timed out waiting for pending tx [Mon Nov 29 16:46:21 2021] br0: port 2(wlan0) entered disabled state [Mon Nov 29 16:46:21 2021] device wlan0 left promiscuous mode [Mon Nov 29 16:46:21 2021] br0: port 2(wlan0) entered disabled state [Mon Nov 29 16:46:22 2021] usb 1-1.4: new high-speed USB device number 6 using dwc_otg [Mon Nov 29 16:46:22 2021] usb 1-1.4: New USB device found, idVendor=0e8d, idProduct=7612, bcdDevice= 1.00 [Mon Nov 29 16:46:22 2021] usb 1-1.4: New USB device strings: Mfr=2, Product=3, SerialNumber=4 [Mon Nov 29 16:46:22 2021] usb 1-1.4: Product: Wireless [Mon Nov 29 16:46:22 2021] usb 1-1.4: Manufacturer: MediaTek Inc. [Mon Nov 29 16:46:22 2021] usb 1-1.4: SerialNumber: 000000000 [Mon Nov 29 16:46:22 2021] usb 1-1.4: reset high-speed USB device number 6 using dwc_otg [Mon Nov 29 16:46:22 2021] mt76x2u 1-1.4:1.0: ASIC revision: 76120044 [Mon Nov 29 16:46:22 2021] mt76x2u 1-1.4:1.0: ROM patch build: 20141115060606a [Mon Nov 29 16:46:22 2021] mt76x2u 1-1.4:1.0: Firmware Version: 0.0.00 [Mon Nov 29 16:46:22 2021] mt76x2u 1-1.4:1.0: Build: 1 [Mon Nov 29 16:46:22 2021] mt76x2u 1-1.4:1.0: Build Time: 201507311614____ [Mon Nov 29 16:46:23 2021] ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'

It seems to work fine when just 1 device is setup for 2.4ghz or 5ghz

[morrownr]

Hi @zaphod24

Good morning. I only have one Alfa ACM but I do have another similar adapter with a mt7612u chipset so let me see if I can duplicate this.

I think it was earlier this year when a guy posed a similar question and I tested but I think he was looking to use 2 adapters with mt7612u chipsets but I think he was using one in AP mode and the other in client mode. I do remember that both worked fine but maybe there is an issue with both in AP mode.

My RasPi4B WiFi router uses an Alfa ACM for 5 GHz but a different adapter for 2.4 GHz (Panda PAU08). I used to use an Alfa ACHM for 2.4 GHz but it was so darn good that it got a promoted to something more mission critical. The ACM and ACHM are about the same price in the places I watch. You might think about swapping one of the ACM's for a ACHM. The ACHM may only be an AC600 adapter but it is one cool little adapter because of its range.

More than you wanted to know probably. I'l try to find time to work on this within the next few days.

Regards

[zaphod24]

Thank you so much for your response, and there is never too much information :)

Just to let you know, I went ahead and built an SD card from scratch with bullseye lite on it and only hostapd. It had the same problem after a bit of usage. I have also set options mt76-usb disable_usb_sg=1 in /etc/modprobe.d/mt76-usb.conf (despite the pi2 only have usb2) as this seems to be in several posts about the mt76 driver.

I'll look into a different "slower" adapter for 2.4ghz in the meantime.

[morrownr]

I did some looking around. OpenWRT maintains a very good downstream of MT76. A lot of good work there goes up into the kernel. Here is the main link:

https://github.com/openwrt/mt76

The only thing I found was this closed issue:

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

I'm pondering whether this might be a configuration issue. Would you mind posting both of your hostapd.conf files?

[zaphod24]

No problem. Here they are (with the password X'd out):

5ghz:

interface=wlan0 driver=nl80211 ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ssid=TheTodds-5G channel=36

country_code=US ieee80211d=1 ieee80211h=1 ieee80211n=1 ieee80211ac=1 ht_capab=[HT40+][HT40-][GF][SHORT-GI-20][SHORT-GI-40] vht_capab=[RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-STBC-1][MAX-A-MPDU-LEN-EXP3][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN] vht_oper_chwidth=1 vht_oper_centr_freq_seg0_idx=42 hw_mode=a

auth_algs=1 max_num_sta=32

wpa=2 wpa_passphrase=xxx wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP

bridge=br0

2ghz:

interface=wlan1 driver=nl80211 ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ssid=TheTodds-2G channel=1

country_code=US ieee80211d=1 ieee80211h=1 ieee80211n=1 ht_capab=[HT40+][HT40-][GF][SHORT-GI-20][SHORT-GI-40] hw_mode=g

auth_algs=1 max_num_sta=32

wpa=2 wpa_passphrase=xxx wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP

bridge=br0

[zaphod24]

Leaving both devices connected, but only running hostapd for the 5ghz one and it's been stable ~24 hours

[zaphod24]

Any additional thoughts? For now, I am using an Alfa AWUS036AC (aka RTL8812AU which I accidentally ordered instead of an AWUS036ACM a while back) for 2.4ghz

[zaphod24]

I take that back... With the AWUS036AC and AWUS036ACM on one Pi2, I still get this after several hours of use:

[35399.022899] mt76x2u 1-1.4:1.0: error: mt76x02u_mcu_wait_resp failed with -71 [35399.022904] mt76x2u 1-1.4:1.0: rx urb failed: -71

Is there anything I can try and change?

[morrownr]

Hi @zaphod24

Sorry about being slow to reply. I've been very busy.

You said you have been trying a Pi 2 and Pi 3 as well as multiple versions of the RasPiOS. I think the best way for me to help get to the bottom of this is for me to try to duplicate the issue. I have a Pi3 that is available for this so if I could get you to lock into using the Pi3B and RasPiOS 32 bit 10-30-21. Once you have this setup in place, let me know so that I can set my Pi3B up the same way.

How are you connecting the 2 adapters to the Pi? Directly? With cables? With a powered external usb hub?

The reason I am asking has to do with available power. The RasPi3B, 3B+ and 4B allocate only 1200 mA of power for the entire usb subsystem. If both the Alfa adapters are pulling power from the usb subsystem, you could be pushing the available power and the result can be unpredictable. Do you have anything besides the 2 adapters plugged into a usb port?

The Alfa ACM will only use about 360 mA of power max but the Alfa AC could use up to 800 mA. I have an Alfa ACM and I have measured its power usage. I don't have an Alfa AC but do have an Alfa ACH and I have measured its power use at up to 800 mA.

After we are satisfied power is not the issue, we have other things to look at.

Nick

[zaphod24]

Hi! I am using an RPi3 and I am running this version of Raspbian:

PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)" NAME="Raspbian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

It is from image 2021-10-30-raspios-bullseye-armhf-lite, then updated to the latest packages.

The adapters are plugged directly into the Pi, looking from the back in the top and bottom ports on the right. There are no other USB items plugged in. I am using a 2.5amp power supply which came with the RPi3 kit.

[zaphod24]

Just for testing purposes, I have temporarily re-purposed an RPi4 I was using for Retropie. I have 2 AWUS036ACM adapters on it and used dd to copy the SD card I was using in the RPi3. After a quick network stress test the 5ghz did this:

[ 442.997827] usb 2-2: USB disconnect, device number 3 [ 442.999933] mt76x2u 2-2:1.0: error: mt76x02u_mcu_wait_resp failed with -108 [ 443.258428] mt76x2u 2-2:1.0: mac specific condition occurred [ 443.367824] mt76x2u 2-2:1.0: mac specific condition occurred [ 443.467838] mt76x2u 2-2:1.0: timed out waiting for pending tx [ 443.472605] br0: port 2(wlan1) entered disabled state [ 443.517977] device wlan1 left promiscuous mode [ 443.518002] br0: port 2(wlan1) entered disabled state [ 443.978066] usb 2-2: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd [ 444.009548] usb 2-2: New USB device found, idVendor=0e8d, idProduct=7612, bcdDevice= 1.00 [ 444.009557] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=4 [ 444.009565] usb 2-2: Product: Wireless [ 444.009572] usb 2-2: Manufacturer: MediaTek Inc. [ 444.009579] usb 2-2: SerialNumber: 000000000 [ 444.158628] usb 2-2: reset SuperSpeed Gen 1 USB device number 4 using xhci_hcd [ 444.189964] mt76x2u 2-2:1.0: ASIC revision: 76120044 [ 444.224435] mt76x2u 2-2:1.0: ROM patch build: 20141115060606a [ 444.388495] mt76x2u 2-2:1.0: Firmware Version: 0.0.00 [ 444.388504] mt76x2u 2-2:1.0: Build: 1 [ 444.388511] mt76x2u 2-2:1.0: Build Time: 201507311614____ [ 445.291979] ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'

[morrownr]

Hi @zaphod24

I wish I had time right now to dig into this issue but I do not. Let me offer you some alternatives:

Since the driver in question is an in-kernel driver, this is the web page that gives instructions for prepping and reporting bugs to Linux-Wireless:

https://wireless.wiki.kernel.org/en/users/documentation/reporting_bugs

It might be a good idea before reporting a bug to Linux-Wireless, if you subscribe to the list and monitor how things are done:

https://wireless.wiki.kernel.org/en/developers/mailinglists

What you will find is a lot of people working on a lot of things. There will be bug reports and pull requests. Keep in mind that all wireless is worked there and not just usb wireless. Since the people are busy, if you send a report that is poorly done, you will be ignored so it is wise to watch and learn and follow the instructions on the web pages I sent. Also,,,

Here is the web page that is specific to some of those working on Mediatek wireless and it includes email addresses that should be used in addition to the Linux-Wireless so that the right people pay attention.

https://wireless.wiki.kernel.org/en/users/drivers/mediatek

Felix, Lorenzo, and Ryder are really good at what they do and if you make it easy for them to understand the problem, then I'll bet that you get results... and if a fix is found, you just helped everyone in the world that might experience this problem because the fix will go in the kernel.

If you need any help putting together the bug report, let me know.

Nick

[zaphod24]

Thank you! I will look into that and try to submit a decent bug report

[amisix]

If it's any consolation I'm having the same issue on a Raspberry Pi 3B v1.2 with two AWUS036ACM adapters in OpenWrt 21.02. It appears for me when there's load of ~70Mbps on the card and I can reproduce it as necessary. Power supply is a 3amp adapter. I have a 3.5A adapter coming soon although I don't believe it's a power issue at this time. I've swapped USB ports, no change. I've researched this until exhaustion only to find it seems to be something within the driver that I'm not talented enough to resolve. It's a shame 'cause I really like these adapters. If you need any additional troubleshooting please reach out (my logs look nearly identical to yours)

ERROR

(~30 of these) mt76x2u 1-1.2:1.0: tx urb failed: -71 [ 751.935327] mt76x2u 1-1.2:1.0: tx urb failed: -71 [ 752.386735] usb 1-1.2: USB disconnect, device number 4 [ 752.396203] mt76x2u 1-1.2:1.0: mac specific condition occurred [ 752.398543] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 6 [ 752.423513] wlan0: deauthenticating from 70:4d:7b:11:47:ec by local choice (Reason: 3=DEAUTH_LEAVING) [ 752.651667] mt76x2u 1-1.2:1.0: mac specific condition occurred [ 752.765142] mt76x2u 1-1.2:1.0: mac specific condition occurred [ 752.869117] mt76x2u 1-1.2:1.0: mac specific condition occurred [ 752.869152] mt76x2u 1-1.2:1.0: timed out waiting for pending tx [ 753.193122] usb 1-1.2: new high-speed USB device number 8 using dwc_otg [ 753.302452] usb 1-1.2: New USB device found, idVendor=0e8d, idProduct=7612, bcdDevice= 1.00 [ 753.316169] usb 1-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=4 [ 753.328718] usb 1-1.2: Product: Wireless [ 753.337930] usb 1-1.2: Manufacturer: MediaTek Inc. [ 753.347862] usb 1-1.2: SerialNumber: 000000000 [ 753.437170] usb 1-1.2: reset high-speed USB device number 8 using dwc_otg [ 753.546649] mt76x2u 1-1.2:1.0: ASIC revision: 76120044 [ 753.585972] mt76x2u 1-1.2:1.0: ROM patch build: 20141115060606a [ 753.768094] mt76x2u 1-1.2:1.0: Firmware Version: 0.0.00 [ 753.776381] mt76x2u 1-1.2:1.0: Build: 1 [ 753.783135] mt76x2u 1-1.2:1.0: Build Time: 201507311614____

[morrownr]

Hi @amisix

You may not be aware of this site:

https://github.com/openwrt/mt76

That is the OpenWRT repo for the mt76 driver. You can reports bugs there. This is a downstream of the mt76 in the Linux kernel. There is a strong relationship between this site and the mt76 in the kernel in that after fixes have been merged and tested here, they are generally upstreamed into the kernel and this site also pulls updates made in the kernel.

Question: Are you running both ACM's in AP mode? I'm curious about how you are setup.

[amisix]

Thanks Nick - I'm learning more and more about this every day, thanks for the heads up. I'm somewhat new to all this.

No, only running one ACM in AP and the other is client. Setup as a Routed AP. Client works fine, AP side crashes spectacularly. The client side is apparently also reset though when dwc_otg resets the USB bus for the AP ACM.

On Wed, Dec 29, 2021 at 5:43 PM Nick @.***> wrote:

Hi @amisix https://github.com/amisix

You may not be aware of this site:

https://github.com/openwrt/mt76

That is the OpenWRT repo for the mt76 driver. You can reports bugs there. This is a downstream of the mt76 in the Linux kernel. There is a strong relationship between this site and the mt76 in the kernel in that after fixes have been merged and tested here, they are generally upstreamed into the kernel and this site also pulls updates made in the kernel.

Question: Are you running both ACM's in AP mode? I'm curious about how you are setup.

— Reply to this email directly, view it on GitHub https://github.com/morrownr/7612u/issues/5#issuecomment-1002837639, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSLA2AQTWWMFX3OX7S2VZTUTO2K5ANCNFSM5JAF5XYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[morrownr]

I learn something everyday. This wifi stuff is about as complicated as it gets.

There are a lot of things that can be done with RasPi's and wifi adapters. Some things are easy and then some are not so easy. It sounds like your project is essentially a wifi repeater. Correct me if I am wrong.

I have a guide up for an ap that uses wired ethernet as the source of internet. That is easy. On the other hand, using a wireless source of internet feeding an ap, that is not so easy. Would you mind sharing your setup?

[amisix]

The WiFi stuff is where the fun is imo - it's tedious, but... fun? Yeah, it's a essentially a wifi repeater, but routed (own subnet/dhcp/nat/firewall. Works beautifully when the wifi usb adapter firmware isn't crashing under load. I've got all the routing done with load balancing and/or failover (mwan3) through ethernet then 1 USB ACM as AP, other ACM as client (wwan) to ASUS Router (edge). Yes, it's a double NAT and it works fine otherwise. I've removed the load balancing and anything but the most basic OpenWrt image (i've created somewhere like ~30 iterations) and everything functions the same, the ACM card in AP modes eats it, bad.

I've troubleshot this rig into the ground. There's no issue whatsoever when I run this exact same setup but replace the ACM client (wwan) with an AWUS036NH with the RaLink 3070 chipset (Wireless N). You know why? Because my wireless N network can't exceed 45Mbps - where the USB ACM AP adapter only crashes at above ~70Mbps under a few seconds of load. I can't even get through a speedtest.net speed test without the firmware crashing when both adapters are ACMs with the MT7612U chipset. When I swapped out one of the ACMs for the AWUS036NH/RaLink 3070 the problem disappeared. It's odd, I know. The MT7612U chipset is pretty much the most popular AC chipset for linux that I can find, it would be immensely helpful to get this resolved.

On Wed, Dec 29, 2021 at 6:17 PM Nick @.***> wrote:

I learn something everyday. This wifi stuff is about as complicated as it gets.

There are a lot of things that can be done with RasPi's and wifi adapters. Some things are easy and then some are not so easy. It sounds like your project is essentially a wifi repeater. Correct me if I am wrong.

I have a guide up for an ap that uses wired ethernet as the source of internet. That is easy. On the other hand, using a wireless source of internet feeding an ap, that is not so easy. Would you mind sharing your setup?

— Reply to this email directly, view it on GitHub https://github.com/morrownr/7612u/issues/5#issuecomment-1002844135, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSLA2C46VN5WQBB7HZC6VDUTO6L3ANCNFSM5JAF5XYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[morrownr]

My suggestion: First, make a post in the appropriate OpenWRT forum outlining your equipment, software, desired outcome and actually outcome. See what you get? There are a lot of pretty smart folks hang out there.

At some point, you may want to post a well done bug report in the mt76 repo I posted above if you don't see anything that indicates it is anything but a driver problem.

[amisix]

I'll do that, thanks for the input. I see that you've been able to get a AWUS036ACM (MT7612U) and an AWUS036CHM (MT7610U) to play well together with one of them in AP mode - is that correct? In the end it makes a lot of sense for me to shell out $40 to get a running AP given my time and $ invested thus far. I can then troubleshoot the dual ACM issue as time and talent permits.

On Wed, Dec 29, 2021 at 7:59 PM Nick @.***> wrote:

My suggestion: First, make a post in the appropriate OpenWRT forum outlining your equipment, software, desired outcome and actually outcome. See what you get? There are a lot of pretty smart folks hang out there.

At some point, you may want to post a well done bug report in the mt76 repo I posted above if you don't see anything that indicates it is anything but a driver problem.

— Reply to this email directly, view it on GitHub https://github.com/morrownr/7612u/issues/5#issuecomment-1002862140, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSLA2H5D5OU2LYQSTLPAVLUTPKJHANCNFSM5JAF5XYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[morrownr]

I see that you've been able to get a AWUS036ACM (MT7612U) and an AWUS036CHM (MT7610U) to play well together with one of them in AP mode - is that correct?

No. I have used them together for long periods on the same system (RasPi4B) with great results but always with both in AP mode. I call it a 24/7/365 setup because it is so solid. I can't always keep the setup together because I use them and the Pi to help test problems that people are having. I maintain several repos to help Linux users:

https://github.com/morrownr?tab=repositories

I am also not using OpenWRT on my Pi's. I do the setup manually with hostapd. I use OpenWRT on my Zyxel router so I do keep up with it. I'll need you to show me how to set it up on a Pi after you solve your problem.

Speaking of the ACHM. I was having a conversation a while back with a guy that asked me if I could only have one adapter, which one would it be. After a lot of thought I told him it would be the ACHM. Even though the ACHM is only an AC600 adapter, it is interesting. It has range that makes it useful for things that your average everyday adapter just can't do. I have plugged it into my Zyxel as a third radio and darn if it does not have longer range on both bands than the Zyxel does and the Zyxel is good.

Come to think of it. I have also had the ACM and ACHM running together on my main dev box. Both were in managed mode. I can say that I have never needed to do mixed mode where one is in AP mode and the other is in managed mode. Have you consider a PowerlineAV setup to get internet to your access point instead of wifi adapter?

[amisix]

No. I have used them together for long periods on the same system (RasPi4B) with great results but always with both in AP mode.

Even better, pushing them both as AP gives me hope that my system will be capable of doing so. On that note, I bought an AWUS036ACHM from Amazon last night after reading your review(s). About the same time I posted on the OpenWrt forums regarding this issue as you had suggested. Thanks. It'll be great to play around with that adapter, looking forward to it.

On that note, after your suggestions and another suggestion on the OpenWrt forum, It has been determined that it is in fact a power issue. Thought my 3amp power supply was sufficient for the setup, it is not (I literally ordered a 3.5amp power supply just a few days ago). Unplugging the USB gigabit ethernet adapter solved everything, no more chasing ghosts (but no failover/alternative admin console too). I should have known sooner... but stupid me didn't have the screen on/turned towards me to see the little electric bolt that comes up on the screen when the Pi is unhappy. Its been running very happily all day as a Routed AP/mixed mode without a single error, just beautiful. It would be nice if I could determine current draw remotely, I'll have to look into that.

I got a chance to look at your repository last night - I had no idea I was speaking with the guy who wrote the driver for the RTL8812BU chipset that I just happened to be looking for a couple weeks back before I went down the ACM rabbit hole. I have a TP-Link Archer T4U on a Windows machine that I wanted to press into service. Wow, I just didn't put two and two together until you linked your repo... thought it looked familiar. LOL. Thanks for all you do, big props.

Regarding the PowerlineAV setup. I'm building this for other uses that don't involve a static location so it kinda nixes that idea, but thanks for the suggestion. Its gotta run full DC power/without need for an AC adapter for reasons.

[morrownr]

Glad to see you making progress. The USB subsystem on the RasPi3B and later is only capable of 1200 mA of power so you really have to know what your devices are using. I have a meter. You may have noticed in a few places that I mention that the Mediatel based adapters work well with the RasPi's and one of the big reasons is that they use far less power than the Realtek based adapters.

I just happened to ponder why you were using two ACM's together today. You are aware that a single ACM can be both in client mode and in AP mode at the same time, right?

$ iw list

From the above command:

valid interface combinations:

• { IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-GO } <= 2,

             total <= 2, #channels <= 1, STA/AP BI must match

I understand that the above is written in a foreign language but basically what is says is that your mt7612u based adapter supports interface combinations. This part #{ managed, AP, mesh point, P2P-client, P2P-GO } <= 2 means you can have one interface in AP mode and one in managed mode. Both interfaces have to be on the same channel. If you create something like a repeater and 400 Mb/s is available then this setup will be capable of providing 200 MB/s via AP because you have the input and output sharing the same radio but there are advantages to this.

The 8812bu is not a bad chipset and the driver I have up is not bad for a Realtek driver. The best drivers for Realtek are the ones for the 8812au and 8811au. If you have any questions about setting the 8812bu up, stop by that repo and let me know.

Cheers

[amisix]

Glad to see you making progress. The USB subsystem on the RasPi3B and later is only capable of 1200 mA of power so you really have to know what your devices are using. I have a meter.

Yeah, slowly but surely. This board and the OpenWrt board are invaluable with who you can bump into and the info they may have. From what I'm aware of 500mA is the max for USB 2.0 right? Being restricted to 1200mA for all 4 USB devices is less than I thought I had, hence the recommendations for a powered hub.. and the ACM's are USB 3.0 right - hopefully they're not expecting more than 500mA huh? I purchased a battery pack with amp meter and the numbers aren't adding up so I picked up one specifically designed for USB. Looking forward to comparing - didn't you say you tested the ACMs and they came in around ~380mA?

No, I had no idea the ACMs could run client and master mode at the same time. That's wicked cool. I did find the 2.4GHz radio and tried setting up dual APs but it didn't quite work - I was chasing power ghosts then too though. Being able to set it up as client & master at the same time though... beautiful for an extender. It basically solves the problem entirely as long as I'm willing the take the speed hit (who cares, my internet tops out at 100Mb). That's gonna be fun to setup. Thanks!

I really like my 8812BU - it was 50% the cost of a MediaTek and it connects faster than my ~3 year old onboard Intel WiFi (in Windows ofc). Anybody trying to make inexpensive WiFi cards work with linux/Raspberry Pi/etc is a damn hero in my book. Can't I install the 8812AU drivers for the BU in openWrt? I don't remember if I read something like that or not. I'll have to setup another linux MicroSD to dig into it some more. Thanks for all the great info.

[amisix]

Well, I just finished setting up the AP/Managed combo on a single AWUS036ACM and it works great! ~30% the power usage (down ~400mA) while achieving the same goal. That's awesome - I never would have thought the adapter would have been capable of that until you told me. A big thank you Nick. I'm going to stress test it overnight and see how it goes - these MediaTek adapters are worth every penny.

[morrownr]

Well, I just finished setting up the AP/Managed combo on a single AWUS036ACM and it works great!

Would you passing the specific details of how you set it? I have a spare Pi3B that I would like to try this on.

From what I'm aware of 500mA is the max for USB 2.0 right?

That is correct and 900 mA for USB3.

and the ACM's are USB 3.0 right

That is correct. The ACHM is USB2.

hopefully they're not expecting more than 500mA huh?

The ACM will use around 360-380 mA when pushed hard and the ACHM will use around 420 mA when pushed hard. I know it seems odd that the AC600 adapter uses more power than the AC1200 adapter does but it does. The likely cause is the amp in the ACHM. You will notice the range of the ACHM.

I did find the 2.4GHz radio and tried setting up dual APs but it didn't quite work

Remember that these usb wifi adapter only contain one radio. To support 2 bands you would need two radios. Dual band wifi routers have two radios.

I really like my 8812BU

I have a couple of adapter based on the 8812bu chipset myself. I've been working hard to make sure Linux users have many toys to play with.

Can't I install the 8812AU drivers for the BU in openWrt?

No. And don't try to install my 88x2bu driver in OpenWRT as it will not work...but it will make a mess. Is it possible to eventually get the 88x2bu in OpenWRT? Yes but it would take a lot of work and you need to know that this specific driver does have some issues with RasPi's. We can talk.

Thanks for all the great info.

You are welcome. Glad you were not in a hurry as I stay pretty busy. You can pay me back by providing a guide that we can post for Linux users that want to use a single ACM as a "repeater".

Regards

[amisix]

Sorry for the delayed response, have been waiting on a few new parts to arrive so I could spend some time fiddling.

Would you passing the specific details of how you set it? I have a spare Pi3B that I would like to try this on.

Of course. Nothing special, I used an additional USB ethernet adapter to access the console/web interface while configuring since eth0 (onboard) MAC address is also assigned to br-lan which has (to have) a different subnet than my local network. Temporarily enabled port forwarding for 22 & 80 so I can get to the console, etc. in case something goes wrong during config. Set eth1 as dynamic then just configured the interfaces with standard wwan,wlan style config while setting wwan as dynamic and wlan as static (in a different subnet than br-lan also). So, router IP of say 10.10.10.1, eth0 dynamic (ex. 10.10.10.2), br-lan static (ex. 10.10.20.1), wwan as dynamic (ex. 10.10.10.3) and wlan as static (ex. 10.10.30.1). Firewall zones are as follows: eth0 = wan, eth1 = wan, wwan = wan, br-lan = lan, wlan = lan. Be sure to config DHCP for the wlan interface and 8/10 times it goes without a hitch. I don't know if I missed anything? I can go more in depth w/screenshots in the guide you requested. Be sure to pull down the 22/80 port forwarding when complete 'cause it's easy to forget.

I received the ACHM and a few other goodies which include a USB voltage/ampmeter. So far what I'm finding leaves me even more perplexed. First, the ACHM in AP mode only allows a maximum transmit power of 4dB (2mW) which is abysmal and practically unusable? I have my Country Code configured (and I've tried others with no change). In client mode it's only marginally better at 18mW maximum. What gives? I can adjust the maximum transmit power of my ACMs in both AP & client mode without issue (up to the maximum 100mW). I really like the idea of this thing... just a bit more fiddling to make it work I guess. LED light doesn't work on it either... don't you have some magic memory addresses for that lying around somewhere?

As for power/current draw I put the USB voltmeter/ampmeter to determine my load/etc and I'm only hitting a maximum current draw of ~1.2-1.4 amps with both ACMs installed and ~40% CPU usage. So how should I look at this? ~500mA for the Pi and ~800mA for the ACMs (~400mA per) should give me ~400mA of play before I hit the 1200mA limit for the entire USB bus... but apparently I'm hitting the limit per port, maybe? I thought it was 1200mA total no matter single USB port or multiple. But it works fine with one ACM that draws just shy of what, 380mA? x2 ACMS = I should have ~250mA to play with but it's not there. It did throttle & there was an under voltage condition in the logs (was hard to catch cause it would crash entirely sometimes). I'm thinking the ACMs draw more than 500mA for a very short period when ramping up which causes the bus to freak out and that's all she wrote. Device disconnects/reconnects a few seconds later then file transfer/speed test resumes shortly thereafter.

So, back to USB powered hubs. I bought one, perfect size, started burn-in, one port failed, requested return. I have another 4 port powered hub with a 3A phone charger (name brand) being delivered shortly. I was hoping to have my power issues fixed with the addition of the hub but its failure created additional issues. Oh well, only a few days setback.

No. And don't try to install my 88x2bu driver in OpenWRT as it will not work...

OK, I won't go down that rabbit hole yet. If you need anyone to test I'd be happy to do so when/if the time comes.

You can pay me back by providing a guide that we can post for Linux users that want to use a single ACM as a "repeater".

Happy to do so. Please be patient as it might take me a bit. I'm going to have to do it through Luci as I'm somewhat inexperienced with OpenWrt & Linux despite a background in PCs and a bit of networking.

[morrownr]

I received the ACHM and a few other goodies which include a USB voltage/ampmeter. So far what I'm finding leaves me even more perplexed. First, the ACHM in AP mode only allows a maximum transmit power of 4dB (2mW) which is abysmal and practically unusable? I have my Country Code configured (and I've tried others with no change). In client mode it's only marginally better at 18mW maximum. What gives? I can adjust the maximum transmit power of my ACMs in both AP & client mode without issue (up to the maximum 100mW). I really like the idea of this thing... just a bit more fiddling to make it work I guess. LED light doesn't work on it either... don't you have some magic memory addresses for that lying around somewhere?

How are you getting those txpower numbers? The numbers from iw dev are not right as far as I can tell. If the numbers were correct, the performance likely would not be good. I guess I should document that somewhere. The performance does not correlate to the txpower numbers. In fact I was doing a test with a little script I was working on yesterday. One part of the script scans signals in monitor mode and another part does injection. To test I had 2 adapters connected: Alfa ACH and ACHM.

The ACH was able to scan 27 clients and the ACHM, from the exact same location 5 minutes later, scanned 43 clients. I then had to hook up a couple of what I call consumer grade adapters just out of curiousity. I saw scanning of 12-16 clients and ap's and reasonable injection rates on about a third of the totals. If you don't do security analysis/pen testing, the numbers may not mean much to you so I'll just say that the ACHM is not your average consumer grade adapter. It is an outlier. My recommendation is to ignore the txpower numbers and focus on results. One of these days when have time, we can write up a bug report and send it in.

I don't have any magic memory address for the mt7610u based adapters but on my to-do list is to write up and subnit a bug. I've looked through the code and it appears the LED is off on purpose. It is not clear why.

About the fiddling to make it work... tell me what you are trying to do and I will try to help.

So how should I look at this? ~500mA for the Pi and ~800mA for the ACMs (~400mA per) should give me ~400mA of play before I hit the 1200mA limit for the entire USB bus.

I regularly run both an ACM and ACHM plugged directly into the ports on a RasPi4B. I can go for the ~800 mA number. I'm not sure where you are getting the 500 mA for the Pi. The 1200 mA total is what the Pi makes available for things plugged into the USB subsystem... the total of all USB devices. I also have a USB device that supports a SSD. If I use the SSD directly on the Pi, I have to move one of the Alfa adapters to a powered hub...or put the SSD on the powered hub.

Things to look at as possible problems. Not all power supplies are created equally. I have a very high quality 3A power supply and I see no problems with it. I also have a low quality 3A power supply that I will be glad to send to you... for free. Naw, I wouldn't do that to you. If you are going to hook up a powered usb3 hub to a Pi, you need to be aware of the history of problems. Very very few powered usb hubs will work right with Pi's. The evidence points to it being a backfeeding problem. The foundation says everything is fine. My experience tells me there is one or more bugs in the USB subsystem of the Pi4B's. We can work around the issues. The ACHM is a USB2 adapter so plug it into one of the Pi's USB2 ports. USB3 is not one of mankind's best efforts. USB2 is solid but I think the engineers that created USB3 reached a little too far and did not test enough.

Regards

[amisix]

How are you getting those txpower numbers?

In Luci in the wireless config (maximum transmit power) although I forget what iw dev displayed, I'll reconnect it tomorrow and do a more in depth check. Yeah, tx power = transmission distance, not speed, I get it. I bought it because I wanted to throw my signal as far as possible and you said it has a good amp! I think the numbers I'm seeing in Luci are very possibly (crossing fingers) incorrect as you suggest. I agree, performance over numbers.

I'm literally giddy about the ACHM and its capabilities. When I did a scan I saw upwards of two dozen access points so I know it has some rx/tx power that doesn't correlate with the numbers I saw in Luci. So it seems to be working fine? More time playing with it over the next few days will shake some things out - I'll document more of what I run into so I can bounce it off of you. Thanks for all your input regarding this.

Yeah... powered hubs, what a topic. I was surprised both hubs I purchased (one unpowered the other powered) seem to be "recognized" fine by the Pi but that's about where it ends. Of course the 2.0 unpowered hub I got is bullet proof... but unpowered. And the 3.0 powered hub I got failed on one port after about 6 hours of usage with an ACM connected to it. I of course bought a 3.0 powered hub with the intention of scalability when I upgrade to an RPi4 but it may be working against me too huh? I'm keeping notes on what's worked in this frankenstein combination... hopefully they'll be of use at some point.

I have a Cannakit 3.5amp power supply for AC and a 26800mAh battery pack for portability with 3 USB output ports. Each output of the battery's two USB A ports is capable of 4.5amps while the 3rd output is a USB C capable of 3amps. I experience the same power issues with both power supplies although a bit less on the 3.5amp Cannakit adapter. Both of these supplies should be capable of providing the ~1.3-~1.4amps (max) I'm seeing used by the Pi and two ACMs at ~40% load. I thought/think? I think the current spike at ~70mbps is what's killing it, the load comes on too suddenly to compensate (esp. for the battery) and it's exceeding a limit somehow? I caught one of the ACMs in the ~500-550mA range on one of the runs but it was for an extremely short period of time, just long enough to muck things up but too short quantify/log. Frustrating but we'll see. I was running the ACHM on the USB 2.0 Pi port and the ACM in the powered hub - I had some success doing that with the dual ACMs too before I had hub connectivity issue (exactly as you describe).

What powered hub(s) do you recommend? I found a couple good 2.0 hubs but they want $40+ for them which is a bit steep for a hub imo. The powered USB 3.0 hub I got is a ByEasy 4 port with 1 charging port and a .3amp power supply that I very quickly swapped out for a Samsung 3.0amp QC adapter (thumbs down to poor quality adapters). The unpowered USB 2.0 hub that works awesome is made by "uni" and it's aluminum and the perfect size for the Pi. But nearly useless unless just using really low powered adapters like a wireless keyboard/mouse dongle.

I'm not an EE but imo USB 3.0 is trying to shove 10 lbs of stuff into a 5 lb box. At some point low gauge wire is only capable of handling so much current effectively and that doesn't even begin to cover issues with rf and chipset/hardware compatibly. I'd like to run a Pi 4B too for bench testing if I could find them for less than $120, lol! No retailers have them in stock until next month at the earliest. Oh well.

The single adapter ACM setup is sitting beside me and has been running for most of the day on battery without a hiccup. Genius. Thanks.

[amisix]

I just upgraded to a Raspberry Pi4 and I'm having very similar crashing issues while using two AWUS036ACMs despite using a powered hub (tried two different ones). I get the crashing whether or not I connect both ACMs to the USB 3.0 or USB 2.0 controller.

But I noticed something, does anybody have any input on this? Why does one ACM device connect (correctly) at SuperSpeed while the other only connects at high-speed? It doesn't matter if I swap USB ports or use a USB hub in between, one ACM always refuses to connect via USB at its rated speed (SuperSpeed). I upgraded to a Raspberry Pi 4 knowing that USB 2.0 on the Pi 3 was a bottleneck but here I am, unable to use the USB 3 on the Raspberry Pi 4 for its intended purpose. I know some bugs were mentioned regarding the USB 3 controller on the Pi 4 - is this one of them or?

System Log:

[ 158.669343] kmodloader: loading kernel modules from /etc/modules.d/* [ 158.823958] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [ 158.857956] mt76x2u 2-2:1.0: ASIC revision: 76120044 [ 158.903711] mt76x2u 2-2:1.0: ROM patch build: 20141115060606a [ 159.086173] mt76x2u 2-2:1.0: Firmware Version: 0.0.00 [ 159.094508] mt76x2u 2-2:1.0: Build: 1 [ 159.099785] mt76x2u 2-2:1.0: Build Time: 201507311614 [ 159.922630] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 160.003448] usb 1-1.1: reset high-speed USB device number 3 using xhci_hcd [ 160.117119] mt76x2u 1-1.1:1.0: ASIC revision: 76120044 [ 160.155703] mt76x2u 1-1.1:1.0: ROM patch build: 20141115060606a [ 160.337827] mt76x2u 1-1.1:1.0: Firmware Version: 0.0.00 [ 160.346330] mt76x2u 1-1.1:1.0: Build: 1 [ 160.351776] mt76x2u 1-1.1:1.0: Build Time: 201507311614 [ 161.170673] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' [ 161.172802] usbcore: registered new interface driver mt76x2u

And lsusb -t:

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M | Port 2: Dev 2, If 0, Class=, Driver=mt76x2u, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M | Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M | Port 1: Dev 3, If 0, Class=, Driver=mt76x2u, 480M | Port 3: Dev 4, If 0, Class=, Driver=usbhid, 12M | Port 3: Dev 4, If 1, Class=, Driver=usbhid, 12M | Port 3: Dev 4, If 2, Class=, Driver=usbhid, 12M

[morrownr]

Well, I guess I am going to have to try this. I only have one ACM but I have other adapters based on 7612u's.

Are you running both in AP mode with hostpad?

[amisix]

Thanks for looking at this. I was eventually able to get both adapters to connect at SuperSpeed by taking out a 6" USB 3.0 cable extension and swapping the USB 3.0 port(s) the adapters were plugged into. Put the 6" cable extension back on... still have SuperSpeed connectivity. Odd. Removed all cables/extensions entirely while working on this configuration further.

But even after that's resolved the one ACM adapter in AP mode continually crashes when there's any load - no matter if it's plugged into a powered hub or not (tried 2 different manufacturers). I also often lose connectivity to the Pi through eth0/eth1/wwan as if the bridge/br-lan isn't functioning any longer. I have to poweroff the Pi and disconnect power entirely in order to reset the adapter(s) or it will fail to function with a standard reboot.

The error message I receive after a reboot is:

reset SuperSpeed Gen 1 USB Device number 2 using xhci_hcd
mt76x2u 2-1:1.0: ASIC revision: 76120044
mt76x2u 2-1:1.0: ROM patch build: 20141115060606a
mt76x2u 2-1:1.0: Firmware version 0.0.00
mt76x2u 2-1:1.0: Build: 1
mt76x2u 2-1:1.0: Build Time 201507311614__________
reset SuperSpeed Gen 1 USB Device number 4 using xhci_hcd
mt76x2u 2-2.4:1.0: ASIC revision: 76120044  
mt76x2u 2-2.4:1.0: ROM patch build: 20141115060606a
mt76x2u 2-2.4:1.0: firmware upload failed: -110
mt76x2u probe of 2-2.4:1.0 failed with error -5
usbcore registered new interface driver mt76x2u
generic driver version 2.4.2

The Pi never hits an under voltage condition; per the logs throttled=0x0. According to my USB voltmeter, the power supply output is at 5.33 volts idle, 5.2 w/load. Current draw is ~1.2-1.5amps while attempting to run a speed test, power supply is a CanaKit rated at 3.5amps. I connected the voltmeter in several locations to determine if I was experiencing significant voltage drop across the power cables and I am not. All splitters extenders/whatever removed, using separate power supply for the powered hub(s). Verified voltage of power supply used for USB hubs. Used voltmeter to verify USB ports on the powered hub(s) are in fact powered by their own power supply and not by the Pi's USB port. max_usb_current=1 is set in /boot/config.txt

I can recreate the issue consistently with the Pi4 (2018 ver. 1.5). I was able to get this exact config to work with the Pi3 B (ver. 1.2), but without USB 3.0 connectivity and speed of course.

I ran all available updates, no change. I updated the Pi's eeprom through Raspbian to the latest release, no change. I verified the driver/firmware (kmod-mt76x2u). No additional network adapters are plugged into the Pi. Only a logitech unifying wireless keyboard/mouse transceiver is connected sometimes so I can poweroff the Pi when I lose connectivity entirely.

[morrownr]

Good information, however, since I am not a mind reader, I need you to answer some basic questions:

What OS are you using? What setup guide are you using? What is the setup trying to accomplish? If using hostapd, post the contents of both hostapd.conf files.

My RasPi4B is now setup in dual AP mode with two 7612u based adapters. This message is coming to you with the system connected to one of the APs. I'm looking for problems but so far, I'm not finding anything. I need more details as noted above.

[amisix]

Sure, yeah, sorry. OS: OpenWrt 21.02.1 No guide any longer. Using Luci. It's a routed AP using the same adapters and physical/software configuration that I ran successfully on my Pi3B just recently. One ACM adapter in managed and the other in AP. Intention was to get rid of the USB 2.0 bottleneck for my USB 3.0 capable devices (ACMs).

Contents of /tmp/run/hostapd-phy1.conf:

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=36
chanlist=36

tx_queue_data2_burst=2.0
ieee80211n=1
ht_coex=0
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1]
ieee80211ac=1
vht_oper_chwidth=0
vht_oper_centr_freq_seg0_idx=38
vht_capab=[RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC-1][MAX-A-MPDU-LEN-EXP3]

radio_config_id=baf7f8e0d899639d19ee5976b327255e
interface=wlan1
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=XXXXXXXXXX
wpa_psk_file=/var/run/hostapd-wlan1.psk
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=XXXXXXXXXXXXX
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
dynamic_vlan=0
vlan_naming=1
vlan_file=/var/run/hostapd-wlan1.vlan
config_id=ff44be3e7938e9d107b7557d1a82c1c3
bssid=00:c0:ca:b0:25:32

[amisix]

@morrownr I configured both ACMs as APs in Luci just as I have everything else (to have a dual AP setup similar to yours) and I can get each adapter/AP to crash when load is applied within a few seconds to a couple minutes. I get a similar error/crash when using just a single ACM in both managed and AP mode also.

My kernel log has the following in it at the time of the crash (two APs), I don't know if it's useful or not:

kern.err kernel: [21535.288743] mt76x2u 2-2.4:1.0: error: mt76x02u_mcu_wait_resp failed with -110
daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 98:48:27:de:5c:02
daemon.info hostapd: wlan1: STA 98:48:27:de:5c:02 IEEE 802.11: disassociated
daemon.notice hostapd: wlan1: STA-OPMODE-N_SS-CHANGED 98:48:27:de:5c:02 1
daemon.info hostapd: wlan1: STA 98:48:27:de:5c:02 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
daemon.info hostapd: wlan1: STA 98:48:27:de:5c:02 IEEE 802.11: authenticated

I have no doubt it's possible to get these adapters functioning as you've described - when they're working they're fast and responsive with good reception, if even only for a couple of minutes (for me).

[morrownr]

@amisix

I see. While I use OpenWRT on my main wifi router, but I'm just a user and not a dev on it. I have no exoerience, well, once, short lived, with OpenWRT on a Pi. Here is what I think I know:

The MT76 driver in the Linux kernel and the one that is available via package in OpenWRT are not the same. Here is the repo for the MT76 driver that is used in OpenWRT. My recommendation is that you engage there.

https://github.com/openwrt/mt76

The MT76 driver in the kernel and the one OpenWRT maintains are very similar and the OpenWRT repo serves as a downstream and testing location for the driver in the kernel. Patches flow up and down.

[amisix]

Great - I'll do that. As always, thank you for your patience and input with describing how this all works.

[amisix]

@morrownr looks like it came down to USB scatter gather. I was disabling it incorrectly. I thought adding "disable_usb_sg=1" to /boot/config.txt and rebooting in OpenWrt was sufficient, it is not. I saw you had something in your ReadMe regarding SG, it was informative

Steps for disabling USB scatter gather in OpenWrt

echo 1 > /sys/module/mt76_usb/parameters/disable_usb_sg

cat /sys/module/mt76_usb/parameters/disable_usb_sg

Should be "Y".

Make it permanent: echo "mt76-usb disable_usb_sg=1" >> /etc/modules.d/mymoduleparam.conf

Reboot

Thanks @bjlockie

[morrownr]

I thought adding "disable_usb_sg=1" to /boot/config.txt

Not the right place but you know that now.

Steps for disabling USB scatter gather in OpenWrt

The way you posted certainly works. I also have a way to do it in the README.md. I know my way is a little longer but it is consistent with how my Realtek repos work for module parameters so I can remember it. He he.

Is everything working better now?

[amisix]

Yeah, lots to learn..

The single and dual ACM configuration run beautifully now & I'm getting the increase in speed I was looking for thanks to the adapters being able to take advantage of the 3.0 bus speeds.

I wouldn't have known about USB scatter and gather being an issue had it not been for your README.md. (Past still learning why things go where they go) I didn't realize that it could cause the adapter to cease functioning entirely as opposed to just a degradation in performance.

Looking forward to using them.

[morrownr]

I wouldn't have known about USB scatter and gather being an issue had it not been for your README.md. (Past still learning why things go where they go) I didn't realize that it could cause the adapter to cease functioning entirely as opposed to just a degradation in performance.

I did not realize this either and I can see now why this was not on my radar. Anytime I set up a system to use a 7612u based adapter, I always turn scattler-gather off.

In looking at this, I think the devs could make an adjustment that would avoid issues like you had to deal with. I think I am going to write a message to the 3 main Mediatek devs and suggest some options. There are 3 other things I would like to discuss with them anyway.

Do you think a posting in Issues over at USB-WiFi would be useful? If so, please post your story regarding this issue over there as more folks will see it over there.

[amisix]

Anytime I set up a system to use a 7612u based adapter, I always turn scattler-gather off.

Yeah, I've got my config lists with detailed steps, this has been added. It's working great now.

I think I am going to write a message to the 3 main Mediatek devs and suggest some options.

I appreciate that, I will defer to you for anything further regarding this issue. I'm curious what the 3 other issues are although they're certainly over my head.

I completed a short issue/solution write-up as you suggested, please let me know if you'd like any modifications.