[GH-ISSUE #56 ] [Bug]: Error! Bad return status for module build on kernel: 6.16.7-arch1-1 (x86_64) #51

Author

Owner

@morrownr commented on GitHub (Sep 15, 2025):

Hi @princeri

This driver won't compile on kernel 6.16 because it should not need to compile on any distro using kernel 6.14 or later. Did you check to see if your adapter was working before you tried to install this driver?

A very solid rtl8812au standards compliant driver was added to the kernel with kernel 6.14. Try running the following:

$ sudo sh remove-driver.sh

After reboot, see what you have.

@morrownr commented on GitHub (Sep 15, 2025): Hi @princeri This driver won't compile on kernel 6.16 because it should not need to compile on any distro using kernel 6.14 or later. Did you check to see if your adapter was working before you tried to install this driver? A very solid rtl8812au standards compliant driver was added to the kernel with kernel 6.14. Try running the following: $ sudo sh remove-driver.sh After reboot, see what you have.

bsakaguchi commented

Author

Owner

@cybersnow02 commented on GitHub (Sep 21, 2025):

Also, I renamed 'remove-driver.sh' to 'uninstall-driver.sh'. Take this into consideration if applying my patch.

@cybersnow02 commented on GitHub (Sep 21, 2025): Also, I renamed 'remove-driver.sh' to 'uninstall-driver.sh'. Take this into consideration if applying my patch.

bsakaguchi commented

Author

Owner

@morrownr commented on GitHub (Sep 21, 2025):

@cybersnow02

Thanks for the information. I have no problems with users continuing to keep this driver going with API related PRs. What I would like instead on one patch is 3 PRs. One for kernel 15, one for kernel 16 and one for the change to uninstall. That will allow me to check things in a more orderly way.

I don't like the fact that newer kernels won't be supported anymore for this driver project.

I understand but I have to make the best use of the time that I have available. Like I said, this repo can live as long as users make the API updates.

The main problem with rtw88 (see lwfinger/rtw88#111) is that we cannot adjust the txpower anymore (higher value).

Have you actually checked to see if txpower can actually be adjusted to a higher value with this driver? I'm not talking about the output of iw, I am talking about checking levels to see if the change is actually being made.

I wrote a message in lwfinger/rtw88#111 a while ago in an effort to start consolidating what we know about txpower. You are welcome to participate in this effort.

@morrownr commented on GitHub (Sep 21, 2025): @cybersnow02 Thanks for the information. I have no problems with users continuing to keep this driver going with API related PRs. What I would like instead on one patch is 3 PRs. One for kernel 15, one for kernel 16 and one for the change to uninstall. That will allow me to check things in a more orderly way. > I don't like the fact that newer kernels won't be supported anymore for this driver project. I understand but I have to make the best use of the time that I have available. Like I said, this repo can live as long as users make the API updates. > The main problem with rtw88 (see lwfinger/rtw88#111) is that we cannot adjust the txpower anymore (higher value). Have you actually checked to see if txpower can actually be adjusted to a higher value with this driver? I'm not talking about the output of `iw`, I am talking about checking levels to see if the change is actually being made. I wrote a message in lwfinger/rtw88#111 a while ago in an effort to start consolidating what we know about txpower. You are welcome to participate in this effort.

bsakaguchi commented

Author

Owner

@princeri commented on GitHub (Sep 22, 2025):

Hi @princeri

This driver won't compile on kernel 6.16 because it should not need to compile on any distro using kernel 6.14 or later. Did you check to see if your adapter was working before you tried to install this driver?

A very solid rtl8812au standards compliant driver was added to the kernel with kernel 6.14. Try running the following:

$ sudo sh remove-driver.sh

After reboot, see what you have.

after uninstalling the driver it uses the
readlink /sys/class/net/wlan0/device/driver

../../../../../../bus/usb/drivers/rtw88_8821au

this driver has problem where the packet inject doesn't works sometime....
also unable to find wifi networs when in monitor mode

the 8812au was working absolutely fine....

@princeri commented on GitHub (Sep 22, 2025): > Hi [@princeri](https://github.com/princeri) > > This driver won't compile on kernel 6.16 because it should not need to compile on any distro using kernel 6.14 or later. Did you check to see if your adapter was working before you tried to install this driver? > > A very solid rtl8812au standards compliant driver was added to the kernel with kernel 6.14. Try running the following: > > $ sudo sh remove-driver.sh > > After reboot, see what you have. after uninstalling the driver it uses the readlink /sys/class/net/wlan0/device/driver ../../../../../../bus/usb/drivers/rtw88_8821au this driver has problem where the packet inject doesn't works sometime.... also unable to find wifi networs when in monitor mode the 8812au was working absolutely fine....

bsakaguchi commented

1__patch_actual_main_kernel_6.14_to_6.15.patch
2__patch_kernel_6.15_to_6.16.patch
3__patch_uninstall.patch

Author

Owner

@cybersnow02 commented on GitHub (Sep 22, 2025):

@morrownr I made incremental patches in 3 steps:

Actual main to Kernel 6.15
Kernel 6.15 to Kernel 6.16
Uninstall patch (do not forget to rename file 'remove-driver.sh' to 'uninstall-driver.sh')

The 'uninstall' patch idea was taken from your other project (https://github.com/morrownr/rtl8852bu-20240418). By now, I could just try to focus on Kernel patch instead of non-urgent mods? I tried to follow your code changes between projects to match what it should be now...

@cybersnow02 commented on GitHub (Sep 22, 2025): @morrownr I made incremental patches in 3 steps: - Actual main to Kernel 6.15 - Kernel 6.15 to Kernel 6.16 - Uninstall patch (do not forget to rename file 'remove-driver.sh' to 'uninstall-driver.sh') The 'uninstall' patch idea was taken from your other project (https://github.com/morrownr/rtl8852bu-20240418). By now, I could just try to focus on Kernel patch instead of non-urgent mods? I tried to follow your code changes between projects to match what it should be now... [1__patch_actual_main_kernel_6.14_to_6.15.patch](https://github.com/user-attachments/files/22475960/1__patch_actual_main_kernel_6.14_to_6.15.patch) [2__patch_kernel_6.15_to_6.16.patch](https://github.com/user-attachments/files/22475961/2__patch_kernel_6.15_to_6.16.patch) [3__patch_uninstall.patch](https://github.com/user-attachments/files/22475962/3__patch_uninstall.patch)

bsakaguchi commented

Author

Owner

@morrownr commented on GitHub (Sep 24, 2025):

@cybersnow02

So the rtw88 enforce the regulation and cannot be modified (for higher values than 20dBm).

Is -20 dBm the maximum allowable txpower setting for your country and channel you are using? If unsure, tell me your country and band/channel you are using and I will show you how to look it up.

With that said, if -20 dBm is the max allowed, then rtw88 is doing its job correctly as it should not allow you to exceed the max allowed by law. If the rtl8812au driver is allowing you to exceed the max allowed txpower, then that needs to be corrected or the driver taken down.

I'm sure that is not what you want to hear but I am pretty good at helping with cases when range needs to be extended... legally.

@morrownr commented on GitHub (Sep 24, 2025): @cybersnow02 > So the rtw88 enforce the regulation and cannot be modified (for higher values than 20dBm). Is -20 dBm the maximum allowable txpower setting for your country and channel you are using? If unsure, tell me your country and band/channel you are using and I will show you how to look it up. With that said, if -20 dBm is the max allowed, then rtw88 is doing its job correctly as it should not allow you to exceed the max allowed by law. If the rtl8812au driver is allowing you to exceed the max allowed txpower, then that needs to be corrected or the driver taken down. I'm sure that is not what you want to hear but I am pretty good at helping with cases when range needs to be extended... legally.

bsakaguchi commented

Author

Owner

@princeri commented on GitHub (Sep 24, 2025):

Hi @morrownr and @princeri

I made a patch so this 8812au driver will work with Kernel 6.15 and 6.16. I don't like the fact that newer kernels won't be supported anymore for this driver project. The main problem with rtw88 (see lwfinger/rtw88#111) is that we cannot adjust the txpower anymore (higher value). So I request that @morrownr continue to update this driver until they find out a solution. Anyway, I tested my patch and it works perfectly under Debian 13 Trixie with Backport kernel 6.16.

@morrownr : can you integrate this patch to main code?

patch_kernel_6.16.patch

Can you please share me your patched version 8812au driver.

@princeri commented on GitHub (Sep 24, 2025): > Hi [@morrownr](https://github.com/morrownr) and [@princeri](https://github.com/princeri) > > I made a patch so this 8812au driver will work with Kernel 6.15 and 6.16. I don't like the fact that newer kernels won't be supported anymore for this driver project. The main problem with rtw88 (see [lwfinger/rtw88#111](https://github.com/lwfinger/rtw88/issues/111)) is that we cannot adjust the txpower anymore (higher value). So I request that [@morrownr](https://github.com/morrownr) continue to update this driver until they find out a solution. Anyway, I tested my patch and it works perfectly under Debian 13 Trixie with Backport kernel 6.16. > > [@morrownr](https://github.com/morrownr) : can you integrate this patch to main code? > > [patch_kernel_6.16.patch](https://github.com/user-attachments/files/22454137/patch_kernel_6.16.patch) Can you please share me your patched version 8812au driver.

bsakaguchi commented

Author

Owner

@morrownr commented on GitHub (Sep 24, 2025):

@cybersnow02

If you are interested, I can give you admin rights to this repo so that you can take over maintenance of this repo. This might be the best solution. I would ask you to consider your changes carefully as I have numerous Realtek WiFi 5 vendor drivers up here and it is best if they work in a consistent manner. An example of what I am talking about is the change from remove to uninstall. I understand the desire as I am the one that made that change starting with the Realtek WiFi 6 drivers... however I do not think it is a good change for WiFi 5 at this point as keeping things consistent would require the change in all drivers and in the docs and in the mind of all current users... and this is a repo that gets a lot of hits per day. I will leave things alone as far as API changes go as long as you don't break things but other things that can lead to a lot of message traffic is something to avoid.

What do you think?

@morrownr commented on GitHub (Sep 24, 2025): @cybersnow02 If you are interested, I can give you admin rights to this repo so that you can take over maintenance of this repo. This might be the best solution. I would ask you to consider your changes carefully as I have numerous Realtek WiFi 5 vendor drivers up here and it is best if they work in a consistent manner. An example of what I am talking about is the change from `remove` to `uninstall`. I understand the desire as I am the one that made that change starting with the Realtek WiFi 6 drivers... however I do not think it is a good change for WiFi 5 at this point as keeping things consistent would require the change in all drivers and in the docs and in the mind of all current users... and this is a repo that gets a lot of hits per day. I will leave things alone as far as API changes go as long as you don't break things but other things that can lead to a lot of message traffic is something to avoid. What do you think?

bsakaguchi commented

Author

Owner

@cybersnow02 commented on GitHub (Sep 24, 2025):

@morrownr

I just want to contribute by sending patches if able to fix it with my current skills :) I do not want to take over maintenance of this repo.

I have a question for you. You said : "I understand but I have to make the best use of the time that I have available". Then, you seem to abandon this project because you prefer the RTW88 alternative since 8812au in now included with the kernel. But, by looking of the work you do with RTL8852BU, you could easily backports the same kind of fixes in 10 minutes like I did, since they are compatible. When the 8852BU will be included in the future kernel, are you going to stop maintaining it as well? I mean, for now, the kernel changes aren't too complicated to justify not supporting it anymore. What I'm doing right now is trying to help you with patches to save you some time. You could then just approve patches from users and add them to the repo?

@cybersnow02 commented on GitHub (Sep 24, 2025): @morrownr I just want to contribute by sending patches if able to fix it with my current skills :) I do not want to take over maintenance of this repo. I have a question for you. You said : "I understand but I have to make the best use of the time that I have available". Then, you seem to abandon this project because you prefer the RTW88 alternative since 8812au in now included with the kernel. But, by looking of the work you do with RTL8852BU, you could easily backports the same kind of fixes in 10 minutes like I did, since they are compatible. When the 8852BU will be included in the future kernel, are you going to stop maintaining it as well? I mean, for now, the kernel changes aren't too complicated to justify not supporting it anymore. What I'm doing right now is trying to help you with patches to save you some time. You could then just approve patches from users and add them to the repo?

bsakaguchi commented

Author

Owner

@cybersnow02 commented on GitHub (Sep 24, 2025):

@princeri
To apply patches, you can follow this guide:
https://www.cyberciti.biz/faq/appy-patch-file-using-patch-command/

@cybersnow02 commented on GitHub (Sep 24, 2025): @princeri To apply patches, you can follow this guide: https://www.cyberciti.biz/faq/appy-patch-file-using-patch-command/

bsakaguchi commented

Author

Owner

@cybersnow02 commented on GitHub (Sep 24, 2025):

By the way, I just realized that I made the patches according to the following commit in February 21, 2025. So before applying my patches, download the right commit main code: github.com/morrownr/8812au-20210820@dabcb74da6

At this stage, it already included the Kernel 6.14 patches. thanks

@cybersnow02 commented on GitHub (Sep 24, 2025): By the way, I just realized that I made the patches according to the following commit in February 21, 2025. So before applying my patches, download the right commit main code: https://github.com/morrownr/8812au-20210820/commit/dabcb74da670a12ca74125588bc89aa8ad086c13 At this stage, it already included the Kernel 6.14 patches. thanks

bsakaguchi commented

Author

Owner

@morrownr commented on GitHub (Sep 24, 2025):

I just realized that I made the patches according to the following commit in February 21, 2025. So before applying my patches

I think you are making this harder than it needs to be. If you want me to merged the patches, make PR requests. That will speed things up on my end and eliminate some potential problems. Remember to git pull so that your repo is at the same level before doing anything.

So that there is no confusion:

I have a question for you. You said : "I understand but I have to make the best use of the time that I have available". Then, you seem to abandon this project because you prefer the RTW88 alternative since 8812au in now included with the kernel. But, by looking of the work you do with RTL8852BU, you could easily backports the same kind of fixes in 10 minutes like I did, since they are compatible. When the 8852BU will be included in the future kernel, are you going to stop maintaining it as well?

Absolutely I am going to stop maintaining the rtl8852bu repo. In fact, the new rtw89 driver for the rtl8952bu chip just went into kernel 6.17. I will probably stop maintaining it and rtl8852cu with the kernel that goes into Ubuntu 26.04. I am aware of user needs and try to accommodate a transition period. I also leave the repos available and accepted PRs tfrom users that want the drivers available for future kernels. The alternative is that I make two clicks and remove the repos from public viability.

What you may not understand is that the Realtek USB vendor drivers are bad in many ways. They are not designed for end users. They are designed for embedded purposes. The Linux development cycle makes it where out-of-kernel , non-standards compliant drivers are very problematic. I have put in many hours over the last several years trying to make the Realtek vendor drivers as user friendly as possible but there are basic limits. The new drivers that we are making are Linux standards compliant drivers (mac80211) and are handled the way Linux drivers should be handled... in-kernel with coordination done in linux-wireless. I CANNOT over emphasize how much better the new drivers are. You have a very specific case for the reason you want this driver to be maintained. I would much prefer that you move to rtw88 and I will be glad to work with you to find a solution to your problem.

@morrownr commented on GitHub (Sep 24, 2025): > I just realized that I made the patches according to the following commit in February 21, 2025. So before applying my patches I think you are making this harder than it needs to be. If you want me to merged the patches, make PR requests. That will speed things up on my end and eliminate some potential problems. Remember to git pull so that your repo is at the same level before doing anything. So that there is no confusion: > I have a question for you. You said : "I understand but I have to make the best use of the time that I have available". Then, you seem to abandon this project because you prefer the RTW88 alternative since 8812au in now included with the kernel. But, by looking of the work you do with RTL8852BU, you could easily backports the same kind of fixes in 10 minutes like I did, since they are compatible. When the 8852BU will be included in the future kernel, are you going to stop maintaining it as well? Absolutely I am going to stop maintaining the rtl8852bu repo. In fact, the new rtw89 driver for the rtl8952bu chip just went into kernel 6.17. I will probably stop maintaining it and rtl8852cu with the kernel that goes into Ubuntu 26.04. I am aware of user needs and try to accommodate a transition period. I also leave the repos available and accepted PRs tfrom users that want the drivers available for future kernels. The alternative is that I make two clicks and remove the repos from public viability. What you may not understand is that the Realtek USB vendor drivers are bad in many ways. They are not designed for end users. They are designed for embedded purposes. The Linux development cycle makes it where out-of-kernel , non-standards compliant drivers are very problematic. I have put in many hours over the last several years trying to make the Realtek vendor drivers as user friendly as possible but there are basic limits. The new drivers that we are making are Linux standards compliant drivers (mac80211) and are handled the way Linux drivers should be handled... in-kernel with coordination done in linux-wireless. I CANNOT over emphasize how much better the new drivers are. You have a very specific case for the reason you want this driver to be maintained. I would much prefer that you move to rtw88 and I will be glad to work with you to find a solution to your problem.

bsakaguchi commented

Author

Owner

@cybersnow02 commented on GitHub (Sep 25, 2025):

I used another antenna and my TX is working fine now (antenna was broken) and this driver respect the regulation. thanks.

@cybersnow02 commented on GitHub (Sep 25, 2025): I used another antenna and my TX is working fine now (antenna was broken) and this driver respect the regulation. thanks.

bsakaguchi commented

Author

Owner

@morrownr commented on GitHub (Sep 25, 2025):

@princeri

I am willing to work with you if you decide to start using the new rtw88 driver. I think you will find the new driver to be quite good.

@morrownr commented on GitHub (Sep 25, 2025): @princeri I am willing to work with you if you decide to start using the new rtw88 driver. I think you will find the new driver to be quite good.

bsakaguchi commented

Author

Owner

@walmis commented on GitHub (Oct 2, 2025):

I've been experiencing some issues with rtw88 on Kernel 6.16 (Archer T4UH Wi-Fi dongle):

5 GHz Wi-Fi instability: Frequent disconnections; dmesg shows repeated CLASS3_FRAME_FROM_NONASSOC_STA messages.
macvtap broken: Guests using libvirt/QEMU can no longer access the local network directly.

Just my perspective as a user - my previous 8812au setup was stable for several years without these issues.
Thanks to these patches, I can roll back to 8812au and continue using my existing hardware.

@walmis commented on GitHub (Oct 2, 2025): I've been experiencing some issues with **rtw88 on Kernel 6.16** (Archer T4UH Wi-Fi dongle): * **5 GHz Wi-Fi instability:** Frequent disconnections; `dmesg` shows repeated `CLASS3_FRAME_FROM_NONASSOC_STA` messages. * **macvtap broken:** Guests using libvirt/QEMU can no longer access the local network directly. Just my perspective as a user - my previous **8812au setup was stable for several years** without these issues. Thanks to these patches, I can roll back to 8812au and continue using my existing hardware.

bsakaguchi commented