Bug 247528 - rtwn(4) RTL8192EU usb wifi dongle can't connect to AP
Summary: rtwn(4) RTL8192EU usb wifi dongle can't connect to AP
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: Unspecified
Hardware: Any Any
: --- Affects Some People
Assignee: Cy Schubert
URL:
Keywords:
Depends on:
Blocks: 258018
  Show dependency treegraph
 
Reported: 2020-06-24 22:51 UTC by Mc James
Modified: 2023-07-31 02:56 UTC (History)
14 users (show)

See Also:


Attachments
Proposed patch. (2.63 KB, patch)
2023-01-09 19:06 UTC, Cy Schubert
no flags Details | Diff
Also fix ifconfig down/up hang (7.00 KB, patch)
2023-01-11 04:28 UTC, Cy Schubert
no flags Details | Diff
rtwn-Fix-RTL8192EU-cannot-associate-in-STA-mode.patch (6.64 KB, patch)
2023-01-12 23:18 UTC, Cy Schubert
no flags Details | Diff
Same for rtl8188eu (3.20 KB, patch)
2023-01-13 19:40 UTC, Cy Schubert
no flags Details | Diff
core.txt file from urtwn crash (127.05 KB, application/x-troff-man)
2023-03-06 06:19 UTC, rkoberman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mc James 2020-06-24 22:51:07 UTC
Hi:
I have a very complex problem.
a dongle with this chipset won't work with FreeBSD SJD 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC  amd64.
furthermore this usb dongle gets disconnected after a couple of tries of wpa_supplicant (from pkg not the base system as the wpa_supplicant from the base system would crash at the first try)

dmesg outpout is strange .... while wpa_supplicant is running ....
usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR
ugen5.2: <Unknown > at usbus5 (disconnected)
uhub_reattach_port: could not allocate new device
ugen7.2: <Realtek 802.11n NIC> at usbus7
rtwn0 on uhub0
rtwn0: <802.11n NIC > on usbus7
rtwn0: MAC/BB RTL8192EU, RF 6052 2T2R
wlan0: Ethernet address: d4:6e:0e:7f:51:67
wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost





Please continue reading !!! the full context is here : 
https://forums.freebsd.org/threads/tp-link-tl-wn823n-v2-device-not-showing-up.75923/
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2020-06-25 01:59:55 UTC
^Triage: assign to usb@ but Cc: wireless@ in case someone there has a quick insight.
Comment 2 Kris 2020-06-29 01:44:04 UTC
i have almost same problem.

https://www.mail-archive.com/freebsd-usb@freebsd.org/msg14466.html
Comment 3 Danilo Egea Gondolfo freebsd_committer freebsd_triage 2020-07-25 20:22:25 UTC
Exactly same problem here. I have a tplink wn823n (RTL8192EU).

The issue is easily reproducible. The device will get UP and things like scanning and adhoc mode will work fine. But if you "ifconfig down" the interface and "ifconfig up" it again it will stuck and the device will get disconnected from the USB bus.

This will make wpa_supplicant try to connect using WPA but it will fail:

ifconfig wlan0 create wlandev rtwn0
wpa_supplicant -i wlan0 -c...

Note that the interface is still down before running wpa_supplicant. wpa_supplicant will put the interface UP and try to connect although it will fail with authentication timeout.

If you put the interface UP yourself and then run wpa_supplicant it will fail and the device will be kicked out from the USB bus when it sends a second ioctl(... IFF_UP) to the interface.

So, the problem is reproducible with:

ifconfig wlan0 create wlandev rtwn0 up
ifconfig wlan0 down
ifconfig wlan0 up

The last command will stuck here:

17899 101638 ifconfig            -                   mi_switch+0xc1 _sleep+0x1cb taskqueue_drain+0xeb ieee80211_waitfor_parent+0x28 ieee80211_ioctl+0x44b ifhwioctl+0xbb2 ifioctl+0x419 kern_ioctl+0x25e sys_ioctl+0xfa amd64_syscall+0x119 fast_syscall_common+0x101 


And this is what happens:

ugen0.4: <Realtek 802.11n NIC> at usbus0
rtwn0 on uhub0
rtwn0: <802.11n NIC > on usbus0
rtwn0: MAC/BB RTL8192EU, RF 6052 2T2R
wlan1: Ethernet address: d0:37:45:0a:a3:81
ugen0.4: <Realtek 802.11n NIC> at usbus0 (disconnected)
rtwn0: at uhub0, port 1, addr 13 (disconnected)
rtwn0: r92e_power_off: failed to block Tx queues
rtwn0: detached
usb_alloc_device: set address 4 failed (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 4 failed, USB_ERR_IOERROR
usbd_req_re_enumerate: addr=4, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 4 failed, USB_ERR_IOERROR
usbd_req_re_enumerate: addr=4, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 4 failed, USB_ERR_IOERROR
usbd_req_re_enumerate: addr=4, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 4 failed, USB_ERR_IOERROR
usbd_req_re_enumerate: addr=4, set address failed! (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 4 failed, USB_ERR_IOERROR
ugen0.4: <Unknown > at usbus0 (disconnected)
uhub_reattach_port: could not allocate new device
Comment 4 Danilo Egea Gondolfo freebsd_committer freebsd_triage 2020-09-12 15:05:47 UTC
Regarding the ifconfig up and down issue, it seems that the function r92e_power_off() is breaking the firmware state machine.

According to the driver provided by the vendor [1], transitioning the device from Active to Low Power State consists of this sequence of steps [2]. The driver in fact does that (plus a few more actions) when you ifconfig down it.

In fact, interrupting the code after it moves the state machine to LPS (inserting a return; right here [3] for example) fixes the device-being-disconnected-from-the-bus issue, what is probably due to a crash in the firmware.

Hopefully it will provide some insight to whoever looks into this issue in the future.

It's still not working when used with wpa_supplicant. 

[1] - https://static.tp-link.com/TL-WN823N(EU)_V2_160315_Linux_1479970241132h.zip
[2] - https://gitlab.cosmoproducts.de/cosmocard/rtl8192eu-linux-driver/-/blob/c50f3f80b97a5ab2d2582021ae93e0a5f07118b7/include/Hal8192EPwrSeq.h#L106
[3] - https://github.com/freebsd/freebsd/blob/master/sys/dev/rtwn/rtl8192e/r92e_init.c#L327
Comment 5 Danilo Egea Gondolfo freebsd_committer freebsd_triage 2020-09-13 12:47:30 UTC
I'm using it on hostap mode right now and it works perfectly. I'm accessing the internet in my smartphone through it.

wlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether d0:37:45:0a:a3:81
        inet6 fe80::d237:45ff:fe0a:a381%wlan1 prefixlen 64 scopeid 0x4
        inet 172.17.0.1 netmask 0xffffff00 broadcast 172.17.0.255
        groups: wlan
        ssid capetinha channel 10 (2457 MHz 11g ht/20) bssid d0:37:45:0a:a3:81
        regdomain NONE country UA authmode WPA2/802.11i privacy MIXED
        deftxkey 2 AES-CCM 2:128-bit txpower 30 scanvalid 60 protmode CTS ht20
        ampdulimit 64k ampdudensity 16 shortgi -stbc -ldpc -uapsd wme
        dtimperiod 1 -dfs
        parent interface: rtwn0
        media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng <hostap>
        status: running
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Comment 6 wahil1976 2020-11-13 05:44:44 UTC
This seems to be a duplicate of bug 244902, which provides some useful information. Apparently it only happens if the device is plugged in to a XHCI controller; it does not happen if it is plugged in to a EHCI controller.
Comment 7 Hans Petter Selasky freebsd_committer freebsd_triage 2020-11-13 10:31:02 UTC
Can you dump the output from usbconfig when the device is working and not working?
Comment 8 wahil1976 2021-01-02 04:23:30 UTC
I don't have any extra computers using an EHCI controller, so I can't.
Comment 9 Cy Schubert freebsd_committer freebsd_triage 2022-04-06 14:45:12 UTC
This may not be a USB issue, as the NIC works nicely in AP mode but fails to work in STA mode. Mine is: MAC/BB RTL8192EU, RF 6052 2T2R.

In AP mode hostapd(8) allows stations to associate and dhcpd(8) hands out IPs allowing stations, bridged to a wired interface, access the network.

However in STA mode it will not associate with either with wpa_supplicant or configured manually.

Conversely the RTL8188EU works in AP and STA mode.
Comment 10 Cy Schubert freebsd_committer freebsd_triage 2022-04-06 14:46:12 UTC
BTW, I'm running a very recent -CURRENT, built yesterday.
Comment 11 Slawomir Wojciech Wojtczak 2022-04-29 20:56:09 UTC
Same problem here on 13.1-RC5.

# dmesg
(...)
ugen1.2: <Realtek 802.11n NIC> at usbus1
rtwn0 on uhub2
rtwn0: <802.11n NIC> on usbus1
rtwn0: MAC/BB RTL8192EU, RF 6052 2T2R

# sysctl net.wlan.devices
net.wlan.devices: rtwn0 iwn0

# usbconfig
(...)
ugen1.2: <Realtek 802.11n NIC> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

# ifconfig wlan0 create wlandev rtwn0

# ifconfig wlan0 up scan
SSID/MESH ID                      BSSID              CHAN RATE    S:N     INT CAPS
wpa2network                       d8:07:b6:b3:f5:a1    7   54M  -63:-95   100 EP   APCHANREP WPA RSN BSSLOAD HTCAP VHTCAP VHTOPMODE WME

# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
Successfully initialized wpa_supplicant
ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Invalid argument
ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Invalid argument
wlan1: Trying to associate with d8:07:b6:b3:f5:a1 (SSID='wpa2network' freq=2442 MHz)
wlan1: Authentication with d8:07:b6:b3:f5:a1 timed out.
wlan1: CTRL-EVENT-DISCONNECTED bssid=d8:07:b6:b3:f5:a1 reason=3 locally_generated=1
BSSID d8:07:b6:b3:f5:a1 ignore list count incremented to 2, ignoring for 10 seconds
wlan1: CTRL-EVENT-DSCP-POLICY clear_all
wlan1: Trying to associate with d8:07:b6:b3:f5:a1 (SSID='wpa2network' freq=2442 MHz)
wlan1: Authentication with d8:07:b6:b3:f5:a1 timed out.
wlan1: CTRL-EVENT-DISCONNECTED bssid=d8:07:b6:b3:f5:a1 reason=3 locally_generated=1
BSSID d8:07:b6:b3:f5:a1 ignore list count incremented to 2, ignoring for 10 seconds
wlan1: CTRL-EVENT-DSCP-POLICY clear_all
wlan1: Trying to associate with d8:07:b6:b3:f5:a1 (SSID='wpa2network' freq=2442 MHz)
wlan1: Authentication with d8:07:b6:b3:f5:a1 timed out.
wlan1: CTRL-EVENT-DISCONNECTED bssid=d8:07:b6:b3:f5:a1 reason=3 locally_generated=1
BSSID d8:07:b6:b3:f5:a1 ignore list count incremented to 2, ignoring for 10 seconds
wlan1: CTRL-EVENT-DSCP-POLICY clear_all
wlan1: Trying to associate with d8:07:b6:b3:f5:a1 (SSID='wpa2network' freq=2442 MHz)
wlan1: Authentication with d8:07:b6:b3:f5:a1 timed out.
wlan1: CTRL-EVENT-DISCONNECTED bssid=d8:07:b6:b3:f5:a1 reason=3 locally_generated=1
BSSID d8:07:b6:b3:f5:a1 ignore list count incremented to 2, ignoring for 10 seconds
wlan1: CTRL-EVENT-SSID-TEMP-DISABLED id=41 ssid="wpa2network" auth_failures=1 duration=10 reason=CONN_FAILED
wlan1: CTRL-EVENT-DSCP-POLICY clear_all
wlan1: CTRL-EVENT-SSID-REENABLED id=41 ssid="wpa2network"
wlan1: Trying to associate with d8:07:b6:b3:f5:a1 (SSID='wpa2network' freq=2442 MHz)
wlan1: Authentication with d8:07:b6:b3:f5:a1 timed out.
wlan1: CTRL-EVENT-DISCONNECTED bssid=d8:07:b6:b3:f5:a1 reason=3 locally_generated=1
BSSID d8:07:b6:b3:f5:a1 ignore list count incremented to 2, ignoring for 10 seconds
wlan1: CTRL-EVENT-SSID-TEMP-DISABLED id=41 ssid="wpa2network" auth_failures=2 duration=39 reason=CONN_FAILED
wlan1: CTRL-EVENT-DSCP-POLICY clear_all
wlan1: CTRL-EVENT-SSID-REENABLED id=41 ssid="wpa2network"
wlan1: Trying to associate with d8:07:b6:b3:f5:a1 (SSID='wpa2network' freq=2442 MHz)
wlan1: Authentication with d8:07:b6:b3:f5:a1 timed out.
wlan1: CTRL-EVENT-DISCONNECTED bssid=d8:07:b6:b3:f5:a1 reason=3 locally_generated=1
BSSID d8:07:b6:b3:f5:a1 ignore list count incremented to 2, ignoring for 10 seconds
wlan1: CTRL-EVENT-SSID-TEMP-DISABLED id=41 ssid="wpa2network" auth_failures=3 duration=56 reason=CONN_FAILED

Regards.
Comment 12 Slawomir Wojciech Wojtczak 2022-04-29 21:07:32 UTC
Theoretically support for that WiFi chipset was added at about 2017 ...

https://svnweb.freebsd.org/base?view=revision&revision=312680
Comment 13 Slawomir Wojciech Wojtczak 2022-05-04 11:53:25 UTC
What debug info I can provide You to move this PR into right direction?
Comment 14 Rich Reamer 2022-07-13 01:19:34 UTC
Hello,
Yep same problem here - usb tplink device that FBSD 13.1 detects as RTL8192EU.
System detects and is configured as wlan0 also.
It "scans" and sees wifi nets - but wont connect.
As stated earlier as other -- what diag info can we provide??
Comment 15 Cy Schubert freebsd_committer freebsd_triage 2022-07-13 01:43:03 UTC
Can you perform this test, please.

1. Create an open unprotected network (guest network or otherwise) on an AP.

2. ifconfig wlan1 create wlandev rtwn0 up

3. ifconfig wlan1 ssid YOUR_NEWLY_CREATED_SSID

4. ifconfig wlan1


I just performed this with,

ugen0.9: <Realtek 802.11n NIC> at usbus0
rtwn0 on uhub7
rtwn0: <802.11n NIC > on usbus0
rtwn0: MAC/BB RTL8192EU, RF 6052 2T2R

It fails to associate:

slippy# ifconfig wlan1
wlan1: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 6c:5a:b0:4a:cb:f0
	inet6 fe80::6e5a:b0ff:fe4a:cbf0%wlan1 prefixlen 64 scopeid 0x6
	groups: wlan
	ssid KQNGN3 channel 8 (2447 MHz 11g)
	regdomain FCC country US authmode OPEN privacy OFF txpower 30 bmiss 7
	scanvalid 60 protmode CTS wme bintval 200
	parent interface: rtwn0
	media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
	status: no carrier
	nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
slippy# 

Can you please perform the the test above to confirm. Thanks.
Comment 16 Rich Reamer 2022-07-15 14:57:05 UTC
@Cy....

Summation: yeah its a driver issue -- "rtwn" does not work with RTL8192EU.

Did the "open network" (ie. no wpa_supplicant usage) tests -- using my phone as an open wifi hotspot called "Blacklisted".

Tested with RTL8188EU (as a control, which worked) and RTL8192EU (which did not)

This same "rc.conf" config used in both tests.
   /etc/rc.conf
      wlans_rtwn0="wlan0"
      ifconfig_wlan0="SYNCDHCP"
-----------
Tested with RTL8188EU.. (test performed by reboot, rtwn connected to Blacklisted automagically - you can see it got and pings, browsing worked)

dmesg:
   rtwn0 on uhub0
   rtwn0: <Realtek 802.11n NIC, class 0/0, rev 2.00/0.00, addr 1> on usbus0
   rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R

wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 6c:5a:b0:de:c3:62
	inet 192.168.43.174 netmask 0xffffff00 broadcast 192.168.43.255
	groups: wlan
	ssid Blacklisted channel 1 (2412 MHz 11g ht/20) bssid ba:d7:af:21:34:be
	regdomain FCC country US authmode OPEN privacy OFF txpower 30 bmiss 7
	scanvalid 60 protmode CTS ht20 ampdulimit 64k ampdudensity 8 shortgi
	-stbc -ldpc -uapsd wme
	parent interface: rtwn0
	media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
	status: associated
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
----------
Tested with RTL8192EU.. (test performed by reboot, rtwn attempted to connect to Blacklisted automagically -- but never could or did. Never acquired an IP, it would continually cycle between trying to connect and drop, as seen below. Even forcing connect via "ifconfig" failed as well)

dmesg:
   rtwn0 on uhub0
   rtwn0: <802.11n NIC > on usbus0
   rtwn0: MAC/BB RTL8192EU, RF 6052 2T2R

wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 6c:5a:b0:6d:62:d8
	groups: wlan
	ssid "" channel 9 (2452 MHz 11g)
	regdomain FCC country US authmode OPEN privacy OFF txpower 30 bmiss 7
	scanvalid 60 protmode CTS wme
	parent interface: rtwn0
	media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
	status: no carrier
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 6c:5a:b0:6d:62:d8
	groups: wlan
	ssid Blacklisted channel 1 (2412 MHz 11g ht/20)
	regdomain FCC country US authmode OPEN privacy OFF txpower 30 bmiss 7
	scanvalid 60 protmode CTS ht20 ampdulimit 8k ampdudensity 16 shortgi
	-stbc -ldpc -uapsd wme
	parent interface: rtwn0
	media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
	status: no carrier
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

ifconfig wlan create wlandev rtwn0 ssid Blacklisted up (failed as well)
Comment 17 Cy Schubert freebsd_committer freebsd_triage 2022-07-15 15:12:14 UTC
(In reply to Rich Reamer from comment #16)
This confirms my findings.

As I have both RTL8188EU and RTL8192EU here, I'll take this ticket unless bz@ or adrian@, both of which have more experience with the driver than I do, prefer to take it.

Playing around with this, RTL8192EU works in AP mode but does not work in STA mode. I am able to associate to it in AP mode but am unable to associate to anything, including manually, in STA mode. I have yet to test it in ADHOC mode.
Comment 18 Cy Schubert freebsd_committer freebsd_triage 2022-07-15 17:50:37 UTC
Let's add a little excitement to this:

Disconnecting the RTL8192EU from my laptop (where it did not work) and plugging it into my sandbox machine downstairs, it immediately associated with my wife's AP using wpa_supplicant with WPA2-PSK. I was not able to do this with my laptop.

Interesting data point: My laptop does have a wlan (iwn) installed on the PCI bus. But, the sandbox also has a wlan (ath) also installed on the PCI bus.

The question that needs to be answered is, what's the difference (other than the obvious that one is a server and the other is a laptop and they each have a different other wlan device installed on the PCI bus) between the sandbox machine and the laptop. Other than the other two huge differences, which may or may not have a bearing on why this is happening.

I'd be interested in finding out what anyone else with an installed wlan has installed also on their PCI bus. Just checking an obvious hunch before digging into this too deeply.
Comment 19 Bjoern A. Zeeb freebsd_committer freebsd_triage 2022-08-09 19:45:59 UTC
(In reply to Cy Schubert from comment #18)

The question might be what is the difference in USB version and chipsets?  It's (hopefully) very unlikely that a PCI card with leak net80211 state to the USB device (if that'd be the case we'd have a lot more trouble).

It my also be a question of that the AP advertises, the RSSI and other paramters...
Comment 20 titus m 2022-12-27 15:58:34 UTC
I can confirm the weirdness
I have a "Tenda U3" rtl8192eu based usb dongle
On a HP t430 thin client it works only in AP mode, does not associate with open or wpa networks 
On a HP t620 thin client it works in STA mode with open networks, could not make it to associate with a wpa one
on a PI ZERO works on a WPA network
the pi runs freebsd 13.0 and the others 13.1 but I booted 13.0 on the HP t430 box and it did not work any different than 13.1

tested with openbsd 6.8 and 7.2 on the hp430 box and it works
Comment 21 titus m 2023-01-07 11:32:28 UTC
everything below is on the HP t430 box

after lots of experimentation, and logging every rtwn_read_NN rtwn_write_NN
did not find anything useful
did the logging with netbsd urtwn (which works), still no go
even the logs look pretty much the same between the working / non working scenario
in the end i came to conclusion that the problem is not in the driver itself
but in the usb code
funny thing is that setting 
hw.usb.debug=1 will cause it to associate/work
after associating hw.usb.debug can be turned to 0 (also improves performance quite a lot)
Comment 22 Rich Reamer 2023-01-07 14:33:49 UTC
Isnt that interesting,  you but not unusual, sometimes in linux kernel in debug mode makes devices work, in that case, its a timing thing.
Comment 23 titus m 2023-01-09 15:20:57 UTC
adding a DELAY(1000) at the end of rtwn_usb_write_region_1  fixed it for me
the delay is really only needed during the execution of r92e_set_chan
tested on both thin clients and it works on both on open and wpa2 networks
performance is about 25Mb/s
Comment 24 Hans Petter Selasky freebsd_committer freebsd_triage 2023-01-09 16:34:41 UTC
Please use usb_pause_mtx() instead of DELAY().

--HPS
Comment 25 Cy Schubert freebsd_committer freebsd_triage 2023-01-09 16:40:18 UTC
This doesn't jibe with the fact that the RTL8192EU works perfectly well in HOSTAP mode but fails to associate in STA mode.

However it works perfectly well in STA mode too with my ASUS machines in my basement but not with my Acer laptop.
Comment 26 titus m 2023-01-09 16:42:31 UTC
actually I used rtwn_usb_delay which should switch to usb_pause_mtx for intervals >=1000us
wrote DELAY above out of laziness
Comment 27 Cy Schubert freebsd_committer freebsd_triage 2023-01-09 19:06:27 UTC
Created attachment 239366 [details]
Proposed patch.

Excellent sleuthing. Thanks for your work.

Can you try the attached patch?

I haven't had a chance to test or even compile this patch. I'll test this myself later on today or tomorrow.
Comment 28 Rich Reamer 2023-01-09 19:11:25 UTC
This is exciting, i can regen my system and test, but that gonna be a few days
Comment 29 titus m 2023-01-09 20:04:14 UTC
r92e_chan.c needs this
#include <dev/rtwn/usb/rtwn_usb_var.h>
rtl8192eu seems to be usb only so not a big problem
there are a couple of RTWN_LOCK(sc) and RTWN_UNLOCK(sc) which need a semicolon after

otherwise it builds and runs ok
only tested on one of the boxes but tomorrow will test on the other one too
also the var name  "USB delay microseconds" may need changing
Comment 30 titus m 2023-01-10 07:09:53 UTC
it works on the other box too
not quite related but the r92e_power_off code is problematic too
a ifconfig wlanX down / ifconfig wlanX up will break and disable the usb port until a power cycle or device reinsertion
Comment 31 Cy Schubert freebsd_committer freebsd_triage 2023-01-11 04:28:40 UTC
Created attachment 239399 [details]
Also fix ifconfig down/up hang

This patch also addresses the ifconfig down/up hang.
Comment 32 titus m 2023-01-11 08:10:49 UTC
Comment on attachment 239399 [details]
Also fix ifconfig down/up hang

the sysctl line should be like
SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(tree), OID_AUTO,
            "rtwn_usb_delay",
            CTLFLAG_RDTUN, &uc->uc_delay_us,
            uc->uc_delay_us, "RTWN USB set channel delay microseconds");
maybe CTLFLAG_RWTUN so you can play without rebooting
also the power_off function problem is not related to the delay
netbsd has no power_off code for rtl8192eu
linux code for rtl8192eu power off looks much more similar with the code in rtl8188eu/usb power_off function
Comment 33 Cy Schubert freebsd_committer freebsd_triage 2023-01-11 15:19:08 UTC
(In reply to titus m from comment #32)

Yes. And the delay should only apply to the RTL8192EU and no other chipsets. Only the 8192EU should start out with a delay of 1000us while other chipsets should initially have no delay. The sysctl can be used to adjust the delay (for all chipsets) subsequent to the initial setting.
Comment 34 Cy Schubert freebsd_committer freebsd_triage 2023-01-11 17:30:34 UTC
Removal of the power_off delay results in a hang. Same as removal of the power_on delay also results in a hang. Both are needed.
Comment 35 titus m 2023-01-11 18:35:08 UTC
for me it does not hang on power off with
delay or no delay but the next power on breaks something and makes the device unusable until the next power cycle / or device reinsertion

reboot does not fix it
when i did the most of experimenting i had power_off function set noop/just return so i could up/down the iface remotely / with out reinsertion
Comment 36 Cy Schubert freebsd_committer freebsd_triage 2023-01-12 23:18:33 UTC
Created attachment 239429 [details]
rtwn-Fix-RTL8192EU-cannot-associate-in-STA-mode.patch

Having resolved all my issues locally, the power_off issue was a red herring unrelated to this patch.

If this works for you and others I will submit a phabricator review of the code.

AP mode still needs some testing though. AP mode worked before however testing of AP mode is required to ensure this causes no regressions there either.
Comment 37 titus m 2023-01-13 07:09:36 UTC
i tested AP mode/open, set up dhcpd, forwarding and connected with my phone
got about 20Mb/s up/down on fast.com (a netflix service) which is inline with what i get in sta mode

my dongle still crashes on ifconfig down/up so i have modified power_off
the last 5 setbits calls from r92e_power_off
	/* SOP option to disable BG/MB. */
        /* Unlock small LDO Register. */
        /* Disable small LDO. */
        /* Enable WL suspend. */
        /* Enable SW LPS. */
changed to 
       /* Enable WL suspend. */
       /* SOP option to disable BG/MB. */	
the other 3 i commented out and it works this way
otherwise the power_on bombs in various places and the device gets disconnected
...
Jan 12 08:35:38 hp430 kernel: rtwn0: rtwn_do_request: control request failed, USB_ERR_IOERROR (retries left: 9).....
Jan 12 08:35:51 hp430 kernel: ugen0.3: <Realtek 802.11n NIC> at usbus0 (disconnected)
Jan 12 08:35:51 hp430 kernel: rtwn0: at uhub0, port 2, addr 2 (disconnected)
...
after that i have to reinsert the dongle, or power cycle the host
a reboot won't fix it, it remains dead

but if this only ifconfig down/up only affects my setup it can stay as it is
I don't really need to ifconfig down/up remotely and otherwise i can remove / reinsert
Comment 38 rkoberman 2023-01-13 17:53:08 UTC
FWIW, while this ticket calls out the 8192EU, my 8188EU was showing identical symptoms. "was" because my internal "Alder Lake-P PCH CNVi WiFi" is now working with iwlwifi, so I am not using the 8188EU any longer.

I can confirm that, when the 8188EU did a reset, only a cold reboot (power down) would recover. Symptoms seem to be an exact match for those described in this bug.
Comment 39 Cy Schubert freebsd_committer freebsd_triage 2023-01-13 18:44:04 UTC
(In reply to rkoberman from comment #38)

I also have "rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R" here. It had no such problems as "rtwn0: MAC/BB RTL8192EU, RF 6052 2T2R" discussed in this ticket.

If you want I can extend the 8192EU mitigations to 8188EU. But I am unable to test here because my 8188EU works perfectly in STA and AP modes.
Comment 40 Cy Schubert freebsd_committer freebsd_triage 2023-01-13 19:40:58 UTC
Created attachment 239455 [details]
Same for rtl8188eu

(In reply to rkoberman from comment #38)

Can you also try this? You will need the first patch as well. This patch builds on the first patch to now include rtl8188eu.

I can't test this here because I have no such problems with my rtl8188eu.
Comment 41 Cy Schubert freebsd_committer freebsd_triage 2023-03-02 17:40:30 UTC
(In reply to rkoberman from comment #38)
Can you please test the patch. My 8188EU never experienced this problem so testing locally doesn't confirm the fix.
Comment 42 Cy Schubert freebsd_committer freebsd_triage 2023-03-02 23:51:58 UTC
Review is at https://reviews.freebsd.org/D38854.
Comment 43 rkoberman 2023-03-06 02:21:22 UTC
I apologize for the long delay. Finally dug out the fob and tried.

First, switched running system from iwlwifi to urtwn. Worked fine.
Then I patched the source and rebuilt with no errors.
Then I tried reloading the kernel. Instant crash. Reboot to new kernel. Instant crash when the driver was loaded.

I am running CURRENT (FreeBSD 14.0-CURRENT #8 main-n261137-b5d248c0c82c-dirty: Sun Mar  5 17:36:08 PST 2023)

Any suggestion on how to proceed? I will generate a dump later today and attach it to the ticket.
Comment 44 rkoberman 2023-03-06 06:19:53 UTC
Created attachment 240612 [details]
core.txt file from urtwn crash

Totally reliable crash with D38854 applied. Interface was working prior to adding the patch.