[Bug 276307] [ure] Unable to ping RTL8153 usb 3.0 to gigabit ethernet adapter (0bda:8153) from connected Windows device after S3 sleep/wake cycling said Windows device (no quirk to set config)

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 14 Jan 2024 01:21:54 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276307

            Bug ID: 276307
           Summary: [ure] Unable to ping RTL8153 usb 3.0 to gigabit
                    ethernet adapter (0bda:8153) from connected Windows
                    device after S3 sleep/wake cycling said Windows device
                    (no quirk to set config)
           Product: Base System
           Version: 15.0-CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: usb
          Assignee: usb@FreeBSD.org
          Reporter: yetoohappy@gmail.com

Read this first:
After writing everything below the dashed line I found
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200693 which says to to run:
usbconfig -d X.Y set_config 1

And this works (although I don't know for how long as the 15-CURRENT live usb I
did this with gets acpi errors in dmesg shortly after, but I'm not sure if
coincidence). If I set this on the ugen device (using 15-CURRENT) before
setting the ip and then set ip after the pinging from the Windows laptop after
S3 sleep/wake cycle worked as well as after physically disconnecting the
interface. It looks like the aforementioned bug report attached a patch which
some variation was committed which changed /head/sys/dev/usb/quirk/usb_quirk.c
to include "USB_QUIRK(REALTEK, RTL8153, 0x0000, 0xffff, UQ_CFG_INDEX_1)," I
don't see this in the current revision of the file at
https://github.com/freebsd/freebsd-src/blob/main/sys/dev/usb/quirk/usb_quirk.c.
It does look like the part of the commit to add RTL8153 vendor and product id
were left intact though
(https://github.com/freebsd/freebsd-src/blob/main/sys/dev/usb/usbdevs#L4064C5-L4064C5)

I am reporting new bug instead of bumping old one in hopes to increase
visibility. Wasted time below dashed line.
-------------------------------------------------
Background:
I encountered this issue when I set up an OPNsense 23.7 box with some usb 3.0
to gigagit ethernet adapters. During set up I was connected some test devices
(which included a laptop with Windows 10 installed) directly to the ethernet
adapters. I found that if the Windows laptop was sleep/wake cycled the ethernet
connection died on the Windows laptop and I needed to restart OPNsense in order
to fix the ethernet connection. I decided to do some more thorough testing with
Freebsd 14.0 stable and FreebSD 15 current and compare it to Fedora 39.
(spoilers Fedora 39 doesn't have this issue)

Setup:
While I wasn't able to test with the exact same model as I experienced with
OPNsense, I believe the differences between them aren't too great. The model I
was using when I first encountered the issue was an Insignia (a Best Buy brand)
NS-PA3U6E. The model I tested for this report is a Best Buy essentials
BE-PA3U6E. I am not able to get the chipset of NS-PA3U6E at the moment, but
BE-PA3U6E is a 3.0 usb to gigabit ethernet adapter with a RTL8153 chipset and
vendor and product id is 0bda:8153.

I used the following live usb images:
1. Freebsd 14 stable (FreeBSD-14.0-RELEASE-amd64-dvd1.iso freebsd
14.0-n265380-f9716eee8ab4 compiled on november 10 05:57:23)
2. Freebsd current snapshot
(FreeBSD-15.0-CURRENT-amd64-20240111-a61d2c7fbd3c-267507-memstick.img)
3. Fedora 39 (linux kernel 6.5.6-300.fc39.x86_64 compiled October 6 19:57:21
UTC 2023)

Thoughout all testing the Windows laptop was assigned ip 192.168.2.1/24 with
gateway 192.168.1.1. A separate laptop as used to boot the live usbs. After
every live usb boot or netif restart the usb to ethernet interface was set to
192.168.1.1.

I have ensured the the Windows laptop was going into S3 sleep and not Modern
Standby.

Testing: 
Freebsd 14.0 stable live usb: 
I booted the live usb, selected live usb mode, and logged in. The relevant
kernel modules were loaded:
if_ure.ko
uether.ko
I assigned ue0 to 192.168.1.1/24 and I could ping 192.168.1.1 from Windows
laptop. But when I did S3 sleep/weke cycle on the Windows laptop it failed to
ping 192.168.1.1 with "Destination host unreachable". 

When I restarted networking via "service netif restart" (or I rebooted the
freebsd live usb) and then assigned ue0 to 192.168.1.1/24 I was able to
successfully ping 192.168.1.1 from the Windows laptop. If I physically
disconnected and reconnected the ethernet on either ends of cable very quickly
(around or less than half a second or so) (one at a time and observation done
after each time) pinging still worked, but if I kept a cable unplugged longer
than very quickly pinging failed with "Destination host unreachable". 

Freebsd most recent current snapshot (as of writing) live usb:
I booted, went into live usb mode, and logged in. The relevant kernel modules
were loaded:
if_ure.ko
uether.ko
I assigned ue0 to 192.168.1.1/24. The same thing happened as with Freebsd 14
stable. When I did S3 sleep/wake cycle on the Windows laptop and pinged
192.168.1.1 ping failed with "Destination host unreachable". I had to restart
networking via "service netif restart" (or reboot the freebsd live usb) and
then assign ue0 to 192.168.1.1/24 to be able to ping 192.168.1.1 from the
Windows laptop. If I physically disconnected and reconnected the ethernet on
either ends of cable very quickly (one end at a time and observation done after
each time) pinging still worked, but if I kept a cable unplugged longer than
very quickly pinging failed with "Destination host unreachable".

Fedora 39 live usb:
I booted, tested the live usb integrity, disabled NetworkManager, and assigned
192.168.1.1/24 to the usb ethernet interface and I was able to ping the fedora
39 live usb at 192.168.1.1 from the Windows laptop. When I put the Windows
laptop to sleep and woke it back up I am still able to ping the Fedora 39 live
usb. I am able to physically disconnect and reconnect the ethernet cable from
both ends two or more times as well as keeping it disconnected for a couple
seconds or longer and I was still able to ping the fedora 39 live usb with no
failure.

What I think:
Freebsd drivers are the problem.

Notes:
If I connected the freebsd 14 live usb laptop to a different machine with
Debian 12 installed (linux kernel 6.1.0-17-amd64) (after disabling
NetworkManager as it was removing ip from interface after not being able to
connect for a period of time), set ip to 192.168.1.2/24, and did S3 sleep/wake
cycle Debian could still ping the live usb laptop. Maybe Linux is doing
something different than Windows, it still doesn't explain why the Freebsd
network needs to be restarted when connected to Windows laptop that sleep/wake
cycled.

-- 
You are receiving this mail because:
You are the assignee for the bug.