Date: Sun, 14 Jan 2024 01:21:54 +0000 From: bugzilla-noreply@freebsd.org To: usb@FreeBSD.org Subject: [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) Message-ID: <bug-276307-19105@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276307 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=3D200693 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 u= sb 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 af= ter S3 sleep/wake cycle worked as well as after physically disconnecting the interface. It looks like the aforementioned bug report attached a patch whi= ch some variation was committed which changed /head/sys/dev/usb/quirk/usb_quir= k.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_quir= k.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#L4064= C5-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 devic= es (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 ethe= rnet connection died on the Windows laptop and I needed to restart OPNsense in o= rder 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 mode= l I was using when I first encountered the issue was an Insignia (a Best Buy br= and) 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 a= nd 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:=20 Freebsd 14.0 stable live usb:=20 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".=20 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 quic= kly (around or less than half a second or so) (one at a time and observation do= ne after each time) pinging still worked, but if I kept a cable unplugged long= er than very quickly pinging failed with "Destination host unreachable".=20 Freebsd most recent current snapshot (as of writing) live usb: I booted, went into live usb mode, and logged in. The relevant kernel modul= es 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 resta= rt 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 a= fter 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 assig= ned 192.168.1.1/24 to the usb ethernet interface and I was able to ping the fed= ora 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 l= ive usb. I am able to physically disconnect and reconnect the ethernet cable fr= om 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/w= ake 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/w= ake cycled. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-276307-19105>