ANDDEAR MT7612U004 Adapter Issue on Raspberry Pi 4B with USB 3.0 #75
Comments
|
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 |
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.
Sure do - I'll do that.
Done. I do not have the same problem with the ALFA ACM in Kali 2022.2. It initializes properly without error.
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. |
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. 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:
|
Hmmm... Kali is starting to look guilty.
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?
It is possible that the firmware is somehow messed up in Kali.
The mt7612u chipset requires two firmware files: mt7662u.bin My recommendation is that you see my guide: 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 The adventure continues... |
We're narrowing it down... yay
Yeah, I'll just create another live boot usb with Rufus or balena.
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. 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: 2: Firmware in /lib/firmware is named mt7662.bin & mt7662_rom_patch.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)? |
|
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. |
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:
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.. ? |
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: 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 |
|
A little grepping later and this is what I have: 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:
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 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 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. |
This makes no sense to me. Why would a USB adapter load
?
Okay
Is this mt7662.bin and mate the originals or the ones that are actually mt7662u.bin and mate but were renamed?
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?
I'll try to hang in there. |
Unknown. Agreed, why?
*Copied from /lib/firmware/mediatek and renamed.
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: Located in /lib/firmware: 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 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 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 |
Sure, Ok.
Yes, on the same page.
Ok, will run through requested tests to confirm.
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: 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) add: Save the file: Ctrl + Alt + o, Enter, Ctrl + Alt + x Reboot Redo one of the tests that failed. Results? |
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.
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.
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 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. I also found another error - something related to the xhci controller itself?
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? |
Zip the text file and the drag the zip and drop it here (actually in the window where you are replying)
Well, okay. While searching I saw similar reports. I had previously only seen issues requiring that parameter in AP mode. |
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.
Are both Pi's the same version?
Need to do some searching. |
|
This is starting to get interesting. Question: When you say Another question: Are you checking with It might be a good idea to add USB3 chipset to the header on each test. The info can be found with 7 Series/C216 Chipset Family USB The USB3 chipset on the RasPi4B is: VL805 I have not reviewed the document with the full results yet but will as I have time today to see if I can pick up on anything else. This last series of tests is very interesting. I think I am going to setup to run detailed testing with the four 7612u based adapters that I have. I have a small lab with 4 systems that I use for testing and said systems span a wide range of capabilities , ages and have various distros installed. Maybe I can find information that can be of use. Is this an issue with the adapter? Is this an issue with the 7612u driver? Is this an issue with the USB stack in Linux? Is this issue specific to certain chipsets? Many questions. The problem with difficult issues like this is knowing where to report the problem. We do not have the data yet to know where to go with a report. Something you may want to do is contact the folks behind the below article and ask them what they are seeing: https://wlan-pi.github.io/wlanpi-documentation/admin/cf912_issues/ The contact info is shown at the bottom of the article. Regards |
Pulling the adapter out of the port and plugging it back in while the machine is on.
Yes. USB3 connectivity displayed 5000Mbps and USB2 displayed 480Mbps as expected.
I'll do that. The x86 laptop has an Intel 100 Series/C230 Series Chipset. I also have an older machine with Intel 7/C210 and Intel 7/C216 Series chipsets (as you do). It also has an ASMedia ASM1042 USB3 chipset... hmmmm.
Well, now it's a party. I bet your lab is fun (more details?), I'm very much looking forward to the results.
Well, we're ruling out pebkac so I'm happy.
Oh, that's neat. I'll reach out to them. |
|
Quick testing with Intel 7/210 Series and ASMedia 1042 USB3 chipsets. ANDDEAR-MT7612U004 Ubuntu 22.04 Test A: FAILED Test B: SUCCESS Test C: FAILED Test D: SUCCESS On all 4 USB 3.0 chipsets we've tested the adapter fails on USB3 Port 1 but it works on USB3 Port 2 (Kali & Ubuntu) EDIT: In the aircrack-ng FAQ I found something that may be useful? At the bottom of the FAQ it describes a bug and I received a nearly identical error in Kali on the Raspberry Pi - "xhci_hcd 0000:01:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.". Something about it being a USB subsystem bug that affects USB 3 and kernels 4.2 and above? |
|
TL;DR Adapter: ANDDEAR-MT7612U004 Issue: ANDDEAR-MT7612U004 wifi adapter doesn't initialize on hot or cold boot when plugged into a USB3 port. Findings: USB3 Port 1: The adapter doesn't function in USB3 Port 1 in any of the Linux distros tested (Kali, RasPiOS, Ubuntu, Manjaro) USB2 Port 1: The adapter functions in Kali, RasPiOS, and Manjaro. *Neither the ANDDEAR-MT7612U004 or an Alfa AWUS036ACM worked with the Ubuntu 22.04 system image for Raspberry Pi Linux distros tested: Additional testing info: USB chipsets tested: Additional Adapter Info: Errors encountered:
Logs (additional logs will be posted once complete): |
|
Good report. It could use a little editing before we get to the point that we submit it. After a few years of taking bug reports from users of the Realtek drivers I have up, I have a good feel for what should be included and what not. I can do a little editing as an example if you do not mind? Status from my perspective: Problem: USB WiFi adapter will not successfully come up on hot or cold boot if plugged into USB3, port 1. Operates normally if plugged into USB3 ports 2+ or if plugged into any USB2 port. Hardware: ANDDEAR MT7612U004 (URL: ? ) Adapter chipset: MT7612u USB3 chipsets tested: VL805 (RasPi4B) Linux distros tested: Ubuntu 22.04 (kernel 5.15) (x86_64) Log: to be added. Thoughts: I took a look at the bug you pointed me to regarding xhci. Wow. That thread is longer than this one. I need time to digest. In looking at the distros and hardware you have tested with, two things in common stick out: All distros are Debian based and all use systemd. I'm pondering if testing with Manjaro (Arch based) or Fedora would show anything. I'm also wondering if finding a distro that does not use systemd would be of any help. I started setting up yesterday to test my adapters to see what I see in the logs. I have four USB3, mt7612u based adapters and various test systems so I will take a look as I have time. Hopefully today. What do I think the problem is at this point? We are closer than we were. Why would this only show up on USB3 port 1? Maybe something during the boot process is happening in the wrong order initially? Maybe it is a timing issue and something is not ready for port 1? The xhci usb3 driver could be the guilty party. Time for more research and reading. I'll report back as able. Regards |
|
Oh, nearly forgot this minor detail: When you talk about the ports in the RasPi4b, you say top and bottom ports. Well, I run my Pi's up side down. My opinion is that many things work better that way. We can discuss at some point if you want but my point is just say port 1 and port2 because my top and bottom are different than yours. Cheers. |
|
I will edit as you've suggested and change the verbiage regarding port numbers. I need a short break tho, too. much. data.
Yeah, I dunno - it's not an exact fit but it's close. I found a couple others but need to read up more on them.
I'll test with fedora.
Thanks, I know it can be tedious, I appreciate the effort. I don't think you're going to have a single issue. Can you get your hands on one of these ANDDEAR adapters? I'll buy you a few pints of beer to cover things. I'm glad we're closer, maybe? So much data to parse that its become convoluted and difficult to follow, making me feel we're farther away. The damn thing keeps throwing different, obscure errors with behavior differing from port to port, what a mess. Thanks. |
|
Fedora does not work either (Workstation 36, x86 64bit). Same exact errors as on the other distros. I don't think I can recommend this adapter. lol |
I have investigated this. I can't get one currently without international shipping being involved. I have tried international shipped twice in the last two years and it did not turn out well either time so I would like to avoid that which leaves me without a good option.
Understand.
I very much understand this. I need a break also. When troubleshooting, it can be good to take a few days off and then come back to the master document to start fresh. I've had to do this hundreds of times over the last years as I try to support those that use the Realtek drivers. I've grown to very much dislike the company Realtek in that their drivers are missing many features you see in the Mediatek drivers and because there is no way to work issues with Realtek. I am very much looking forward to the new generation of Mediatek USB WiFi adapters based on the mt7921u driver.
I've already pulled the listing and review. Before writing this replay, I did a quick review of this thread and while we are making progress that could eventually lead to code modifications that could help with this issue and others that are similar, it is beginning to look like there is something specific to this adapter that is problematic.
Have you had time to contact the folks from the above article? There are several folks there that have this adapter and can test to see if they have any luck with USB3 port 1.
I started testing my adapters with mt7612u chipsets yesterday. I started testing on a very modern laptop that has three USB 3.1 (3.0) ports and one USB 3.2 port. The system is running Ubuntu 22.04 (not my favorite distro but it will do until the next release of Mint is available). Anyway, I test my ALFA ACM, Netgear A6210 and TEROW ROW02CD. I also have a COMFAST CF-WU785AC and I need to include it as well. I tested each on all 4 ports. I have a little converter for the USB 3,2 USB-C port. I decided to start with WPA3, DFS channel on my router and anything else I could think of to make it hard. Result: No operational problems at all. I tested and pushed them with iperf3 and all I could see was smooth sailing. I had never tested USB-C 3.2 before so a good test was a good thing to see. I did capture mt76 and usb log entries to files and I will look at them today to see what came up. At this point, I am beginning to suspect a manufacturing abnormality in the ANDDEAR adapter could be the cause. Have you tested with Windows or OSX? I think we probably have enough data at this point and maybe we should slow down some and look at doing more research. Regards |
Yeah, that's no good. I have an "extra" one that I can mail to you if you'd be amenable to that.
Agreed. Start seeing double and dyslexia kicks in, not too good for things like mt7612u & mt7621u etc.
Realtek sounds like monsters, flooding the market with sh*t chipsets & code. But... consumers would never know because: Windows. Seems like their primary market is naive users who never look under the hood because they wouldn't know how to fix it if they tried. Then a bunch of linux aficionados come along and are like... hey... that's a nice chipset you have there, it would be a shame if we made it do things you didn't design it to do... and it just spirals from there. I too am looking very much forward to the upcoming release of the mt7621u chipset despite not having an AX capable rout... oh, yeah, "If you build it, wifi will come".
Thank you. This thread is more like an anti-review, unfortunately.
Awesome, you work fast. Having some eyes on it that know what they're doing is very much appreciated. Looking forward to hopefully determining a resolution that doesn't involve percussive maintenance. and a shot glass.
Not yet as their contact link goes to an error 404 page. But I found their repository and am still trying to determine the best way to reach out (It's not really geared towards Q&A, more like feedback). Their input may be invaluable though imo. Interestingly... they have a system image that runs on Raspberry Pi 4 that supposedly uses this adapter - is a functioning driver baked into their image or...? We shall see when I download and try it out.
Yeah, there we go, a bunch of testing to show the ANDDEAR adapter does not function in the same environment as other mt7612u adapters. I mean.. it's a USB adapter based on an exceptional chipset - is there a hardware difference compared to other mt7612u adapters? Is there some kind of memory addressing issue or is it a power management issue that resets the adapter? Or is it a multi-layered issue that's compounding the problem? Just postulating a bit - I'll wait for more info from you while I do a bit of searching.
Yup, Windows 10, It works - I've actually been using one of them as my 2nd wifi adapter part of the time. Thanks. |
Ah, you don't need an AX capable router. You just need 2 mt7921u wifi adapters. My router is an AC2600 device with a USB3 port and a USB2 port. I have tested my ALFA ACM in the USB3 port as a second 5 GHz radio and it works very well. I use OpenWRT. You can run OpenWRT on many routers AND on a RasPi4B. I can show you how with one of your Pi's if interested. You could learn with the ALFA ACM and then you are ready to go when we actually have adapters that we can buy.
Well, it seems this problem is specific to Linux but not specific to Debian which makes it look like something between power on and interface creation is fouled up. Since we are looking at many other mt7612u adapters that are not having the problem, it very well could be something in this specific adapter. Adapter makers buy the chipset from the chipset maker and then add antennas, amps and the various other things that make up an adapter. This really does not seem to be a chipset problem but rather something ANDDEAR has added may have messed up the timing.
I think the default hardware they use only has one USB2 port so they may not be aware of the USB3 problem. But, of course, they should have adapters that they can test in USB3 porrts so if you can get in touch with of them and ask them to test, that could be very useful and it is something they probably need to know and warn people about.
I'm fine with that. Now if we had a good way to exchange private email addresses so that we aren't broadcasting them to the world. I'm sure there is a way, I just haven't run into this situation before. Regards |
Exactly where I was going with that. Just an excuse to build another WiPi hotspot! I built one that's been running nicely for a couple months now as my only router. It's a RPi 3B with OpenWrt and an Alfa ACM along with two Realtek 8153 USB ethernet adapters. Learning OpenWrt while at the same time figuring out the Pi atmosphere has been challenging and fun.
lol, similar thinking, I like it. If it's not wasting your time I'll take you up on that offer. I'd like to do antenna and system optimization (DFS channels? why irqbalance? who cares about jitter?) with what I have now but it's my edge router so let's build something with Openwrt that I can break.
Yeah, USB 2.0 on the CM4 version.. I downloaded the wlanpi system image for the Raspberry Pi 4B and the ANDDEAR adapter initialized fine with no errors (dmesg is clear, ifconfig shows adapter). So I put another one in the other USB3 port and it initialized fine with no errors. Then I checked it with iwlist scanning and both adapters function. lsusb shows both adapters at 5000Mbps on the 3.0 bus. Rebooted a few times and repeated. Ran airodump-ng scans and they work.. Also, I reached out to ANDDEAR and they sent me these drivers that should come on a CD with the adapter. They're 6 years old. The documentation makes reference to the Ralink/Mediatek RT2870 chipset? But there are .bin files related to mt7612 and mt7662. This looks like a nightmare to implement given their "instructions" - what to do? Are these drivers included in the wlanpi system image or is it something else? dmesg | grep -i mt76 info displayed is identical to other builds we've tested (because it's polling the adapter, not the driver?).
|
|
@morrownr Got a new error message this morning. ERROR Transfer event..?
It happened shortly after I received this error:
|
|
Hi @amisix I've been sick so am behind on everything I am working on. I tried the temp email in your link but it came back saying no address exists.
Those drivers are a waste of time. They are from a time right after Mediatek bought Ralink and they seemed to have thought doing what Realtek was doing was a good idea. They then learned it was not a good idea and started working with the kernel devs to make good in-kernel drivers. I'll have to defer answering other issues until I feel a little better. Regards |
Hope you feel better. We kinda need you
Yeah... For ANDDEAR to even suggest that path was ridiculous imo. So, no real support path, the only path I had to them was through the chat on Ali Express and there was clearly a language barrier which meant no troubleshooting. I'd like to hear more about Ralink & Mediatek history, please share when able. I have an old Alfa AWUS036NH that kinda got me into this stuff. Thanks. |
|
I tried the ANDEAR adapter with Ubuntu 22.04 on a x86 mini PC using an N5105 (not sure about MB chipset) and I got similar results: works fine on USB 3.0 port 2 but is unreliable on USB 3.0 port 1. Disappointing because apart from that it's a nice small adapter. |
|
@jclark Thanks for testing that. So odd, that it doesn't function in a specific port despite differing OS and USB chipsets. I do also really like the adapter because of its size. I would have thought that the adapter only functioning on 50% of onboard USB3 ports would be considered faulty but apparently the vendor thinks otherwise. The guys over at WLAN-Pi also confirmed the issue recently and have updated their documentation accordingly. |
|
Hi, I have 2 of these adapters. I ran into a similar problem as you, then I upgraded to master kernel 5.15 on openwrt for the rpi and did not run into any issues. I am able to get both usb adapters working in AP mode on 5ghz with a custom compiled openwrt (with a patch that enables DFS) on usb3 ports 1 and 2. It's a long thread so give me some time to read up on the logs. Edit: If you give me some time I will find my openwrt build/mods and write down documentation so you guys can flash it. There's quite a few steps but I will dig it up again, it's been several months since I've worked on this project (mostly that I got it working and then my curiosity was satisfied). Do you want me to upload/document this somewhere? What tests do you want me to run to show you it is working on both usb3 ports? Can you guys confirm you guys have this patch in your kernels raspberrypi/linux@a538fd2 ? |
|
@Snuupy Your efforts are very much appreciated - looks like you've gotten real far with this adapter. Yes, anything you can compile regarding your solution and necessary resources would be awesome. I think the most common test @morrownr runs is sustained iperf3 tests (15+ minutes). It usually drops out after 5 minutes if you get it to function at all. The WLAN-Pi guys recommended this to show the adapter is plugged into the problematic port (USB3 Port1). iperf3 tests on both USB3 ports would be great though because of how it functions/fails on Port 2 also. Thanks!
|
|
It's possible the adapter overheats too. I ran some benchmarks on it a few months ago and it got really hot. Do you have a preferred iperf command you run? |
|
openwrt-bcm27xx-bcm2711-rpi-4.zip Try this
some notes
|
|
tl;dr: I got it working on usb3 port 1!!! I knew II had previously fucked around enough with this dongle, rpi4, and openwrt to get it working. Instructions to reproduce:
Explanationon openwrt, if you unplug and re-plug the same adapter into the same USB port, it will assign it a new wlan ID (ex. 1st plug is wlan0, 2nd plug is wlan1, 3rd plug is wlan2, etc.) I got this to work when I plugged the adapter in twice, so it was assigned a different wlan ID than the 1st one, despite being in usb3 port 1. I confirmed this by running So guys please try my openwrt build, plug and unplug the adapter in usb3 port1, and try to start an AP. You should see the wlanX (where X is the wlan ID) increment in the system logs, and then it should work "as normal" 😂 Then let me know if this can be reproduced on your end or not. Questions
iperf3 logsdropdownsetup
OLD EDITS ENCLOSED/jumbled thoughts/testing, I have kept it for documentation purposesdropdownActually, I think you're all right and I misremembered, I get these in my logs on openwrt: maybe that's why I had the other adapter in the usb2 port. My bad. Looks like it does not work on usb3 port 1. Edit: I unplugged the usb wifi adapter on usb3 port 2 and port1 started working again. I forgot to install iperf3 on my rpi when I built openwrt, so I have to connect a 2nd device on the ethernet port to host the iperf3 server. Edit 2: By "working" I mean that it doesn't disassociate and I can send ping packets through. However, throughput is abysmal (I didn't have a 2nd laptop/linux box conveniently with me so I had to host librespeed on my laptop connected to the rpi through ethernet and my phone was using the rpi wifi network). USB3 port 1: I got 0.03mbps down/1.54 mbps up, 69ms ping, 107ms jitter. No error notable error logs in openwrt except for earlier, which mysteriously does not show up now. Something is definitely going on breaking usb3 port 1 even if it doesn't completely drop from the system. Removed usb dongle from USB3 port 1, plugged into USB3 port 2 without rebooting. Got a bunch of logs. I guess it doesn't like it when you unplug the dongle from usb3 port 1 into usb3 port 2. I tried a reboot and tested again, with dongle still plugged into usb3 port 2. Still the same I plugged dongle into usb2 port 1, got 11ms ping, 1.9 ms jitter, 101 mbps down, 247 mbps up. Definitely something wrong going on with the usb3 ports, the adapter, or a combination of the 2. At this point, it is not sufficient to see if the adapter connects and disconnects to the adapter/AP, you must check throughput as well to see if something strange is going on. To me, it looks like anything connected to usb3 on that adapter does not work and it only works on usb2. How strange. Has anyone messaged ANDDEAR to see what their response is? Edit 3: Okay, now this is hilarious. I plugged the same usb dongle back into usb3 port1, and openwrt registered the dongle as a completely new adapter: I got 9ms ping, 3.43 jitter, 332 down, 404 up. Now it is working as intended, on usb3 port 1. This must be how I got this dongle working on plug 1, by unplugging it and plugging it back in again where it registers as a completely different adapter 😂 Note how it says Edit 4: I have now been spamming speedtests for ~10 minutes and it has not crashed while doing expected (300/400mbps down/up) performance, normal ping times. So the hilarious solution/workaround is to use an OS where each re-plug of the adapter makes the system assign a different WLAN/USB number to it, and then you will have worked around the Edit 5: After some more testing, I get this log and the adapter crashes. To start it back up again, I have to unplug/replug, which creates wlan6 (also on usb3 port 1). Maybe it overheated? Edit 6: After replugging the adapter (wlan6) I was not able to get it to crash, but the adapter is hot to the touch after many consecutive speedtests. I am getting 250-400 down, 350-500 up consistently. Maybe just my noisy neighbors. Tested on channel 36 because I didn't want to wait for DFS scan time every time I unplugged/replugged. |
|
Ok I made a bunch of edits and notes in the previous comment, please test and let me know. @amisix |
|
My to-do list is too full to take another look at this right now. I'm not aware of any adapters that have flashable firmware. I'm pretty sure the firmware inside the adapters is small and not something that would be subject to errors for the most part. The external firmware is changable but that would be the Mediatek kernel devs that would work it but they may not have the adapter. This could be a hard nut to crack. I tested at length against other adapters with mt7812u chipsets. This adapter is the only one showing the problem so it seems there is something specific to this adapter. Exactly what is causing the problem is still a mystery. Depending on how a person uses the adapter, putting it in a USB2 port works everytime and is fast enough for most uses. Nick |
|
No worries, thank you for setting up this repo @morrownr. We wouldn't be here if it weren't for your docs! One limitation of the usb2 bus is if want to set up a wireless repeater with 2 adapters. For instance, 300 send +300 receive = 600mbps, which is already greater than the 480mbps limit on the usb2 bus (as it is shared on the rpi4) so one would be limited to 240mbps instead. And sometimes I can even hit 400mbps on a single adapter. This adapter is also the cheapest (even shipping included) so it'd be really nice to find a way to get this working. I think I bought 2 for 36usd (so $18 each) and the others on the list are slightly more, none with the same slim form factor where I can comfortably fit 2 of these adapters right next to each other. With the other adapters it's likely I would also need to buy right angled (90 degree) usb3 adapters as well. I have yet to test it on usb3 port 2 as I was going to run some benchmarks today to test stability after keeping it running for 1-2 days but I suspect results will be the same: unplug/replug to get a new wlanID as a workaround temporarily. I'll report back when I have tested that. |
|
I get what you are saying about USB2 limiting the stream. I wish was not a problem. @amisix is actually the one who discovered the problem. I'm glad he did as I try to do a good job of only putting good adapters on the in-kernel list. Sometimes something slips by for a while. Give it a try in port 2 and see what you get. This is a strange problem. Let us know what you find out. Nick |
|
@Snuupy
I contacted them via AliExpress online chat. They were responsive but uncaring. There was a language barrier which added an additional layer of complexity. I referenced this thread. I was told to use the drivers that come on CD with the adapter (that are 6+ years old). I tried looking around for a contact outside of AliExpress but was unable to find anything. |
When you hear or read this line, you know you are dealing with someone who knows absolutely nothing about Linux. To help correct the situation we really need to support those who support us. That will channel money to those who are doing the better job and it will move the market and make things better for all of us. Right now, the only retailer that I am aware of that does a good job with their Linux customers is Rokland. The only maker that does a reasonably good job is ALFA. Panda used to do a good job of making adapters that use in-kernel drivers available but they are not making any modern adapters in this day in time. I don't know what is going on there. |
@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.
The text was updated successfully, but these errors were encountered: