Realtek 8157 driver installation (Wavlink WL-NWU340G)

[sunseeker2k5]

@rebelliouswhiz : it looks like you are on a USB3.1 or USB3.2 GEN1 port which is only 5Gbps.
Only GEN2 ports can do 10Gbps AFAIK.

@DerekG : can you share the link to the no-brand device ? Might give it a try while I wait for the test device they promised.

 

[rebelliouswhiz]

@rebelliouswhiz : it looks like you are on a USB3.1 or USB3.2 GEN1 port which is only 5Gbps.
Only GEN2 ports can do 10Gbps AFAIK.

@DerekG : can you share the link to the no-brand device ? Might give it a try while I wait for the test device they promised.

Right, I am on USB 3.0 (or called USB 3.1, USB 3.2 GEN1, thank you USB-IF!), but I am curious why it's showing 10000 M for DerekG? Is RTL 8157 even capable of doing it with USB 3.2 GEN 2?

And I am also noticing the USB adapter / r8152 driver is causing CPU soft lockup, and causing the node not to respond to the network. Quite unstable, I'd say, but pretty much expected as it's not supported directly at the kernel level.

 

[sunseeker2k5]

Right, I am on USB 3.0 (or called USB 3.1, USB 3.2 GEN1, thank you USB-IF!), but I am curious why it's showing 10000 M for DerekG? Is RTL 8157 even capable of doing it with USB 3.2 GEN 2?

And I am also noticing the USB adapter / r8152 driver is causing CPU soft lockup, and causing the node not to respond to the network. Quite unstable, I'd say, but pretty much expected as it's not supported directly at the kernel level.

Because he is on a GEN2 port like I am. If you look at my lsusb -t in the very first post, you can see it's also 10000 for me.
That speed is the capability of the port, not the capability of the device.

You can verify the speed the device will negotiate on or the current link speed with ethtool :


RTL8157 can do 5Gbps and it fits the throughput (with overhead) of the USB3.1/3.2GEN2.
The lockups were reported by other folks as well but was on the earlier version of the driver.

 

[DerekG]

Hi DerekG, I found the same github link as you mentioned. I am using the same deb package, but as far as I see it, it's the same as @sunseeker2k5 's method, just packed in a deb.

I tried to make /etc/modprobe.d/r8152.conf and update-initramfs -u, got no luck, still at 3.39 Gbps.

I notice, when I lsusb -t, my adapters show 5000M speed, not 10000M as yours.

root@prox0:/etc/modprobe.d# cat r8152.conf
options r8125 aspm=1
options r8125 eee_enable=0
root@prox0:/etc/modprobe.d# lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
    |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
    |__ Port 4: Dev 4, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M

Is it possible that your no-brand RTL8157 is actually RTL8159, which offers 10 Gbps?

@rebelliouswhiz,

No, it's definitely an RTL8157, I have multiple 6th Gen mini PC's here in my Proxmox cluster, all of those connect at 5000M (USB.3.0) and then I get the 3.3 Gbits/sec TX/RX and the connection is unstable. On the N150 where it connects at 10000M, it's rock solid.

Other points noted during my testing here, I have a 6th Gen Windows Mini PC and that RTL8157 is connected via a powered USB hub, that connection is more stable (doesn't drop the connection) than if the adapter is connected direct to the PC, however Tx/Rx is still 3.3Gits/sec.

I also checked on my 11th Gen laptop (which is supposed to have USB3.2 & USB4 ports, yet in that case even though the Windows shows it's connected at 5Gbe, the Tx/Rx is still at 3.3Gbits/sec in iperf3.

So with that I conclude that if the USB only connects at 5000M then the Tx/Rx rate will be 3.3. only AND that the power draw by the adapter is also having an effect on the stability.

Key for me was to get the N150 connected at as fast a speed as possible, so that issue is solved for me. For the other 6th Gen PC I have a couple of the RTL8126 PCI M.2 cards on order, which I will install in the WiFi M.2 slot, and I suspect that will provide the 5Gbe correctly (although it's not critical for my home lab).

DerekG

 

[rebelliouswhiz]

Because he is on a GEN2 port like I am. If you look at my lsusb -t in the very first post, you can see it's also 10000 for me.
That speed is the capability of the port, not the capability of the device.

You can verify the speed the device will negotiate on or the current link speed with ethtool :
View attachment 85546

RTL8157 can do 5Gbps and it fits the throughput (with overhead) of the USB3.1/3.2GEN2.
The lockups were reported by other folks as well but was on the earlier version of the driver.

Thanks for the explanation! I missed that info... I guess that's it for my use case then.

 

[rebelliouswhiz]

@rebelliouswhiz,

No, it's definitely an RTL8157, I have multiple 6th Gen mini PC's here in my Proxmox cluster, all of those connect at 5000M (USB.3.0) and then I get the 3.3 Gbits/sec TX/RX and the connection is unstable. On the N150 where it connects at 10000M, it's rock solid.

Other points noted during my testing here, I have a 6th Gen Windows Mini PC and that RTL8157 is connected via a powered USB hub, that connection is more stable (doesn't drop the connection) than if the adapter is connected direct to the PC, however Tx/Rx is still 3.3Gits/sec.

I also checked on my 11th Gen laptop (which is supposed to have USB3.2 & USB4 ports, yet in that case even though the Windows shows it's connected at 5Gbe, the Tx/Rx is still at 3.3Gbits/sec in iperf3.

So with that I conclude that if the USB only connects at 5000M then the Tx/Rx rate will be 3.3. only AND that the power draw by the adapter is also having an effect on the stability.

Key for me was to get the N150 connected at as fast a speed as possible, so that issue is solved for me. For the other 6th Gen PC I have a couple of the RTL8126 PCI M.2 cards on order, which I will install in the WiFi M.2 slot, and I suspect that will provide the 5Gbe correctly (although it's not critical for my home lab).

DerekG

Thanks @DerekG ! I guess my speed is as good as I possibly can... I am now considering buying a few mini PC with N150...

 

[sunseeker2k5]

@rebelliouswhiz,

No, it's definitely an RTL8157, I have multiple 6th Gen mini PC's here in my Proxmox cluster, all of those connect at 5000M (USB.3.0) and then I get the 3.3 Gbits/sec TX/RX and the connection is unstable. On the N150 where it connects at 10000M, it's rock solid.

Other points noted during my testing here, I have a 6th Gen Windows Mini PC and that RTL8157 is connected via a powered USB hub, that connection is more stable (doesn't drop the connection) than if the adapter is connected direct to the PC, however Tx/Rx is still 3.3Gits/sec.

I also checked on my 11th Gen laptop (which is supposed to have USB3.2 & USB4 ports, yet in that case even though the Windows shows it's connected at 5Gbe, the Tx/Rx is still at 3.3Gbits/sec in iperf3.

So with that I conclude that if the USB only connects at 5000M then the Tx/Rx rate will be 3.3. only AND that the power draw by the adapter is also having an effect on the stability.

Key for me was to get the N150 connected at as fast a speed as possible, so that issue is solved for me. For the other 6th Gen PC I have a couple of the RTL8126 PCI M.2 cards on order, which I will install in the WiFi M.2 slot, and I suspect that will provide the 5Gbe correctly (although it's not critical for my home lab).

DerekG

What is the non-branded USB NIC you managed to get 5 Gbps with ?

 

[DerekG]

@rebelliouswhiz : it looks like you are on a USB3.1 or USB3.2 GEN1 port which is only 5Gbps.
Only GEN2 ports can do 10Gbps AFAIK.

@DerekG : can you share the link to the no-brand device ? Might give it a try while I wait for the test device they promised.

Hi Sunseeker2k5,

Thanks for all the work you've put into investigating this issue, you are right, the USB standards committee really dropped the ball when it comes to the USB3.x specs. There are some USB 3.1 which do communicate @ 10000M, but it seems that most only communicate @ 5000M.

I'm confused as to why your adapter has the reduced 3.3 Tx/Rx rate in the original post, as the USB is @ 10000M, but then I get the same on my 11th Gen Win laptop too.

This is the no brand RTL8157 I'm using:
https://www.aliexpress.com/item/100...order_list.order_list_main.107.65471802vUaI76

But to be honest I also have the WisPi model and am unable to see any difference, regardless of which PC they are used on:
https://www.aliexpress.com/item/100...order_list.order_list_main.188.65471802vUaI76

When I have some time I'll start investigating the USB power drawn by these adapters because I'm sure that is key to the stability issues.

All the best out there

DerekG

 

[sunseeker2k5]

Power and chipset were the two items cited by Wavlink customer support as well.
Provided that i tried it on 2 different platforms : AMD (3700x on x570) and Intel (N100) I don't think it was the chipset.
Which could boil it down to the power as in both cases power was provided by the USB-C port itself.

 

[DerekG]

Power and chipset were the two items cited by Wavlink customer support as well.
Provided that i tried it on 2 different platforms : AMD (3700x on x570) and Intel (N100) I don't think it was the chipset.
Which could boil it down to the power as in both cases power was provided by the USB-C port itself.

Perhaps this is the new model which Wavelink are advising about?
They are now providing external power to the 5G NIC.

https://www.aliexpress.com/item/1005008743340916.html?spm=a2g0o.detail.pcDetailBottomMoreOtherSeller.72.65d84C2D4C2DNK&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.40050.354490.0&scm_id=1007.40050.354490.0&scm-url=1007.40050.354490.0&pvid=0079a7fe-c4bf-4157-a1c2-41785bf2a659&_t=gps-idcDetailBottomMoreOtherSeller,scm-url:1007.40050.354490.0,pvid:0079a7fe-c4bf-4157-a1c2-41785bf2a659,tpp_buckets:668#2846#8112#1997&pdp_ext_f={"order":"5","eval":"1","sceneId":"30050"}&pdp_npi=4@dis!GBP!31.20!15.29!!!40.26!19.73!@211b816617461653633387622e0cca!12000046648149705!rec!UK!6000181829!XZ&utparam-url=scenecDetailBottomMoreOtherSeller|query_from:#nav-specification

I tried to test the power draw of these 5Gbe adapters, but both my testers only work @ USB2.0 so do not provide real world results.

People might trust Amazon more, but AliExpress is where the new tech appears first.

My RTL8126 based M.2 PCI 5Gbe NIC's are in the country so I'm expecting them any day now.

I believe that they will solve the stability, the power and the Tx/Rx speed issues, if the PC has a M.2 WiFi card slot which can be swapped out (which my N150 doesn't have).,

 

[DerekG]

Final update on this Realtek 5Gbe NIC issue.

The Realtek RTL8126 based M.2 A+E key (PCIe NIC) works correctly and can be installed in place of the WiFi card.

I have one now fitted in my Win 10 PC, and if I need WiFi I'll fit a USB model.

This is the NIC I used:
https://www.aliexpress.com/item/100....order_list.order_list_main.29.57ed1802c517Sm

Anyone ordering this NIC should be careful of the components around the WiFi card and ensure that the network cable orientation will actually fit in the physical space. I've damaged one connector trying to get it to fit.

Here is the current install in Win 10

Link speed (Receive/Transmit): 5000/5000 (Mbps)
IPv6 address:
Link-local IPv6 address:
IPv4 address: 192.168.10.53
IPv4 DNS servers: 192.168.10.3
192.168.10.15
192.168.10.33
Primary DNS suffix: workgroup
Manufacturer: Realtek
Description: Realtek PCIe 5GbE Family Controller
Driver version: 10.74.1128.2024
Physical address (MAC): 00-E0-4C-68-01-10

These are the results of the iperf3 test

C:\iperf3>iperf3 -c 192.168.10.28
Connecting to host 192.168.10.28, port 5201
[  5] local 192.168.10.53 port 56805 connected to 192.168.10.28 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.01   sec   573 MBytes  4.77 Gbits/sec
[  5]   1.01-2.01   sec   566 MBytes  4.75 Gbits/sec
[  5]   2.01-3.01   sec   564 MBytes  4.75 Gbits/sec
[  5]   3.01-4.00   sec   565 MBytes  4.75 Gbits/sec
[  5]   4.00-5.00   sec   566 MBytes  4.75 Gbits/sec
[  5]   5.00-6.01   sec   571 MBytes  4.75 Gbits/sec
[  5]   6.01-7.01   sec   566 MBytes  4.75 Gbits/sec
[  5]   7.01-8.00   sec   561 MBytes  4.75 Gbits/sec
[  5]   8.00-9.01   sec   568 MBytes  4.75 Gbits/sec
[  5]   9.01-10.01  sec   566 MBytes  4.75 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.01  sec  5.53 GBytes  4.75 Gbits/sec                  sender
[  5]   0.00-10.02  sec  5.53 GBytes  4.74 Gbits/sec                  receiver

iperf Done.

C:\iperf3>iperf3 -c 192.168.10.28 -R
Connecting to host 192.168.10.28, port 5201
Reverse mode, remote host 192.168.10.28 is sending
[  5] local 192.168.10.53 port 56820 connected to 192.168.10.28 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.01   sec   574 MBytes  4.75 Gbits/sec
[  5]   1.01-2.00   sec   560 MBytes  4.74 Gbits/sec
[  5]   2.00-3.01   sec   569 MBytes  4.74 Gbits/sec
[  5]   3.01-4.02   sec   567 MBytes  4.73 Gbits/sec
[  5]   4.02-5.01   sec   559 MBytes  4.74 Gbits/sec
[  5]   5.01-6.01   sec   568 MBytes  4.74 Gbits/sec
[  5]   6.01-7.00   sec   561 MBytes  4.74 Gbits/sec
[  5]   7.00-8.01   sec   570 MBytes  4.74 Gbits/sec
[  5]   8.01-9.01   sec   566 MBytes  4.74 Gbits/sec
[  5]   9.01-10.01  sec   566 MBytes  4.75 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.02  sec  5.53 GBytes  4.74 Gbits/sec  254            sender
[  5]   0.00-10.01  sec  5.53 GBytes  4.74 Gbits/sec                  receiver

iperf Done.

For anyone interested there are also M.2 B+M key 10Gbe NIC's available, but that requires a spare NVMe slot.

I hope that helps.

DerekG

 

[rebelliouswhiz]

Because he is on a GEN2 port like I am. If you look at my lsusb -t in the very first post, you can see it's also 10000 for me.
That speed is the capability of the port, not the capability of the device.

You can verify the speed the device will negotiate on or the current link speed with ethtool :
View attachment 85546

RTL8157 can do 5Gbps and it fits the throughput (with overhead) of the USB3.1/3.2GEN2.
The lockups were reported by other folks as well but was on the earlier version of the driver.

After hours of diagnosis, with the driver installed and the current Proxmox kernel (6.8), I managed to get ~3.6 Gbps with my setup (USB 3.0, and a very weak CPU i3 4010u).

jiayuan@prox1:~$ iperf3 -c 10.0.0.3
Connecting to host 10.0.0.3, port 5201
[  5] local 10.0.0.2 port 32998 connected to 10.0.0.3 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   430 MBytes  3.61 Gbits/sec    0   1.10 MBytes       
[  5]   1.00-2.00   sec   426 MBytes  3.58 Gbits/sec    0   1.15 MBytes       
[  5]   2.00-3.00   sec   428 MBytes  3.59 Gbits/sec    0   1.15 MBytes       
[  5]   3.00-4.00   sec   428 MBytes  3.58 Gbits/sec    0   1.21 MBytes       
[  5]   4.00-5.00   sec   426 MBytes  3.58 Gbits/sec    0   1.21 MBytes       
[  5]   5.00-6.00   sec   428 MBytes  3.59 Gbits/sec    0   1.21 MBytes       
[  5]   6.00-7.00   sec   426 MBytes  3.58 Gbits/sec    0   1.65 MBytes       
[  5]   7.00-8.00   sec   428 MBytes  3.59 Gbits/sec    0   1.65 MBytes       
[  5]   8.00-9.00   sec   426 MBytes  3.58 Gbits/sec    0   1.65 MBytes       
[  5]   9.00-10.00  sec   428 MBytes  3.59 Gbits/sec    0   1.65 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  4.17 GBytes  3.58 Gbits/sec    0             sender
[  5]   0.00-10.00  sec  4.17 GBytes  3.58 Gbits/sec                  receiver

iperf Done.

I checked the interface using "sudo ethtool -k eno1" and found out I can turn on "rx-gro-list" and "rx-udp-gro-forwarding". With 0 understanding of what those are, I turned them on by changing the /etc/network/interfaces:

auto eno1
iface eno1 inet static
  pre-up ip link set $IFACE up
  mtu 16330
  post-up /sbin/ethtool -K eno1 rx-gro-list on
  post-up /sbin/ethtool -K eno1 rx-udp-gro-forwarding on

I am happy with what I am getting.

I also found out what is causing the soft lockup/system hang, I need to turn on the "KRBD" option for Ceph. I searched a little bit, it might be related to the krbd CPU usage vs librbd. It can be because of my weak CPU.

 

[arcadiancomp]

If anyone is still trying to get the Realtek 8157 supported r8152 driver compiled on newer kernels, the latest May 2025 driver source from Realtek compiles and loads fine right up to 6.15.x. I made this DKMS config and got the module to compile and load:

PACKAGE_NAME=r8152
PACKAGE_VERSION=2.20.1
MAKE[0]="make -C ${kernel_source_dir} M='$(pwd)'"
BUILT_MODULE_NAME[0]="r8152"
BUILT_MODULE_LOCATION[0]="."
DEST_MODULE_LOCATION[0]="/updates"
AUTOINSTALL=yes

[root@cerberus r8152-2.20.1]# lsusb -t
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 006: Dev 006, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 006: Dev 006, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 014: Dev 005, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 014: Dev 005, If 1, Class=Wireless, Driver=btusb, 12M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/10p, 10000M
|__ Port 002: Dev 005, If 0, Class=Mass Storage, Driver=uas, 5000M
|__ Port 003: Dev 006, If 0, Class=Mass Storage, Driver=uas, 5000M
|__ Port 004: Dev 010, If 0, Class=Vendor Specific Class, Driver=r8152, 10000M
[root@cerberus r8152-2.20.1]# ethtool -i enp0s20f0u4
driver: r8152
version: v2.20.1 (2025/05/13)
firmware-version:
expansion-rom-version:
bus-info: usb-0000:00:14.0-4
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
[root@cerberus r8152-2.20.1]#

 

[sunseeker2k5]

it was compiling fine earlier on for us too but the speed was mediocre 3.6 instead of closer to 5.

 

[aioue]

Working solution: RTL8157 (Wisdpi WP-UT5) on Proxmox VE 9 with r8152 DKMS

I’ve got the Wisdpi WP-UT5 (RTL8157) running cleanly on PVE 9 using the awesometic r8152 DKMS driver, with Secure Boot MOK enrollment and automatic cdc_* blacklisting. I wrapped the steps into a safe one-shot script that handles:

- temporary failover of vmbr0 to onboard NIC during the switch
- DKMS install for the running kernel
- MOK enrollment if Secure Boot is on
- driver rebind (prompt to unplug/replug once)
- restore vmbr0 to the USB NIC and print a concise report

Script (auto-fetches latest .deb if not present, or you can just download awesometic's realtek-r8152-dkms_2.20.1-1_amd64.deb to /root/ and run if there are issues):
https://github.com/aioue/r8152_proxmox_setup/blob/main/r8152_proxmox_setup.sh

Hardware
- USB NIC: Wisdpi WP-UT5 (Realtek RTL8157)
- Link: 5 Gbps, Full Duplex (validated with ethtool)

Software/Host

# pveversion
pve-manager/9.0.10 (running kernel: 6.14.11-2-pve)
# uname -a
Linux pve 6.14.11-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.14.11-2 (2025-09-12T09:46Z) x86_64 GNU/Linux

- Headers installed: proxmox-headers-6.14.11-2-pve
- Secure Boot: Enabled; DKMS MOK enrolled (script prompts and handles import)
- Driver:

# ethtool -i enxXXXXXXXXXXXX
driver: r8152
version: v2.20.1 (2025/05/13)
bus-info: usb-0000:05:00.4-1

- Bind check:

# lsusb -t (excerpt)
|__ Port 001: Dev N, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M

- /etc/network/interfaces updated so vmbr0 bridges the USB NIC; hwaddress set to avoid MAC flips.

Notes
- The script blacklists cdc_ncm, cdc_ether, r8153_ecm and updates initramfs so r8152 binds first.
- If Secure Boot is enabled, you’ll be prompted to enroll the DKMS key (MOK) and reboot once; rerun the script after the reboot to complete.
- Requires onboard NIC (default enp3s0) to be cabled during the switch so management stays up.

If you move to kernels ≥ 6.16 and hit API changes, consider the wget fork of r8152 DKMS. With MOK already enrolled, it should load cleanly as well.

 

[arcadiancomp]

Working solution: RTL8157 (Wisdpi WP-UT5) on Proxmox VE 9 with r8152 DKMS

I’ve got the Wisdpi WP-UT5 (RTL8157) running cleanly on PVE 9 using the awesometic r8152 DKMS driver, with Secure Boot MOK enrollment and automatic cdc_* blacklisting. I wrapped the steps into a safe one-shot script that handles:

- temporary failover of vmbr0 to onboard NIC during the switch
- DKMS install for the running kernel
- MOK enrollment if Secure Boot is on
- driver rebind (prompt to unplug/replug once)
- restore vmbr0 to the USB NIC and print a concise report

Script (auto-fetches latest .deb if not present, or you can just download awesometic's realtek-r8152-dkms_2.20.1-1_amd64.deb to /root/ and run if there are issues):
https://github.com/aioue/r8152_proxmox_setup/blob/main/r8152_proxmox_setup.sh

Hardware
- USB NIC: Wisdpi WP-UT5 (Realtek RTL8157)
- Link: 5 Gbps, Full Duplex (validated with ethtool)

Software/Host

# pveversion
pve-manager/9.0.10 (running kernel: 6.14.11-2-pve)
# uname -a
Linux pve 6.14.11-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.14.11-2 (2025-09-12T09:46Z) x86_64 GNU/Linux

- Headers installed: proxmox-headers-6.14.11-2-pve
- Secure Boot: Enabled; DKMS MOK enrolled (script prompts and handles import)
- Driver:

# ethtool -i enxXXXXXXXXXXXX
driver: r8152
version: v2.20.1 (2025/05/13)
bus-info: usb-0000:05:00.4-1

- Bind check:

# lsusb -t (excerpt)
|__ Port 001: Dev N, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M

- /etc/network/interfaces updated so vmbr0 bridges the USB NIC; hwaddress set to avoid MAC flips.

Notes
- The script blacklists cdc_ncm, cdc_ether, r8153_ecm and updates initramfs so r8152 binds first.
- If Secure Boot is enabled, you’ll be prompted to enroll the DKMS key (MOK) and reboot once; rerun the script after the reboot to complete.
- Requires onboard NIC (default enp3s0) to be cabled during the switch so management stays up.

If you move to kernels ≥ 6.16 and hit API changes, consider the wget fork of r8152 DKMS. With MOK already enrolled, it should load cleanly as well.

Great effort, well done!