Page MenuHomeVyOS Platform

Update Realtek r8152 driver
Open, HighPublicBUG

Description

r8152 driver in VyOS 1.4 is outdated and modern USB 2.5 Gbps NICs are not fully supported.
We should update the driver to add support for such NICs.

We had the task for 1.3 where it was fixed and works as expected https://vyos.dev/T5187 and PR https://github.com/vyos/vyos-build/pull/343

But for some reason, we do not have this in the build for 1.4
So after the update to 1.4.0 users face these issues.

1.4.0

$ modinfo r8152
filename:       /lib/modules/6.6.32-amd64-vyos/kernel/drivers/net/usb/r8152.ko
version:        v1.12.13
license:        GPL
description:    Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
author:         Realtek linux nic maintainers <[email protected]>

1.3.8

vyos@r1:~$ modinfo r8152
filename:       /lib/modules/5.4.268-amd64-vyos/updates/drivers/net/usb/r8152.ko
version:        v2.17.1 (2023/06/13)
license:        GPL
description:    Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
author:         Realtek nic sw <[email protected]>

Details

Difficulty level
Unknown (require assessment)
Version
1.4
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Unspecified (please specify)

Related Objects

Event Timeline

Viacheslav triaged this task as Normal priority.
Viacheslav raised the priority of this task from Normal to High.Thu, Sep 12, 1:38 PM

Unfortunately the version: v2.18.1 (2024/05/20) does not work correctly and previous versions 2.17.1 are not compatible with the newest kernel version

make -C /vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/linux M=/vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/vyos-drivers-realtek-r8152-2.17.1 modules
make[2]: Entering directory '/vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/linux-6.6.49'
  CC [M]  /vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/vyos-drivers-realtek-r8152-2.17.1/r8152.o
/vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/vyos-drivers-realtek-r8152-2.17.1/r8152.c: In function ‘r8152_csum_workaround’:
/vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/vyos-drivers-realtek-r8152-2.17.1/r8152.c:2114:24: error: implicit declaration of function ‘skb_gso_segment’; did you mean ‘skb_gso_reset’? [-Werror=implicit-function-declaration]
 2114 |                 segs = skb_gso_segment(skb, features);
      |                        ^~~~~~~~~~~~~~~
      |                        skb_gso_reset
/vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/vyos-drivers-realtek-r8152-2.17.1/r8152.c:2114:22: warning: assignment to ‘struct sk_buff *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
 2114 |                 segs = skb_gso_segment(skb, features);
      |                      ^
cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:243: /vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/vyos-drivers-realtek-r8152-2.17.1/r8152.o] Error 1
make[3]: *** [/vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/linux-6.6.49/Makefile:1921: /vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/vyos-drivers-realtek-r8152-2.17.1] Error 2
make[2]: *** [Makefile:234: __sub-make] Error 2
make[2]: Leaving directory '/vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/linux-6.6.49'
make[1]: *** [debian/rules:23: override_dh_auto_build] Error 2
make[1]: Leaving directory '/vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/vyos-drivers-realtek-r8152-2.17.1'
make: *** [debian/rules:9: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui failed
Traceback (most recent call last):
  File "/vyos/work/T6713-current-realtek/vyos-build/packages/linux-kernel/./build-driver-realtek-r8152.py", line 88, in <module>
    run(debuild_cmd, cwd=PACKAGE_DIR, check=True)
  File "/usr/lib/python3.11/subprocess.py", line 571, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['debuild']' returned non-zero exit status 29.

Waiting for the 3d-party fix.

Hi,

I am currently using 2.18.1 with kernel

Hi,

I am currently using 2.18.1 with kernel 6.6.51-vyos

modinfo r8152
filename: /lib/modules/6.6.51-vyos/kernel/drivers/net/usb/r8152.ko
version: v2.18.1 (2024/05/20)
license: GPL
description: Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
author: Realtek nic sw <[email protected]>

depends:
retpoline: Y
name: r8152
vermagic: 6.6.51-vyos SMP preempt mod_unload modversions

What appears to be the problem?

SteveP

SteveP - Even when using 2.18.1 - when I try to force the speed of the USB interface to 2500 (and duplex to full, as then required), I see error messages on the commit. See below. This happens with multiple 2.5G capable interfaces.

Traceback (most recent call last):

File "/usr/libexec/vyos/conf_mode/interfaces_ethernet.py", line 433, in <module>
  apply(c)
File "/usr/libexec/vyos/conf_mode/interfaces_ethernet.py", line 410, in apply
  e.update(ethernet)
File "/usr/lib/python3/dist-packages/vyos/ifconfig/ethernet.py", line 446, in update
  self.set_speed_duplex(speed, duplex)
File "/usr/lib/python3/dist-packages/vyos/ifconfig/ethernet.py", line 221, in set_speed_duplex
  return self._cmd(cmd)
         ^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/vyos/ifconfig/control.py", line 52, in _cmd
  return cmd(command, self.debug)
         ^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/vyos/utils/process.py", line 155, in cmd
  raise OSError(code, feedback)

OSError: [Errno 75] failed to run command: ethtool --change eth3 speed 2500 duplex full autoneg off
returned:
exit code: 75

Running the ethtool command manually (as root) also fails -
ethtool --change eth3 speed 2500 duplex full autoneg off
netlink error: Invalid argument

BUT ethtool --change eth3 speed 1000 duplex full autoneg off

works fine!

Hi, Yes I get the same if I try that but mine is already 2500 full.

sh int eth eth6 p
Settings for eth6:

Supported ports: [ MII ]
Supported link modes:   10baseT/Half 10baseT/Full
                        100baseT/Half 100baseT/Full
                        1000baseT/Full
                        2500baseT/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
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
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Auto-negotiation: on

If I change it to sudo ethtool --change eth6 speed 1000 duplex full autoneg off it is fine as you say.

If I the do sudo ethtool --change eth6 speed 2500 duplex full autoneg on it is also OK.

I think this may possibly be the expected behaviour. (2500 full only with autoneg on).
https://ubuntuforums.org/showthread.php?t=2491821
https://forum.odroid.com/viewtopic.php?t=39578
https://github.com/bb-qq/r8152/issues/180

Are you getting the driver from Realtek? Mine is this one:
https://www.realtek.com/Download/ToDownload?type=direct&downloadid=3375

I have seen some modified ones for Synology floating around on the web!
https://github.com/bb-qq/r8152
https://github.com/bb-qq/r8152/issues/277

He was also having problems with defaulting to 1G. Can be caused by low power. I am using them on powered USB hubs.

SteveP

Technically according to IEEE autoneg is mandatory when doing 1Gbps and above using RJ45.

This will also bring you auto mdi/mdi-x (meaning you dont have to care if its a straight or crossover cable used between devices which was a thing back in the days) which otherwise gets disabled.

What you can do when using autoneg and want a fixed speed (due to issues with NBASE-T where one end thinks its a different speed resulting in no traffic will pass at all) is to limit what speed/duplex combos your end will advertise.

For example autoneg=on + only advertise 2500/FD. Hopefully the other side will do the same but if the other side is left at auto/auto (and supports 2.5G) it should autoneg into 2.5G/FD (saying should since its a known drawback of NBASE-T nic's to not always beahve as they "should").