Realtek RTL8157 5 GbE adapters with 10 Gb USB interface - Wavlink, WisdPi

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
W

WhiteNoise

Member
Jan 20, 2024
82
29
18
Even though I promised myself to not buy another nic, especially another USB one, yesterday I bought another one.

While I was making the last minute, before tariff, purchases on Aliexpress, I noticed this super cheap https://www.aliexpress.us/item/3256808357803191.html

I have seen the complains in this thread, however, I am not 100% sure Realtek is to blame. In the past, I have had issue with some devices and some ports rated USB 10gb (Usb 3 Gen 2x1) and 20gb(Usb 3 Gen 2x2).
 
T

Tinkerer

Member
Sep 5, 2020
95
28
18
Don't think this was mentioned before, but to those who are having stability issues on Linux with Realtek USB-C adapters, try this:

Code: 
echo disable > /sys/class/net/enp1s0f0u1/rtl_adv/sg_en
replace the enp1s0f0u1 with whatever name your USB network adapter has. You can check with ip l for instance.

I have tested it with iperf3 bidirectionally for about 5 minutes and it has been stable. That's really something considering it used to crash within seconds even on simple ping replies.
 
D

dza

New Member
Sep 10, 2023
4
0
1
Here's my notes for my adapter Club3D CAC-2530 5Gbps with R8157 similar to WisdPi, WAVLINK, etc.

You need the latest realtek r8152 driver (2.19.2)

Realtek

www.realtek.com www.realtek.com

I also recommend you install the 50-usb-realtek-net.rules into /usr/lib/udev/rules.d/50-usb-realtek-net.rules
Bash: 
# This is used to change the default configuration of Realtek USB ethernet adapters

ACTION!="add", GOTO="usb_realtek_net_end"
SUBSYSTEM!="usb", GOTO="usb_realtek_net_end"
ENV{DEVTYPE}!="usb_device", GOTO="usb_realtek_net_end"

# Modify this to change the default value
ENV{REALTEK_MODE1}="1"
ENV{REALTEK_MODE2}="3"

# Realtek
ATTR{idVendor}=="0bda", ATTR{idProduct}=="815[2,3,5,6,7]", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="0bda", ATTR{idProduct}=="8053", ATTR{bcdDevice}=="e???", ATTR{bConfigurationValue}!="$env{REALTEK_MODE2}", ATTR{bConfigurationValue}="$env{REALTEK_MODE2}"

# Samsung
ATTR{idVendor}=="04e8", ATTR{idProduct}=="a101", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"

# Lenovo
ATTR{idVendor}=="17ef", ATTR{idProduct}=="304f", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="3052", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="3054", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="3057", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="3062", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="3069", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="3082", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="3098", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="7205", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="720a", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="720b", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="720c", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="7214", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="721e", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="8153", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="a359", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="a387", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"

# TP-LINK
ATTR{idVendor}=="2357", ATTR{idProduct}=="0601", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"

# Nvidia
ATTR{idVendor}=="0955", ATTR{idProduct}=="09ff", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"

# LINKSYS
ATTR{idVendor}=="13b1", ATTR{idProduct}=="0041", ATTR{bConfigurationValue}!="$env{REALTEK_MODE1}", ATTR{bConfigurationValue}="$env{REALTEK_MODE1}"

LABEL="usb_realtek_net_end"
The bConfigurationMode should be 1 to work with the r8152 driver, so if yours for whatever reason has entered a different mode remember this, you can set it back by locating the bus, port in lsusb --tree and using this path in the sysfs dir, example: echo "1" | sudo tee /sys/bus/usb/devices/2-4/bConfigurationValue (here the bus is 002, the port is 004)

The difference between the latest in-kernel (6.14, 6.15) r8157 driver and the Realtek one is that the current kernel does not define 5Gbps only 2.5 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/usb/r8152.c#n1200

You will find 5000 defined in the realtek driver.

Once your realtek driver r8152 v2.19.2 is built, installed you can simply modprobe r8152, you can verify it is your version by comparing modinfo r8152 before and after installing it.

After that your ethtool query sudo ethtool enp15s0u4 should show:

Code: 
$ sudo ethtool enp15s0u4
Settings for enp15s0u4:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
                                5000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
                                5000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
                                             2500baseT/Full
                                             5000baseT/Full
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 5000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00007fff (32767)
                               drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
        Link detected: yes
I couldn't find anything about the Club3D CAC-2530 anywhere, but I figured it must work somehow.. Finally got it working by building their own driver.. It was very confusing that it was already in-kernel I thought it was the same version, but I couldn't see any commits around 2024-11 when Realtek last updated it on their page.

suspend/sleep NOTE: I found that the r8152 driver did not suspend properly, locks on resume if enabled. You can do a simple service to fix this.

INI: 
# /etc/systemd/system/r8152-fix.service

[Unit]
Description=Disable r8152 before sleep
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStart=/usr/sbin/modprobe -r r8152
ExecStop=/usr/sbin/modprobe r8152

[Install]
WantedBy=sleep.target
Bash: 
sudo systemctl daemon-reload
sudo systemctl enable r8152-fix
 
Last edited:
J

jerrythea

Member
Sep 12, 2022
42
21
8
Just as a very important caveat:

I got the above Linux drivers built and working on a Proxmox VE 8 cluster, and everything worked well, except for a huge issue:

If you host an NFS share on a system with one of the USB network adapters, the Linux kernel will get wedged, and eventually hang, and then crash.

I tested this for a few weeks, and confirmed it is the driver iteself, and not the Kernel.

The exact same configuration using 2.5 GBs USB realtek has been rock solid for multiple years.

I was also able to confirm that the more mature AQ drivers were equally rock solid for 10 GBs over Thunderbolt 3/4.

Until I see a mainline kernel with the following code in the source tree, I would not rely on these 5 GBs USB Realtek for use with Linux:
Code: 
# grep -i rtl8157 r8152.[ch]
static int rtl8157_runtime_enable(struct r8152 *tp, bool enable)
static int rtl8157_enable(struct r8152 *tp)
static int rtl8157_change_mtu(struct r8152 *tp)
static int rtl8157_up(struct r8152 *tp)
        ret = rtl8157_change_mtu(tp);
static int rtl8157_down(struct r8152 *tp)
static void rtl8157_unload(struct r8152 *tp)
                ops->enable             = rtl8157_enable;
                ops->up                 = rtl8157_up;
                ops->down               = rtl8157_down;
                ops->unload             = rtl8157_unload;
                ops->autosuspend_en     = rtl8157_runtime_enable;
                ops->change_mtu         = rtl8157_change_mtu;
On Windows and macOS these USB dongles are pretty stable as well, but these are not server platforms designed to be running 24x7x365
 
  • Like
Reactions: rursache, dza, blunden and 1 other person
J

John T Davis

Member
Nov 19, 2022
60
11
8
dza said:
Here's my notes for my adapter Club3D CAC-2530 5Gbps with R8157 similar to WisdPi, WAVLINK, etc.

You need the latest realtek r8152 driver (2.19.2)

Realtek

www.realtek.com www.realtek.com

I also recommend you install the 50-usb-realtek-net.rules into /usr/lib/udev/rules.d/50-usb-realtek-net.rules
Click to expand...
Thanks for posting this. I had some questions about what everything did, since the DKMS driver install from Realtek's GitHub page only pegs the interface name to the next available ethN designation.

At least with the DKMS from GitHub, bConfigurationValue = 1 by default when I checked my install. Everything works, even if the speeds aren't as consistent as I'd like.

I'm getting a correct 5000 Mbps full duplex link speed negotiation according to ethtool, though.

dza said:
suspend/sleep NOTE: I found that the r8152 driver did not suspend properly, locks on resume if enabled. You can do a simple service to fix this.

INI: 
# /etc/systemd/system/r8152-fix.service

[Unit]
Description=Disable r8152 before sleep
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStart=/usr/sbin/modprobe -r r8152
ExecStop=/usr/sbin/modprobe r8152

[Install]
WantedBy=sleep.target
Bash: 
sudo systemctl daemon-reload
sudo systemctl enable r8152-fix
Click to expand...
This is only needed for systems that enter suspend mode, right? It wouldn't be needed for, say, a Proxmox server or some other machine that always stays active?

Until I see a mainline kernel with the following code in the source tree, I would not rely on these 5 GBs USB Realtek for use with Linux:
Click to expand...
@jerrythea What does this code do? It looks like a series of function declarations (and, I assume, implementations).

I'm understanding your comment as saying that once those functions are implemented to add RTL8157 5Gbps hardware support to the kernel, the RTL8157 driver have to work with NFS because otherwise NFS would be broken in a shipping kernel, which can't be allowed.
 
D

dza

New Member
Sep 10, 2023
4
0
1
John T Davis said:
This is only needed for systems that enter suspend mode, right? It wouldn't be needed for, say, a Proxmox server or some other machine that always stays active?
Click to expand...
Correct. Desktop systems that suspend to RAM (also hibernate to disk) is subject to this issue.


@jerrythea What does this code do?

jerrythea said:
... because otherwise NFS would be broken in a shipping kernel, which can't be allowed.
Click to expand...
I think you're correct in that assumption. This "supposed" NFS problem (it might actually be broken fragmentation, not NFS in particular) does not meet the kernels standards. Recently a similar suspend issue was fixed in the bluetooth drivers kernel/git/stable/linux.git - Linux kernel stable tree its a common problem with drivers.
 
J

John T Davis

Member
Nov 19, 2022
60
11
8
dza said:
Correct. Desktop systems that suspend to RAM (also hibernate to disk) is subject to this issue.


@jerrythea What does this code do?


I think you're correct in that assumption. This "supposed" NFS problem (it might actually be broken fragmentation, not NFS in particular) does not meet the kernels standards. Recently a similar suspend issue was fixed in the bluetooth drivers kernel/git/stable/linux.git - Linux kernel stable tree its a common problem with drivers.
Click to expand...
I'm new to using Realtek NICs on Linux with modern drivers (I tried years ago and it was basically impossible). I'm kind of curious how often we can reasonably expect Realtek to update their drivers when issues are reported to them. It's been months since 2.19.2 came out--but on the other hand, the Github for the R8152 driver with DKMS has no issues pending.

I'm currently trying to diagnose an issue exposed by iPerf3--over TCP, sending data to the iPerf3 server shows the expected speed, but receiving data from the iPerf3 server shows a drastic drop. Using UDP, I can see a 60+ percent package loss on the receiver in each case.

Is it possible this is a bad cable, or does it look more like the driver just being awful (or awfully misconfigured)?

Bash: 
# iperf3 -B 10.10.200.19 -c 10.10.200.2 -P 10

[SUM]   0.00-10.00  sec  5.56 GBytes  4.77 Gbits/sec    0             sender
[SUM]   0.00-10.00  sec  5.55 GBytes  4.77 Gbits/sec                  receiver

# iperf3 -B 10.10.200.19 -c 10.10.200.2 -P 10 -R
[SUM]   0.00-10.00  sec  4.41 GBytes  3.79 Gbits/sec  39658             sender
[SUM]   0.00-10.00  sec  4.40 GBytes  3.78 Gbits/sec                  receiver

# iperf3 -B 10.10.200.19 -c 10.10.200.2 -b 0 -u
Connecting to host 10.10.200.2, port 5201
[  5] local 10.10.200.19 port 34382 connected to 10.10.200.2 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec   592 MBytes  4.96 Gbits/sec  69340
[  5]   1.00-2.00   sec   591 MBytes  4.96 Gbits/sec  69290
[  5]   2.00-3.00   sec   591 MBytes  4.96 Gbits/sec  69310
[  5]   3.00-4.00   sec   591 MBytes  4.96 Gbits/sec  69290
[  5]   4.00-5.00   sec   591 MBytes  4.96 Gbits/sec  69310
[  5]   5.00-6.00   sec   591 MBytes  4.96 Gbits/sec  69290
[  5]   6.00-7.00   sec   591 MBytes  4.96 Gbits/sec  69300
[  5]   7.00-8.00   sec   591 MBytes  4.96 Gbits/sec  69300
[  5]   8.00-9.00   sec   591 MBytes  4.96 Gbits/sec  69300
[  5]   9.00-10.00  sec   591 MBytes  4.96 Gbits/sec  69300
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  5.78 GBytes  4.96 Gbits/sec  0.000 ms  0/693030 (0%)  sender
[  5]   0.00-10.00  sec  1.94 GBytes  1.67 Gbits/sec  0.063 ms  460332/692969 (66%)  receiver

# iperf3 -B 10.10.200.19 -c 10.10.200.2 -b 0 -u -R
Connecting to host 10.10.200.2, port 5201
Reverse mode, remote host 10.10.200.2 is sending
[  5] local 10.10.200.19 port 51863 connected to 10.10.200.2 port 5201
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec   457 MBytes  3.83 Gbits/sec  0.022 ms  81965/135469 (61%)
[  5]   1.00-2.00   sec   449 MBytes  3.77 Gbits/sec  0.019 ms  82938/135612 (61%)
[  5]   2.00-3.00   sec   437 MBytes  3.66 Gbits/sec  0.028 ms  85146/136341 (62%)
[  5]   3.00-4.00   sec   450 MBytes  3.77 Gbits/sec  0.033 ms  83644/136363 (61%)
[  5]   4.00-5.00   sec   445 MBytes  3.74 Gbits/sec  0.031 ms  85389/137592 (62%)
[  5]   5.00-6.00   sec   436 MBytes  3.66 Gbits/sec  0.022 ms  87503/138584 (63%)
[  5]   6.00-7.00   sec   436 MBytes  3.66 Gbits/sec  0.023 ms  86542/137692 (63%)
[  5]   7.00-8.00   sec   433 MBytes  3.63 Gbits/sec  0.029 ms  85267/136021 (63%)
[  5]   8.00-9.00   sec   457 MBytes  3.83 Gbits/sec  0.026 ms  85107/138642 (61%)
[  5]   9.00-10.00  sec   459 MBytes  3.85 Gbits/sec  0.019 ms  84844/138603 (61%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  11.4 GBytes  9.82 Gbits/sec  0.000 ms  0/1371380 (0%)  sender
[  5]   0.00-10.00  sec  4.35 GBytes  3.74 Gbits/sec  0.019 ms  848345/1370919 (62%)  receiver
Even with more streams, Reverse mode just bleeds packets.
Bash: 
iperf3 -B 10.10.200.19 -c 10.10.200.2 -b 0 -u -P 10
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec   667 MBytes   560 Mbits/sec  0.000 ms  0/78190 (0%)  sender
[  5]   0.00-10.00  sec   667 MBytes   560 Mbits/sec  0.208 ms  0/78182 (0%)  receiver
[  7]   0.00-10.00  sec   655 MBytes   549 Mbits/sec  0.000 ms  0/76730 (0%)  sender
[  7]   0.00-10.00  sec   655 MBytes   549 Mbits/sec  0.217 ms  0/76721 (0%)  receiver
[  9]   0.00-10.00  sec   626 MBytes   525 Mbits/sec  0.000 ms  0/73330 (0%)  sender
[  9]   0.00-10.00  sec   626 MBytes   525 Mbits/sec  0.138 ms  1/73320 (0.0014%)  receiver
[ 11]   0.00-10.00  sec   619 MBytes   519 Mbits/sec  0.000 ms  0/72500 (0%)  sender
[ 11]   0.00-10.00  sec   619 MBytes   519 Mbits/sec  0.100 ms  0/72500 (0%)  receiver
[ 13]   0.00-10.00  sec   582 MBytes   488 Mbits/sec  0.000 ms  0/68210 (0%)  sender
[ 13]   0.00-10.00  sec   582 MBytes   488 Mbits/sec  0.163 ms  0/68210 (0%)  receiver
[ 15]   0.00-10.00  sec   576 MBytes   483 Mbits/sec  0.000 ms  0/67490 (0%)  sender
[ 15]   0.00-10.00  sec   576 MBytes   483 Mbits/sec  0.225 ms  0/67480 (0%)  receiver
[ 17]   0.00-10.00  sec   562 MBytes   472 Mbits/sec  0.000 ms  0/65910 (0%)  sender
[ 17]   0.00-10.00  sec   562 MBytes   472 Mbits/sec  0.161 ms  0/65910 (0%)  receiver
[ 19]   0.00-10.00  sec   558 MBytes   468 Mbits/sec  0.000 ms  0/65420 (0%)  sender
[ 19]   0.00-10.00  sec   558 MBytes   468 Mbits/sec  0.162 ms  0/65420 (0%)  receiver
[ 21]   0.00-10.00  sec   537 MBytes   450 Mbits/sec  0.000 ms  0/62930 (0%)  sender
[ 21]   0.00-10.00  sec   537 MBytes   450 Mbits/sec  0.163 ms  0/62930 (0%)  receiver
[ 23]   0.00-10.00  sec   532 MBytes   446 Mbits/sec  0.000 ms  0/62360 (0%)  sender
[ 23]   0.00-10.00  sec   532 MBytes   446 Mbits/sec  0.126 ms  0/62360 (0%)  receiver
[SUM]   0.00-10.00  sec  5.78 GBytes  4.96 Gbits/sec  0.000 ms  0/693070 (0%)  sender
[SUM]   0.00-10.00  sec  5.78 GBytes  4.96 Gbits/sec  0.166 ms  1/693033 (0.00014%)  receiver

# iperf3 -B 10.10.200.19 -c 10.10.200.2 -b 0 -u -P 10 -R
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.33 GBytes  1.14 Gbits/sec  0.000 ms  0/159200 (0%)  sender
[  5]   0.00-10.00  sec   501 MBytes   420 Mbits/sec  0.143 ms  100431/159142 (63%)  receiver
[  7]   0.00-10.00  sec  1.28 GBytes  1.10 Gbits/sec  0.000 ms  0/153330 (0%)  sender
[  7]   0.00-10.00  sec   481 MBytes   404 Mbits/sec  0.168 ms  96856/153275 (63%)  receiver
[  9]   0.00-10.00  sec  1.24 GBytes  1.07 Gbits/sec  0.000 ms  0/148820 (0%)  sender
[  9]   0.00-10.00  sec   464 MBytes   389 Mbits/sec  0.177 ms  94414/148764 (63%)  receiver
[ 11]   0.00-10.00  sec  1.20 GBytes  1.03 Gbits/sec  0.000 ms  0/143540 (0%)  sender
[ 11]   0.00-10.00  sec   450 MBytes   378 Mbits/sec  0.225 ms  90721/143480 (63%)  receiver
[ 13]   0.00-10.00  sec  1.15 GBytes   992 Mbits/sec  0.000 ms  0/138530 (0%)  sender
[ 13]   0.00-10.00  sec   432 MBytes   363 Mbits/sec  0.160 ms  87829/138474 (63%)  receiver
[ 15]   0.00-10.00  sec  1.12 GBytes   959 Mbits/sec  0.000 ms  0/133990 (0%)  sender
[ 15]   0.00-10.00  sec   419 MBytes   352 Mbits/sec  0.165 ms  84810/133930 (63%)  receiver
[ 17]   0.00-10.00  sec  1.08 GBytes   925 Mbits/sec  0.000 ms  0/129240 (0%)  sender
[ 17]   0.00-10.00  sec   403 MBytes   338 Mbits/sec  0.214 ms  81953/129184 (63%)  receiver
[ 19]   0.00-10.00  sec  1.05 GBytes   901 Mbits/sec  0.000 ms  0/125820 (0%)  sender
[ 19]   0.00-10.00  sec   393 MBytes   330 Mbits/sec  0.176 ms  79734/125784 (63%)  receiver
[ 21]   0.00-10.00  sec  1.02 GBytes   879 Mbits/sec  0.000 ms  0/122770 (0%)  sender
[ 21]   0.00-10.00  sec   384 MBytes   322 Mbits/sec  0.147 ms  77774/122734 (63%)  receiver
[ 23]   0.00-10.00  sec  1.00 GBytes   862 Mbits/sec  0.000 ms  0/120420 (0%)  sender
[ 23]   0.00-10.00  sec   377 MBytes   317 Mbits/sec  0.160 ms  76156/120384 (63%)  receiver
[SUM]   0.00-10.00  sec  11.5 GBytes  9.85 Gbits/sec  0.000 ms  0/1375660 (0%)  sender
[SUM]   0.00-10.00  sec  4.20 GBytes  3.61 Gbits/sec  0.173 ms  870678/1375151 (63%)  receiver
Also, I'm trying to figure out if the RTL8157 supports any hardware offloading features that aren't turned on by default and should be activated. Here's what ethtool has to say about that, but I'll be honest and say I really don't fully understand what I'm looking at.

If it matters, I have an N100. When I run the speed test, I never see more than 25-30 percent used on a single core (I did get it to spike up to 40 percent once, using 20 parallel connections with UDP). So it's definitely not offloading everything. :p

Bash: 
# ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: on
        tx-checksum-ip-generic: off [fixed]
        tx-checksum-ipv6: on
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: on
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
tx-gso-list: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]
Here are the ones marked OFF (I assume FIXED means they can't be turned on):

Code: 
       tx-checksum-ip-generic: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
tcp-segmentation-offload: on
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp-mangleid-segmentation: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
tx-gso-list: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]
 
Last edited:
J

John T Davis

Member
Nov 19, 2022
60
11
8
Hate to double-post, but I have an update.

After some testing, seems the USB-A to USB-C cable that ships with the NIC is bad. This is apparently a known but inconsistent issue. I replaced it with this one from CableMatters:
Cable Matters [USB-IF Certified] 10Gbps Gen 2 USB A to USB C Cable - 3.3 ft, USBC to USBA Cable, Black, Compatible with iPhone 16/15 Pro Max/Plus

When I first plugged it in and tried `iPerf3`. It was a complete disaster--TX errors all over `dmesg`, a failed `iperf3` test. I flipped the USB-C end of the cable over at the NIC end and it worked. After taking a moment to rage about a USB-C cable and/or device once again failing at working properly in any orientation, I actually noticed the results.


Bash: 
# iperf3 -B 10.10.200.19 -c 10.10.200.2 -b 0 -u -P 10
[SUM]   0.00-10.00  sec  5.78 GBytes  4.96 Gbits/sec  0.000 ms  0/693110 (0%)  sender
[SUM]   0.00-10.00  sec  5.78 GBytes  4.96 Gbits/sec  0.158 ms  0/693110 (0%)  receiver

# iperf3 -B 10.10.200.19 -c 10.10.200.2 -b 0 -u -P 10 -R
Connecting to host 10.10.200.2, port 5201
Reverse mode, remote host 10.10.200.2 is sending
[SUM]   0.00-10.00  sec  11.5 GBytes  9.86 Gbits/sec  0.000 ms  0/1376910 (0%)  sender
[SUM]   0.00-10.00  sec  5.78 GBytes  4.96 Gbits/sec  0.142 ms  683338/1376399 (50%)  receiver


#iperf3 -B 10.10.200.19 -c 10.10.200.2 -P 10 -R
[SUM]   0.00-10.00  sec  5.56 GBytes  4.77 Gbits/sec    0             sender
[SUM]   0.00-10.00  sec  5.55 GBytes  4.77 Gbits/sec                  receiver

#iperf3 -B 10.10.200.19 -c 10.10.200.2 -P 10 -R
Connecting to host 10.10.200.2, port 5201
Reverse mode, remote host 10.10.200.2 is sending
[SUM]   0.00-10.00  sec  5.77 GBytes  4.96 Gbits/sec  8889             sender
[SUM]   0.00-10.00  sec  5.76 GBytes  4.95 Gbits/sec                  receiver
The `iperf3` server is running on a TrueNAS box with a 10 GbE connection, so a 50 percent packet loss when `iperf3` is throwing data at 10 Gbps to a 5 Gbps NIC on UDP is exactly the result I'd expect. Likewise, `-R` mode is a bit slower on TCP mode as well.

Those are spectacular results, IMO.

That said, even with the new cable, this thing has some sort of physical flaw.
Once I verified the performance was now as expected, I put some stickers on the cable and the NIC to show me how they're oriented, and moved the NIC to a new location, without unplugging it from the Proxmox server.
  1. That was enough to offline the NIC until I issued an `ifup -a`. Put another way, the NIC will completely or totally lose connection if it's jostled too much.
  2. It'll also lose connection if it's unplugged from the Proxmox server and plugged back in, at least until the interface is brought back up.
So …

That's not great. It's also been reported by others. So, there's some sort of design or manufacturing flaw at play, I think. I'm thinking there's a bad solder joint where the USB connector is attached, or an issue with the case design that's causing a component inside to make contact with the metal case (?) and short out/auto-power off? It treats being moved around just like being unplugged and plugged back in.
 
  • Like
Reactions: blunden
MountainBofh

MountainBofh

Beating my users into submission
Mar 9, 2024
398
290
63
Realtek just released a new Linux driver for their USB network cards on 05/23/2025. Version is 2.20.1

You can find it here (their site is dog slow right now).

Realtek

www.realtek.com www.realtek.com
 
  • Like
Reactions: John T Davis
J

John T Davis

Member
Nov 19, 2022
60
11
8
MountainBofh said:
Realtek just released a new Linux driver for their USB network cards on 05/23/2025. Version is 2.20.1

You can find it here (their site is dog slow right now).

Realtek

www.realtek.com www.realtek.com
Click to expand...
Thanks for the alert. :)

Am I blind, or are there no release notes? I downloaded the Unix (Linux) version, and the only thing that's changed is the C source code, but I'm not sure I've got the brain to try to re-learn enough C to figure out what they did. :p

EDIT: The WisdiPi WP-UT5 DKMS repo has not yet been updated; I don't seem to be able to file an issue, either. GitHub - wisdpi/wp-ut5_dkms: A DKMS package for easy use of WP-UT5

It appears to track an upstream DKMS repo for the R8152 driver. I've opened an issue there.
See: New Driver Version Released: 2.20.1 on May 23, 2025 · Issue #29 · awesometic/realtek-r8152-dkms
 
Last edited:
T

Tinkerer

Member
Sep 5, 2020
95
28
18
jerrythea said:
Just as a very important caveat:

I got the above Linux drivers built and working on a Proxmox VE 8 cluster, and everything worked well, except for a huge issue:

If you host an NFS share on a system with one of the USB network adapters, the Linux kernel will get wedged, and eventually hang, and then crash.

I tested this for a few weeks, and confirmed it is the driver iteself, and not the Kernel.

The exact same configuration using 2.5 GBs USB realtek has been rock solid for multiple years.

I was also able to confirm that the more mature AQ drivers were equally rock solid for 10 GBs over Thunderbolt 3/4.

Until I see a mainline kernel with the following code in the source tree, I would not rely on these 5 GBs USB Realtek for use with Linux:
Code: 
# grep -i rtl8157 r8152.[ch]
static int rtl8157_runtime_enable(struct r8152 *tp, bool enable)
static int rtl8157_enable(struct r8152 *tp)
static int rtl8157_change_mtu(struct r8152 *tp)
static int rtl8157_up(struct r8152 *tp)
        ret = rtl8157_change_mtu(tp);
static int rtl8157_down(struct r8152 *tp)
static void rtl8157_unload(struct r8152 *tp)
                ops->enable             = rtl8157_enable;
                ops->up                 = rtl8157_up;
                ops->down               = rtl8157_down;
                ops->unload             = rtl8157_unload;
                ops->autosuspend_en     = rtl8157_runtime_enable;
                ops->change_mtu         = rtl8157_change_mtu;
On Windows and macOS these USB dongles are pretty stable as well, but these are not server platforms designed to be running 24x7x365
Click to expand...
 
T

Tinkerer

Member
Sep 5, 2020
95
28
18
Tinkerer said:
Don't think this was mentioned before, but to those who are having stability issues on Linux with Realtek USB-C adapters, try this:

Code: 
echo disable > /sys/class/net/enp1s0f0u1/rtl_adv/sg_en
replace the enp1s0f0u1 with whatever name your USB network adapter has. You can check with ip l for instance.

I have tested it with iperf3 bidirectionally for about 5 minutes and it has been stable. That's really something considering it used to crash within seconds even on simple ping replies.
Click to expand...
And if that doesn't help and you ordered Wavlink devices, contact support.

I got all mine replaced with new ones, return shipping has been refunded. With the new ones you should still use disable sg_en though. Matters very little and makes the driver stable.
 
J

John T Davis

Member
Nov 19, 2022
60
11
8
Tinkerer said:
And if that doesn't help and you ordered Wavlink devices, contact support.

I got all mine replaced with new ones, return shipping has been refunded. With the new ones you should still use disable sg_en though. Matters very little and makes the driver stable.
Click to expand...
How would we know if we had this instability? What are the symptoms? As long as I don't jostle mine too much, it stays connected.

(I really need to contact WisdPi about that …)
 
Last edited:
J

John T Davis

Member
Nov 19, 2022
60
11
8
Tinkerer said:
The driver will crash and connection will fail.
Click to expand...
Thanks! Okay; sounds like I don't have that problem. Mine loses connection (it goes DOWN in ip -a) if it's physically moved too much, but I've never seen an actual driver crash in the console.
 
A

Abzstrak

New Member
Jun 3, 2025
1
0
1
I ran across this thread while googling... I have a 8157 USB ugreen adapter that I've been trying to get running in unraid (2.20.1 driver), but it keeps hard locking the system, console, everything is completely locked up. I kinda gave up for now, running the onboard intel 1g NICs is perfectly stable, but the RTL lasts about an hour or so streaming plex or the like. since unraid boots from usb and runs in ram, this makes looking at logs impossible when it hard locks like this.

i do have a C to A adapter on mine, now Im thinking i should try turning it over, or maybe replacing, like John is having with the wavlink... its weird though since this seems to work just fine and stable on my laptop (Arch) but really hates unraid.
 
U

ugene

New Member
Oct 10, 2024
1
0
1
Hi @spuwho

Can confirm on Windows 11, the Wavlink WL-NWU340G REV refused to work on my usb 3.1 gen 2 ports as well (frequent disconnects)

Unfortunately was unable to replicate your success by connecting:
usb 3.1 gen 2 port ---> usb 3.2 gen 2 hub --> Wavlink WL-NWU340G REV A - still frequently disconnects under load

Sad, got to return it



spuwho said:
I kicked off another round of testing when I saw a small sticker on the box that said "Must use USB 3.2 C-Port".

I have a mini-PC with both a USB 3.1 Gen 2 10Gbps C-Port and a USB4 port.

The results on the USB4 port were excellent. 4.76Gbps on iperf3.

I ran USBView in Windows and noticed the device reports itself as USB 3.2 to the USB Controller.

I was using the Microsoft Realtek drivers that came with Windows Update.

But the results on the USB 3.1 Gen 2 port were terrible.It worked (briefly) then refused to ping or iperf. I thought it was hung so I power cycled (not a reboot) and tried again. This time it wouldn't work at all.

So I power cycled again, but moved it back to the USB4 port and everything was golden. ping, iperf all went through no issues and I got the same results 4.76Gbps.

So I am under a working assumption that USB 3.1 Gen 2 ports (which is what I had on my laptops) are not up to the task, or vary so much in implementation that either there is a USB fallback issue, or a USB timing problem with the USB 3.2 bridge chip in the adapter.

I have a USB 3.2 Gen 2 port on another system. I will see if I have better results there.
Click to expand...
 
J

jerrythea

Member
Sep 12, 2022
42
21
8
MountainBofh said:
Realtek just released a new Linux driver for their USB network cards on 05/23/2025. Version is 2.20.1

You can find it here (their site is dog slow right now).

Realtek

www.realtek.com www.realtek.com
Click to expand...
I have been studying the source code changes from 2.19.2 to 2.20.1.

I know nothing about writing kernel drivers, and no even less about the specifics of these devices, but it is pretty clear that a bunch of error checking and guard conditions have been added to the code base, with this design pattern:
C: 
    ret = ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_RCR1, BIT(3));
    if (ret < 0)
        goto out;
This seems like the type of code changes that would be made to rectify bugs and other edge conditions that maybe, just maybe, we have all been seeing for the last 9 months or so??
 
  • Like
Reactions: rursache
You must log in or register to reply here.
Top Bottom