Page MenuHomeVyOS Platform

Realtek driver doesn't support recent NICs
Needs testing, NormalPublicBUG

Assigned To
Authored By
Viacheslav
Sep 12 2024, 1:31 PM
Referenced Files
F5006769: image.png
Nov 5 2024, 8:41 PM
F5002046: journalct.log
Nov 2 2024, 11:56 AM
F5002045: journalct-k.log
Nov 2 2024, 11:56 AM
F4977162: config.boot
Oct 28 2024, 6:18 PM
F4977163: journalct-k.log
Oct 28 2024, 6:18 PM
F4977164: journalct.log
Oct 28 2024, 6:18 PM
F4969946: image.png
Oct 27 2024, 8:52 AM

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

Version
1.4
Is it a breaking change?
Perfectly compatible
Issue type
Bug (incorrect behavior)

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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").

Driver added to the latest rolling release

vyos@r14# run show version all | match realtek
ii  vyos-drivers-realtek-r8152           2.18.1-1                                    amd64        auto-generated package by debmake
[edit]
vyos@r14# 


vyos@r14# run show ver
Version:          VyOS 1.5-rolling-202410080006
Release train:    current
Release flavor:   generic


vyos@r14# modinfo r8152
filename:       /lib/modules/6.6.54-vyos/updates/drivers/net/usb/r8152.ko
version:        v2.18.1 (2024/05/20)
license:        GPL
description:    Realtek RTL8152/RTL8153 Based USB Ethernet Adapters

It will be good is someone can check it.

Viacheslav changed the task status from Open to Needs testing.Oct 8 2024, 9:58 AM
Viacheslav claimed this task.
Viacheslav lowered the priority of this task from High to Normal.Oct 8 2024, 10:52 AM

Hi,

It is not working I'm afraid.

modprobe: ERROR: could not insert 'r8152': Key was rejected by service

It is a signing error. I am getting the same thing now with 6.6.52 (I just tried it) but 6.6.51 (one I am running) is fine. I can't try 6.6.54 as the headers are not there.

SteveP

Could it be related to this: https://portal.productboard.com/vyos/1-vyos-roadmap/c/67-secure-boot-uefi

Secure boot UEFI
Secure Boot is an important security feature designed to prevent malicious software from loading when the servers start up by preventing the loading of UEFI drivers or OS boot loaders that are not signed with an acceptable digital signature

Are you working on this at the same time?

I don't think it is related to secure boot.

mokutil --sb-state
EFI variables are not supported on this system

I am running in VMware and have BIOS boot mode.

Hi,

It is not working I'm afraid.

modprobe: ERROR: could not insert 'r8152': Key was rejected by service

It is a signing error. I am getting the same thing now with 6.6.52 (I just tried it) but 6.6.51 (one I am running) is fine. I can't try 6.6.54 as the headers are not there.

SteveP

which headers do you mean? Those ? https://packages.vyos.net/repositories/current/pool/main/l/linux-upstream/

You can update to the latest rolling

Hi, I have upgraded to latest rolling. That is how I know you are now on 6.6.54. I get the error modprobe: ERROR: could not insert 'r8152': Key was rejected by service.

I have also tried to create r8152.ko for 6.6.52 and it gives the same error where 6.6.51 is working. I'll go and create my own module for 6.6.54 now but I suspect it will be the same.

SteveP

I have been getting headers from http://dev.packages.vyos.net/repositories/current current main" 6.6.52 is the latest there.

I have created r8152.ko for 6.6.54 and it gives the same error

modprobe: ERROR: could not insert 'r8152': Key was rejected by service

Let me know if you would like me to try anything else.

SteveP

Hi,

6.6.51
sudo find / -name config-uname -r
/usr/lib/live/mount/rootfs/1.5-rolling-202409250007.squashfs/boot/config-6.6.51-vyos
sudo grep MODULE_SIG /usr/lib/live/mount/rootfs/1.5-rolling-202409250007.squashfs/boot/config-6.6.51-vyos
CONFIG_MODULE_SIG is not set

6.6.54
sudo find / -name config-`uname -r
/usr/lib/live/mount/rootfs/1.5-rolling-202410081209.squashfs/boot/config-6.6.54-vyos
sudo grep MODULE_SIG /usr/lib/live/mount/rootfs/1.5-rolling-202410081209.squashfs/boot/config-6.6.54-vyos
CONFIG_MODULE_SIG_FORMAT=y
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_ALL=y
CONFIG_MODULE_SIG_SHA1 is not set
CONFIG_MODULE_SIG_SHA224 is not set
CONFIG_MODULE_SIG_SHA256 is not set
CONFIG_MODULE_SIG_SHA384 is not set
CONFIG_MODULE_SIG_SHA512=y
CONFIG_MODULE_SIG_HASH="sha512"
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
CONFIG_MODULE_SIG_KEY_TYPE_RSA=y

I believe CONFIG_MODULE_SIG_FORCE=y is possibly the culprit

SteveP

Hi,

Looking at the igb module from latest vyos, it is getting signed. Why is this one not signed?

name:           igb
vermagic:       6.6.54-vyos SMP mod_unload modversions
sig_id:         PKCS#7
signer:         VyOS build time autogenerated kernel key
sig_key:        24:1A:12:65:B6:94:37:A6:4A:D3:9E:68:D4:02:FF:72:A2:2B:09:C7
sig_hashalgo:   sha512
signature:      4D:54:81:AA:DF:6B:CB:47:77:04:B6:51:A4:93:2A:E2:29:DD:D4:93:
                04:C2:5C:88:D8:51:2C:02:03:44:16:15:96:1A:4D:65:8F:B5:A2:17:
                CE:69:7C:70:58:9E:F4:3D:C5:FB:09:2C:A6:85:C6:94:75:50:EA:AA:
                7B:15:5D:6C:18:18:93:31:33:9A:C4:8D:C3:39:5D:54:33:35:A0:2C:
                EF:C9:D7:68:D3:B2:07:99:BD:D4:9D:80:82:D4:6B:48:00:50:D1:B5:
                C2:8C:F3:A2:B5:CC:22:33:AE:20:07:5E:A1:F6:62:AC:A1:08:36:C4:
                A8:F1:16:2E:81:E1:76:4E:B8:CF:AB:FC:DF:6F:BC:E2:78:79:E9:E7:
                E8:24:B2:CF:B2:C4:B9:14:7D:45:14:06:C9:BB:73:E7:56:8E:8F:2B:
                C5:29:AB:35:98:B6:03:70:41:03:D8:BE:68:31:A2:EF:35:2F:9B:F5:
                50:E0:34:52:F1:CC:1C:03:2A:63:8A:D7:C3:42:75:40:96:D4:53:DA:
                86:C0:AC:86:41:B0:AC:FB:2D:D1:33:F0:06:02:BF:E7:F8:F6:37:4D:
                E3:A3:73:21:B0:2E:6F:0B:9D:6E:37:6A:19:54:92:C9:F8:DF:61:C2:
                F3:33:B9:76:C0:FD:9C:D1:DA:A4:B4:1D:61:4C:1F:A7:1E:45:66:1F:
                83:6B:02:03:FE:39:C5:1F:85:65:C3:88:3C:F8:1B:C9:73:DB:EE:20:
                06:88:75:BD:3F:22:9B:93:62:FF:19:EE:52:9D:78:AC:EF:FC:CA:C6:
                28:BB:30:F4:A7:1D:56:C0:14:A7:6F:00:EC:30:93:DC:AE:24:DF:D0:
                28:1F:63:27:3A:1B:59:1A:30:FD:BC:7A:80:16:35:2C:9C:96:58:4F:
                9D:AD:DA:43:B3:F1:06:03:C3:59:1F:B5:F5:07:39:EE:53:E8:2B:E8:
                58:68:6C:CF:E4:FA:DE:46:D5:DF:12:43:E0:EC:9B:63:17:B2:0B:DD:
                59:18:F5:68:F0:B9:E5:32:35:03:F0:57:32:18:33:FE:07:AA:5D:91:
                FB:4E:3D:B3:6F:64:85:45:66:03:E2:5A:4C:62:BF:C5:35:01:91:C9:
                82:FA:1D:1B:5E:ED:C8:9A:B6:A7:33:89:AB:74:02:C0:51:FE:06:EA:
                30:35:8F:FC:81:E7:1E:89:33:85:FC:0E:7A:E7:66:E8:D1:05:07:4B:
                27:7A:6D:CD:42:5B:FC:E6:A1:8E:94:3A:87:51:51:1B:B6:04:92:B1:
                1A:D7:F2:BA:35:2D:0B:12:92:97:F1:08:12:5A:54:C3:A5:A8:4C:AE:
                F5:30:72:21:DF:C7:10:30:C7:C5:65:37
parm:           max_vfs:Maximum number of virtual functions to allocate per physical function (uint)
parm:           debug:Debug level (0=none,...,16=all) (int)

It should already be in the latest rolling release.
@SteveP could you re-check?

Hi,

I'm afraid it didn't work.

modinfo r8152
filename:       /lib/modules/6.6.54-vyos/updates/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]>
srcversion:     417E89E6CC4E595B9923A2F
alias:          usb:v0B05p1976d*dc*dsc*dp*ic02isc0Dip00in*
.
.
alias:          usb:v0BDAp8050d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v0BDAp8050d*dc*dsc*dp*icFFisc*ip*in*
depends:
retpoline:      Y
name:           r8152
vermagic:       6.6.54-vyos SMP mod_unload modversions

sudo insmod /lib/modules/6.6.54-vyos/updates/drivers/net/usb/r8152.ko
insmod: ERROR: could not insert module /lib/modules/6.6.54-vyos/updates/drivers/net/usb/r8152.ko: Key was rejected by service

SteveP

Im guessing this one is behind that all modules must now be signed in VyOS:

https://vyos.dev/T861

https://github.com/vyos/vyos-build/pull/772

The key lives in /tmp and is destroyed after the build container exits and is named: VyOS build time autogenerated kernel key.

In addition the Kernel now uses CONFIG_MODULE_SIG_FORCE. This makes it unable to load any Kernel Module to the image that is NOT signed by the ephemeral key.

The above gives that it will be somewhat tricky to add your own module afterwards unless you do a full recompile since the key used to sign the kernel lives in the /tmp and is lost once the ISO have been created.

Im guessing there should be a 2nd round of thoughts regarding this signing "feature" since it breaks to ability to add modules on your own to an existing VyOS installation (unless this "ephemeral key" used during compile of the ISO somehow is available somewhere (like stored within the ISO?) - which on its own would counter the purpose of signing the kernel to begin with).

The above gives that it will be somewhat tricky to add your own module afterwards unless you do a full recompile since the key used to sign the kernel lives in the /tmp and is lost once the ISO have been created.

This is the sole idea about it, to not be able to add modules to a running system without rebuilding the entire Kernel. This adds a layer of security for loading malicious Kernel modules at runtime

Hi c-po

That's clear then. I'll wait for the next rolling build, test again and let you know.

If/When 2.19.x comes out, I'll create a kernel with CONFIG_MODULE_SIG_FORCE=y turned off in order to test it/use it.

As for T861. I am happy to test it for you when you are ready. "c-po changed the task status from In progress to Needs testing."
I have created an encrypted VM with TPM, EFI secure boot on. It currently reports

error: bad shim signature
error: you need to load the kernel first

Please reply over on T861 if you would like me to do anything.

SteveP

Hi c-po

I signed my r8152 driver with the MOK used in T861 but it doesn't load.

sudo insmod /lib/modules/6.6.54-vyos/updates/drivers/net/usb/r8152.ko
insmod: ERROR: could not insert module /lib/modules/6.6.54-vyos/updates/drivers/net/usb/r8152.ko: Key was rejected by service

modinfo r8152
filename:       /lib/modules/6.6.54-vyos/updates/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]>
srcversion:     384F473A047F25CAB202677
.
.
retpoline:      Y
name:           r8152
vermagic:       6.6.54-vyos SMP mod_unload modversions
sig_id:         PKCS#7
signer:         MyMOK
sig_key:        4F:03:07:B9:FC:F5:AC:51:17:BF:EF:32:1B:BB:41:B2:79:77:D0:D7
sig_hashalgo:   sha512
signature:      46:17:FC:50:16:2F:0B:F7:1A:D9:AC:3D:C6:C7:CE:8B:3D:F6:5D:2C:
                94:99:82:43:F7:AA:A1:C0:37:3C:B8:64:A4:15:9A:97:66:37:E3:8C:
                ED:3E:70:BA:30:7C:40:7E:F6:26:62:4C:9F:D9:42:61:BC:EE:BF:F0:
                5C:C5:8D:D9:93:DD:D6:41:88:22:0D:32:85:73:88:4F:B2:19:68:21:
                64:39:B4:A5:6D:4F:BC:15:73:30:3B:DD:9C:F7:B8:04:E9:49:29:5D:
                30:97:AE:A7:BC:33:57:51:A1:42:2E:CC:E5:EF:30:D7:A9:93:01:C3:
                9C:D8:CC:80:17:CB:37:D5:05:57:0B:D6:DE:C9:F5:E4:92:4F:82:75:
                FE:40:D4:85:D1:67:0A:DB:59:A0:2D:0F:FD:1C:47:A4:10:35:BD:26:
                70:CB:1A:AE:70:13:B9:B0:71:50:3D:02:F3:35:BA:23:4C:15:F9:6B:
                A0:36:8B:7C:D8:DB:BF:AA:D0:4D:99:A2:97:9C:CE:B0:A3:F2:12:40:
                A5:7F:D8:79:84:0D:E4:76:1E:73:E2:D7:B6:28:2D:08:64:47:54:5E:
                C3:EA:0D:B3:79:84:6F:F5:73:1E:71:97:8E:EF:72:99:FF:13:E6:F3:
                AD:D1:3D:EA:29:5C:56:C0:28:E4:59:73:2B:3E:93:7E:BC:9F:3E:DA:
                AB:DD:C7:FF:64:0A:69:14:6A:28:83:25:DB:94:8D:CF:55:01:14:16:
                F9:10:8A:0C:10:9C:69:A4:AD:37:2C:DF:D9:11:46:69:F5:70:FD:B6:
                9E:4A:D4:A5:32:A4:A7:EC:C5:FA:43:2C:B1:CD:9F:FC:92:52:42:5F:
                27:06:F0:7D:45:26:75:59:61:2E:5A:76:44:B1:3F:5B:64:A8:C4:16:
                B9:15:E5:42:0A:44:83:24:C9:14:9F:0F:82:3E:92:D3:80:4D:EF:FC:
                6E:C2:A4:77:ED:1C:4D:4F:BE:DC:0B:CD:B1:0B:C1:6A:81:14:67:BB:
                7C:AD:52:8F:85:56:EA:1F:46:17:45:B5:42:17:2B:1A:96:24:9E:08:
                6B:4C:9F:AC:2F:4A:9D:B0:77:32:06:53:AB:E9:CF:48:D1:6E:F8:C4:
                EF:AC:A1:D7:8D:AD:5A:67:92:15:6C:4E:D1:F2:7A:94:D5:11:C0:5E:
                03:11:6A:D4:F4:96:A3:19:89:46:3A:34:4C:86:C9:EC:4A:06:69:5A:
                2F:85:88:E1:AA:12:2C:C4:E5:91:C8:A4:6B:AF:10:34:15:C4:AE:8C:
                66:E6:3F:62:87:53:C4:D4:69:F6:6D:07:A6:37:50:1C:01:0F:D8:1F:
                4F:0F:54:C3:E6:E8:6A:53:8A:8F:3E:E1

When I look at a different driver, igb for example, it is not signed by my generated MOK.

modinfo igb
filename:       /lib/modules/6.6.54-vyos/kernel/drivers/net/ethernet/intel/igb/igb.ko
license:        GPL v2
description:    Intel(R) Gigabit Ethernet Network Driver
author:         Intel Corporation, <[email protected]>
.
.
depends:        i2c-algo-bit
retpoline:      Y
intree:         Y
name:           igb
vermagic:       6.6.54-vyos SMP mod_unload modversions
sig_id:         PKCS#7
signer:         VyOS build time autogenerated kernel key
sig_key:        64:BC:0E:77:09:E3:14:C5:FB:9A:0A:8C:25:71:46:F1:7A:6F:17:4B
sig_hashalgo:   sha512
signature:      6F:CD:8E:69:35:B0:A1:72:DF:63:BC:1D:72:EB:87:45:6B:0A:43:4B:
                6A:91:32:A4:33:44:2F:DD:60:DC:C1:B7:DC:A4:9A:7E:75:F1:EB:B3:
                F7:81:CE:EB:DD:34:5C:87:CA:FA:94:7E:D8:F2:DE:E4:06:29:B8:B5:
                6B:55:1C:E2:B9:33:A4:35:45:CD:69:2A:7D:E4:BF:53:E5:E4:51:68:
                F4:5E:DD:A3:24:D6:CE:46:4C:D0:D7:0F:79:28:26:48:AA:1E:94:59:
                A4:19:EA:3C:48:03:41:AC:56:9E:82:DA:D1:7C:2D:75:DD:32:EE:D0:
                62:09:CC:EB:BA:13:00:A8:F4:6E:1F:78:3C:21:8F:5C:30:F7:09:C4:
                C6:4F:AA:C3:4D:61:EF:84:C3:53:73:48:F9:01:8C:95:26:F5:65:4B:
                E0:B5:3D:F6:4F:23:FC:62:D7:C1:8D:F4:70:B0:7B:A2:D5:BD:34:6C:
                E2:50:80:1C:9E:1A:7E:C6:1B:BF:13:55:59:5C:9A:60:7D:C7:78:DD:
                49:66:46:91:F5:A9:D3:82:72:E8:CC:07:AD:ED:2B:82:B3:66:8F:34:
                24:94:76:89:5A:19:4A:06:A4:71:DF:18:25:7D:D3:C7:3C:A7:33:26:
                7D:51:F3:21:3E:A1:06:A7:65:64:3F:AC:E2:36:2E:90:1C:84:D9:B5:
                7A:A9:A7:25:62:3D:DE:83:3E:D8:71:F2:94:D4:3C:92:2B:01:E7:A8:
                9B:11:C9:6A:31:48:92:46:61:B4:05:45:8E:1E:6A:6D:CD:57:34:2E:
                06:76:97:17:A2:68:C8:86:1B:B8:EE:00:F1:42:BA:5C:F8:B0:30:F2:
                35:40:62:36:D8:7F:AB:AC:4D:D1:5C:BC:CD:A0:3F:F0:F8:F3:AD:1D:
                A4:6F:2D:3B:15:A6:7C:A3:51:BD:21:4E:66:41:BC:B2:E4:46:3D:78:
                D4:A4:16:C3:23:2B:7B:3A:2C:DB:21:99:C0:AD:B3:6E:43:1D:C8:F7:
                2F:1A:3E:98:75:EC:B5:B3:60:09:65:63:11:08:1A:25:52:79:08:7F:
                D7:D9:30:1D:FC:8E:F3:E9:58:15:34:13:0B:1C:DC:8B:60:00:78:FC:
                A1:E2:CF:72:C6:5B:31:D9:D2:E6:9D:1B:FA:6E:5E:46:20:F9:BD:17:
                F9:63:F7:62:93:3C:6F:16:35:57:84:7D:4D:41:3A:65:C1:50:E4:6D:
                50:C6:64:8C:95:C6:11:CB:2F:F2:25:E8:1E:86:18:AD:42:1E:6A:6D:
                E1:E6:0C:CC:E5:E4:4F:6D:C7:E7:F6:85:2D:3E:02:86:FC:EA:33:B6:
                BC:83:52:FD:52:BC:64:9E:4C:DB:56:C0
parm:           max_vfs:Maximum number of virtual functions to allocate per physical function (uint)
parm:           debug:Debug level (0=none,...,16=all) (int)

Any thoughts?

SteveP

Yes, that‘s correct behavior.

The MOK signs the kernel and the ephemeral key signs the modules. As the public key portion of your MOK is not part of the Kernel, the Kernel can not verify the signature of the modules.

I will start a rolling build now.

Hi,

I have installed the latest rolling release and the r8152 driver does seem ok (interface now comes up) however, eth0 now disappears. It is being renamed to eth5 (the r8152). This is eerily similar to T1066 I was involved in back in 2019. Turned out to be a kernel bug. Was not working with kernel 4.19.52 and was fixed in kernel 4.19.54

sudo dmesg
e1000e 0000:04:00.0 eth3: renamed from e3
[   21.652517] e1000e 0000:13:00.0 eth1: renamed from e5
[   21.661618] e1000e 0000:1b:00.0 eth2: renamed from e6
[   21.753532] e1000e 0000:0c:00.0 eth4: renamed from e4
[   21.973459] r8152 3-1:1.0 eth5: renamed from eth0
[   22.477198] systemd[1]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set
[   26.344991] pim6reg: entered allmulticast mode
[   26.422149] NET: Registered PF_PACKET protocol family
[   28.777976] e1000e 0000:1b:00.0 eth2: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[   30.497247] e1000e 0000:13:00.0 eth1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[   31.203951] e1000e 0000:0c:00.0 eth4: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[   31.901856] e1000e 0000:04:00.0 eth3: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
dmbaturin renamed this task from Update Realtek r8152 driver to Realtek driver doesn't support recent NICs.Oct 14 2024, 8:53 AM
dmbaturin removed a project: Restricted Project.
dmbaturin edited a custom field.
dmbaturin changed Is it a breaking change? from Unspecified (possibly destroys the router) to Perfectly compatible.
dmbaturin changed Issue type from Unspecified (please specify) to Bug (incorrect behavior).

Hi, If we are not going forward with this could we please remove the broken driver and go back to the stock one. It is not useable at all with a r8152 loaded at the moment as it breaks eth0 too early on.

I guess I could use it as eth0 but it seems a bit of a fudge!

Thanks

SteveP

Hi,

I have compiled a kernel with CONFIG_MODULE_SIG_FORCE off so I can load unsigned drivers. This worked fine. I then made an iso with the stock r8152 drivers, all good so far. I can now load the 2.18.1 drivers on 6.6.56 after everything has booted and settled down. It still breaks the router.

I guess we will have to wait until something in the kernel changes or Realtek releases a new version.

If you decide to take it out and revert to the kernel driver, I'll try it again each time you update the kernel and let you know if it starts working.

SteveP

OK,

Now that I have stopped your vyos-drivers-realtek-r8152_2.18.1-1_amd64.deb module from loading in data/architectures/amd64.toml and have turned off CONFIG_MODULE_SIG_FORCE, I can load my unsigned r8152.ko re-compiled for 6.6.56 and loaded from vyos-preconfig-bootup.script as I always have and everything is working. I suspect that this is because it is loading later after the nic renaming has been done.

If however, I use the current nightly build, it breaks the router (no eth0). As long as you are using the same source code as me, https://www.realtek.com/Download/ToDownload?type=direct&downloadid=3375, (please confirm), the difference must be the point at which it loads.

In order to play with patching the source files, I will need to be able to produce a .deb in order to load it from /vyos-build/packages/ during the build and I don't currently know how to do that.

Perhaps you could steer me in the right direction. Is there somewhere I can drop the source files and create the .deb during the build process?

SteveP

Realtek also listed a new driver yesterday.

USB NIC Linux driver for kernel up to 6.1 2.18.1 2024/10/17 81 KB

However, when you look at the files in it, they are the same files, same dates, no changes. I think this is an oversight and will soon be spotted.

On another note, the links you sent are for modified drivers for Synology NAS. Why are you using these over the ones from Realtek? Just curious.

SteveP

@SteveP could you provide the link to the source code (git) for the official drivers?
Where we can clone the code and build correct package for Debian?

https://www.realtek.com/Download/ToDownload?type=direct&downloadid=3375

It has a capcha on it so you will probably have to host it yourselves, also see note re new version yesterday. looks like the same one from May to me.

The original driver will be included in the next rolling release

Still broken I'm afraid.

I tried it on 6.6.58 too (I notice we have gone back to 6.6.56) but that also didn't work. It is working up to 6.6.51 even though the Realtek site says "USB NIC Linux driver for kernel up to 6.1".

I'll have a look at the difference between .51 & .52 to see if there are any clues.

SteveP

nothing in the difference between .51 & .52. I'm beginning to doubt myself now that that was the point it broke. That was also the point where you started requiring signed drivers and maybe I'm conflating the problems I had at that point.

I know I can create a kernel from pre 6.6.51 but, if I do, how do I instruct ./build-vyos-image iso that I want to use it? It fails if I just copy it into packages and run it. Can I build an iso to a point in time and include the current r8152 package? If I can, I'll work backward and try to figure it out.

Also, even though the Realtek site says "USB NIC Linux driver for kernel up to 6.1", looking in r8152.c there is:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,4,10)
#include <net/gso.h>
#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(6,4,10) */

so they must have tested it to at least there right?

SteveP

Looking at dmesg from a working config we can see:

sudo dmesg | grep -ie "renamed from"
[    0.883572] vmxnet3 0000:0b:00.0 e2: renamed from eth0
[    1.229786] e1000e 0000:04:00.0 e3: renamed from eth1
[    1.235255] e1000e 0000:0c:00.0 e4: renamed from eth0
[    1.240044] e1000e 0000:13:00.0 e5: renamed from eth2
[    1.245533] e1000e 0000:1b:00.0 e6: renamed from eth3
[    1.749115] r8152 4-1:1.0 e7: renamed from eth0
[   18.536107] e1000e 0000:13:00.0 eth1: renamed from e5
[   18.540849] vmxnet3 0000:0b:00.0 eth0: renamed from e2
[   18.647673] e1000e 0000:04:00.0 eth3: renamed from e3
[   18.754589] e1000e 0000:0c:00.0 eth4: renamed from e4
[   18.761645] e1000e 0000:1b:00.0 eth2: renamed from e6
[   18.832072] r8152 4-1:1.0 eth5: renamed from e7

Correct me if I'm wrong but it looks like the kernel renaming them in the first group (eth0 to e2 etc) and VyOS ordering them and re-naming them in the second group. It also looks like it takes them in groups of same driver and starts from eth0 with every new driver type.
vmxnet3 eth0
e1000e eth0-eth3
r8152 eth0 again.

Now if we look at a broken config:
{

image.png (243×689 px, 66 KB)
}

the only difference in the first block is that, when r8152 comes along, it skips e7 and renames it to e8. VyOS then skips the vmxnet3 eth0, gets the next group of e1000e correct and then picks up the r8152 as eth0 instead of e8.

Is it the gap in the sequence that is causing the problem? Does this tell you anything? Can you patch round it by allowing for a gap in the numbering?

I’d prefer to drop it at all for now.
Until someone can investigate it more deeply.
I don’t have any idea what is wrong.
Thanks

No worries, I'm all good here. I can turn off signing and carry on with the unsigned drivers as before. It is all good if I load them in the pre-script. If I figure it out I'll let you know.

SteveP

@SteveP could you attach those files for debugging where the issue exists?

/config/config.boot
/run/udev/log/vyos-net-name 
sudo journalctl -b | tee /tmp/journalct.log
sudo journalctl -k | tee /tmp/journalct-k.log

Enjoy

SteveP

This is the bad one:
Oct 28 18:03:45 debian vyos_net_name[896]: Started with arguments: ['/lib/udev/vyos_net_name', 'e8']
Oct 28 18:03:45 debian vyos_net_name[886]: Started with arguments: ['/lib/udev/vyos_net_name', 'e4', '00:0c:29:2d:44:53', 'eth4']
Oct 28 18:03:45 debian vyos_net_name[888]: Started with arguments: ['/lib/udev/vyos_net_name', 'e6', '00:0c:29:2d:44:3f', 'eth2']
Oct 28 18:03:45 debian vyos_net_name[887]: Started with arguments: ['/lib/udev/vyos_net_name', 'e5', '00:0c:29:2d:44:35', 'eth1']
Oct 28 18:03:45 debian vyos_net_name[884]: Started with arguments: ['/lib/udev/vyos_net_name', 'e3', '00:0c:29:2d:44:49', 'eth3']
Oct 28 18:03:45 debian vyos_net_name[885]: Started with arguments: ['/lib/udev/vyos_net_name', 'e2', '00:0c:29:2d:44:2b', 'eth0']
e7 is missing e8 has no mac address

This is what it should look like:
Oct 28 16:00:00 vyos-NB02 vyos_net_name[880]: Started with arguments: ['/lib/udev/vyos_net_name', 'e4', '00:0c:29:2d:44:53', 'eth4']
Oct 28 16:00:00 vyos-NB02 vyos_net_name[878]: Started with arguments: ['/lib/udev/vyos_net_name', 'e2', '00:0c:29:2d:44:2b', 'eth0']
Oct 28 16:00:00 vyos-NB02 vyos_net_name[882]: Started with arguments: ['/lib/udev/vyos_net_name', 'e3', '00:0c:29:2d:44:49', 'eth3']
Oct 28 16:00:00 vyos-NB02 vyos_net_name[881]: Started with arguments: ['/lib/udev/vyos_net_name', 'e6', '00:0c:29:2d:44:3f', 'eth2']
Oct 28 16:00:00 vyos-NB02 vyos_net_name[879]: Started with arguments: ['/lib/udev/vyos_net_name', 'e5', '00:0c:29:2d:44:35', 'eth1']
Oct 28 16:00:00 vyos-NB02 vyos_net_name[883]: Started with arguments: ['/lib/udev/vyos_net_name', 'e7', '00:e0:4c:ee:89:5b']

Looks like it is related to T5324

I too have

Oct 28 18:03:46 debian vyos_net_name[888]: lookup e6, 00:0c:29:2d:44:3f
Oct 28 18:03:46 debian vyos_net_name[884]: lookup e3, 00:0c:29:2d:44:49
Oct 28 18:03:46 debian vyos_net_name[887]: lookup e5, 00:0c:29:2d:44:35
Oct 28 18:03:46 debian vyos_net_name[886]: lookup e4, 00:0c:29:2d:44:53
Oct 28 18:03:46 debian vyos_net_name[885]: lookup e2, 00:0c:29:2d:44:2b
Oct 28 18:03:46 debian vyos_net_name[1295]: lookup eth0, 00:e0:4c:ee:89:5b

I don't have /run/udev/log/ folder!

vyos@vyos-NB02:/$ ls /run/udev/
control data links tags watch

SteveP

New version 2.19.2 same problem!

This version has a 6.9.0 section so you would think it would also cover 6.6.x

Perhaps the issue is with the kernel. Not sure where to go next with this.

SteveP

#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,9,0)
static int r8152_get_eee(struct r8152 *tp, struct ethtool_keee *eee)
.
.
.
.

#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(6,9,0) */

and another in compatibility.h

#if LINUX_VERSION_CODE < KERNEL_VERSION(6,9,0)
	#define ethtool_keee ethtool_eee
.
.
.
#endif /* LINUX_VERSION_CODE < KERNEL_VERSION(6,9,0) */
This comment was removed by SteveP.
This comment was removed by SteveP.
This comment was removed by SteveP.
This comment was removed by SteveP.
This comment was removed by SteveP.

It seems to be the 50-usb-realtek-net.rules file causing the strange behaviour.

When I load the module in the pre script as I have been for ages, I don't load the 50-usb-realtek-net.rules file. As soon as I include that file eth0 disappears.

I have created a v2.19.2 package without 50-usb-realtek-net.rules and all seems ok.

 sudo dmesg | grep -i "renamed from"
[    1.116038] vmxnet3 0000:0b:00.0 e2: renamed from eth0
[    1.477120] e1000e 0000:04:00.0 e3: renamed from eth1
[    1.485915] e1000e 0000:0c:00.0 e4: renamed from eth2
[    1.503652] e1000e 0000:13:00.0 e5: renamed from eth0
[    1.505619] e1000e 0000:1b:00.0 e6: renamed from eth3
[    2.195250] r8152 4-1:1.0 e9: renamed from eth0
[   20.423097] r8152 4-1:1.0 eth5: renamed from e9
[   20.451075] e1000e 0000:0c:00.0 eth4: renamed from e4
[   20.623545] e1000e 0000:1b:00.0 eth2: renamed from e6
[   21.081452] e1000e 0000:13:00.0 eth1: renamed from e5
[   21.133478] vmxnet3 0000:0b:00.0 eth0: renamed from e2
[   21.181613] e1000e 0000:04:00.0 eth3: renamed from e3

I now have two gaps in the numbering and your script deals with that.
eth5 is renamed from e9 as it should be and eth0 is OK.

SteveP

I'll let you know.

don't forget 2.19.2.

fastest I've ever seen it!

iperf3 --bind-dev eth5 -c 172.16.32.2 -P2 -t60
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.00  sec  8.38 GBytes  1.20 Gbits/sec  108             sender
[  5]   0.00-60.00  sec  8.38 GBytes  1.20 Gbits/sec                  receiver
[  7]   0.00-60.00  sec  8.11 GBytes  1.16 Gbits/sec   93             sender
[  7]   0.00-60.00  sec  8.11 GBytes  1.16 Gbits/sec                  receiver
[SUM]   0.00-60.00  sec  16.5 GBytes  2.36 Gbits/sec  201             sender
[SUM]   0.00-60.00  sec  16.5 GBytes  2.36 Gbits/sec                  receiver

SteveP

Ah, does that explain what I commented on earlier?

"It also looks like it takes them in groups of same driver and starts from eth0 with every new driver type.
vmxnet3 eth0
e1000e eth0-eth3
r8152 eth0 again."

BTW @SteveP these iperf speeds look quite impressive, I thought USB overhead would make it difficult to see much more than 1 Gbps in practice. Realtek was traditionally a "low cost, low performance" brand, it seems they have made a lot of progress...

Hi marekm

It has not always been this way. The trick is to select a particular version of the RTL8156 chipset.

sudo udevadm info -a -p /sys/class/net/eth5 | grep -i bcdd
  ATTRS{bcdDevice}=="3104"

The 31:04 is the particular RTL8156B(S) version and is the only one that works like this. The ones used here are a Startech usbc variant and a Club3d USBA one.

If you need any more info let me know.

SteveP