Clarification...

The error occur when trying to use either one of the two Realtek USB Wifi adapters

    0bda:0179 (rtl8188eu) USB Wifi adapter,

or

    0bda:f179 (rtl8188fu) USB Wifi adapter

Not using both of them at the same time.  Each of them load up the rtl8xxxu kernel module.

Same problem with manually compiled from source downloaded from kernel.org, kernel 6.3.1

(In reply to dbnusr495 from comment #0)
> Dear Maintainer,
> 
> 
> * What led up to the situation?
> * What was the outcome of this action?
> 
> With Debian Sid, trying to use two different Realtek USB Wifi Adapters (with
> Antenna).
> 
> Using kernels including various Liquorix 6.2.x, 6.3.x , and the most recent
> 
>     linux-image-6.3.4-1-liquorix-amd64
> 
> also, Debian experimental
> 
>     Debian (experimental) linux-image-6.3.0-0-amd64-unsigned
> 6.3.5-1~exp1
> 
>     Debian's linux-image-6.3.0-0-amd64 (Linux  6.3.0-0-amd64 #1 SMP
> PREEMPT_DYNAMIC Debian 6.3.2-1~exp1 (2023-05-15) x86_64 GNU/Linux)
> 
> same problem.
> 
> At local library's public open wifi, no password required.  Using either
> 
>     0bda:0179 (rtl8188eu) USB Wifi adapter,
> 
> or
> 
>     0bda:f179 (rtl8188fu) USB Wifi adapter
> 
> Both adapters are loading
> 
>     rtl8xxxu kernel module
> 
> Using ( manual Wifi connection ) script , the system was able to obtain DHCP
> IP
> address.  Normally, all HTTP(S) requests get redirected to a public usage
> policy web page, where users have to click on "I agree" to continue.  Which
> works fine with another USB adapter (mt7601 kernel module).
> 
> However, with both Realtek adapters above, web browser will just time out,
> will
> NOT even get redirect to a "Public Use Notice" web page.
> 
> The relevant error message from system log shows
> 
>     2023-05-15T16:57:48.491567-04:00 usrhostname kernel: wlan1:
> deauthenticated
> from 7a:83:c2:8a:f1:13 (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA)
> 
> Apparently, the rtl8xxxu driver assumes an error condition, and immediately
> deauthenticates and drops the Wifi connection, will not complete the
> redirection to the "Public Use Notice" web page.
> 
> Try to connect again, same problem, repeating itself, not allowing any
> additional wifi traffic at all.
> 
> 
> 
> ----- Relevant system log messages -----
> 
> 
> 2023-05-24T20:44:39.073931-04:00 usrhostname kernel: [  144.044027] usb
> 2-1.2:
> ne
> w high-speed USB device number 4 using ehci-pci
> 2023-05-24T20:44:39.187649-04:00 usrhostname kernel: [  144.160895] usb
> 2-1.2:
> Ne
> w USB device found, idVendor=0bda, idProduct=f179, bcdDevice= 0.00
> 2023-05-24T20:44:39.187676-04:00 usrhostname kernel: [  144.160910] usb
> 2-1.2:
> Ne
> w USB device strings: Mfr=1, Product=2, SerialNumber=3
> 2023-05-24T20:44:39.187678-04:00 usrhostname kernel: [  144.160914] usb
> 2-1.2:
> Pr
> oduct: 802.11n
> 2023-05-24T20:44:39.187679-04:00 usrhostname kernel: [  144.160917] usb
> 2-1.2:
> Ma
> nufacturer: Realtek
> 2023-05-24T20:44:39.187680-04:00 usrhostname kernel: [  144.160920] usb
> 2-1.2:
> Se
> rialNumber: 00E0332D9E3F
> 2023-05-24T20:44:39.257625-04:00 usrhostname mtp-probe: checking bus 2,
> device
> 4:
>  "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2"
> 2023-05-24T20:44:39.258373-04:00 usrhostname mtp-probe: bus: 2, device: 4 was
> not
>  an MTP device
> 2023-05-24T20:44:39.533899-04:00 usrhostname kernel: [  144.506136] usb
> 2-1.2:
> Ve
> ndor: Realtek
> 2023-05-24T20:44:39.533920-04:00 usrhostname kernel: [  144.506146] usb
> 2-1.2:
> Pr
> oduct: 802.11n
> 2023-05-24T20:44:39.533924-04:00 usrhostname kernel: [  144.506148] usb
> 2-1.2:
> RT
> L8188FU rev B (SMIC) romver 0, 1T1R, TX queues 2, WiFi=1, BT=0, GPS=0, HI
> PA=0
> 2023-05-24T20:44:39.533925-04:00 usrhostname kernel: [  144.506152] usb
> 2-1.2:
> RT
> L8188FU MAC: 00:e0:33:2d:9e:3f
> 2023-05-24T20:44:39.533926-04:00 usrhostname kernel: [  144.506155] usb
> 2-1.2:
> rt
> l8xxxu: Loading firmware rtlwifi/rtl8188fufw.bin
> 2023-05-24T20:44:39.589963-04:00 usrhostname kernel: [  144.562560] usb
> 2-1.2:
> fi
> rmware: direct-loading firmware rtlwifi/rtl8188fufw.bin
> 2023-05-24T20:44:39.589980-04:00 usrhostname kernel: [  144.562587] usb
> 2-1.2:
> Fi
> rmware revision 4.0 (signature 0x88f1)
> 2023-05-24T20:44:40.773946-04:00 usrhostname kernel: [  145.744439] usbcore:
> regi
> stered new interface driver rtl8xxxu
> 2023-05-24T20:44:40.800483-04:00 usrhostname mtp-probe: checking bus 2,
> device
> 4:
>  "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2"
> 2023-05-24T20:44:40.800889-04:00 usrhostname mtp-probe: bus: 2, device: 4 was
> not
>  an MTP device
> 2023-05-24T20:44:40.801385-04:00 usrhostname (udev-worker)[2414]: Network
> interface NamePolicy= disabled on kernel command line.
> 2023-05-24T20:44:40.802420-04:00 usrhostname systemd[1]: Starting systemd-
> rfkill.service - Load/Save RF Kill Switch Status...
> 2023-05-24T20:44:40.829665-04:00 usrhostname systemd[1]: Started systemd-
> rfkill.service - Load/Save RF Kill Switch Status.
> 2023-05-24T20:44:45.836336-04:00 usrhostname systemd[1]: systemd-
> rfkill.service: Deactivated successfully.
> 2023-05-24T20:44:52.944262-04:00 usrhostname systemd[1]: libvirtd.service:
> Deactivated successfully.
> 2023-05-24T20:45:01.129084-04:00 usrhostname dhclient[2546]: DHCPRELEASE of
> 192.168.46.57 on wlan1 to 192.168.46.1 port 67
> 2023-05-24T20:45:01.129289-04:00 usrhostname dhclient[2546]: send_packet:
> Network is unreachable
> 2023-05-24T20:45:01.129380-04:00 usrhostname dhclient[2546]: send_packet:
> please consult README file regarding broadcast address.
> 2023-05-24T20:45:01.129446-04:00 usrhostname dhclient[2546]: dhclient.c:3124:
> Fai
> led to send 300 byte long packet over fallback interface.
> 2023-05-24T20:45:11.737904-04:00 usrhostname kernel: [  176.709150] warning:
> `iwc
> onfig' uses wireless extensions which will stop working for Wi-Fi 7 hardware;
> us
> e nl80211
> 2023-05-24T20:45:13.756588-04:00 usrhostname kernel: [  178.727991] wlan1:
> authen
> ticate with 02:ec:da:b7:dc:69
> 2023-05-24T20:45:13.756617-04:00 usrhostname kernel: [  178.728016] wlan1: 80
> MHz
>  not supported, disabling VHT
> 2023-05-24T20:45:13.769919-04:00 usrhostname kernel: [  178.741350] wlan1:
> send
> a
> uth to 02:ec:da:b7:dc:69 (try 1/3)
> 2023-05-24T20:45:13.773884-04:00 usrhostname kernel: [  178.746228] wlan1:
> authen
> ticated
> 2023-05-24T20:45:13.780519-04:00 usrhostname kernel: [  178.752052] wlan1:
> associ
> ate with 02:ec:da:b7:dc:69 (try 1/3)
> 2023-05-24T20:45:13.785906-04:00 usrhostname kernel: [  178.759760] wlan1: RX
> Ass
> ocResp from 02:ec:da:b7:dc:69 (capab=0x1421 status=0 aid=2)
> 2023-05-24T20:45:13.788379-04:00 usrhostname kernel: [  178.761594] usb
> 2-1.2:
> rt
> l8xxxu_bss_info_changed: HT supported
> 2023-05-24T20:45:13.791913-04:00 usrhostname kernel: [  178.764501] wlan1:
> associ
> ated
> 2023-05-24T20:45:13.815271-04:00 usrhostname dhclient[2737]: Internet Systems
> Con
> sortium DHCP Client 4.4.3-P1
> 2023-05-24T20:45:13.815496-04:00 usrhostname dhclient[2737]: Copyright
> 2004-2022
> Internet Systems Consortium.
> 2023-05-24T20:45:13.815612-04:00 usrhostname dhclient[2737]: All rights
> reserved.
> 2023-05-24T20:45:13.815702-04:00 usrhostname dhclient[2737]: For info, please
> vis
> it https://www.isc.org/software/dhcp/
> 2023-05-24T20:45:13.815790-04:00 usrhostname dhclient[2737]:
> 2023-05-24T20:45:13.850170-04:00 usrhostname dhclient[2737]: Listening on
> LPF/wla
> n1/00:06:25:64:75:74
> 2023-05-24T20:45:13.850406-04:00 usrhostname dhclient[2737]: Sending on
> LPF/wla
> n1/00:06:25:64:75:74
> 2023-05-24T20:45:13.850553-04:00 usrhostname dhclient[2737]: Sending on
> Socket/
> fallback
> 2023-05-24T20:45:13.850703-04:00 usrhostname dhclient[2737]: DHCPDISCOVER on
> wlan
> 1 to 255.255.255.255 port 67 interval 5
> 2023-05-24T20:45:13.961945-04:00 usrhostname kernel: [  178.935354] wlan1:
> Limiti
> ng TX power to 30 (30 - 0) dBm as advertised by 02:ec:da:b7:dc:69
> 2023-05-24T20:45:14.971746-04:00 usrhostname dhclient[2737]: DHCPOFFER of
> 192.168
> .46.217 from 192.168.46.1
> 2023-05-24T20:45:14.972016-04:00 usrhostname dhclient[2737]: DHCPREQUEST for
> 192.
> 168.46.217 on wlan1 to 255.255.255.255 port 67
> 2023-05-24T20:45:15.006123-04:00 usrhostname dhclient[2737]: DHCPACK of
> 192.168.4
> 6.217 from 192.168.46.1
> 2023-05-24T20:45:15.015898-04:00 usrhostname avahi-daemon[620]: Joining mDNS
> mult
> icast group on interface wlan1.IPv4 with address 192.168.46.217.
> 2023-05-24T20:45:15.016106-04:00 usrhostname avahi-daemon[620]: New relevant
> inte
> rface wlan1.IPv4 for mDNS.
> 2023-05-24T20:45:15.016198-04:00 usrhostname avahi-daemon[620]: Registering
> new
> a
> ddress record for 192.168.46.217 on wlan1.IPv4.
> 2023-05-24T20:45:15.118669-04:00 usrhostname dhclient[2737]: bound to
> 192.168.46.
> 217 -- renewal in 370 seconds.
> 
> 
> 2023-05-24T20:45:28.578681-04:00 usrhostname kernel: [  193.552517] wlan1:
> deauthenticated from 02:ec:da:b7:dc:69 (Reason:
> 6=CLASS2_FRAME_FROM_NONAUTH_STA)
> 
> 
> ----- ----- -----
> 
> A couple of blank lines inserted above the last line (from system log) for
> easier reading.
> 
> The last line is logged when the very first HTTP(S) request is sent from the
> web browser.  Which deauthenticate and drop the Wifi connection.
> 
> 
> 
> 
> 
> ----- ----- -----
> 
> * What exactly did you do (or not do) that was effective (or
>      ineffective)?
> 
> 
> ----- Expected behavior -----
> 
> At local library's public open wifi, no password required, works fine with an
> Android tablet or phone.  Using another USB Wifi adapter (mt7601u kernel
> module),  everything works fine.
> 
> The system obtains DHCP IP address.  All HTTP(S) request are redirected to a
> "Public Use Notice" web page, which require user to click on "OK" (or "I
> Agree"), which then redirect that web page to the library's "Welcome" web
> page.
> After that, all HTTP(S) request works fine.
> 
> 
> 
> * What outcome did you expect instead?
> 
> So for a public open wifi access point, the rtl8xxxu driver module should not
> deauthenticate (disconnect an already associated session) from a public open
> Wifi AP right at the first error.  It should allow at least 1-3 such error
> condition(s) (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA) before it
> deauthenticate
> (disconnecting) the associated Wifi session.
> 

Can you bisect this regression please? And also try latest mainline (v6.4-rc5).

This kernel driver module had never worked properly for me before.

Kernel module rtl8xxxu started supporting these two adapter ID's since kernel 6.2.0.  Debian took a while to have a package precompiled.  At that time, I tried one or two Liquorix 6.2.x precompiled kernel packages.  Exact same problem.

Since then, I tried a couple of Liqouorix 6.3.x, two Debian 6.3.x from Experimental repository, as well as compiled 6.3.1 from kernel.org.  Exact same problem.

Don't know if anyone with a Realtek USB Wifi adapter supported by rtl8xxxu had ever tried using such adapter at a public open Wifi at a library, airport, internet cafe, or others that redirect all web traffics to a Public Usage Policy page, required user agreement before allowing any web traffics through their AP.

I also tried connecting with NetworkManager, which took a long time, reconnecting numerous tries to display the Public Usage Policy web page.  How ever it never complete the "I Agree" button click.  The web browser timed out.  Syslog show repeated tries of wifi association attemps, but never get passed that stage.

The mt7601u module seemed to never check for this return code.  When I tried turn on debugging for mt7601u module.  Not sure if that mt7601u driver ignored because it was open wifi, or because it may simply ignore most error return code as a way to allow monitor mode.  I never tried to see if it ever suuported monitor mode, but have read that kernel module for ralink ra5370 device does support monitor mode.  And mt7601u chipset is a clone of sort of ra5370 chipset.

So I think no bisect needed, because no previous working kernel version of rtl8xxxu was ever worked for me.

Let me know if I need to do anything else.  I looek at the code briefly, I belive the rtl8xxxu called a function from 802.11 layer to handle the return code (Reason code 6), which promptly call a function to deauthenticate the session, thus disconnected the device from further wifi traffic.

I believe the 802.11 level handling is too harsh for public open AP.  However, i think the Realtek level code is too lazy.  Realtek driver code should check for reasonable return codes for situations like this and allow paasing at least a few of these before considering these as hacking attempts, which require deauthenticating, or disconnecting.  But then again, this would also be too strict for monitor mode handling of traffic.

Don't know if 802.11 level specs even have considerations for situations like these at all, or they simply handle lower level logic and leave these things for the device drivers to cooperate with application layers to handle these.

Can you provide a permanent email address instead of disposable one (you're using guerrilla mail) so that maintainers can reach you?

email me at  dbnusr4950@proton.me

Some Wifi routeor or AP for home use may have "SomeSSID-guest" as an open Wifi SSID, not using WPA for access.  Although I think they also require a web based password before allowing general web traffic for that connection.

That is probably very similar to the commercial softwares used by libraries, airports, hotels...  Try a Wifi scan for anything ending with "-guest" or similar names that is Open Wifi, no preshared keys.

Try to browse a generic web page without the web base password, it should give some error, but not sire if they would actually give Reason code 6, or simply does a web redirect.  Perhaps after numerous invalid requests, they would just disconnect the session from their (the server) end,

Can email me at dbnusr4950@proton.me

The next six days will be rainy here, but after that I can take my laptop for a walk and try to reproduce your bug with the city's free wifi.

In the meantime, if you want to investigate yourself, this is where I would start (using the RTL8188FU):

diff --git a/rtl8xxxu_core.c b/rtl8xxxu_core.c
index 796d802..817a36a 100644
--- a/rtl8xxxu_core.c
+++ b/rtl8xxxu_core.c
@@ -6288,6 +6298,12 @@ int rtl8xxxu_parse_rxdesc24(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
 		} else {
 			struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
 
+			pr_warn("frame_control: 0x%04x, addr1: %x:%x:%x:%x:%x:%x, addr2: %x:%x:%x:%x:%x:%x, addr3: %x:%x:%x:%x:%x:%x\n",
+				le16_to_cpu(hdr->frame_control),
+				hdr->addr1[0], hdr->addr1[1], hdr->addr1[2], hdr->addr1[3], hdr->addr1[4], hdr->addr1[5],
+				hdr->addr2[0], hdr->addr2[1], hdr->addr2[2], hdr->addr2[3], hdr->addr2[4], hdr->addr2[5],
+				hdr->addr3[0], hdr->addr3[1], hdr->addr3[2], hdr->addr3[3], hdr->addr3[4], hdr->addr3[5]);
+
 			if (rx_desc->phy_stats)
 				priv->fops->parse_phystats(priv, rx_status, phy_stats,
 							   rx_desc->rxmcs, hdr,


You don't have to compile the entire kernel. You can obtain the module from here: https://github.com/lwfinger/rtl8xxxu or here: https://github.com/a5a5aa555oo/rtl8xxxu

Solved with latest driver from

   https://github.com/lwfinger/rtl8xxxu/

downloaded source a couple of days ago.  Did not have a chance to try it then.  Also download and boot up with latest Liquorix kernel

   6.3.7-1-liquorix-amd64

the rtl8xxxu module from this Liquorix kernel still has the same problem.

Download latest rtl8xxxu driver sometime on 2023-06-12 from

   https://github.com/lwfinger/rtl8xxxu/

compile with

   make  &&  make install

then

   modprobe -r  rtl8xxxu

plug in the USB Wifi adapter, it loaded up

   rtl8xxxu_git

module as expected.

Connected fine now.  Problem solved.

Expected new releases of the latest kernel will work fine.

Kernel version 6.3.8 was released earlier today.

Liquorix also release their 

  6.3.8-1-liquorix-amd64

I downloaded Liquorix and tried the builtin kernel module rtl8xxxu and that did not work.

Recompile the same github code downloaded earlier on Jun 12 from

   github.com/lwfinger/rtl8xxxu/

for the Liquorix 6.3.8-1 kernel, install it, and the github code works fine.  So the mainline kernel need the latest github code for this problem to go away.

On 15/06/2023 02:55, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=217531
> 
> --- Comment #12 from dbnusr4950@proton.me ---
> Kernel version 6.3.8 was released earlier today.
> 
> Liquorix also release their 
> 
>   6.3.8-1-liquorix-amd64
> 
> I downloaded Liquorix and tried the builtin kernel module rtl8xxxu and that
> did
> not work.
> 
> Recompile the same github code downloaded earlier on Jun 12 from
> 
>    github.com/lwfinger/rtl8xxxu/
> 
> for the Liquorix 6.3.8-1 kernel, install it, and the github code works fine. 
> So the mainline kernel need the latest github code for this problem to go
> away.
> 

It's good to know the problem was already fixed. I looked at the commits
which are not in 6.3.x and this is the only one that seems likely:
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/commit/drivers/net/wireless/realtek/rtl8xxxu?id=66dcb574418eac0b09121d37ea0b52dede021887

If you apply that patch in reverse on top of
https://github.com/lwfinger/rtl8xxxu/ does the problem come back?

If you identify which commit fixed the problem, it can be applied to the
older kernels too.

With that reverse patch, using Liquorix kernel

   6.3.8-1-liquorix-amd64

everything works fine, no problems at all.  So it wasn't that particular patch.

Anyway, the reverse patch was rejected.  I tried to reverse the patch with:

   patch -R   <  path_to_diff_changes_from_git_link_above.txt

Since it was only a few lines, I did a manual patch.  Compile the reversed change.  

   modprobe -r rtl8xxxu_git

unplug, plug in, the USB Wifi adapter, try to reconnect.  Everything works fine.  Did not get Reason 6 disconnection.

Forgot to mention I did a 

   make ; make install

along with the

   modprobe -r rtl8xxxu_git

If it helps at all here the content of the rejected patch file

   rtl8xxxu_core.c.rej


----------
--- rtl8xxxu_core.c
+++ rtl8xxxu_core.c
@@ -6689,22 +6689,22 @@ static void rtl8xxxu_configure_filter(struct ieee80211_hw *hw,
 	 */
 
 	if (*total_flags & FIF_BCN_PRBRESP_PROMISC)
-		rcr &= ~(RCR_CHECK_BSSID_BEACON | RCR_CHECK_BSSID_MATCH);
+		rcr &= ~RCR_CHECK_BSSID_BEACON;
 	else
-		rcr |= RCR_CHECK_BSSID_BEACON | RCR_CHECK_BSSID_MATCH;
-
-	if (priv->vif && priv->vif->type == NL80211_IFTYPE_AP)
-		rcr &= ~RCR_CHECK_BSSID_MATCH;
+		rcr |= RCR_CHECK_BSSID_BEACON;
 
 	if (*total_flags & FIF_CONTROL)
 		rcr |= RCR_ACCEPT_CTRL_FRAME;
 	else
 		rcr &= ~RCR_ACCEPT_CTRL_FRAME;
 
-	if (*total_flags & FIF_OTHER_BSS)
+	if (*total_flags & FIF_OTHER_BSS) {
 		rcr |= RCR_ACCEPT_AP;
-	else
+		rcr &= ~RCR_CHECK_BSSID_MATCH;
+	} else {
 		rcr &= ~RCR_ACCEPT_AP;
+		rcr |= RCR_CHECK_BSSID_MATCH;
+	}
 
 	if (*total_flags & FIF_PSPOLL)
 		rcr |= RCR_ACCEPT_PM;

Just browsing the diff output between Kernel 6.3.x and github code does not show much.  Howevee, after looking at function

   rtl8xxxu_parse_rxdesc24()

It looks like Kernel 6.3.x only process one single skb, then return.

The github codebase as of 20230612 added a do-while loop to process all available skb units, until next_skb is NULL, then return to the caller.

Another change was in function

  rtl8xxxu_config_endpoints_no_sie()

where the switch statement added

   case 6:
   case 5:

Being not too familiar with the code, not sure of any impact of this particular function, just want to point out for sharper eyes and sharper minds to take a closer look.  The original error has "Reason code: 6".

Nope, just tried with removing changes, i.e. the do-while loop, and "case 6:" changes.  Separately for each functions, also together for both functions, those are 3 different variations.  Everything still connecting and working fine.  So those changes are not the ones that makes it works in the github code base.

With same code from github 20230612, comment out one line in rtl8xxxu_8188f.c

   .ustime_tsf_edca = 0x28,

then recompile, retry.  The error ReasonCode 6, NONAUTH will cause connection deauthorization again.

Of course the problem associated code change from kernel 6.2.x and 6.3.x involve  more than just that one line.

Did not get much working forward from kernel 6.3.x.

So, trying to comment out, or remove some changes from the working github 20230612 code base.  That was one thing that cause the same error so far.  

Adding just that variable init to kernel 6.3.x will not resolve the problem.

On 29/06/2023 22:08, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=217531
> 
> --- Comment #19 from dbnusr4950@proton.me ---
> With same code from github 20230612, comment out one line in rtl8xxxu_8188f.c
> 
>    .ustime_tsf_edca = 0x28,
> 
> then recompile, retry.  The error ReasonCode 6, NONAUTH will cause connection
> deauthorization again.
> 

This can't be the cause if you have the same problem with RTL8188EU.

That commented out value assignment...  Only tested quickly with an 8188FU adapter.  Did not try with 8188EU adapter.  Will try that later.

Just tried again.  Commented out the github 20230612 [working] code, in rtl8xxxu_8188f.c

     .ustime_tsf_edca = 0x28,

make it

//     .ustime_tsf_edca = 0x28,

compile, install, unload all rtl8xxxu or rtl8xxxu_git module, loaded the new rtl8xxxu_git module.  Sure enough, the 8188FU adtapter gave ReasonCode 6 NONAUTH message, and disconnected.

Unplug the disconneted 8188FU adapter, plug in the 8188EU adapter, it still works fine with the github 20230612 code.

As mentioned before the above assignment statement is NOT the only change needed to make Kernel 6.2.x, and 6.3.x to work for 8188FU.  It will involves more than that one line.

On 01/07/2023 22:36, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=217531
> 
> --- Comment #22 from dbnusr4950@proton.me ---
> Just tried again.  Commented out the github 20230612 [working] code, in
> rtl8xxxu_8188f.c
> 
>      .ustime_tsf_edca = 0x28,
> 
> make it
> 
> //     .ustime_tsf_edca = 0x28,
> 
> compile, install, unload all rtl8xxxu or rtl8xxxu_git module, loaded the new
> rtl8xxxu_git module.  Sure enough, the 8188FU adtapter gave ReasonCode 6
> NONAUTH message, and disconnected.
> 
> Unplug the disconneted 8188FU adapter, plug in the 8188EU adapter, it still
> works fine with the github 20230612 code.
> 
> As mentioned before the above assignment statement is NOT the only change
> needed to make Kernel 6.2.x, and 6.3.x to work for 8188FU.  It will involves
> more than that one line.
> 

That line has nothing to do with your problem. The commit which introduced
that line simply moved some code, without changing the functionality:
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/commit/?id=a5be45ea459371ad70eb1508b3fd4b731cdc57c7

[***]  With official Kernel 6.5.0 release, the reported problem is solved, no longer an issue.


The problem is in 6.2.x, 6.3.x, and 6.4.x up to, including 6.4.10.  I tried with a couple of Liquorix 6.4.x precompiled kernels, and perhaps one or two Debian 6.4.x kernels.  Now that 6.5.0 is available, I would not try with 6.4.11 or later in the 6.4.x series.

Debian experimental repository had a release called:

	6.5.0-0-amd64 . . .  Debian 6.5~rc4-1~exp1 (2023-08-04)

which solved this reported problem, however it was only a release candidate, so I waited for official 6.5.0.