Bug 233949

# cat /boot/loader.conf 
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
zfs_load="YES"
legal.realtek.license_ack=1
if_rtwn_pci_load="YES"
if_rtwn_usb_load="YES"
pf_load="YES"

# cat /etc/rc.conf
...
ifconfig_em0="DHCP"
wlans_rtwn0="wlan0"
ifconfig_wlan0="WPA DHCP"
...

Comment 2 Andriy Voskoboinyk 2018-12-12 23:38:48 UTC

Hi,

Ping times are a bit unstable - how many APs in range? (ifconfig wlan0 list scan)

You can try to disable some (or all) 11n features - there may be a reason of packet loss:
1) ifconfig wlan0 -shortgi
2) ifconfig wlan0 -ampdutx
3) ifconfig wlan0 -amsdutx

If nothing helps, try to force 11g mode:
ifconfig wlan0 channel 11:g

I have two SSIDs from one WAP,
# ifconfig wlan0 list scan
SSID/MESH ID                      BSSID              CHAN RATE    S:N     INT CAPS
WAPGUEST                       82:2a:a8:d7:ec:a5   11   54M  -81:-95   100 EPS  BSSLOAD HTCAP WME ATH RSN
WAPNAME                      80:2a:a8:d7:ec:a5   11   54M  -83:-95   100 EPS  BSSLOAD HTCAP WME ATH RSN
# ping -c 100 -q 172.30.8.65
PING 172.30.8.65 (172.30.8.65): 56 data bytes

--- 172.30.8.65 ping statistics ---
100 packets transmitted, 98 packets received, 2.0% packet loss
round-trip min/avg/max/stddev = 8.787/20.475/77.679/12.369 ms
#  
# ifconfig wlan0 -shortgi
# ping -c 100 -q 172.30.8.65
PING 172.30.8.65 (172.30.8.65): 56 data bytes

--- 172.30.8.65 ping statistics ---
100 packets transmitted, 99 packets received, 1.0% packet loss
round-trip min/avg/max/stddev = 9.907/31.190/1020.956/101.438 ms
# ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 74:da:38:d5:f5:4b
	inet 172.30.8.76 netmask 0xffffffc0 broadcast 172.30.8.127 
	groups: wlan 
	ssid WAPNAME channel 11 (2462 MHz 11g ht/20) bssid 80:2a:a8:d7:ec:a5
	regdomain FCC country US authmode WPA2/802.11i privacy ON
	deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60
	protmode CTS ht20 ampdulimit 64k ampdudensity 8 -stbc -ldpc wme
	roaming MANUAL
	media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
	status: associated
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
# ifconfig wlan0 -ampdutx
# ping -c 100 -q 172.30.8.65
PING 172.30.8.65 (172.30.8.65): 56 data bytes

--- 172.30.8.65 ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.537/21.692/70.821/10.093 ms
# ifconfig wlan0 ampdutx
# ifconfig wlan0 amsdutx
# ping -c 100 -q 172.30.8.65
PING 172.30.8.65 (172.30.8.65): 56 data bytes

--- 172.30.8.65 ping statistics ---
100 packets transmitted, 99 packets received, 1.0% packet loss
round-trip min/avg/max/stddev = 11.616/31.129/1034.261/101.653 ms
# ping -c 100 -q 172.30.8.65
PING 172.30.8.65 (172.30.8.65): 56 data bytes
f
--- 172.30.8.65 ping statistics ---
100 packets transmitted, 99 packets received, 1.0% packet loss
round-trip min/avg/max/stddev = 11.069/29.829/1092.987/107.861 ms
# ifconfig wlan0 -amsdutx
# ping -c 100 -q 172.30.8.65
PING 172.30.8.65 (172.30.8.65): 56 data bytes

--- 172.30.8.65 ping statistics ---
100 packets transmitted, 99 packets received, 1.0% packet loss
round-trip min/avg/max/stddev = 10.609/28.940/1082.781/106.818 ms
# ifconfig wlan0 amsdutx
# ifconfig wlan0 ampdutx
# ifconfig wlan0 
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 74:da:38:d5:f5:4b
	inet 172.30.8.76 netmask 0xffffffc0 broadcast 172.30.8.127 
	groups: wlan 
	ssid WAPNAME channel 11 (2462 MHz 11g ht/20) bssid 80:2a:a8:d7:ec:a5
	regdomain FCC country US authmode WPA2/802.11i privacy ON
	deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60
	protmode CTS ht20 ampdulimit 64k ampdudensity 8 -stbc -ldpc wme
	roaming MANUAL
	media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
	status: associated
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
# ifconfig wlan0 channel 11:g
# ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 74:da:38:d5:f5:4b
	inet 172.30.8.76 netmask 0xffffffc0 broadcast 172.30.8.127 
	groups: wlan 
	ssid WAPNAME channel 11 (2462 MHz 11g ht/20) bssid 80:2a:a8:d7:ec:a5
	regdomain FCC country US authmode WPA2/802.11i privacy ON
	deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60
	protmode CTS ht20 ampdulimit 64k ampdudensity 8 -stbc -ldpc wme
	roaming MANUAL
	media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
	status: associated
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
# ping -c 100 -q 172.30.8.65
PING 172.30.8.65 (172.30.8.65): 56 data bytes

--- 172.30.8.65 ping statistics ---
100 packets transmitted, 84 packets received, 16.0% packet loss
round-trip min/avg/max/stddev = 10.599/175.849/2100.622/391.322 ms
# 

Using the -ht flag doesn't improve performance, and I can replicate this issue across three different, identical NICs.

I've run a PCAP on the gateway, as well as the host, and it would appear that it largely affects the receive queue and it's asymmetrical sends-receives. The packet loss is on the reception side.

I think the tx/rx queues are jacked. I get 100% packet transfer in DragonFlyBSD and 100% in OpenBSD. I am unsure about the code re-architecture.

Is there something you are doing to produce this issue? I do not have this problem on my end. I have an RTL8188EU and it works without packet loss for me.

I am just performing an ICMP-echo to my gateway with the rtwn(4) driver. I have determined that it's neither the 80211 stack nor the NIC because I get 0% packet loss with DFlyBSD/OpenBSD and their urtwn(4) driver.

While performing the ICMP-echo with the gateway, I've captured a PCAP on the gateway and the FreeBSD host; I see FreeBSD sending the ICMP-echo, and I see the gateway receiving it and sending the ICMP-reply back. But on the FreeBSD/12-RELEASE and FreeBSD/13-CURRENT host, the ICMP-replies are not showing in the PCAP.

I am using an EDIMAX N150 (RTL8192CU) wireless NIC, as outlined in my usbconfig dump.

Comment 8 Andriy Voskoboinyk 2019-01-19 16:05:22 UTC

This is RTL8192CU-specific - I can reproduce the packet loss with RTL8188CUS, but not with others.

Created attachment 201576 [details]
Performance and changes

I am unsure as to what is happening, but I referred to the DrangonflyBSD urtwn(4) driver for some guidance. It's odd that this change improved performance from 25% packet loss to ~1% packaet loss. Any ideas?

It seems there are some data type mismatches, which may be resulting in undefined behavior. This is probably more appropriate, after reviewing the data structures...
Index: /usr/src/sys/dev/rtwn/rtl8192c/r92c_rx.c
===================================================================
--- /usr/src/sys/dev/rtwn/rtl8192c/r92c_rx.c    (revision 343552)
+++ /usr/src/sys/dev/rtwn/rtl8192c/r92c_rx.c    (working copy)
@@ -83,10 +83,10 @@
 r92c_get_rssi_ofdm(struct rtwn_softc *sc, void *physt)
 {
        struct r92c_rx_phystat *phy = (struct r92c_rx_phystat *)physt;
-       int rssi;
+       uint8_t rssi = phy->pwdb_all;
 
        /* Get average RSSI. */
-       rssi = ((phy->pwdb_all >> 1) & 0x7f) - 110;
+       rssi = ((rssi >> 1) & 0x7f) - 110;
 
        return (rssi);
 }

If my diff @2019-02-04 21:07:00 UTC, proves to resolve packet loss on RTL8192CU and RTL8188CU, then this may be resolved. My RTL8192CU has an acceptable number of packet loss <1%.

I will however open another ticket regarding performance, as it's getting "dial-up speeds."

Okay - this is confusing; Linux is reporting this device as RTL8188CUS, which is it?

Bus 006 Device 003: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]

Comment 13 commit-hook 2019-03-04 03:04:22 UTC

A commit references this bug:

Author: avos
Date: Mon Mar  4 03:02:15 UTC 2019
New revision: 344745
URL: https://svnweb.freebsd.org/changeset/base/344745

Log:
  rtwn_usb(4): fix Tx instability with RTL8192CU chipsets

  - Fix data frames transmission via POWER_STATUS register setup -
  it seems to be set by MACID_CONFIG firmware command, which was broken*
  in r290439 and later disabled in r307529.

  We can re-enable it later if / when firmware rate adaptation will be
  ready; however, this step will be required anyway - for firmware-less
  builds.

  - Force RTS / CTS protection frame rate to CCK1 (this rate works fine
  without any additional setup; no better workaround is known yet).

  The problem was not observed on the channel 1 or with CCK1 rate enforced
  ('ifconfig wlan0 ucastrate 1' for 11 b/g; not possible for 11n networks
  due to ifconfig(8) bug).

  * I'm not sure if it works before r290439 because - AFAIR - I never seen
  firmware rate adaptation working for 10-STABLE urtwn(4)
  (It needs EN_BCN bit set and RSSI updates at least).

  Tested with RTL8188CUS in STA mode
  (in regular mode and with disabled MRR - DARFRC*8 is set to 0)

  PR:		233949
  MFC after:	2 weeks

Changes:
  head/sys/dev/rtwn/rtl8192c/r92c_reg.h
  head/sys/dev/rtwn/rtl8192c/r92c_tx.c
  head/sys/dev/rtwn/rtl8192c/usb/r92cu_init.c

Comment 14 Andriy Voskoboinyk 2019-03-06 08:38:58 UTC

Can you reproduce the issue with committed fix?

Comment 15 commit-hook 2019-03-18 02:57:26 UTC

A commit references this bug:

Author: avos
Date: Mon Mar 18 02:56:52 UTC 2019
New revision: 345253
URL: https://svnweb.freebsd.org/changeset/base/345253

Log:
  MFC r344745:
  rtwn_usb(4): fix Tx instability with RTL8192CU chipsets

  PR:		233949

Changes:
_U  stable/12/
  stable/12/sys/dev/rtwn/rtl8192c/r92c_reg.h
  stable/12/sys/dev/rtwn/rtl8192c/r92c_tx.c
  stable/12/sys/dev/rtwn/rtl8192c/usb/r92cu_init.c

Comment 16 commit-hook 2019-03-18 02:59:30 UTC

A commit references this bug:

Author: avos
Date: Mon Mar 18 02:58:35 UTC 2019
New revision: 345254
URL: https://svnweb.freebsd.org/changeset/base/345254

Log:
  MFC r344745:
  urtwn(4): fix Tx instability with RTL8192CU chipsets

  PR:		233949

Changes:
_U  stable/11/
  stable/11/sys/dev/urtwn/if_urtwn.c
  stable/11/sys/dev/urtwn/if_urtwnreg.h

# uname -U; uname -K
1300074
1300074

# tail /var/log/messages
Jan  8 12:30:15 fb13c01 kernel: rtwn0: at uhub0, port 1, addr 1 (disconnected)
Jan  8 12:30:15 fb13c01 kernel: rtwn0: r92c_handle_c2h_task: C2H report 15 (len 15) was not handled
Jan  8 12:30:15 fb13c01 kernel: wlan0: link state changed to DOWN
Jan  8 12:30:15 fb13c01 kernel: rtwn0: detached
Jan  8 12:30:22 fb13c01 kernel: usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT
Jan  8 12:30:23 fb13c01 kernel: usbd_req_re_enumerate: addr=1, set address failed! (USB_ERR_IOERROR, ignored)
Jan  8 12:30:29 fb13c01 kernel: usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT
Jan  8 12:30:30 fb13c01 kernel: usbd_req_re_enumerate: addr=1, set address failed! (USB_ERR_IOERROR, ignored)
Jan  8 12:30:36 fb13c01 kernel: usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT
Jan  8 12:30:36 fb13c01 kernel: usbd_req_re_enumerate: addr=1, set address failed! (USB_ERR_IOERROR, ignored)
Jan  8 12:30:42 fb13c01 kernel: usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT
Jan  8 12:30:43 fb13c01 kernel: usbd_req_re_enumerate: addr=1, set address failed! (USB_ERR_IOERROR, ignored)
Jan  8 12:30:49 fb13c01 kernel: usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT
Jan  8 12:30:49 fb13c01 kernel: ugen0.2: <Unknown > at usbus0 (disconnected)
Jan  8 12:30:49 fb13c01 kernel: uhub_reattach_port: could not allocate new device

Comment 18 Kubilay Kocak 2020-07-31 03:26:21 UTC

^Triage: 

- Assign to committer that resolved
- Track merges

@Reporter If this is still an issue, please re-open with additional details and steps to reproduce

Comment 19 commit-hook 2024-12-19 16:08:50 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=eb6314510c882472628984e6190e39a6ab70687e

commit eb6314510c882472628984e6190e39a6ab70687e
Author:     Adrian Chadd <adrian@FreeBSD.org>
AuthorDate: 2024-12-11 05:16:54 +0000
Commit:     Adrian Chadd <adrian@FreeBSD.org>
CommitDate: 2024-12-19 16:07:28 +0000

    rtwn: disable a workaround introduced earlier for RTL8192CU TX performance

    I'm unable to reproduce the original problem with my RTL8192CU USB
    devices with the current codebase and I can't find any reference
    to what this power register is doing - I see it defined in drivers,
    but it's not described or used anywhere.

    This reverts 7f740971658d71c1ee95ee68032b4696c1684845 -
    rtwn_usb(4): fix Tx instability with RTL8192CU chipsets

    In any case being able to do higher rate RTS/CTS is beneficial.

    Local testing:

    * rtl8192cu, STA mode, TX/RX testing

    PR:             233949

    Differential Revision:  https://reviews.freebsd.org/D48026
    Reviewed by:    imp

 sys/dev/rtwn/rtl8192c/r92c_tx.c        | 6 ------
 sys/dev/rtwn/rtl8192c/usb/r92cu_init.c | 2 --
 2 files changed, 8 deletions(-)