Bug 255251 - The ue0 device has an unstable network connection
Summary: The ue0 device has an unstable network connection
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 13.0-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-usb (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-20 09:25 UTC by Roman
Modified: 2024-10-19 19:21 UTC (History)
8 users (show)

See Also:


Attachments
dmesg.boot file when system is started with the Dell adapter attached (11.51 KB, text/plain)
2021-09-26 06:43 UTC, Michael Reim
no flags Details
dmesg.boot file when system is started with an Anker adapter attached (26.51 KB, text/plain)
2021-09-26 06:45 UTC, Michael Reim
no flags Details
Panic hit with Anker adapter (1.69 KB, text/plain)
2021-09-26 06:53 UTC, Michael Reim
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman 2021-04-20 09:25:19 UTC
When I connect an external ethernet card to usb-c, its interface constantly switches from UP to DOWN and back. Only the execution of the command "usbconfig -d 0.11 set_config 1" and the manual launch of the command "dhclient ue0" helps to avoid this.

kernel: ure0 on uhub3
kernel: ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 3.00/31.00, addr 9> on usbus0
kernel: ure0: unknown version 0x6010
kernel: miibus0: <MII bus> on ure0
kernel: rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus0
kernel: rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
kernel: ue0: <USB Ethernet> on ure0
kernel: ue0: Ethernet address: d4:3a:65:xx:xx:xx
kernel: ue0: link state changed to DOWN
kernel: ue0: link state changed to UP
ue0: link state changed to DOWN
kernel: ue0: link state changed to UP
dhclient[59000]: New IP Address (ue0): 192.168.51.200
dhclient[59741]: New Subnet Mask (ue0): 255.255.255.0
dhclient[60075]: New Broadcast Address (ue0): 192.168.51.255
dhclient[60092]: New Routers (ue0): 192.168.51.1
kernel: ue0: link state changed to DOWN
kernel: ue0: link state changed to UP
kernel: ue0: link state changed to DOWN
kernel: ue0: link state changed to UP
dhclient[70375]: New IP Address (ue0): 192.168.51.200
dhclient[71188]: New Subnet Mask (ue0): 255.255.255.0
dhclient[72005]: New Broadcast Address (ue0): 192.168.51.255
dhclient[72582]: New Routers (ue0): 192.168.51.
Comment 1 Li-Wen Hsu freebsd_committer freebsd_triage 2021-04-20 11:39:04 UTC
I guess it's mode an issue in ure(4)
Comment 2 Michael Reim 2021-09-26 06:43:17 UTC
Created attachment 228184 [details]
dmesg.boot file when system is started with the Dell adapter attached
Comment 3 Michael Reim 2021-09-26 06:45:01 UTC
Created attachment 228185 [details]
dmesg.boot file when system is started with an Anker adapter attached
Comment 4 Michael Reim 2021-09-26 06:53:43 UTC
Created attachment 228186 [details]
Panic hit with Anker adapter
Comment 5 Michael Reim 2021-09-26 06:58:53 UTC
I have experienced this problem, too, on a Dell XPS laptop (manufactured late 2019) which has no ethernet socket and thus forces me to use a USB2LAN adapter. I've tried out two: The Dell one that came with the laptop and an Anker one that I've been using without problems e.g. when playing with my Pinebook and FreeBSD. Both are directly (no HUB or such) attached with traditional USB plugs (not USB-C). I've uploaded dmesgs for system starts with either adapter attached.

I've observed that networking generally does work. After installing 13.0, I had trouble running freebsd-update. It started to download files but then the system would lose connection (state for ue0 changes from active to no carrier. Removing the network plug and putting it back didn't help but pulling out the USB connector and reattaching it did. However the same thing happened if I tried to run freebsd-update again.

Updating briefly worked with the other (Anker) adapter, so I continued building my system. I was able to zfs send over 100GB to the laptop without the network having any issue, install a lot of packages for desktop use and so on. But when I tried to use Ansible to provision another machine from the XPS, network connection would immediately break. So I decided to clone the FreeBSD source and update to 14-CURRENT to see if it happens there, too. Unfortunately cloning a git repo triggers the same problem.

Therefore I cloned it on another machine and scp'd it over. System is running 14-CURRENT now and the situation has improved (cloning seems to work now) and Ansible can do a few tasks instead of losing connection immediately, but ultimately it still fails after a moment.

This is all a bit weird. I know that the Anker one works just fine with other hardware and I briefly tested the Dell one on another laptop as well without any problems. And since 14-CURRENT behavior definitely is different from 13.0, some related work seems to have been done. A former co-worker used the machine with Ubuntu installed and I don't know of any network issues.

I hope this helps with identifying what the actual problem is. I'd be happy to answer questions or provide additional info.
Comment 6 Jean-Sébastien Pédron freebsd_committer freebsd_triage 2021-10-22 22:56:10 UTC
I'm also getting unstable connections with two Realtek Ethernet USB-C adapters.

The first one is inside a Dell W19TB docking station. The second one is a standalone adapter. The laptop (a Dell Precision 5540) has no internal RJ45, so I'm stuck with the external ones...

I also configured if_lagg on top of if_ure to use wifi when I unplug the Ethernet cable.

The symptoms are losses of connections/packets. I don't see the DOWN/UP events from ue0 however. Perhaps they are "hidden" by the use of if_lagg. I enabled if_ure debugging with hw.usb.ure=1 but it doesn't log anything so far.

I will try to capture USB packets using usbdump(8) as described in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244845 (another bug report about if_ure) and share everything I can.
Comment 7 Ali Abdallah 2022-04-15 09:24:10 UTC
This is must be related to bug 252165. It is a race condition between ure_tick and ure_ifmedia_sts I'm trying to understand since some time...

I'm currently using a workaround (bug 252165 comment 3) to get rid of the issue.
Comment 8 Jonathan Vasquez 2022-06-17 02:05:18 UTC
I'm also experiencing this on FreeBSD leslie 13.1-STABLE FreeBSD 13.1-STABLE #0 stable/13-n251124-026e19496cc: Thu Jun 16 19:22:47 EDT 2022     root@leslie:/usr/obj/usr/src/amd64.amd64/sys/DEBUG amd64.

Ethernet over USB-C using this (Anker PowerExpand+ 7-in-1 USB-C PD Ethernet Hub):

https://www.amazon.com/gp/product/B07PPGWQ15/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1


You can see the dongle below (I believe it's ure0 (and acccessed with ue0)):

uhid0 on uhub0
uhid0: <Control Interface> on usbus1
uhid1 on uhub3
uhid1: <Logitech USB Receiver, class 0/0, rev 2.00/24.11, addr 3> on usbus1
uhid2 on uhub3
uhid2: <Microsoft Microsoft 2.4GHz Transceiver v9.0, class 0/0, rev 2.00/7.97, addr 5> on usbus1
ums0 on uhub3
ums0: <Logitech USB Receiver, class 0/0, rev 2.00/24.11, addr 3> on usbus1
ums0: 16 buttons and [XYZT] coordinates ID=2
ums1 on uhub3
ums1: <Microsoft Microsoft 2.4GHz Transceiver v9.0, class 0/0, rev 2.00/7.97, addr 5> on usbus1
ums1: 5 buttons and [XYZT] coordinates ID=26
ums1: 0 buttons and [T] coordinates ID=0
ure0 on uhub3
ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 2.10/30.00, addr 4> on usbus1
miibus0: <MII bus> on ure0
rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
ue0: <USB Ethernet> on ure0
ue0: Ethernet address: a0:ce:c8:d3:ca:0a
iichid0: <FRMW0001:01 32AC:0006 I2C HID device> at addr 0x50 on iicbus10
iichid0: Interrupt setup failed. Fallback to sampling
hidbus0: <HID bus> on iichid0
iichid1: <PIXA3854:01 093A:0274 I2C HID device> at addr 0x2c on iicbus11
iichid1: Interrupt setup failed. Fallback to sampling
hidbus1: <HID bus> on iichid1
Comment 9 Jonathan Vasquez 2022-06-17 02:06:02 UTC
Btw, this is just a GENERIC kernel with the following:

include GENERIC
ident DEBUG

options INVARIANTS
options INVARIANT_SUPPORT
Comment 10 Jonathan Vasquez 2024-04-27 00:07:09 UTC
I believe that due to my previous faulty framework mainboard, that may have affected my network adapter. I recently got the mainboard replaced and haven't been having issues, but I'll need more time to test.