Info: Status of Realtek out-of-kernel drivers at this time #314
Comments
|
Reported to bugzilla: I decided to add Realtek to the list of "problematic drivers" regarding monitor mode and frame injection: And I fully share your "humble opinion" regarding mt76 drivers/devices. |
|
Some good news. |
|
Thanks for the info. I have not had much success with the in-kernel driver for the rtl8811cu (rtw_8821cu). The version for the rtl8812bu works fairly good except for problems getting into USB3 mode. |
|
@morrownr Please take a look at the issue reports of hcxdumptool (and you can imagine what I mean): BTW: |
I do my best to encourage Linux users to buy adapters that use in-kernel (in-tree) drivers because I've seen the difference in the amount of reported problems over the last 5 years. As you noted, there is a major difference in support between Realtek and Mediatek. With Mediatek, we have access to report bugs and it will be worked by a Mediatek employee as time permits. Mediatek appears to be fully commited to Linux Wireless Standards but Realtek is not. Find a way for us to report problems to Realtek... you can't unless you have connections to an adapter maker or seller as some are able to report bugs but most won't care. I recently brought a new repo online for the rtl8852bu chipset. It took some work but I eventually got the driver in good enough shape that it can work well for some users that have an adapter based on the rtl8852/32bu chipsets in managed mode. However, behind the scenes, I ran into a lot of things that simply do not work. In the README.md, I wrote right up front that basically Linux users should not buy adapters based on these chipset if Mediatek based adapters are available.
I agree with you. Maintenance of the Realtek out-of-kernel drivers is not consist and there are some chipsets that have basically been abandoned. I think my rtl8814au driver is the last standing driver for that chipset. Overall, it is a really bad driver and always has been but I keep it going as best I can.
I've been supporting multiple Realetk out-of-kernel drivers for the last 4-5 years so there is little you can tell me that will surprise me. In fact, I got so tired of answering questions about monitor mode that I made some scripts. Here is the repo: https://github.com/morrownr/Monitor_Mode
USB3 is not mankinds greatest invention. What I have observed is that USB3 capable adapters such as the adapters based on the mt7612u and mt7921au seem to work 100% regarding the use of USB3 mode. The in-kernel driver for the rtl8812bu works depending on the hardware you are on. Since Realtek did not create and does not maintain the usb support, it will depend on someone in the community to figure it out. Given your knowledge, let make sure that you understand that you are always welcome to point out anything that you disagree with on this site. |
|
@morrownr BTW: Just tested one of these drivers: |
|
@morrownr do you think I should just give up on this problem and find a different dual band wifi adaptor for my nethunter build |
|
I see that this driver has not had any updates since March of 21. As far as I can tell, the rtl8814au repo here is the only one getting maintenance. The repo here works with kernel 6.6 and does a decent job with managed and master modes. The Realtek driver is not easy to maintain as the driver was not well done in the first place. The rtl8812au driver is a far better, much more modern driver as far as Realtek out-of-kernel drivers go. It is not clear to me why Realtek did such a poor job on the rtl8814au driver. |
This is a question that I can't answer without more information. I am currently looking at this site: https://www.kali.org/docs/nethunter/ I have some old phones that might work for this but could use your advice as to what features of old phones would work best? Also, of the various options, tell me what you are doing? |
|
@morrownr It compiles fine and it inserts fine: But it looks like the vendor ID of my EDIMAX is missing: |
Isn't the 8812 an earlier model than the 8814? |
|
$ lsusb $ dmesg |
|
I merged a patch for ID 7392:a812. Do a git pull and tell me if that worked. FYI: I am going to do my best to keep support for the rtl8812au chipset going as long as I can because there are so many Linux users that have adapters with this chipset. The driver you see is very good in managed and master modes. It could use some work on monitor mode but that is not an area I am very good at. Also, I have the source for a slightly newer version, which also happened to be the last version produced by Realtek. What I would like to do is round up a small group of people that would like to work with me in a private repo to get it ready to release. I haven't started but can start anytime. It would be really good if we can had a couple of experts on monitor mode that could work on monitor mode while myself and some other work everything else. FYI: if you run 'install-driver.sh' you don't have to worry about uninstalling anything as the script searches for and removes previous installations before compiling and installing. |
Yes, that is correct as far as the 8812au is concerned. There is also a 8812bu that was released at about the same time as the 8814au. The 8812au dates back to around 2013 I think and was very popular. It is a very solid chipset and the out-of-kernel Linux driver, in my opinion, is probably the best out-of-kernel driver Realtek has ever released. |
|
@morrownr |
|
@morrownr |
|
@morrownr |
|
Looks like 8811au support is gone with this driver. |
|
Thanks. Per the post from @maheralbashek3 , it looks like you have an adapter based on the rtl8821au, not the rtl8812au. I will need to revert my patch and direct you to another repo: |
Has been for many years. I try to maintain the latest available versions of the drivers here. |
|
@morrownr |
device is usable by hcxdumtool: Packet injection is working, too: A few problems regarding 5GHz: |
|
I'm thinking it was an old android version I installed patched magilsk coz I couldn't find the correct one android version. Still can't find it. |
|
@morrownr running same regulatory domain: |
|
@morrownr |
|
hcxdumptool stands and falls with the driver. With a "matching" driver, it can do magic. |
I just downloaded and compiled hcxdumptool. A couple of things you posted earlier reminded me that I need to rework the following item om the Main Menu:
I had started that with documents about each adapter which was a mistake. It should be a document for each driver and it appears that your program can deliver what we need, I am open for ideas. It would be good to have the right information in a single place. I do have a wide variety of chipsets available to test. mt7921au |
|
That would be a great idea. BTW: It started with kernel 6.3 (and hit me too) : BTW: You can monitor RTNETLINK/NETLINK activity of "start-mon.sh" by nlmon too. Starting with Linux kernel 6.8, it is finally time to say goodby to WEXT (only) tools (e.g. iwlist, iwconfig and more ...) and to WEXT (only) drivers (and to all outdated tutorials that use this tools, too). |
|
BTW: Nice script, but a little bit oversized for me to run a "quick and dirty" test on a fresh compiled kernel module (driver). |
|
|
I already signed the disclaimer. Another day at the office here. I test until failure around here and I install clean new distros often. Nothing of value will be in harms way. What I could use to get me going if you have time is examples to help me build a single document on each driver showing the capabilities that hcxdumptool can provide. |
Yes, I have been following along as I subscribe to linux-wireless. One of the things that has caught my attention is that starting with WiFi 7, Realtek will have no choice but to retire their out-of-kernel drivers as we know them. Realtek has been doing reasonably well with rtw88 and rtw89 if would appear but that is manned by folks that are not working on usb. Hopefully this change will cause them to change how they do things. |
|
I agree, rtw88 and rtw89 is a good step in the right direction. Usually I test a driver as follows (here: ALFA AWUS036ACM) Set regulatory domain: Stop all services that take access to the device, but do not set monitor mode by third party tools. Retrieve information about the device: Check dmesg if everything is working as expected: Test device is not connected to an USB3 port due to known problems running USB3. Run hcxdumptool to retrieve information about all available devices: Retrieve information about the test device: At this time we have some initial information about driver, frequency range and tx power of the device. Start packet injection test on the physical interface: For this test we use a defined time gap of 2 minutes and scan common channels only. But to be sure we check dmesg again: Some additional notes: At every time, you can run tshark or Wireshark in parallel on the same physical interface to monitor 802.11 traffic. hcxdumptool is available on most of the distributions, e.g. Debian: |
|
@morrownr so I done a factory reset on the phone re rooted reinstalled nethunter and recompiled nethunter project kernel and same outcome. |
|
@axeldog You are on kernel 4.14.234 which means you need the linux-api headers 4.x. uname shows you the kernel version, e.g. in may case: And hcxdumptool shows you the linux api version it is compiled with: You can also use your distribution package manager to get this information, e.g. on Arch Linux: In every case, this version numbers must match to each other: A good explanation (linux-api-headers vs. linux-headers) is here: Depending on the linux-api headers, make compiles functions for a specific kernel version. Now you can imagine what happens when hcxdumptool executes a function on kernel 4.14.234 that is compiled to execute Linunx kernel 6.5.0 code. |
|
Your comment reminded me to add detection of Linux kernel at runtime to hcxdumptool That has been done by this commit: If the major version (e.g. 6.x) does not match, something is wrong with the compiler environment. |
|
BTW: Something funny. I believe Albert Einstein said this: |
|
There's a few different ways to compile the nethunter kernel so hopefully one of them will not be the cyberknight777 kernel. |
|
Problem is not the Linux kernel and problem is not KALI. |
|
so how do i change it to matching versions. when i say compile i mean with the hethunter installer project |
|
I don't use nethunter. Maybe this is a good starting point to get help: |
|
Can't register on kali forum, been trying for months just get this message. "Sorry, registration has been disabled by the administrator" |
|
@axeldog and has been moved to gitlab: Do you know that your kernel is official not supported (as of October 26th)? |
|
Maybe they moved the forums too.
|
|
It a kernel made on the nethunter project yesterday. |
|
@ZerBea I wouldn't know where to start installing kernel from github |
|
@axeldog |
|
@axeldog There are several discussions about nethunter like this one: |
As you know, if you stop by this site periodically, I am a proponent of in-kernel drivers as they are designed to be much more reliable and trouble-free for users of desktop and server distros. However, I do maintain several WiFi 5 and WiFi 6 Realtek out-of-kernel drivers at this site as there are many Linux users, or Windows users that may switch to Linux, that use Realtek based usb wifi adapters.
Here is my take on where the driver situation is for Realtek based usb wifi adapters:
WiFi 5 adapters that Linux users should avoid new purchase of as they are highly likely to be a dead end.
rtl8814au - this chipset will likely never see an in-kernel driver. Realtek out-of-kernel driver development ended in 2019. That driver was not a good driver and is hard to maintain. This chipset is likely a DEAD-END for Linux users and should be avoided.
rtl8812au - this chipset will likely never see an in-kernel driver. Realtek out-of-kernel driver development ended in 2021. The driver I have up is a good driver for an out-of-kernell driver and I have a newer 2021 version of this driver and I want to stand up a new repo based on it if anyone is interested in helping. My intent is to support this chipset as long as possible. However, this chipset is likely a DEAD-END for Linux users so users should avoid new purchases.
rtl8821/11au - this chipset will likely never see an in-kernel driver. Realtek out-of-kernel driver development ended in 2021. My intent is to support this chipset as long as possible. However, this chipset is likely a DEAD-END for Linux users so users should avoid new purchases.
WiFi 5 Realtek adapters that have Linux in-kernel drivers based on the in-kernel rtw88 driver series.
There are other Realtek chipsets that are supported with in-kernel drivers based on the rtw88 driver series but there are issues of one kind or another that cause me to only recommend adapters using the rtl8812bu chipset (as noted above).
WiFi 6 adapters that Linux users should avoid at this time as they are highly likely to be a dead end.
WiFi 6 Realtek based adapters that Linux users may consider if you do not have access to Mediatek adapters and really want WiFi 6. I am not recommending the following chipsets but if you have no choice, these chipsets could work for you long term if Realtek decided to use rtw89 to start supporting these chipsets with an in-kernel driver.
rtl8852/32bu - I have an out-of-kernel driver in a repo here. It is a reasonably good driver at this point and there may be an in-kernel driver at some point in the future based on the in-kernel rtw89 driver series. It is hard to find adapters based on this chipset that are single-state. I have yet to find one. If you are aware of one, let us know.
rtl8852/32cu - I may try to bring up a repo with an out-of-kernel driver for this chipset.
So, bottom line, the only Realtek usb wifi chipset that I currently recommend is the rtl8812bu. Look for an adapter that is single-state.
Where does Realtek go from here? That is not clear at all. I've seen no indications of additional WiFi 6 usb wifi chipsets on the way and I have seen nothing indicating WiFi 7 usb wifi chipsets. On the other hand, Mediatek is in the process of merging their Linux driver support for their new mt7925 (WiFi 7) chipset which will support USB and PCIe. The initial support is set to go into kernel 6.7. This, as usual, will be a fully Linux Wireless Standards compliant driver.
Of note: Linux contains code that will prevent WiFi 7 drivers from operating unless they are fully Linux Standards Compliant drivers. What is Realtek going to do? That is unclear. What is clear is that it will be the end of the Realtek out-of-kernel drivers as we know them.
For WiFi 5 and later USB WiFi adapters, the best chipsets, in my humble opinion, are currently:
...and we are looking forward to see what the mt7925 has to offer.
Cheers,
@morrownr
The text was updated successfully, but these errors were encountered: