Info: Status of Realtek out-of-kernel drivers at this time

[morrownr]

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.

• rtl8822/12bu - as of kernel 6.2, an in-kernel driver is available for this chipset. I have been testing it and it is pretty good. If you live in a part of the world where your options are limited to adapters based on Realtek chipsets, the rtl8812bu chipset is the one you want and you should research and test to ensure you get an adapter that is single-state (no onboard Windows driver) and single-function (no bluetooth) as those options will make for the most stable and trouble-free setup.

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.

• rtl8852/32au - I worked for over a year to stand up a repo with an out-of-kernel driver for this chipset. It was a terrible driver and I suspect silicone problems in the design so please AVOID adapters based on this chipset.

---

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:

• mt7921au
• mt7612u
• rtl8812bu
• mt7610u

...and we are looking forward to see what the mt7925 has to offer.

Cheers,

@morrownr

[ZerBea]

Reported to bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=218040

I decided to add Realtek to the list of "problematic drivers" regarding monitor mode and frame injection: https://github.com/ZerBea/hcxdumptool/commit/6298b7875b75a79b37579b003cb87935fe0cbb94

And I fully share your "humble opinion" regarding mt76 drivers/devices.

[ZerBea]

Some good news. Looks like frame injection on rtw88 Linux stock kernel (rtw_8821ce) is working again (kernel 6.6-rc7): https://bugzilla.kernel.org/show_bug.cgi?id=218040#c7

[morrownr]

@ZerBea

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.

[ZerBea]

@morrownr My experience (as a coder/developer) is a little different. There are hundreds of drivers outside in the wildness (git). Some users expect that hcxdumptool works on every driver. That is not the case. I decided to give support only on Linux stock drivers because I'm tired to wrestle with third party drivers. I admit, some of them are well maintained, but most of them not. On problems caused by Linux stock drivers, we can discuss this on bugzilla (or the wireless mailing list) and we can expect a fix, soon.

Please take a look at the issue reports of hcxdumptool (and you can imagine what I mean): https://github.com/ZerBea/hcxdumptool/issues?q=is%3Aissue+is%3Aclosed Nearly all reports (problems) are related to third party drivers. That include reports related to KALI, because this distribution included third party drivers, too.

BTW: Depending on the hardware, this USB3 problem is really ugly and mostly unfixed since a long time. The entire code is very complex. After diving into the code, I don't expect a quick fix.

[morrownr]

I decided to give support only on Linux stock drivers because I'm tired to wrestle with third party drivers.

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 decided to give support only on Linux stock drivers because I'm tired to wrestle with third party drivers.

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.

Please take a look at the issue reports of hcxdumptool (and you can imagine what I mean):

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

Depending on the hardware, this USB3 problem is really ugly and mostly unfixed since a long time. The entire code is very complex. After diving into the code, I don't expect a quick fix.

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

[ZerBea]

@morrownr Thanks for this information and the invitation.

BTW: I'm in contact with Christian (kimocoder): https://github.com/kimocoder/realtek_rtwifi https://github.com/aircrack-ng/rtl8812au https://github.com/aircrack-ng/rtl8814au

Just tested one of these drivers: https://github.com/ZerBea/hcxdumptool/issues/355#issuecomment-1782871637

[axeldog]

@morrownr do you think I should just give up on this problem and find a different dual band wifi adaptor for my nethunter build

[morrownr]

@ZerBea

https://github.com/aircrack-ng/rtl8814au

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.

[morrownr]

@axeldog

do you think I should just give up on this problem and find a different dual band wifi adaptor for my nethunter build?

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?

[ZerBea]

@morrownr Unfortunately I can't test this driver: https://github.com/morrownr/8812au-20210629

It compiles fine and it inserts fine:

[40909.162141] RTW: rtl8812au v5.13.6-15-gc40b977e2.20210629
[40909.162187] usbcore: registered new interface driver rtl8812au

But it looks like the vendor ID of my EDIMAX is missing:

$ lsusb
Bus 001 Device 012: ID 7392:a812 Edimax Technology Co., Ltd [unknown]

$ dmesg
[40936.646320] usb 1-9.3: new high-speed USB device number 12 using xhci_hcd
[40936.772364] usb 1-9.3: New USB device found, idVendor=7392, idProduct=a812, bcdDevice= 2.00
[40936.772368] usb 1-9.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40936.772370] usb 1-9.3: Product: Edimax AC600 USB
[40936.772372] usb 1-9.3: Manufacturer: Realtek
[40936.772374] usb 1-9.3: SerialNumber: 00e04c000001

[bjlockie]

The rtl8812au driver is a far better, much more modern driver as far as Realtek out-of-kernel drivers go.

Isn't the 8812 an earlier model than the 8814?

[maheralbashek3]

$ lsusb Bus 001 Device 012: ID 7392:a812 Edimax Technology Co., Ltd [unknown]

$ dmesg [40936.646320] usb 1-9.3: new high-speed USB device number 12 using xhci_hcd [40936.772364] usb 1-9.3: New USB device found, idVendor=7392, idProduct=a812, bcdDevice= 2.00 [40936.772368] usb 1-9.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [40936.772370] usb 1-9.3: Product: Edimax AC600 USB [40936.772372] usb 1-9.3: Manufacturer: Realtek [40936.772374] usb 1-9.3: SerialNumber: 00e04c000001

[morrownr]

@ZerBea

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.

[morrownr]

@bjlockie

Isn't the 8812 an earlier model than the 8814?

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.

[ZerBea]

@morrownr I don't think that adding the vendor ID will work on that device, but I give it a try.

[ZerBea]

@morrownr Chipset of the Edimax EW-7811UAC is an 8811au.

[ZerBea]

@morrownr Thanks for your effort. But, as expected, It doesn't work:

[43540.817118] RTW: rtl8812au v5.13.6-15-gc40b977e2.20210629
[43540.817167] usbcore: registered new interface driver rtl8812au
[43540.817169] RTW: module init ret=0
[43550.245075] usb 1-9.3: new high-speed USB device number 15 using xhci_hcd
[43550.367751] usb 1-9.3: New USB device found, idVendor=7392, idProduct=a812, bcdDevice= 2.00
[43550.367756] usb 1-9.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[43550.367759] usb 1-9.3: Product: Edimax AC600 USB
[43550.367761] usb 1-9.3: Manufacturer: Realtek
[43550.367763] usb 1-9.3: SerialNumber: 00e04c000001

[ZerBea]

Looks like 8811au support is gone with this driver.

[morrownr]

@maheralbashek3

Thanks.

@ZerBea

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:

https://github.com/morrownr/8821au-20210708

[morrownr]

@ZerBea

Looks like 8811au support is gone with this driver.

Has been for many years. I try to maintain the latest available versions of the drivers here.

[ZerBea]

@morrownr Thanks. I'll give it a try.

[ZerBea]

@morrownr

Looking better, now:
[46956.286508] RTW: rtl8821au v5.12.5.2-0-g70054197b.20210708_COEX20190509-6d6f
[46956.286510] RTW: rtl8821au BT-Coex version = COEX20190509-6d6f
[46956.286573] usbcore: registered new interface driver rtl8821au
[46956.286574] RTW: module init ret=0
[46961.200409] usb 1-9.3: new high-speed USB device number 16 using xhci_hcd
[46961.326488] usb 1-9.3: New USB device found, idVendor=7392, idProduct=a812, bcdDevice= 2.00
[46961.326496] usb 1-9.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[46961.326499] usb 1-9.3: Product: Edimax AC600 USB
[46961.326501] usb 1-9.3: Manufacturer: Realtek
[46961.326503] usb 1-9.3: SerialNumber: 00e04c000001
[46965.973685] RTW: HW EFUSE
[46965.973693] RTW: 0x000: 29 81 00 7C  01 00 01 00  4C 00 04 00  10 00 00 00  
[46965.973710] RTW: 0x010: 20 20 20 20  20 20 28 28  28 29 29 F0  FF FF FF FF  
[46965.973726] RTW: 0x020: FF FF 2C 2B  2A 29 2E 2C  2A 29 28 27  29 2A 29 28  
[46965.973742] RTW: 0x030: 01 FF FF FF  FF FF CC FF  FF FF FF FF  FF FF FF FF  
[46965.973758] RTW: 0x040: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.973773] RTW: 0x050: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.973789] RTW: 0x060: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.973804] RTW: 0x070: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.973820] RTW: 0x080: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.973835] RTW: 0x090: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.973851] RTW: 0x0A0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.973866] RTW: 0x0B0: FF FF FF FF  FF FF FF FF  42 0B 1E 00  00 00 FF 00  
[46965.973882] RTW: 0x0C0: FF 08 00 FF  00 00 00 55  00 FF FF FF  FF FF FF FF  
[46965.973897] RTW: 0x0D0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.973913] RTW: 0x0E0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.973929] RTW: 0x0F0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.973944] RTW: 0x100: 92 73 12 A8  FF FF 03 74  DA 38 06 45  E7 09 03 52  
[46965.973960] RTW: 0x110: 65 61 6C 74  65 6B 12 03  45 64 69 6D  61 78 20 41  
[46965.973975] RTW: 0x120: 43 36 30 30  20 55 53 42  00 FF FF FF  FF FF FF FF  
[46965.973991] RTW: 0x130: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.974006] RTW: 0x140: FF FF FF FF  FF FF FF 0F  FF FF FF FF  FF FF FF FF  
[46965.974022] RTW: 0x150: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.974037] RTW: 0x160: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.974053] RTW: 0x170: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.974068] RTW: 0x180: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.974084] RTW: 0x190: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.974099] RTW: 0x1A0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.974115] RTW: 0x1B0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.974130] RTW: 0x1C0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.974146] RTW: 0x1D0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.974161] RTW: 0x1E0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.974177] RTW: 0x1F0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[46965.976672] RTW: hal_com_config_channel_plan chplan:0x42
[46966.018682] RTW: [RF_PATH] ver_id.RF_TYPE:RF_1T1R
[46966.018688] RTW: [RF_PATH] HALSPEC's rf_reg_trx_path_bmp:0x11, rf_reg_path_avail_num:1, max_tx_cnt:1
[46966.018691] RTW: [RF_PATH] PG's trx_path_bmp:0x00, max_tx_cnt:0
[46966.018692] RTW: [RF_PATH] Registry's trx_path_bmp:0x00, tx_path_lmt:0, rx_path_lmt:0
[46966.018694] RTW: [RF_PATH] HALDATA's trx_path_bmp:0x11, max_tx_cnt:1
[46966.018695] RTW: [RF_PATH] HALDATA's rf_type:RF_1T1R, NumTotalRFPath:1
[46966.018697] RTW: [TRX_Nss] HALSPEC - tx_nss:1, rx_nss:1
[46966.018698] RTW: [TRX_Nss] Registry - tx_nss:0, rx_nss:0
[46966.018699] RTW: [TRX_Nss] HALDATA - tx_nss:1, rx_nss:1
[46966.018701] RTW: txpath=0x1, rxpath=0x1
[46966.018703] RTW: txpath_1ss:0x1, num:1
[46966.019032] RTW: rtw_regsty_chk_target_tx_power_valid return _FALSE for band:0, path:0, rs:0, t:-1
[46966.019538] RTW: rtw_ndev_init(wlan0) if1 mac_addr=74:da:38:06:45:e7
[46966.037442] rtl8821au 1-9.3:1.0 wlp22s0f0u9u3: renamed from wlan0
[47031.894049] usb 1-9.3: USB disconnect, device number 16
[47031.894467] RTW: rtw_ndev_uninit(wlp22s0f0u9u3) if1
[47031.977407] rtl8821au 1-9.3:1.0: Runtime PM usage count underflow!
[47033.927638] usb 1-9.3: new high-speed USB device number 17 using xhci_hcd
[47034.054206] usb 1-9.3: New USB device found, idVendor=7392, idProduct=a812, bcdDevice= 2.00
[47034.054214] usb 1-9.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[47034.054216] usb 1-9.3: Product: Edimax AC600 USB
[47034.054219] usb 1-9.3: Manufacturer: Realtek
[47034.054221] usb 1-9.3: SerialNumber: 00e04c000001

device is usable by hcxdumtool:

$ hcxdumptool -L

Requesting physical interface capabilities. This may take some time.
Please be patient...

available wlan devices:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  3   6 74da380645e7 74da380645e7 + wlp22s0f0u9u3    rtl8821au (NETLINK)

* active monitor mode available
+ monitor mode available
- no monitor mode available

bye-bye

Packet injection is working, too:

$ sudo hcxdumptool --rcascan=active

110 packet(s) captured
51 RESPONSE(s) received

exit on sigterm
bye-bye

A few problems regarding 5GHz:

$ hcxdumptool -I wlp22s0f0u9u3

Requesting physical interface capabilities. This may take some time.
Please be patient...

interface information:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  3   6 74da380645e7 74da380645e7 + wlp22s0f0u9u3    rtl8821au (NETLINK)

available frequencies: frequency [channel] tx-power of Regulatory Domain: DE

  2412 [  1] 16.0 dBm     2417 [  2] 16.0 dBm     2422 [  3] 16.0 dBm     2427 [  4] 16.0 dBm
  2432 [  5] 16.0 dBm     2437 [  6] 16.0 dBm     2442 [  7] 16.0 dBm     2447 [  8] 16.0 dBm
  2452 [  9] 16.0 dBm     2457 [ 10] 16.0 dBm     2462 [ 11] 16.0 dBm     2467 [ 12] 16.0 dBm
  2472 [ 13] 16.0 dBm     2484 [ 14] disabled     5180 [ 36] 13.0 dBm     5200 [ 40] 13.0 dBm
  5220 [ 44] 13.0 dBm     5240 [ 48] 13.0 dBm     5260 [ 52] disabled     5280 [ 56] disabled
  5300 [ 60] disabled     5320 [ 64] disabled     5500 [100] disabled     5520 [104] disabled
  5540 [108] disabled     5560 [112] disabled     5580 [116] disabled     5600 [120] disabled
  5620 [124] disabled     5640 [128] disabled     5660 [132] disabled     5680 [136] disabled
  5700 [140] disabled     5720 [144] disabled     5745 [149] disabled     5765 [153] disabled
  5785 [157] disabled     5805 [161] disabled     5825 [165] disabled     5845 [169] disabled
  5865 [173] disabled     5885 [177] disabled

bye-bye

[axeldog]

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.

[ZerBea]

@morrownr Compared to rtl88xxau driver:

[47356.834348] usbcore: registered new interface driver rtl88XXau
[47361.493527] usb 1-9.3: new high-speed USB device number 19 using xhci_hcd
[47361.619790] usb 1-9.3: New USB device found, idVendor=7392, idProduct=a812, bcdDevice= 2.00
[47361.619801] usb 1-9.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[47361.619803] usb 1-9.3: Product: Edimax AC600 USB
[47361.619806] usb 1-9.3: Manufacturer: Realtek
[47361.619808] usb 1-9.3: SerialNumber: 00e04c000001
[47366.268961] usb 1-9.3: 88XXau 74:da:38:06:45:e7 hw_info[107]
[47366.324635] rtl88XXau 1-9.3:1.0 wlp22s0f0u9u3: renamed from wlan0

running same regulatory domain:

$ hcxdumptool -I wlp22s0f0u9u3

Requesting physical interface capabilities. This may take some time.
Please be patient...

interface information:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  4   7 74da380645e7 74da380645e7 + wlp22s0f0u9u3    rtl88XXau (NETLINK)

available frequencies: frequency [channel] tx-power of Regulatory Domain: DE

  2412 [  1] 20.0 dBm     2417 [  2] 20.0 dBm     2422 [  3] 20.0 dBm     2427 [  4] 20.0 dBm
  2432 [  5] 20.0 dBm     2437 [  6] 20.0 dBm     2442 [  7] 20.0 dBm     2447 [  8] 20.0 dBm
  2452 [  9] 20.0 dBm     2457 [ 10] 20.0 dBm     2462 [ 11] 20.0 dBm     2467 [ 12] 20.0 dBm
  2472 [ 13] 20.0 dBm     2484 [ 14] 20.0 dBm     5075 [ 15] 30.0 dBm     5080 [ 16] 30.0 dBm
  5085 [ 17] 30.0 dBm     5090 [ 18] 30.0 dBm     5100 [ 20] 30.0 dBm     5120 [ 24] 30.0 dBm
  5140 [ 28] 30.0 dBm     5160 [ 32] 23.0 dBm     5180 [ 36] 23.0 dBm     5200 [ 40] 23.0 dBm
  5220 [ 44] 23.0 dBm     5240 [ 48] 23.0 dBm     5260 [ 52] 20.0 dBm     5280 [ 56] 20.0 dBm
  5300 [ 60] 20.0 dBm     5320 [ 64] 20.0 dBm     5340 [ 68] 20.0 dBm     5360 [ 72] 30.0 dBm
  5380 [ 76] 30.0 dBm     5400 [ 80] 30.0 dBm     5420 [ 84] 30.0 dBm     5440 [ 88] 30.0 dBm
  5460 [ 92] 30.0 dBm     5480 [ 96] 26.0 dBm     5500 [100] 26.0 dBm     5520 [104] 26.0 dBm
  5540 [108] 26.0 dBm     5560 [112] 26.0 dBm     5580 [116] 26.0 dBm     5600 [120] 26.0 dBm
  5620 [124] 26.0 dBm     5640 [128] 26.0 dBm     5660 [132] 26.0 dBm     5680 [136] 26.0 dBm
  5700 [140] 26.0 dBm     5720 [144] 13.0 dBm     5745 [149] 13.0 dBm     5765 [153] 13.0 dBm
  5785 [157] 13.0 dBm     5805 [161] 13.0 dBm     5825 [165] 13.0 dBm     5845 [169] 13.0 dBm
  5865 [173] 13.0 dBm     5885 [177] 30.0 dBm

bye-bye

[ZerBea]

@morrownr Slightly more packets captured and more RESPONSEs on our PROBEREQUESTs received:

$ sudo hcxdumptool --rcascan=active
...
216 packet(s) captured
69 RESPONSE(s) received

[ZerBea]

hcxdumptool stands and falls with the driver. With a "matching" driver, it can do magic. But with an unmatching driver it will fail epically. It would be great to get this driver working, too.

[morrownr]

@ZerBea

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:

3. iw_list - Adapter technical information

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 mt7612u mt7610u my7601u (doesn't anything but managed mode) rtl8832bu rtl8812bu rtl8811cu rtl8812au rtl8811au rtl8814au Various others that are WiFi 4 and some that are pre-WiFi 4 but this site really concentrates on what is available to buy right now.

[ZerBea]

That would be a great idea.

BTW: With kernel 6.8, a new game begins: "The plan is to kill off all PCMCIUA WiFi drivers as well as all WEXT users within drivers/net/wireless. " https://www.phoronix.com/news/Linux-Old-WiFi-Removal-Plan

It started with kernel 6.3 (and hit me too) : https://github.com/aircrack-ng/aircrack-ng/discussions/2543 But now, hcxdumptool is state of the art, running RTNETLINK and NETLINK (NL80211). All its activities can be directly monitored by tshark or Wireshark (running on the same physical interface). Additional a NETLINK monitor can be activated to monitor (by tshark or Wireshark) the communication between hcxdumptool and the driver. NETLINK monitor mode:

$ sudo ip link add  nlmon0 type nlmon
$ sudo ip link set dev nlmon0 up

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).

[ZerBea]

BTW: 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.

Nice script, but a little bit oversized for me to run a "quick and dirty" test on a fresh compiled kernel module (driver). I'm not a friend of "all in one" scripts within a test environment, because it makes it very hard to hunt for a bug.

[ZerBea]

I just downloaded and compiled hcxdumptool. Please use it with care. By default it is aggressive as hell: https://github.com/ZerBea/hcxdumptool/issues/246

[morrownr]

Please use it with care. By default it is aggressive as hell: ZerBea/hcxdumptool#246

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.

[morrownr]

With kernel 6.8, a new game begins:

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.

[ZerBea]

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: $ sudo iw reg set DE

Stop all services that take access to the device, but do not set monitor mode by third party tools. That is important, because hcxdumptool detect the capability to run e.g. active monitor mode and use it. I'm running Arch Linux and I know exactly what services are running and what services should be terminated:

$ sudo systemctl stop NetworkManager.service
$ sudo systemctl stop wpa_supplicant.service

Retrieve information about the device:

$ lsusb
Bus 001 Device 008: ID 0e8d:7612 MediaTek Inc. MT7612U 802.11a/b/g/n/ac Wireless Adapter

Check dmesg if everything is working as expected:

$ dmesg
[43566.482580] usb 1-9.3: new high-speed USB device number 8 using xhci_hcd
[43566.612674] usb 1-9.3: New USB device found, idVendor=0e8d, idProduct=7612, bcdDevice= 1.00
[43566.612682] usb 1-9.3: New USB device strings: Mfr=2, Product=3, SerialNumber=4
[43566.612685] usb 1-9.3: Product: Wireless 
[43566.612687] usb 1-9.3: Manufacturer: MediaTek Inc.
[43566.612689] usb 1-9.3: SerialNumber: 000000000
[43566.845463] usb 1-9.3: reset high-speed USB device number 8 using xhci_hcd
[43566.966649] mt76x2u 1-9.3:1.0: ASIC revision: 76120044
[43567.550708] mt76x2u 1-9.3:1.0: ROM patch build: 20141115060606a
[43567.886466] mt76x2u 1-9.3:1.0: Firmware Version: 0.0.00
[43567.886472] mt76x2u 1-9.3:1.0: Build: 1
[43567.886474] mt76x2u 1-9.3:1.0: Build Time: 201507311614____
[43571.085407] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[43571.086080] usbcore: registered new interface driver mt76x2u
[43571.102484] mt76x2u 1-9.3:1.0 wlp22s0f0u9u3: renamed from wlan0

Test device is not connected to an USB3 port due to known problems running USB3.

Run hcxdumptool to retrieve information about all available devices:

$ hcxdumptool -L
Requesting physical interface capabilities. This may take some time.
Please be patient...

available wlan devices:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0   3 00c0ca42a46a 00c0ca42a46a * wlp22s0f0u9u3    mt76x2u (NETLINK)

* active monitor mode available
+ monitor mode available
- no monitor mode available

bye-bye

Retrieve information about the test device:

$ hcxdumptool -I wlp22s0f0u9u3
Requesting physical interface capabilities. This may take some time.
Please be patient...

interface information:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0   3 00c0ca42a46a 00c0ca42a46a * wlp22s0f0u9u3    mt76x2u (NETLINK)

available frequencies: frequency [channel] tx-power of Regulatory Domain: DE

  2412 [  1] 20.0 dBm     2417 [  2] 20.0 dBm     2422 [  3] 20.0 dBm     2427 [  4] 20.0 dBm
  2432 [  5] 20.0 dBm     2437 [  6] 20.0 dBm     2442 [  7] 20.0 dBm     2447 [  8] 20.0 dBm
  2452 [  9] 20.0 dBm     2457 [ 10] 20.0 dBm     2462 [ 11] 20.0 dBm     2467 [ 12] 20.0 dBm
  2472 [ 13] 20.0 dBm     2484 [ 14] disabled     5180 [ 36] 20.0 dBm     5200 [ 40] 20.0 dBm
  5220 [ 44] 20.0 dBm     5240 [ 48] 20.0 dBm     5260 [ 52] 20.0 dBm     5280 [ 56] 20.0 dBm
  5300 [ 60] 20.0 dBm     5320 [ 64] 20.0 dBm     5500 [100] 20.0 dBm     5520 [104] 20.0 dBm
  5540 [108] 20.0 dBm     5560 [112] 20.0 dBm     5580 [116] 20.0 dBm     5600 [120] 20.0 dBm
  5620 [124] 20.0 dBm     5640 [128] 20.0 dBm     5660 [132] 20.0 dBm     5680 [136] 20.0 dBm
  5700 [140] 20.0 dBm     5720 [144] 13.0 dBm     5745 [149] 13.0 dBm     5765 [153] 13.0 dBm
  5785 [157] 13.0 dBm     5805 [161] 13.0 dBm     5825 [165] 13.0 dBm     5845 [169] 13.0 dBm
  5865 [173] 13.0 dBm

bye-bye

At this time we have some initial information about driver, frequency range and tx power of the device. This highly depend on the wireless regulatory domain settings, which are fully respected by hcxdumtpool. The impact of regulatory domain settings is huge.

Start packet injection test on the physical interface:

$ sudo hcxdumptool -i wlp22s0f0u9u3 --rcascan=active --tot=2
Requesting physical interface capabilities. This may take some time.
Please be patient...

interface information:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0   3 00c0ca42a46a b4e1eba643a5 * wlp22s0f0u9u3    mt76x2u (NETLINK)

available frequencies: frequency [channel] tx-power of Regulatory Domain: DE

  2412 [  1] 20.0 dBm     2417 [  2] 20.0 dBm     2422 [  3] 20.0 dBm     2427 [  4] 20.0 dBm
  2432 [  5] 20.0 dBm     2437 [  6] 20.0 dBm     2442 [  7] 20.0 dBm     2447 [  8] 20.0 dBm
  2452 [  9] 20.0 dBm     2457 [ 10] 20.0 dBm     2462 [ 11] 20.0 dBm     2467 [ 12] 20.0 dBm
  2472 [ 13] 20.0 dBm     2484 [ 14] disabled     5180 [ 36] 20.0 dBm     5200 [ 40] 20.0 dBm
  5220 [ 44] 20.0 dBm     5240 [ 48] 20.0 dBm     5260 [ 52] 20.0 dBm     5280 [ 56] 20.0 dBm
  5300 [ 60] 20.0 dBm     5320 [ 64] 20.0 dBm     5500 [100] 20.0 dBm     5520 [104] 20.0 dBm
  5540 [108] 20.0 dBm     5560 [112] 20.0 dBm     5580 [116] 20.0 dBm     5600 [120] 20.0 dBm
  5620 [124] 20.0 dBm     5640 [128] 20.0 dBm     5660 [132] 20.0 dBm     5680 [136] 20.0 dBm
  5700 [140] 20.0 dBm     5720 [144] 13.0 dBm     5745 [149] 13.0 dBm     5765 [153] 13.0 dBm
  5785 [157] 13.0 dBm     5805 [161] 13.0 dBm     5825 [165] 13.0 dBm     5845 [169] 13.0 dBm
  5865 [173] 13.0 dBm

scan frequencies: frequency [channel] of Regulatory Domain: DE

  2412 [  1]      2437 [  6]      2462 [ 11]

This is a highly experimental penetration testing tool!
It is made to detect vulnerabilities in your NETWORK mercilessly!

BPF is unset! Make sure hcxdumptool is running in a 100% controlled environment!

Initialize main scan loop...
...
421 packet(s) captured
218 RESPONSE(s) received

exit on TOT
bye-bye

For this test we use a defined time gap of 2 minutes and scan common channels only. If we got some (more or less) responses, we know packet injection is working as expected.

But to be sure we check dmesg again:

$ sudo dmesg
44886.638695] mt76x2u 1-9.3:1.0 wlp22s0f0u9u3: entered promiscuous mode
[44939.811805] mt76x2u 1-9.3:1.0 wlp22s0f0u9u3: left promiscuous mode

Some additional notes: In every case hcxdumptool retrieve the hardware MAC (00c0ca42a46a) from the device via RTNETLINK message. A third party tool like ethtool is not necessary. To prevent counter measures against it, hcxdumptool use a randomized MAC (b4e1eba643a5) as source MAC. Third party tools like macchanger are useless. The rcascan (Radio and Channel Assignment scan) is an active scan active (transmit PROBEREQUESTs and receive PROBERESPONSEs).

At every time, you can run tshark or Wireshark in parallel on the same physical interface to monitor 802.11 traffic. Additional you can active the NETLINK monitor to monitor internal RTNETLINK and NETLINK messages between hcxdumptool and the driver.

hcxdumptool is available on most of the distributions, e.g. Arch Linux https://archlinux.org/packages/extra/x86_64/hcxdumptool/

e.g. Debian: https://packages.debian.org/bookworm/hcxdumptool

[axeldog]

@morrownr so I done a factory reset on the phone re rooted reinstalled nethunter and recompiled nethunter project kernel and same outcome.

[ZerBea]

@axeldog If you compile modules or tools which are close to the kernel (like hcxdumptool), it is mandatory that the installed linux-api-headers match to the installed kernel. If not, the modules do not compile and the compiled tools are not working as expected.

You are on kernel 4.14.234 which means you need the linux-api headers 4.x. Latest kali comes with linux-api-headers 6.5.0, e.g. linux-headers-6.5.0-kali3-amd64. https://pkg.kali.org/pkg/linux These headers do not match to the installed kernel and you have to build an environment (tool chain) for kernel 4.14.x.

uname shows you the kernel version, e.g. in may case:

$ uname -r
6.5.9-arch2-1

And hcxdumptool shows you the linux api version it is compiled with:

$ hcxdumptool -v
hcxdumptool 6.3.1-72-gb680a88 (C) 2023 ZeroBeat
compiled by gcc 13.2.1
compiled with Linux API headers 6.4.0
compiled with glibc 2.38

You can also use your distribution package manager to get this information, e.g. on Arch Linux:

$ pacman -Q | grep linux
linux 6.5.9.arch2-1
linux-api-headers 6.4-1
linux-headers 6.5.9.arch2-1

In every case, this version numbers must match to each other:

linux 6.5.9 == linux headers 6.5.9
linux 6.x == linux api-headers 6.x

A good explanation (linux-api-headers vs. linux-headers) is here: https://bbs.archlinux.org/viewtopic.php?id=258173

Depending on the linux-api headers, make compiles functions for a specific kernel version. e.g. on linux api headers >= 5.x this special code will be compiled: https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L36

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.

[ZerBea]

@axeldog

Your comment reminded me to add detection of Linux kernel at runtime to hcxdumptool

$ hcxdumptool -v
hcxdumptool 6.3.1-74-gf75a357 (C) 2023 ZeroBeat
running on Linux kernel 6.5.9-arch2-1
compiled by gcc 13.2.1
compiled with Linux API headers 6.4.0
compiled with glibc 2.38

That has been done by this commit: https://github.com/ZerBea/hcxdumptool/commit/f75a357161c791cb6b91041ab5c41b626681b156

If the major version (e.g. 6.x) does not match, something is wrong with the compiler environment.

[ZerBea]

BTW: https://github.com/morrownr/USB-WiFi/issues/314#issuecomment-1786095094

Something funny. I believe Albert Einstein said this: The definition of insanity is doing the same thing over and over and expecting different results. While coding new functions, exactly this happens very often to me too.

[axeldog]

There's a few different ways to compile the nethunter kernel so hopefully one of them will not be the cyberknight777 kernel.

[ZerBea]

Problem is not the Linux kernel and problem is not KALI. If you decide to compile something, you need the header files, matching to your kernel. That is not the case. Exactly this is your problem: https://unix.stackexchange.com/questions/730644/how-to-install-kenel-headers-for-the-kernel-linux-headers-4-14-0-xilinx-in-deb

[axeldog]

so how do i change it to matching versions. when i say compile i mean with the hethunter installer project

[ZerBea]

I don't use nethunter. Maybe this is a good starting point to get help: https://forums.kali.org/forumdisplay.php?14-NetHunter-Forums

[axeldog]

Can't register on kali forum, been trying for months just get this message. "Sorry, registration has been disabled by the administrator"

[ZerBea]

@axeldog The git hub is closed, too: https://github.com/offensive-security/kali-nethunter

and has been moved to gitlab: https://gitlab.com/kalilinux/nethunter/build-scripts/kali-nethunter-project

Do you know that your kernel is official not supported (as of October 26th)? https://stats.nethunter.com/kernels.html

[bjlockie]

Maybe they moved the forums too.

[axeldog]

It a kernel made on the nethunter project yesterday.

[axeldog]

@ZerBea I wouldn't know where to start installing kernel from github

[ZerBea]

@axeldog I'm out of ideas, too, because I neither use KALI nor nethunter. Desktop, notebooks and netbooks are running Arch Linux and the Raspberries (first generation, mostly Zero) are running Raspbian OS Lite (because Arch has removed armv6 support).

[ZerBea]

@axeldog a good starting point could be this https://xdaforums.com/

There are several discussions about nethunter like this one: https://xdaforums.com/t/rom-unofficial-nethunter-oneplus-8t-android-11-12-26-08-21.4324555/page-11