USB-WiFi
USB-WiFi copied to clipboard
morrownr
ANDDEAR MT7612U004 Adapter Issue on Raspberry Pi 4B with USB 3.0
@morrownr - I'm having a strange issue with the ANDDDEAR MT7612U004 adapter that I recently picked up where it won't initialize properly on the USB 3.0 bus of my Raspberry Pi 4B but it will work fine on the USB 2.0 bus (Kali 2022.2). I originally evaluated the adapter with a CM4 and had no issues because, USB 2.0. The issue occurs whether I have a single adapter or multiple adapters connected. If I take the adapter and swap it to USB 2.0, the issue disappears and the adapter works fine.
I think this may impact other users of this adapter if they choose to use it on a Raspberry Pi 4B with USB 3.0. We may need to modify or remove my review depending on the solution.
lsusb freezes/locks up & there is no output iw dev output does not show the adapter
EDIT: This thread got really long. Here's a recap with troubleshooting and a workaround.
Hi @amisix
Hmmm... so Kali 2022.2 on a RasPi4B only while using a USB3 port. My first thought is to say bad words about the selection of the USB3 hardward in the RasPi4B. There are probably thousands of Pi4B users that have had issues with this.
Let's do some troubleshooting:
Do you have an extra sd card that you could do a clean installation of the RasPiOS v 2022-04-04? If so, make it happen and see if you get the same problem.
Would you mind also try the ALFA ACM with the USB3 port with Kali 2022.2 to see if you have the same problem?
Have you tested the adapter in a x86/amd64 based system with Linux installed to see if you see the problem?
Hopefully that will help us narrow things down. Not long ago a patch was applied to the RasPiOS USB3 driver due to a hardware incompatibility. The problem was not in the Linux driver but was a hardware bug. I can be more specific if depending on what we find.
Regards
My first thought is to say bad words about the selection of the USB3 hardware in the RasPi4B. There are probably thousands of Pi4B users that have had issues with this.
Fun times. Hopefully whatever we find out can be useful.. In a previous post you had mentioned bugs in the Raspberry Pi 4B USB controller, I was thinking we might end up there with this but I'm not so sure now after testing it with the Alfa ACM.
Do you have an extra sd card that you could do a clean installation of the RasPiOS v 2022-04-04? If so, make it happen and see if you get the same problem.
Sure do - I'll do that.
Would you mind also try the ALFA ACM with the USB3 port with Kali 2022.2...
Done. I do not have the same problem with the ALFA ACM in Kali 2022.2. It initializes properly without error.
Have you tested the adapter in a x86/amd64 based system with Linux installed...
Not yet but I have a live boot Kali image ready to go. I'll run it up to see what comes of it.
Thanks.
Fun times. Hopefully whatever we find out can be useful.. In a previous post you had mentioned bugs in the Raspberry Pi 4B USB controller, I was thinking we might end up there with this but I'm not so sure now after testing it with the Alfa ACM.
That the ALFA ACM is working is just a data point. It does not rule out the Pi4B USB3 hardware being the problem imho. The 8812au driver has worked fine on the Pi4B while the 8812bu driaver has had ongoing problems for a long time. It seems the fix that went into the Pi4B has fixed the problem with the 8812bu driver but I am not aware of that fix being upstreamed.
We will just have to search and since I don't have that adapter, all I can do forward suggestions.
Regards
Let me be clear: The 2022-04-04 version of the RasPiOS should and does appear to have the RasPi4b USB3 fix but the version of Kali you are using most likely does not as the fix would need to work its way up into the kernel Linus maintains and then downward. That does not mean the problem you are seeing is the result of the problem that the fix addressed but the fact that it is happening only on a USB3 port makes one ponder the issue.
^ Understood.
The issue does occur in RasPiOS on both USB3 ports. The adapter will not initialize on USB3 Port 1 but it will initialize on USB3 Port 2 although it will not connect to any access points. (Edited: Previously I had stated USB3 Port 2 functioned, it does not)
There is an issue with the ANDDEAR adapter in Kali on x86 hardware although it is not identical it still leads to the adapter being non-functional. I can see the adapter but it won't connect to anything then it says "network disconnected" while no longer allowing me to even attempt a connection. Is it loading the incorrect firmware - ? There's a reference to mt7662.bin (not 7612)? Line 2 and Line 5.
Errors on x86 hardware:
[ 15.069700] mt76x2u 2-3:1.0: ASIC revision: 76120044 [ 15.069796] mt76x2u 2-3:1.0: firmware: direct-loading firmware mt7662_rom_patch.bin [ 15.069807] mt76x2u 2-3:1.0: ROM patch build: 20141115060606a [ 15.126913] Bluetooth: hci1: RTL: fw version 0x0999646b [ 15.201949] mt76x2u 2-3:1.0: firmware: direct-loading firmware mt7662.bin [ 15.201958] mt76x2u 2-3:1.0: Firmware Version: 0.0.00 [ 15.201962] mt76x2u 2-3:1.0: Build: 1 [ 15.201964] mt76x2u 2-3:1.0: Build Time: 201507311614____ [ 15.928821] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' [ 15.930020] usbcore: registered new interface driver mt76x2u [ 18.503647] r8169 0000:03:00.0: firmware: direct-loading firmware rtl_nic/rtl8168h-2.fw [ 18.533693] Generic FE-GE Realtek PHY r8169-0-300:00: attached PHY driver (mii_bus:phy_addr=r8169-0-300:00, irq=MAC) [ 18.725739] r8169 0000:03:00.0 eth0: Link is Down [ 18.741103] iwlwifi 0000:02:00.0: Applying debug destination EXTERNAL_DRAM [ 18.818936] iwlwifi 0000:02:00.0: Applying debug destination EXTERNAL_DRAM [ 18.820194] iwlwifi 0000:02:00.0: FW already configured (0) - re-configuring [ 18.855815] iwlwifi 0000:02:00.0: Applying debug destination EXTERNAL_DRAM [ 18.933961] iwlwifi 0000:02:00.0: Applying debug destination EXTERNAL_DRAM [ 18.935387] iwlwifi 0000:02:00.0: FW already configured (0) - re-configuring [ 20.885724] mt76x2u 2-3:1.0: mac specific condition occurred [ 21.005747] usb 2-3: USB disconnect, device number 3 [ 21.140248] mt76x2u 2-3:1.0: mac specific condition occurred [ 21.349695] mt76x2u 2-3:1.0: mac specific condition occurred [ 21.453699] mt76x2u 2-3:1.0: mac specific condition occurred [ 21.553693] mt76x2u 2-3:1.0: timed out waiting for pending tx [ 21.885886] usb 2-3: new SuperSpeed USB device number 4 using xhci_hcd [ 21.906677] usb 2-3: New USB device found, idVendor=0e8d, idProduct=7612, bcdDevice= 1.00 [ 21.906681] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 21.906682] usb 2-3: Product: 802.11ac WLAN [ 21.906683] usb 2-3: Manufacturer: MediaTek Inc. [ 21.906684] usb 2-3: SerialNumber: 000000000 [ 22.038055] usb 2-3: reset SuperSpeed USB device number 4 using xhci_hcd
The issue does not occur whatsoever in RasPiOS - the adapter works fine on USB 3.0 - able to see and connect to access points with no errors in the logs.
Hmmm... Kali is starting to look guilty.
There is an issue with the ANDDEAR adapter in Kali on x86 hardware although it is not identical it still leads to the adapter being non-functional.
Kali is really starting to look guilty.
Are you going to be able to test a non-Kali x86 Linux distro such as Ubuntu 22.04?
I can see the adapter but it won't connect to anything then it says "network disconnected" while no longer allowing me to even attempt a connection. Is it loading the incorrect firmware - ?
It is possible that the firmware is somehow messed up in Kali.
There's a reference to mt7662.bin (not 7612)? Line 2 and Line 5.
The mt7612u chipset requires two firmware files:
mt7662u.bin mt7662u_rom_patch.bin
My recommendation is that you see my guide:
https://github.com/morrownr/USB-WiFi/blob/main/How_to_Install_Firmware_for_Mediatek_based_USB_WiFi_adapters.md
What I think you should do at this point is download both files as instructed in the above document and then compare the files to what is in Kali. The files in Kali should be identical to what you download byte per byte. There is one thing to note, the mt7612u firmware files are usually installed in two different directories and there is a history to understand.
At one time, all firmware files were just dumped into lib/firmware but as time passed and more files were showing up, it was decided that each company have its own directory. All Mediatek firmware files are in /lib/firmware/mediatek however due to old code in the mt7612u driver, it looks in the old location which is lib/firmware. What most distros do is they put the two files in both locations so you should check the files in both locations.
The adventure continues...
Kali is really starting to look guilty.
We're narrowing it down... yay
Are you going to be able to test a non-Kali x86 Linux distro such as Ubuntu 22.04?
Yeah, I'll just create another live boot usb with Rufus or balena.
My recommendation is that you see my guide...
It could be the firmware? I'll follow your instructions and do a diff/hash comparison as suggested.
We shall see. Thanks for breaking it all out.
It could be the firmware?
It could. These files get sent all over the place. One little bit gets flipped and now the file does operate as designed. Is it likely this is the problem? No, but firmware errors are what is showing up so we need to be 100% that firmware file integrity is not the problem. I am looking forward to your report from a test on an x86/amd64 system. So far, the only time we are seeing the problem is with Kali.
Ubuntu x86: No go, adapter not recognized at all. lsusb locks up when run, no output. iw dev shows no wireless device. dmesg showed another "mac specific condition occurred" with no additional details. I stopped there as I could go down another rabbit hole..
Ubuntu ARM/Raspberry Pi No go either. Adapter recognized by lsusb but iw dev and ifconfig shows no wireless device other than onboard. dmesg & logread show nothing of value/no visible errors.
Kali firmware: 1: Firmware content in /lib/firmware does not match firmware in /lib/firmware/mediatek.
2: Firmware in /lib/firmware is named mt7662.bin & mt7662_rom_patch.bin (missing "u" after mt7662 that's in /lib/firmware/mediatek/ filename. Example: mt7662u.bin)
3: Firmware in directory /lib/firmware/mediatek matches firmware from git (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek)
Why the discrepancy between the firmware in /lib/firmware compared to /lib/firmware/mediatek (and git)? I copied the firmware from git to /lib/firmware (& rebooted) and the issue persists. I'm going to do it again for good measure but need a bit more time.
Well. Interesting.
Let me dive into the code in the mt7612u driver so that we know exactly which firmware files the driver is looking for and what their location without a doubt.
Let me dive into the code in the mt7612u driver so that we know exactly which firmware files the driver is looking for and what their location without a doubt.
Awesome, thanks.
@morrownr RE: Kali Firmware
I removed the firmware from /lib/firmware/ then copied the firmware from /lib/firmware/mediatek in its place. I renamed the two .bin files to match what was already in /lib/firmware (removed the "u" after mt7662, Example: mt7662u.bin = mt7662.bin & mt7662u_rom_patch.bin = mt7662_rom_patch.bin)
Weirdest thing, the adapter now works on one USB 3.0 port (top) without errors, but not the other USB 3.0 port (bottom). The error I receive on the bottom USB 3.0 port is the same as the previous error:
mt76x2u 2-1:1.0: error: mt76x02u_mcu_wait_resp failed with -108 mt76x2u 2-1:1.0: mac specific condition occurred
BUT, one port is now working with the firmware swap.. thoughts?
EDIT: After additional testing both USB 3.0 ports are now working without errors. Apparently swapping the firmware worked.. ?
EDIT: After additional testing both USB 3.0 ports are now working without errors. Apparently swapping the firmware worked.. ?
I have busy since we worked on thiss yesterday. Give me a chance to read your reports and then I will try to sit aside the next hour to look at this.
Let me throw out some info so that we are on the same sheet of music:
The Linux kernel firmware repository for Mediatek:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek
It shows the following files as available:
91412 May 5 12:54 mt7662u.bin
20686 May 5 13:00 mt7662u_rom_patch.bin
It does not show any files called mt7662.bin or mt7662_rom_patch.bin at all. So, we have a mystery on our hands.
Let me do the digging in the driver source that I started to do yesterday.
While I am working, here is something for you to test:
Delete mt7662.bin and mt7662_rom_patch.bin from /lib/firmware and then reboot so as to have a clean boot and then see what happens.
A little grepping later and this is what I have:
mt76/mt76x0/mt76x0.h:#define MT7610E_FIRMWARE "mediatek/mt7610e.bin"
mt76/mt76x0/mt76x0.h:#define MT7650E_FIRMWARE "mediatek/mt7650e.bin"
mt76/mt76x0/mt76x0.h:#define MT7610U_FIRMWARE "mediatek/mt7610u.bin"
mt76/mt76x2/mt76x2.h:#define MT7662_FIRMWARE "mt7662.bin"
mt76/mt76x2/pci.c:MODULE_FIRMWARE(MT7662_FIRMWARE);
mt76/mt76x2/pci.c:MODULE_FIRMWARE(MT7662_ROM_PATCH);
mt76/mt76x2/pci_mcu.c: ret = request_firmware(&fw, MT7662_FIRMWARE, dev->mt76.dev);
mt76/mt76x2/usb_mcu.c: err = request_firmware(&fw, MT7662_FIRMWARE, dev->mt76.dev);
mt76/mt76x2/usb.c:MODULE_FIRMWARE(MT7662_FIRMWARE);
mt76/mt76x2/usb.c:MODULE_FIRMWARE(MT7662_ROM_PATCH);
It appears mt7662.bin and its mate are for the PCI version of the chipset and should be in /lib/firmware whick should answer the below question you had:
Why the discrepancy between the firmware in /lib/firmware compared to /lib/firmware/mediatek (and git)?
One is for the PCI chipset and one is for the USB chipset. It is interesting how they ended up to two different places.
I am not seeing anything in the code that tells me when mt7662u.bin and its mate should be. Interesting. We will have to assume it is /lib/firmware/mediatek as I have checked multiple distros now and that it where they are.
It is interesting that you copied the files from /mediatek to /lib/firmware and removed the u and things started working. I am being to suspect a faulty part in the adapter as what you did should not have solved the problem. Is it possible that there is some dust in the ports or in the adapter?
This may be a case where putting things down for a couple of days and then start over.
I removed mt7662.bin and mate from /lib/firmware and the issue reappears. The adapter fails to initialize.
Error:
[ 7.329300 ] mt76x2u 2-2:1.0: Direct firmware load for mt7662_rom_patch.bin failed with error -2 [ 7.329382] bcmgenet fd580000.ethernet: configuring instance for external RGMII (RX delay) [ 7.337947] bcmgenet fd580000.ethernet eth0: Link is Down [ 7.446507] systemd-journald[171]: Oldest entry in /var/log/journal/71f4eaa596ae498e8f46633c136a5627/system.journal is older than the configured file retention duration (1month), suggesting rotation. [ 7.464436] systemd-journald[171]: /var/log/journal/71f4eaa596ae498e8f46633c136a5627/system.journal: Journal header limits reached or header out-of-date, rotating. [ 8.040892] mt76x2u: probe of 2-2:1.0 failed with error -2 [ 8.048231] usbcore: registered new interface driver mt76x2u
The adapters and plugs are clean. I have a second MT7612U004 adapter I've tried it with, same behavior.
EDIT: I put mt7662.bin and mate back in /lib/firmware and the adapter starts working again.
EDIT EDIT: It fails when I connect a second adapter, whether it be an ANDDEAR or Alfa MT7612U. The first adapter that initialized fine stays functioning but the second adapter immediately starts throwing disconnect/reconnect errors repetitively every few seconds. Oh well, one works great for now.
So, there's a temporary fix - but, why? This can totally wait if you want to try again another day.
I removed mt7662.bin and mate from /lib/firmware and the issue reappears. The adapter fails to initialize.
Error:
[ 7.329300 ] mt76x2u 2-2:1.0: Direct firmware load for mt7662_rom_patch.bin failed with error -2
This makes no sense to me. Why would a USB adapter load mt7662_rom_patch.bin?
[ 8.040892] mt76x2u: probe of 2-2:1.0 failed with error -2
?
[ 8.048231] usbcore: registered new interface driver mt76x2u
Okay
The adapters and plugs are clean. I have a second MT7612U004 adapter I've tried it with, same behavior.
EDIT: I put mt7662.bin and mate back in /lib/firmware and the adapter starts working again.
Is this mt7662.bin and mate the originals or the ones that are actually mt7662u.bin and mate but were renamed?
EDIT EDIT: It fails when I connect a second adapter, whether it be an ANDDEAR or Alfa MT7612U. The first adapter that initialized fine stays functioning but the second adapter immediately starts throwing disconnect/reconnect errors repetitively every few seconds. Oh well, one works great for now.
When I put two 7612u adapters in any system here, they both work fine but I don't have a ANDDEAR MT7612U004.
This is starting to hurt my head.
This testing needs to be done in a scientific manner. We really need a sheet where we write the exact details. I'm getting lost on which distro and which hardware and how many or which adapters you are testing.
Are you using a usb hub or direct into the port?
So, there's a temporary fix - but, why? This can totally wait if you want to try again another day.
I'll try to hang in there.
This makes no sense to me. Why would a USB adapter load mt7662_rom_patch.bin?
Unknown. Agreed, why?
Is this mt7662.bin and mate the originals or the ones that are actually mt7662u.bin and mate but were renamed?
*Copied from /lib/firmware/mediatek and renamed.
This is starting to hurt my head. This testing needs to be done in a scientific manner. We really need a sheet where we write the exact details. I'm getting lost on which distro and which hardware and how many or which adapters you are testing.
Same. I'm trying my best. I can go back through the thread and compile things a bit better if need be. I only used the ALFA ACM in place of the ANDDEAR as requested in one of your tests, and once as a secondary adapter (recently) on the USB 3.0 bus - past that it's all the ANDDEAR-MT7612U004 that's throwing a fit (I have two of them on hand).
No hub, direct to the port(s). Single adapter connected unless specifically testing dual adapters to see how it responded (1 test).
Thanks..
How about we do a short review and come up with a plan? We can contact the Mediatek kernel devs if need be but right now all we have is kind of a mess as far as something to present.
We zeroed in on checking the firmware as a possible problem. Here is how we think the firmware should be setup for mt7612u/mt7612e chipsets:
Located in /lib/firmware/mediatek: 91412 mt7662u.bin 20686 mt7662u_rom_patch.bin
Located in /lib/firmware: 81908 mt7662.bin 26350 mt7662_rom_patch.bin
I have checked the above files in multiple distros and this is what is working. Take note that the files in /lib/firmware/mediatek are different than those in /lib/firmware and the theory is that the ones without u are for the pci version of the chipset. Our look inside the code of the mt76 driver appeared to confirm that.
Assumption: If test systems have the above 4 files exactly as they are shown above, the firmware files should be the right files and in the right place. I've seen distro makers mess this up so it was worth checking.
Mt suggestion now is to take that clean sd of RasPiOS 2022-04-04 and use it in the RasPi4B to do a full checkout and save logs. You had said that the adapter was working fine with this setup so let's work this setup to confirm that it is working fine so that we can save log files that show how things should be when it is working fine.
I think it worthwhile to refresh out memories on how to clean out log files between boots so we are not confusing things.
Can I get you to run the following tests while booting in between tests? Save from log on each boot using something like...
$ dmesg | grep -i mt76
Configurations to test: (cold boot between tests)
one ANDDEAR 004 adapter in usb3 port two ANDDEAR 004 adapters in usb3 ports one ANDDEAR 004 adapter in usb2 port two ANDDEAR 004 adapters in usb2 ports two ANDDEAR 004 adapters in one of each type of port one ANDDEAR 004 adapter in usb3 port and one ALFA ACM adapters in the other usb3 port if they both fit at the same time
Also, run the follow and save results while the ANDDEAR adapter is in a usb3 port:
$ lsusb -t
You should see something like this:
Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=mt76x2u, 5000M
That is to make sure we are in usb3 mode. It is possible to use a usb3 capable chipset but make the adapter only usb2 capable.
Once we have a full set of good results in hand, we can then boot with Kali and run similar tests to see what the difference is. My recommendation is that the Kali bootable sd be a clean installation. The reason is that I have seen many things get messed up in Kali over time due to the rolling release. A clean, updated installation should help with any problems that could build up over time.
Regards
How about we do a short review and come up with a plan? We can contact the Mediatek kernel devs if need be but right now all we have is kind of a mess as far as something to present.
Sure, Ok.
We zeroed in on checking the firmware as a possible problem. Here is how we think the firmware should be setup for mt7612u/mt7612e chipsets:...
Yes, on the same page.
Assumption: If test systems have the above 4 files exactly as they are shown above, the firmware files should be the right files and in the right place.
Ok, will run through requested tests to confirm.
Can I get you to run the following tests while booting in between tests?
Of course. It will take a bit but I will get it. All previous tests have been completed with a clean, freshly imaged copy of whichever OS was requested, I will continue to do that for these tests.
Thanks much for all your efforts regarding this.
Take your time. I enjoy solving a good mystery. It often takes time.
You may want to start a text document to put the results of your testing and you can zip it and post it here instead of having a very long report. It is also easier to add to a text document than to edit and keep up with results here. Below is an example like I might use:
RasPi4B
RasPiOS 2022-04-04
one ANDDEAR 004 adapter in usb3 port
$ dmesg | grep -i mt76
[ 11.289928] mt76x2u 2-2:1.0: ASIC revision: 76120044
[ 11.332857] mt76x2u 2-2:1.0: ROM patch build: 20141115060606a
[ 11.497666] mt76x2u 2-2:1.0: Firmware Version: 0.0.00
[ 11.497688] mt76x2u 2-2:1.0: Build: 1
[ 11.497694] mt76x2u 2-2:1.0: Build Time: 201507311614____
[ 12.319504] usbcore: registered new interface driver mt76x2u
[ 12.363881] mt76x2u 2-2:1.0 wlx0013ef5f0c7c: renamed from wlan0
The multiple tests with the RasPiOS hopefully will give us a baseline of tests that are successful, then the same tests with Kali on the RasPi4B can be compared.
Regards
Can I get you to add one test to the previously posted list?
one ALFA ACM adapter in usb3 port
OK, 50th time is the charm. Github sure doesn't make it easy to simply upload a text file without trying to tie it to some code or a branch or some such sh*t. Here's a .zip file with the RasPiOS tests
Thanks for giving it 50 times. I think I can show you an easier way to upload the compressed file. What OS are your trying to upload it with?
I read through the file. I saw consistent results. I took the primary error line and did some searching. Try this:
Open a terminal (Ctrl + Alt + t)
sudo nano /etc/modprobe.d/mt76_usb.conf
add:
options mt76_usb disable_usb_sg=1
Save the file: Ctrl + Alt + o, Enter, Ctrl + Alt + x
Reboot
Redo one of the tests that failed.
Results?
Thanks for giving it 50 times. I think I can show you an easier way to upload the compressed file. What OS are your trying to upload it with?
Please do. Windows 10 (chrome) - I thought it should have been easier, don't know what I was missing. Can run basic tests in CLI, can't upload .txt file. Hopeless.
I read through the file. I saw consistent results. I took the primary error line and did some searching. Try this (disable SG):
Consistent results, good.
I disabled USB Scatter Gather, rebooted, then confirmed it was off with the command below. I tested with a single ANDDEAR adapter on USB3 port. Unfortunately the issue persists with no change in error messages.
cat /sys/module/mt76_usb/parameters/disable_usb_sg
Thanks for searching the error further. I also completed some searching for similar error messages but almost all referred to the error "mt76x02u_mcu_wait_resp failed with -110", not the "mt76x02u_mcu_wait_resp failed with -108" I've been receiving. Although I don't know how relevant that difference is at this time.
Thanks.
Quick test (re-run a dozen times): Kali 32bit 2022.1 Single ANDDEAR adapter, USB3 Port 1 (top) - FAIL (same errors as in RasPiOS) Single ANDDEAR adapter, USB3 Port 2 (bottom) - SUCCESS
Why would the adapter work on one USB3 port and not the other?
I also tested USB3 Port 1 with an Alfa ACM and the Alfa adapter works fine on that port, no errors. Then I ran the test on a different Raspberry Pi 4 and USB3 Port 1 with the ANDDEAR adapter failed just like previous tests.
I also found another error - something related to the xhci controller itself?
xhci_hcd 0000:01:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. mt76x2u 2-2:1.0: mac specific condition occurred
USB bug?
Greetings! I've read through the thread of progress made regarding this issue. Now the thing is, I'm using the MT7612UN and having no luck whatsoever, either. Not sure what makes the "UN" different from the "U" or "BU" versions?
Please do. Windows 10 (chrome) - I thought it should have been easier, don't know what I was missing. Can run basic tests in CLI, can't upload .txt file. Hopeless.
Zip the text file and the drag the zip and drop it here (actually in the window where you are replying)
I disabled USB Scatter Gather, rebooted, then confirmed it was off with the command below. I tested with a single ANDDEAR adapter on USB3 port. Unfortunately the issue persists with no change in error messages.
Well, okay. While searching I saw similar reports. I had previously only seen issues requiring that parameter in AP mode.
Quick test (re-run a dozen times): Kali 32bit 2022.1 Single ANDDEAR adapter, USB3 Port 1 (top) - FAIL (same errors as in RasPiOS) Single ANDDEAR adapter, USB3 Port 2 (bottom) - SUCCESS
Why would the adapter work on one USB3 port and not the other?
Very good question. I don't have an answer yet.
Which revision of the RasPi4B do you have?
At this point, I'd like to see the results of testing on x86/amd64 hardware. Yes, again. The expanded version of testing like you have been doing and documenting. Please continue documenting your testing as it is the best we have right now to see something to help and if we figure out what the problem is, it will be something to send in with a report.
I have 4 different adapters based on the mt7612u chipset and I have never run into such as this. I have a RasPi4B. It is a v1.2.
I also tested USB3 Port 1 with an Alfa ACM and the Alfa adapter works fine on that port, no errors. Then I ran the test on a different Raspberry Pi 4 and USB3 Port 1 with the ANDDEAR adapter failed just like previous tests.
Are both Pi's the same version?
I also found another error - something related to the xhci controller itself?
xhci_hcd 0000:01:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. mt76x2u 2-2:1.0: mac specific condition occurred
USB bug?
Need to do some searching.