New 8821au driver v5.12.5.2-0-g70054197b.20210708 #1
Comments
|
I have this new driver up and running on one of my spare arm64 boards (currently running kernel v5.15-rc2). I submitted a pull request for a few changes needed to get it going (#2). So far all is well! If I get time tonight I will make a build for v5.14.7 and try it on one of my production systems as well. |
|
@morrownr - I wanted to see what you think about modifying the default driver Kconfig to "select WIRELESS_EXT" by default. This way the config ensures that the "iw" tools work nicely with the driver. (I do this locally in my version, and have not submitted a PR for this change as I'm not sure it's something you want to do by default in your version - just a small suggestion.) |
|
@5kft - I merged the pull request. I appreciate you working the issues out there on the bleeding edge. Hopefully we can catch any big issues before the general public finds the repo. I am not going to put a link in the old repo until we have a few days to test. My testing so far has been pretty positive. I had to bring a couple of old patches over but there is some definite improvement as I have not had to patch anything regarding master mode and it seems to be working very well here. Please do submit a PR for the Kconfig patch when able. Nick |
|
Glad to help! (And apologies that this is really bleeding-edge at the moment...) So far, it's working great. Will leave it transferring data randomly for several hours. |
|
No problem with the bleeding edge as long as you hang in there and test it like it needs to be tested. I'm testing basic function and compiling on older kernels so this can work out well. If you see anything that could work better a different way, bring it on. I am also trying to bring a new driver for the 8812au online. It is a bigger challenge as I have to turn monitor mode on, or get roasted by the crowd that uses that driver, and it has to work right or I will get roasted. The good thing with the 8812au is that the current repo I have up is actually a really good driver so no need to be in a big hurry with it. This 8811au driver has a few issues so getting new version up is more pressing. The real disaster, as far as Realtek drivers are concerned, is the 8814au. The driver in my 8814au repo is the latest known code but it is from 2019 and it was a bad release. I've had a lot of help from the guys who hang out at that repo and we have got it to where it mostly works but is hard to maintain. |
|
Quick update - this new driver seems to work great! I've been running it on two systems under both 5.15-rc2 and 5.14.7 (the latter is a "production" device that gets a lot of network activity), and have had no issues whatsoever...very nice! In general I've had really poor luck with so many of my Realtek adapters under Linux. Then I came across the Netis WF2180 and it has worked flawlessly for me. So...as a result I now have a number of WF2180s in use - they have been working great for me for a couple of years now. For the sake of completeness, in terms of platform testing for the README for this driver, I've been using your 8821au driver under Debian 10 Buster and Debian 11 Bullseye. |
|
I have used this new driver in AP mode with my Alfa ACS (8811au) for the last day. I used 80MHz channel width for 5GHz. Actually I tested all widths but it spent the most time at 80 so as to push and see if it could hang in there. The result is that I have not seen a single problem in AP mode. I was using a RasPi4B with 32 bit RasPiOS and hostapd. I am becoming more and more impressed with this driver. Most Realtek drivers are bad once you try something other than managed mode but this new driver is working well. I am adding Debian 11 to the README since you are testing with it. Are you going to use Debian 11 to test WPA3? |
Agreed (still zero issues in managed mode, multiple devices)
Yes (will test this weekend) |
morrownr
changed the title
|
Can I get you to recheck the PR you submitted regarding the patches for k5.15? I merged it but was doing a crosscheck this evening and it appears several needed changes are missing. |
|
Yes, it's okay - for this new one I just included the removal of the deprecated IPX protocol-related code. I didn't bother including the "inline" keyword removal - that seems to have been included in the original patch for the mainline 8188 driver as part of a number of cleanup/optimization changes, and is not needed for kernel v5.15. |
|
Okay. Copy all. I am testing managed mode now as well as installation on various distros. I'd like to set a goal of wrapping up the release by the middle of next week if possible as I have other drivers that need my attention. I do have some ideas about updates to the README so I'll look at that. Would you be interested in being named the Primary Maintainer of this repo? I have other repos and I really need some help and since you have multiple adapters with 8811au chipsets that you support, maybe you are interested in helping take some of the load off of me with this repo? Let me know. |
|
I just submitted the PR for WPA3 support (#4) - an issues thread in your other tree was very helpful for this (morrownr/88x2bu#47)! I encountered the same behavior with this new 8821au driver, and the resolution was ultimately the same. I appreciate the consideration re: the Maintainer question, but unfortunately I don't have bandwidth...sincere apologies... I am of course happy to continue to contribute as much as I can. Thank you so much for all of your efforts here! |
I remember that thread but I went back to read it again. Yes, this driver and the earlier version have the code to support WPA3. I discontinued working toward getting support in earlier versions because, well, what the hell? Clone the current master of wpa_supplicant and compile it? Sure. If you get it working and find a way that does not include trying to turn grandma into a coder, I'm all for it. I try to help folks out but Realtek is the real problem. Once you get beyond basic managed mode with these Reltek drivers, things become an adventure more often than not. I also have and use adapters based on in-kernel drivers and the difference is big. Master and monitor modes, as well as WPA3 and other things just work. You will notice that I have not activated monitor mode in this driver... and I have no intention to do so. Okay. Rank mode off.
I really appreciate the help. Right now I am little frustrated. I worked on the new 8812au code some today. There are problems. These Realtek drivers do not come with any docs at all so everything takes a lot of time. I may end up putting it aside for a few days so as to reduce frastration. We'll see. |
Yes, I totally hear you 😊 However the good news is that getting WPA3 to work with this driver is actually quite easy, given it works right off with the Debian "experimental" (current "top-of-tree") wpasupplicant package - no patching/building required. (E.g., this is far less arduous than with the Cypress FMAC driver, which requires a large number of patches on the vanilla v2.9 hostap source, config tweaks, etc.) Thanks again for all of your efforts here, it's really nice how you've put together this collection of working drivers. Again, hugely appreciated! |
For you and me, it may be easy but the philosophy I use for running this site is that I must keep things simple enough for the average new Linux user to follow while not getting in the way of the more advanced user. What I won't do at this point is add WPA3 activation instructions to the basic installation instructions. I will add a statement in a FAQ pointing out what needs to be done for the advanced user that wants the capability. I have some questions since you are testing WPA3. Are the changes to the Makefile required when testing Debian "experimental"? Is the only reason Debian "experimental" is working is because it is using the current "top-of-the-tree" wpa_supplicant instead of v2.9? How do you think WPA3 support should be handled in the README given what you know?
You are welcome and I appreciate the testing and input you are providing. My goal when starting this site was to get usb wifi on Linux to the point that it "just works" and I think some progress has been made. There is a lot of work to do though. A big part of the strategy is the USB-WiFi repo that shows users that there are good adapters out there that use Standards Compliant in-kernel drivers. I am of the opinion that most Linux users would see better results from using adapters that use in-kernel drivers but there are new users and some existing users that have Realtek based adapters that need support that "just works" so I will continue to do my best along with the help I get as long as I am able. |
Yes, this makes sense.
No Makefile changes are needed.
That would be my guess - the package changelog indicates that this uses a new "upstream snapshot" (see https://metadata.ftp-master.debian.org/changelogs//main/w/wpa/wpa_2.9.0+git20210909+a75fdcd-1_changelog), and there have been a lot of patches made of late in the supplicant (see https://w1.fi/cgit/hostap/log/ )...so something was included that makes it work.
It's a great question...perhaps you should clearly caveat that any guidance provided is clearly "unsupported and is for advanced users only", etc.? The reality is that right now this is nowhere near plug-and-play, at least not until a much newer wpasupplicant is released that includes the necessary changes. Unfortunately I found that in bringing up WPA3 on my Broadcom modules yesterday, it appears that wpasupplicant isn't as abstracted yet from the underlying wireless driver as much it really needs to be (e.g., Cypress makes a lot of patches to v2.9). While the Debian "experimental" wpasupplicant package happens to work, I can't speak to how one would do this for RPi, or Ubuntu, etc. I first brought WPA3 up by manually patching the vanilla v2.9 wpa_supplicant source (using the patches referred in the other thread - in particular morrownr/88x2bu#47 (comment)), but then found that the mainline was updated with the necessary changes when I gave it a try. I think that this all falls in the "here are some pointers for you to figure it out, but you are on your own" category...? |
I that case, I am going to revert the previous changes to the Makefile. Keeping things clean as we go is a good idea.
That would be my guess also. I have other pressing projects to press on with right now. I can come back, investigate and document it later.
I agree, WPA3 is still nowhere near plug-and-play for these Realtek drivers. The code is in the drivers but patches to wpa_supplicant are required and have only been made in the wpa_supplican repo but have not shown up in an releases yet.
It has been several months since I checked WPA3 support for the build-in wifi on a RasPi. It didn't work but I did not investigate as I always disable the built-in wifi. I'm not fan of the RasPi built-in wifi. So, for folks that think they must have WPA3 right now, as far as dual band USB adapters are concerned, they have multiple options... Mediatek and Mediatek. That is a little joke but it is true. https://github.com/morrownr/USB-WiFi In case you have a need, the following cheap little adapter does WPA3. In fact, it is plug-n-play and my guess is that it has about the same range as the Netis adapters you have. https://www.amazon.com/Cable-Matters-Dual-Band-Wireless-Adapter/dp/B00ZQ0C4KI One last issue: As this new driver stands right now, I have left out 2 features that the old version had.
I'm not sure LED control matters for the 8821au and I have seen nobody using monitor mode. Both are important, especially monitor mode, with other drivers but not this one if I am correct. Leaving monitor mode out will save me a lot of headaches. Your thoughts on the issues? |
Apologies, what I meant was that no further Makefile changes were needed as of the latest Makefile for this driver that was checked in this morning (i.e., including my PR changes). Everything that was there was good - you shouldn't revert those changes.
Wow, cheap! But large (nice thing about the Netis is that they are relatively small)...
The LED works on my adapters with this driver, although I haven't tried the option to try turning it off yet (not sure why I would want to turn it off). I actually haven't used monitor mode since forever - seems like it'd be fine to defer work there and see if any requests for it come in, then you can decide what to do? |
Opps. I made the change before seeing this reply. We have the note here and the previous PR so I can put it back in when needed. How about for now we do a freeze and see what kind of reports we get?
There are smaller ones based on the mt7610u. https://www.amazon.com/Linksys-Wireless-Mini-Adapter-AE6000/dp/B00BWT1IFE The AE6000 is tiny and has pretty darn good range for being little more than the size of a nano adapter. Darn the price. You could get these for a good price but the market is all messed up these days.
My point exactly which is why I did not add the code this time. It is a desired feature on 3 of the other drivers so I will keep it in those.
Just what I was thinking. It seems folks with this chipset only use managed and master modes so that is less to maintain as far as I am concerned. I'm already working on the new driver for the 8812au chipset now. It has to have monitor mode. I'm having nightmares already. Realtek does a crap job supporting monitor mode so wish me luck. |
Personally, if it were up to me I'd keep all of the submitted changes from my PRs, but I'm probably biased 😊. The big one is the debug log level, but you already noticed that...
Interesting, the price is crazy but I appreciate the pointer. I'll look more into these at some point. |
I need to slow down. I try to maintain 5 Realtek drivers and the repo with info about adapters that use in-kernel drivers and it can be a load. I hope to finish some documentation updates on this driver today so that I can fully concentrate on getting the new 8812au driver out the door.
The prices of a lot of adapters have gone crazy. There is one AC600 adapter that was not cheap in the first place but the price has not risen: I have one of those. If you have a use case where range is important, look at this adapter. It has the longest range of any usb wifi adapter I have ever owned. |
|
@5kft @akmalkady @Pajkastare I am seeing traffic to this repo increase and we are not seeing any bug reports. That is probably a good sign. Are y'all seeing any issues? |
|
Been using it on a couple of arm64 devices 24x7 for a month now (client mode), no issues. |
|
I've been using it as an access point using I have not managed to enable the AP on a DFS channel that is tagged "radar detection". |
I decided to test this issue this evening. What I found is that DFS support is working here. This message is going through my 8811au adapter in AP mode on channel 60 which is definitely DFS here in the US. What I did find, that was causing big problems, was that this driver and adapter do not support SU Beamformer. I have merged changes to reflect this. If you have SU Beamformer turned on in hostapd.conf or in 8821au.conf, make the appropriate mods and see if you still have a problem. I guess I made the mistake because the new 8812au does support SU Beamformer and I have been bringing both up at the same time. |
Good to hear. I went ahead and took down the previous version yesterday. It was not a terrible driver this is a much better driver. The old URL is now just basically a link to this driver so everyone coming to this site for a driver will be using this version. As you probably noticed, I had made a coding mistake on the LED control support but I think that is fixed now. Can I get you to test all 3 options for the LED control support as you have time? Regards |
I tested all three options (off/activity/on) and they work fine with my adapter - nice work! |
Good. Thanks for the report. Functionality is mostly working the way we want in this driver now so I am going to work on the docs. Come get me if there is a big problem! Regards |
|
And I got my AP to work in DFS channels as well (I also switched off everything beamforming-related but I don't really know if it's related), and my adapter does not have any LEDs, so everything seems to work as it should now. Thanks for all the support and effort! |
That is good. Thanks for the report.
I'm going to take another look at beamforming. I know it is a hot mess in general but maybe some folks can make something of it... but it might be best if it off by default.
You are welcome. Stop by anytime. I'm closing this issue. |
Request that you test and report any problems. Specific bugs should be reported by opening a new issue. Discussion can go here.
Nick
The text was updated successfully, but these errors were encountered: