These are very popular with USB(-c) hubs that include an ethernet (gigabit) port. They are based around the ASIX AX88179 chip.
Examples of such hubs that have been tested by me and suffer from this issue are the following:
- UGREEN USB C Hub, USB C Hub Multiport Adapter with 4K 60Hz HDMI,100W Power Delivery, RJ45 Ethernet, 2 USB 3.0 5Gbps Data Ports, for MacBook Air, MacBook Pro, XPS, and More
- USB C Hub, Dockteck 6 in 1 USB-C Ethernet PD Hub Adapter with 4K 60Hz HDMI, 100W Power Delivery, USB-C Data Port, 1Gbps Ethernet, 2 USB Ports, for MacBook Pro/Air M1, iPad Pro, HP Laptop
- USB C Hub, Dockteck 7-in-1 USB-C Hub Multiport Adapter with 4K@60Hz HDMI, Ethernet Port, 100W PD, 2 USB 3.0, SD/microSD, for MacBook Pro/Air, iPad Pro/Air/Mini 6, XPS 13 and More
You can notice how these are essentially the same hardware under different names, shapes and sizes. They all use the same ASIX chip.
Most USB(-c) to ethernet adapters (no HDMI) use the more common Realtek 8152 or 8153, which work perfectly out of the box. This guide is not for those adapters (since they work fine).
For example this thing here, works great (but no HDMI and/or charging, so a different device altogehter).
Ethernet disconnects and reconnects all the time with output similar to this:
Oct 03 11:09:20 kepler kernel: ax88179_178a 2-2.2:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-2.2, ASIX AX88179 USB 3.0 Gigabit Ethernet, 08:26:ae:36:4d:66
Oct 03 11:09:21 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2: renamed from eth0
Oct 03 11:09:22 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2: Failed to read reg index 0x0040: -32
Oct 03 11:09:24 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2: ax88179 - Link status is: 1
Oct 03 11:09:26 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2: unregister 'ax88179_178a' usb-0000:00:14.0-2.2, ASIX AX88179 USB 3.0 Gigabit Ethernet
Oct 03 11:09:26 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2: Failed to read reg index 0x0009: -19
Oct 03 11:09:26 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2: Failed to read reg index 0x000a: -19
Oct 03 11:09:26 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2: Failed to read reg index 0x0004: -19
Oct 03 11:09:26 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2: Failed to read reg index 0x0005: -19
Oct 03 11:09:26 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2: Failed to read reg index 0x0002: -19
Oct 03 11:09:26 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2: Failed to write reg index 0x0002: -19
Oct 03 11:09:26 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2 (unregistered): Failed to write reg index 0x0002: -19
Oct 03 11:09:26 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2 (unregistered): Failed to write reg index 0x0001: -19
Oct 03 11:09:26 kepler kernel: ax88179_178a 2-2.2:1.0 enp0s20f0u2u2 (unregistered): Failed to write reg index 0x0002: -19
Oct 03 11:09:27 kepler kernel: ax88179_178a 2-2.2:1.0 (unnamed net_device) (uninitialized): Failed to read reg index 0x0040: -32
And the loop restarts.
This clearly makes the adapter completely unusable for ethernet use.
This problem is documented also in this kernel bug (ID 212731):
USB Ethernet adapter ASIX AX88179 disconnects under heavy load.
Althouth it's mentioned that kernels from 5.19 should work fine (and that a fix has been applied), the problem persists. I have tried all Fedora kernels from 5.18 to 5.19.12 (as of today), and the problem persists. The problem also persists on Pop!_OS 22.04 with 5.17 all the way to 5.19 and Ubuntu 22.04 with 5.15 (and backports).
To compile and install a different driver.
I have tried this driver provided by nothingstopsme here: https://github.com/nothingstopsme/AX88179_178A_Linux_Driver
Clone the repo to your disk, then enter the source folder, and do make and sudo make install and reboot. That's it.
It appears there are two drivers sources, one from the manufacturer, used in the kernel, and one from the community (?), which is the one used by nothingstopsme in his github page. Currently the effort is to get the manufacturer based driver to work in the kernel, and while there has been some work (as reported here) the problem stil persists.
You need to compile the driver and install it again for each new kernel. Sorry.