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/
^Triage: assign to usb@ but Cc: wireless@ in case someone there has a quick insight.
i have almost same problem. https://www.mail-archive.com/freebsd-usb@freebsd.org/msg14466.html
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
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
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>
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.
Can you dump the output from usbconfig when the device is working and not working?
I don't have any extra computers using an EHCI controller, so I can't.
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.
BTW, I'm running a very recent -CURRENT, built yesterday.
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.
Theoretically support for that WiFi chipset was added at about 2017 ... https://svnweb.freebsd.org/base?view=revision&revision=312680
What debug info I can provide You to move this PR into right direction?
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??
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.
@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)
(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.
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.
(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...
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
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)
Isnt that interesting, you but not unusual, sometimes in linux kernel in debug mode makes devices work, in that case, its a timing thing.
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
Please use usb_pause_mtx() instead of DELAY(). --HPS
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.
actually I used rtwn_usb_delay which should switch to usb_pause_mtx for intervals >=1000us wrote DELAY above out of laziness
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.
This is exciting, i can regen my system and test, but that gonna be a few days
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
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
Created attachment 239399 [details] Also fix ifconfig down/up hang This patch also addresses the ifconfig down/up hang.
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
(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.
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.
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
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.
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
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.
(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.
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.
(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.
Review is at https://reviews.freebsd.org/D38854.
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.
Created attachment 240612 [details] core.txt file from urtwn crash Totally reliable crash with D38854 applied. Interface was working prior to adding the patch.
Has any progress been made on this bug? The latest updates both here and in D38854 are over a year old.
Looking at it, it looks like putting the lock/unlocks everywhere is problematic. Chances are deleting the right ones will fix the recursion. ;-) cy@, wanna take another crack at it?
Created attachment 253233 [details] This should fix locking issues. Sorry for the delay. I got sidetracked by the MIT KRB5 import. This should fix the recursive locking.
Thanks for the prompt update cy@ Unfortunately, the patch in attachment 253233 [details] doesn't apply cleanly. The attachment comprises 3 "emails" and the first (Subject: [PATCH] rtwn: Fix RTL8188EU cannot associate in STA mode) and third (Subject: [PATCH 2/2] rtwn: Fix RTL8188EU cannot associate in STA mode) affect the same files but include different (incompatible) patches to sys/dev/rtwn/rtl8188e/usb/r88eu_init.c I'm uncertain whether the correct version is the one with all the RTWN_LOCK()/UNLOCK() pairs or the other version. In addition the following hunk doesn't look right in either because the "return ETIMEDOUT" has moved outside the "if" statement: @@ -112,7 +120,10 @@ r88eu_power_on(struct rtwn_softc *sc) break; rtwn_delay(sc, 10); } - if (ntries == 5000) + if (ntries == 5000) { + if (uc != NULL) + uc->uc_write_delay = 0; + } return (ETIMEDOUT); sys/dev/rtwn/rtl8188e/usb/r88eu_init.c
(In reply to Peter Jeremy from comment #49) The correct version is without the RTWN_{LOCK,UNLOCK}. My mistake re the patch. I did git format-patch but forgot I had another format-patch output in /tmp when I cat(1)ed them together. I'll reupload. Sorry about that.
Created attachment 253264 [details] Fix for two RTWN chipsets, for real. There should be two patches in this file. Both do NOT include RTWN_LOCK/UNLOCK calls -- this results in a recursive lock panic. The first patch is for the RTL8192EU. The second patch is for RTL8188EU. I have three different RTL8192EU here. The first patch fixed the problem for the one that was having this problem.
Comment on attachment 253264 [details] Fix for two RTWN chipsets, for real. I'm withdrawing this patch. Something went wrong when I rebased the patches to remove the locking. I'll upload a new patch on Tuesday. This is what happens when someone gives me the bums rush on something unrelated. I will have a lot more time on Tuesday to do this properly. Sorry about this.
Just a quick update. Before posting both patches (in one file) tomorrow. I can associate to one of my APs here when connected to USB 2.0 but when using USB 3.0, dhclient segfaults after associating to the same AP. I will investigate tomorrow.
Created attachment 253301 [details] Confirmed fix for rtwm(4) on some USB2 laptops Confirmed this fixes association of TL-WN823N v2/v3 [Realtek RTL8192EU] TP-Link on Acer 4752 with USB2 support. Of the three rtwm(4) dongles I have here, only the above dongle failed to associate on the laptop with USB2 support. It did work without the patch on the laptop with USB3 support, directly, and through a USB2 hub. The patch allows the dongle to associate on the USB2 laptop.
Created attachment 253303 [details] Reformated RTL8192EU patch. Reformatted RTL8192EU patch.
Created attachment 253304 [details] Reformatted RTL8188EU patch. Reformatted RTL8188EU patch. Apply both the RTL8192EU and the RTL8188EU patches.
Sorry for the delay in responding. I've had attachment 253304 [details] running on an ARM SBC (Rock64) with RTL8192EU for several days without any obvious issues (other than very poor WiFi speed). I don't believe speed is related to these patches and so would support the patches being committed.
I have uploaded both patches to https://reviews.freebsd.org/D38854 for review.
User feedback: I have been running this patch with a RTL8192EU USB adapter for a couple of days, loading on boot, connecting to my home 2.4GHz WPA network, and it works, nothing wrong so far. It actually applied fine on 14.2 so that's where I am.
I've been digging deep in this and i've found some fun stuff. First, the power up / down / up sequencing problem. there's code in rtl8192eu that doesn't exist at all in rtl8xxxu in linux. If I just delete them, the power up / down / up / down sequence doesn't break for me. https://reviews.freebsd.org/D48428 Second, there's some extra delays in the rtl8192eu RF register programming in rtl8xxxu - it looks like some bit is toggled high -> low to kick start some hardware shifting/state machine. https://reviews.freebsd.org/D48512 Third, after tracing the write sleeps in cy@'s patch through the setup path, it turns out we only need a sleep at the end of the channel programming, not for every write. https://reviews.freebsd.org/D48517 The last one is interesting. I added setting the CCX report bit in the TX descriptor for raw frames, so I'd get a per-frame report. However, when this condition occurs, I don't get /any/ response. It's like the frame isn't even attempted to be sent. So, I checked the contents of TXPAUSE after the channel config, and it's 0x0f and 0x4f, not 0x0 - so SOME queues are blocked. I also tried logging it during the TX path and yes, it's non-zero too during association attempts - however since the net80211 comlock is held during scans, and net80211 txlock is held during normal transmit, things blew up pretty quickly there. (I'll fix those locks later.) Linux also retries the auth send more than once, whereas freebsd only tries it once. If the NIC isn't ready or fails to send it with its hardware/firmware retry setup, then association fails. This is also likely suboptimal and fixing this in net80211 would be awesome, but again, we'll have to tackle that later. So, I'd like cy@ and others w/ an RTL8192EU to try the three above diffs and report back. Let's see if it improves things or not.
(In reply to Adrian Chadd from comment #60) applied all 3 patches. now it doesn't disappear from usb after destroy & create, and it successfully connects to wpa2 ap and passes traffic without any loss
additional platform info here this is FreeBSD ask-m-001 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n274860-2f35419fb26d-dirty: Sun Jan 19 23:40:21 EET 2025 root@green.sau.si.pri.ee:/root/files/fbsd/current/obj/univ-min/root/files/fbsd/current/src/arm.armv7/sys/GENERIC-NODEBUG arm on allwinner h3 soc, 32bit, armv7 nic is ugen7.2: <Realtek 802.11n NIC> at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) idVendor = 0x0bda idProduct = 0x818b noname brand usb2 2ghz only rtwn0 on uhub7 rtwn0: <Realtek 802.11n NIC, class 0/0, rev 2.10/2.00, addr 2> on usbus7 rtwn0: MAC/BB RTL8192EU, RF 6052 2T2R
(In reply to Adrian Chadd from comment #60) The patches work with RTL8188EU (TL-WN725N) almost immediately. The AC1200 (Archer T4UH wireless Realtek 8812AU TP-Link) also does immediately work. The RTL8192EU, a TL-WN823N, appears not to work but if left plugged in for a while, up to a minute, it did finally associate. This test was performed on a laptop (HP 840 G5) with XHCI. I will test on a laptop (Acer 4752) with EHCI and OHCI tomorrow, when I can dig it out of its bag. The previous patch (https://reviews.freebsd.org/D47562) the TL-WN823N associated immediately while the TL-WN725N took more time to. This current patch set reverses the behaviour. Either way I don't think this is an issue. The T4UH was never affected.
(In reply to Sulev-Madis Silber from comment #62) What type of USB controller does your laptop have? XHCI? EHCI?
(In reply to Cy Schubert from comment #63) Hm, I didn't think my diffs changed RTL8188EU behaviour! The RTL8188E code uses the RTL8192C channel change code but overrides a couple of methods. None of the rest of the power sequencing, channel change or RF register programming is shared with the RTL8192E code.
(In reply to Cy Schubert from comment #64) not laptop at all, this is actually nanopi neo core module on custom pcb and usb wifi with custom headers soldered on and plugged on the side. as allwinner h3 only has usb 2.0 ports at max, i guess it's ehci then. i'm also using just integrated port, one of them, it's not it's otg port. there are no hubs involved either
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=043d6a24b29030989fdf2b79c5ff90391f859225 commit 043d6a24b29030989fdf2b79c5ff90391f859225 Author: Adrian Chadd <adrian@FreeBSD.org> AuthorDate: 2025-01-19 20:16:55 +0000 Commit: Adrian Chadd <adrian@FreeBSD.org> CommitDate: 2025-01-22 21:46:57 +0000 rtwn: add workaround sleep in r92e_set_chan() It /looks/ like there's some weirdness in initial frame send after the chip programming / channel change. Linux rtl8xxxu has no sleeps here, instead it just retries the auth frame a few times. My guess is there's some sequencing going on here between finishing the programming, doing a calibration run and then sending the initial frame. Instead of doing sleeps on every write during the RF channel change, this 10ms sleep at the end is enough to reliably associate in my test environment (12-core intel laptop, USB-3 port.) It's not required for an earlier 2-core haswell laptop w/ USB-3. See the PR for more information. PR: kern/247528 Differential Revision: https://reviews.freebsd.org/D48517 sys/dev/rtwn/rtl8192e/r92e_chan.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)