Bug 216746 - RTL8192EU Wifi Dongle (Tenda U1) not working (authentication timed out) with rtl8xxxu module.
Summary: RTL8192EU Wifi Dongle (Tenda U1) not working (authentication timed out) with ...
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-27 07:05 UTC by Jun ASAKA
Modified: 2022-12-27 01:59 UTC (History)
3 users (show)

See Also:
Kernel Version: 6.1.0-rc6
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg (5.15 KB, text/plain)
2022-11-27 07:05 UTC, Jun ASAKA
Details

Description Jun ASAKA 2022-11-27 07:05:11 UTC
Created attachment 303302 [details]
dmesg

The Tenda U1 Wifi dongle (RTL8192EU chip) not working with the rtl8xxxu module in the kernel v6.1.0-rc6 (not work on v5.19.8 as well).
  The linux distribution I'm using is Fedora 37 on intel x86 laptop, with a self-compiled kernel v6.1.0-rc6. The dmesg messages attached below reminded me "authentication with 14:3d:f2:ca:97:80 timed out" which may be the key of this issue. Also, I tried to use the dongle on a ARMv7 single-board computer (Arch linux ARM installed with kernel v5.19.8), just got the same error messages on it.
  But it works fine with other drivers (e.g. https://github.com/Mange/rtl8192eu-linux-driver). So I think it's indeed an issue caused by rtl8xxxu module.
  By the way, I noticed that an Bug (ID: 196796: https://bugzilla.kernel.org/show_bug.cgi?id=196769) was published in Bugzilla reporting the same issue, but the given patches not work for me.
  Please bring out some solutions towards it, and I will help as much as possible.

Thanks and regards,
Jun ASAKA.
Comment 1 petardimicmain 2022-12-03 21:41:13 UTC
Can confirm bug happening on Tenda U1 WiFi dongle with RTL8192EU chip, also not working with WNP-UA300P-01 also having RTL8192EU chip.
Comment 2 petardimicmain 2022-12-03 22:55:41 UTC
Manage to fix it with installing:

https://aur.archlinux.org/packages/rtl8192eu-dkms

Since I use CachyOS I had to install linux-cachyos-headers, if you use vanilla go with linux-headers.


Working for around 1 hour with no problems so far. :)
Comment 3 Jun ASAKA 2022-12-04 08:22:10 UTC
(In reply to petardimicmain from comment #2)
> Manage to fix it with installing:
> 
> https://aur.archlinux.org/packages/rtl8192eu-dkms
> 
> Since I use CachyOS I had to install linux-cachyos-headers, if you use
> vanilla go with linux-headers.
> 
> 
> Working for around 1 hour with no problems so far. :)

Thanks for your reply.
I noticed that the dkms package you've mentioned is actually built from https://github.com/Mange/rtl8192eu-linux-driver which is a patched realtek official driver and it's works fine with my device.
As a consequense, the reason why the rtl8192eu dongles cannot work without the realtek official driver came from the bug of rtl8xxxu module in the kernel which I am digging on.

Cheers,
Jun ASAKA.
Comment 4 rtl8821cerfe2 2022-12-15 21:40:59 UTC
After looking at the code and trying all sorts of things for several days with no results, I finally tried some older kernel versions, because this used to work around 2016. ubuntu-16.10-desktop-i386.iso with kernel 4.8.0 works, ubuntu-17.04-desktop-i386.iso with kernel 4.9.? does not work. One of the commits from September 2016 probably broke it:

https://github.com/torvalds/linux/commits/master?before=041fae9c105ae342a4245cf1e0dc56a23fbb9d3c+105&branch=master&path%5B%5D=drivers&path%5B%5D=net&path%5B%5D=wireless&path%5B%5D=realtek&path%5B%5D=rtl8xxxu&qualified_name=refs%2Fheads%2Fmaster

https://github.com/torvalds/linux/commits/master?after=041fae9c105ae342a4245cf1e0dc56a23fbb9d3c+104&branch=master&path%5B%5D=drivers&path%5B%5D=net&path%5B%5D=wireless&path%5B%5D=realtek&path%5B%5D=rtl8xxxu&qualified_name=refs%2Fheads%2Fmaster
Comment 5 Jun ASAKA 2022-12-16 01:02:41 UTC
(In reply to rtl8821cerfe2 from comment #4)
> After looking at the code and trying all sorts of things for several days
> with no results, I finally tried some older kernel versions, because this
> used to work around 2016. ubuntu-16.10-desktop-i386.iso with kernel 4.8.0
> works, ubuntu-17.04-desktop-i386.iso with kernel 4.9.? does not work. One of
> the commits from September 2016 probably broke it:
> 
> https://github.com/torvalds/linux/commits/
> master?before=041fae9c105ae342a4245cf1e0dc56a23fbb9d3c+105&branch=master&path
> %5B%5D=drivers&path%5B%5D=net&path%5B%5D=wireless&path%5B%5D=realtek&path%5B%
> 5D=rtl8xxxu&qualified_name=refs%2Fheads%2Fmaster
> 
> https://github.com/torvalds/linux/commits/
> master?after=041fae9c105ae342a4245cf1e0dc56a23fbb9d3c+104&branch=master&path%
> 5B%5D=drivers&path%5B%5D=net&path%5B%5D=wireless&path%5B%5D=realtek&path%5B%5
> D=rtl8xxxu&qualified_name=refs%2Fheads%2Fmaster

Thanks for your help. Actually, I am doing the same research as you did and I'll keep on doing this. Thanks again for your information.

Jun ASAKA.
Comment 6 rtl8821cerfe2 2022-12-16 20:21:21 UTC
Well, I thought it was a really simple and silly mistake, like "u16 val32;" (I did that recently), but I didn't expect this:

diff --git a/rtl8xxxu_8192e.c b/rtl8xxxu_8192e.c
index fea4c4d..3b5c0a1 100644
--- a/rtl8xxxu_8192e.c
+++ b/rtl8xxxu_8192e.c
@@ -1735,6 +1735,9 @@ static void rtl8192e_enable_rf(struct rtl8xxxu_priv *priv)
 	val8 = rtl8xxxu_read8(priv, REG_PAD_CTRL1);
 	val8 &= ~BIT(0);
 	rtl8xxxu_write8(priv, REG_PAD_CTRL1, val8);
+
+	rtl8xxxu_write8(priv, REG_TXPAUSE, 0x00);
+
 }
 
 static s8 rtl8192e_cck_rssi(struct rtl8xxxu_priv *priv, u8 cck_agc_rpt)



When you plug in the device, something (mac80211?) calls rtl8xxxu_start(), then rtl8xxxu_stop(), then rtl8xxxu_start() again. rtl8xxxu_stop() sets REG_TXPAUSE to 0xff (disables all transmissions) and then nothing sets it back to 0.
Comment 7 Jun ASAKA 2022-12-17 03:13:32 UTC
(In reply to rtl8821cerfe2 from comment #6)
> Well, I thought it was a really simple and silly mistake, like "u16 val32;"
> (I did that recently), but I didn't expect this:
> 
> diff --git a/rtl8xxxu_8192e.c b/rtl8xxxu_8192e.c
> index fea4c4d..3b5c0a1 100644
> --- a/rtl8xxxu_8192e.c
> +++ b/rtl8xxxu_8192e.c
> @@ -1735,6 +1735,9 @@ static void rtl8192e_enable_rf(struct rtl8xxxu_priv
> *priv)
>       val8 = rtl8xxxu_read8(priv, REG_PAD_CTRL1);
>       val8 &= ~BIT(0);
>       rtl8xxxu_write8(priv, REG_PAD_CTRL1, val8);
> +
> +     rtl8xxxu_write8(priv, REG_TXPAUSE, 0x00);
> +
>  }
>  
>  static s8 rtl8192e_cck_rssi(struct rtl8xxxu_priv *priv, u8 cck_agc_rpt)
> 
> 
> 
> When you plug in the device, something (mac80211?) calls rtl8xxxu_start(),
> then rtl8xxxu_stop(), then rtl8xxxu_start() again. rtl8xxxu_stop() sets
> REG_TXPAUSE to 0xff (disables all transmissions) and then nothing sets it
> back to 0.

Hi.
Thanks for your reply.
I've compared the code with other modules yesterday and figured out that this operation is missing for 8192e chip just like what you pointed out. Then I test the amended code and it works fine for me.
I just submitted the code to Linux Wireless Mailing list to figure out if it's fine for the other rtl8192eu devices.

Cheers!
Jun ASAKA.
Comment 8 Jun ASAKA 2022-12-27 01:59:31 UTC
Fixed by patch c6015bf3ff1f applied to wireless-next. https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/commit/?id=c6015bf3ff1ffb3caa27eb913797438a0fc634a0

Note You need to log in before you can comment on or make changes to this bug.