I have noticed ongoing issues using a USB-C adapter with the Realtek 8152 chipset on x86_64.
(Note: BIOS version on PC is current)
This issue has been ongoing across multiple versions of OpenWRT from 22.x through current stable release 24.10.0, though the frequency of occurrence has reduced with newer versions.
(On 22.x would happen randomly 3 - 4 times a month, whereas on version 23.05.5 twice a month.)
It has happened once on 24.10.0 stable since upgrading last week.
kern.warn kernel: [10339.357134] r8152 4-1.1:1.0 eth1: Tx status -71
[10349.062409] net_ratelimit: 158 callbacks suppressed
49139 Fri Mar 7 07:09:39 2025 kern.warn kernel: [10349.062422] r8152 4-1.1:1.0 eth1: Tx status -71
49140 Fri Mar 7 07:09:39 2025 kern.warn kernel: [10349.075200] r8152 4-1.1:1.0 eth1: Tx status -71
( Connectivity is then broken. The Tx status -71 repeats continuously in the log until the adapter is physically disconnected / reconnected. Then the adapter works again. )
# lsusb -t
/: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/4p, 5000M
|__ Port 001: Dev 003, If 0, Class=[unknown], Driver=r8152, 5000M
# lsusb
Bus 004 Device 003: ID 17ef:7214
I have spent a couple of hours searching on both this forum and the internet in general.
Based on what I have found this isn't specific to PC / host device model, the specific adapter model I have, or limited to just OpenWRT either. Similar issues with multiple NIC adapters with the r8152 chipset are reported on different distributions of Linux, PCs of various manufacturer branding , and Nano Pis.
Here is a forum post from @alexmelSC on 2025-03-02 with a similar yet different issue with r8152 on NanoPi RS2: https://forum.openwrt.org/t/nanopi-r2s-usb-ethernet-fail-how-to-fix/226412/2?u=justanotherenduser
The issue reported there was an entirely different error, and had additional error messages not showing in my logs. (Because of the differences reported in that post, I was inclined to create my own thread rather than add to that one. )
Here is the associated bug report by @alexmelSC
Would appreciate suggestions, or information if the devs know of an updated r8152 firmware that may be coming that would address this issue. ( Or could the source for the alternate "Immortal" driver referenced in the link above be modified and incorporated into OpenWRT? ) Thank you.
and if you're using the device for vlan or perhaps other things that make 'devices' make sure the mtu of the base device is greater than the added devices
eg set eth0 to mtu 2048 and the vlan interfaces to 1500
An update on this. I did some additional searching based on your suggestion (thanks again). I found various posts suggesting to disable offloading, or noting various issues ( not just specfic to a single adapter or chipset )
Among those: https://access.redhat.com/solutions/20278
Anyway, for now I have added this to startup for testing:
Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
/usr/bin/setterm --blank 1 > /dev/tty0
/usr/sbin/ethtool --set-eee eth0 eee off
/usr/sbin/ethtool --set-eee eth1 eee off
/usr/sbin/ethtool -K eth1 gro off
/usr/sbin/ethtool -K eth1 gso off
exit 0
I already had the "Energy Efficient Ethernet" set to off because of the issues noted in 24.10.0 thread, but have now added gro / gso off. I have left TCP-segmentation-offload enabled.
When I check with ethtool and grep offload, I see there are some types that show "off [fixed]" so guessing those are hard set to off at the driver or kernel level?
# ethtool -k eth1|grep offload
tcp-segmentation-offload: on
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
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]
macsec-hw-offload: off [fixed]
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]
I will test with this config for now and see how it goes.
I also looked around a bit, I think you can specifically disable the gro fraglist with:
ethtool -K [name of device] rx-gro-list off
Which is specifically what Openwrt enables by default. Obviously you've decided to just disable all offloading, which i'm not sure will be best for performance, or even stability as well.
Looking around I saw some talk here:
Which led to here:
So i'm guessing if the usb device is the one you're using for WAN, it might be best to disable it anyway and enable "rx-udp-gro-forwarding" instead
ethtool -K [name of device] rx-gro-list off rx-udp-gro-forwarding on
An update for anyone having similar issue or that is following this thread. It is the 5th day testing with the configuration shown in post 4 of this thread. There has not been any recurrence of issue so far. Due that the frequency of issue was randomly only 2 - 4 times a month though will be looking to test this same configuration for at least another 3 weeks for more solid validation of its effect.
On the subject of performance, there has not been any noticeable degradation whatsoever. ( @wilsonyan - I'm not using Tailscale, so applicable issues there.)
From the perspective of having multiple PCs, IOTs, and two streaming televisions all simultaneously connected, all perform as expected without issue. I have also been throwing in some repeated, random speed tests (while other devices connected ) just to put on some extra load. The results of the speed tests compared to ones run before the configuration change (to disable offloading) are almost identical.
I am running OpenWRT x86_64 on a multi-core PC, which never really breaks a sweat. Even under heavy traffic load, the CPU utilization on all cores typically stays below 15%.
On average the typical system load measurement stays below 0.3 out of 4.
The point being that even if disabling offloading were to put some extra load on the CPU, seems negligible.
Being that the network adapter in question is an externally attached USB-C device, I don't even know if it actually has an ability to offload anyway. I can't find any definitive information on the manufacturer's website. Could it be that all of the overhead of the adapter goes through the bus and always puts the load on the CPU?
I don't know if this will help... I once had a work laptop I would use in my home office, which required an external USB ethernet adapter. I went through 3 or 4 adapters with different chipsets and each would appear stable for maybe a week or two at a time, and then stop working until disconnected and reconnected, as in your first message. Eventually, what worked for me was to use an adapter with an integrated USB hub, which somehow made the thing more reliable for me. The exact adapter I used was https://www.amazon.com/dp/B0871ZHCKK .
It's not clear to me what the underlying issue was, as I stopped looking into it after I finally found an adapter that worked.
Posting an update on testing since disabling gro / gso offloading on the NIC.
So far there have been no more "Status -71" errors or other issues.
Because of the sporadic nature of the issue, intending to test for another two weeks. (Historically the span between repeat occurrences would occur within 30 days.)
On a side note from further searching / reading on the net about 'ethtool' usage to check status / change settings, I was led to another discovery. I found that on the same adapter, there were rx_missed errors. This was defined in a Stack Exchange post as meaning: "...packets which the NIC received but had to drop [and/or re-transmit] because they couldn’t be stored or processed — typically, because the FIFO they would have gone to was full." Stack Exchange - RX_Missed
The post suggested increasing the RX buffer gradually and retesting. I did this over a span of several days. Initially the buffer on the adapter was at the default setting of 100 ( out of 4092 max setting).
With the default buffer of a 100, the rx_missed count was 8598 packets (out of 3,170,444 total ).
Dividing the missed count into the total is an approximate average of 1 out of every 378 packets 'missing'
which is a missed / total ratio of 1:749
If I am looking at this correctly then the buffer increases are helping.
Not sure about what all other factors I should be taking into consideration.
With all the searching I've done not sure why I am just finding this now!
The proposed fix for my error (TX status -71) and the error from @alexmelSC's thread linked above (TX status -2), is setting a USB quirk. Detailed in this Arch Linux Wiki page:
(part. 3.8 at the bottom of the page )
Specifically:
I will try this quirk. Hopefully it will work. I still think it was a good thing to disable the offloading though. That alone may have helped mitigate the issue.
This thread has been open for one month,and I am calling it solved at this point.
Ultimately I believe the fix to be in thread post 9 above.
The answer being in the linked Arch Linux Wiki that details the issue and USB quirk workaround to disable power management on the adapter.
This was specifically noted in the linked post to affect Realtek 8152 / 8153 chipsets. If you are getting the Status -71 / -72 on other model adapters though, perhaps the fix will be also applicable to yours.
( Using lsusb command to find the device id of the USB network adapter, then adding that address with :k (disable PM ) on the end either to Grub kernel parameters, or to the /sys/module/usbcore/parameters/quirks file. example: abcd:1234:k )
In addition to the quirk, I have decided to also keep all of the offloading turned off. There has been no noticiable performance impact, plus also read in the 24.10.0-Stable Release thread a discussion of a leak issue that can be caused if GRO / rx-gro-list is enabled.
Thanks again to @walken and @wilsonyan for your links and input. That helped in researching settings and the adapter.
