ubuntuusers.de

wenn ich das Gerät abziehe sieht es so aus:

johnny@MATERUS17YE5:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 3252:0004 Goodong USB Camera
Bus 001 Device 003: ID 25a7:fa7e Areson Technology Corp 2.4G Wireless Receiver
Bus 001 Device 002: ID 1044:7a3b Chu Yuen Enterprise Co., Ltd USB-HID Keyboard
Bus 001 Device 005: ID 8087:0033 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

wenn ich nur das USB-C Hub ohne weitere Peripherie dran stecke so:

johnny@MATERUS17YE5:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 3252:0004 Goodong USB Camera
Bus 001 Device 003: ID 25a7:fa7e Areson Technology Corp 2.4G Wireless Receiver
Bus 001 Device 011: ID 0bda:5459 Realtek Semiconductor Corp. BillBoard Device
Bus 001 Device 009: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 008: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 006: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 002: ID 1044:7a3b Chu Yuen Enterprise Co., Ltd USB-HID Keyboard
Bus 001 Device 005: ID 8087:0033 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 005: ID 30f3:0419 Realtek USB 10/100/1000 LAN
Bus 004 Device 004: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub
Bus 004 Device 003: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

dementsprechend gehören zu dem Hub folgende Devices:

• Bus 001 Device 011: ID 0bda:5459 Realtek Semiconductor Corp. BillBoard Device

• Bus 001 Device 009: ID 05e3:0608 Genesys Logic, Inc. Hub

• Bus 001 Device 008: ID 05e3:0610 Genesys Logic, Inc. Hub

• Bus 001 Device 006: ID 05e3:0610 Genesys Logic, Inc. Hub

• Bus 004 Device 005: ID 30f3:0419 Realtek USB 10/100/1000 LAN

• Bus 004 Device 004: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub

• Bus 004 Device 003: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub

Dav0 schrieb:

[…]

johnny@MATERUS17YE5:~$ lsusb
[…] Bus 004 Device 005: ID 30f3:0419 Realtek USB 10/100/1000 LAN

Das ist die ID der Ethernet-Schnittstelle.

Starte den Rechner neu und durchsuche damit das Systemlog:

journalctl -b  | grep -i 30f3 

Ok

johnny@MATERUS17YE5:~$ journalctl -b  | grep -i 30f3 
Jan 26 18:03:28 MATERUS17YE5 kernel: usb 4-1.4.1: New USB device found, idVendor=30f3, idProduct=0419, bcdDevice=31.01
Jan 26 18:03:29 MATERUS17YE5 sbkeysync[1179]:     726b3eb654046a30f3f83d9b96ce03f670e9a806d1708a0371e62dc49d2c23c1
Jan 26 18:03:29 MATERUS17YE5 sbkeysync[1179]:     726b3eb654046a30f3f83d9b96ce03f670e9a806d1708a0371e62dc49d2c23c1

Gehe ich recht in der Annahme, dass der Treiber nicht zugeordnet wird?

Dav0 schrieb:

Ok

johnny@MATERUS17YE5:~$ journalctl -b  | grep -i 30f3 
Jan 26 18:03:28 MATERUS17YE5 kernel: usb 4-1.4.1: New USB device found, idVendor=30f3, idProduct=0419, bcdDevice=31.01
[…]

Gehe ich recht in der Annahme, dass der Treiber nicht zugeordnet wird?

Die Verwendung des bestimmten Artikels ist verfrüht, denn wir wissen ja noch gar nicht, welcher Treiber für Deine Hardware zuständig sein könnte. Allerdings muss es einen Treiber geben, denn sonst würde die Ethernet-Schnittstelle – entgegen Deiner Aussage – gar nicht funktionieren. Also Deine Annahme ist falsch. Der Diagnosebefehl ist auch nicht geeignet, den unbekannten Treiber anzuzeigen, wohl aber die temporäre Adresse der Hardware im USB-System. Damit kann man weiter suchen:

journalctl -b  | grep usb | grep -i 30f3
journalctl -b  | grep usb | grep '4-1'
find /sys/bus/usb/drivers/ -type l -name '4-1*'

Die Angabe 4-1 musst Du ggf. an den aktuellen Wert der temporären Adresse anpassen.

Vielen Dank für die Rückmeldung. Die Suche nach 303f ergab die vorherige 4-1-Angabe. Daher habe ich die Suche so wie du vorgeschlagen hast abgearbeitet:

johnny@MATERUS17YE5:~$ journalctl -b  | grep usb | grep -i 30f3
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4.1: New USB device found, idVendor=30f3, idProduct=0419, bcdDevice=31.01
johnny@MATERUS17YE5:~$ journalctl -b  | grep usb | grep '4-1'
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1: New USB device found, idVendor=05e3, idProduct=0626, bcdDevice= 6.63
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1: Product: USB3.1 Hub
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1: Manufacturer: GenesysLogic
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4: new SuperSpeed USB device number 3 using xhci_hcd
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4: New USB device found, idVendor=05e3, idProduct=0626, bcdDevice= 6.63
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4: Product: USB3.1 Hub
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4: Manufacturer: GenesysLogic
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4.1: new SuperSpeed USB device number 4 using xhci_hcd
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4.1: New USB device found, idVendor=30f3, idProduct=0419, bcdDevice=31.01
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4.1: Product: USB 10/100/1000 LAN
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4.1: Manufacturer: Realtek
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4.1: SerialNumber: 101000001
Jan 27 11:21:08 MATERUS17YE5 kernel: cdc_ether 4-1.4.1:2.0 eth0: register 'cdc_ether' at usb-0000:00:0d.0-1.4.1, CDC Ethernet Device, c0:ea:c3:62:27:07
Jan 27 11:21:09 MATERUS17YE5 mtp-probe[794]: checking bus 4, device 4: "/sys/devices/pci0000:00/0000:00:0d.0/usb4/4-1/4-1.4/4-1.4.1"
Jan 27 11:21:11 MATERUS17YE5 ModemManager[1181]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:0d.0/usb4/4-1/4-1.4/4-1.4.1': not supported by any plugin
johnny@MATERUS17YE5:~$ find /sys/bus/usb/drivers/ -type l -name '4-1*'
/sys/bus/usb/drivers/usb/4-1.4
/sys/bus/usb/drivers/usb/4-1
/sys/bus/usb/drivers/usb/4-1.4.1
/sys/bus/usb/drivers/hub/4-1:1.0
/sys/bus/usb/drivers/hub/4-1.4:1.0
/sys/bus/usb/drivers/cdc_ether/4-1.4.1:2.1
/sys/bus/usb/drivers/cdc_ether/4-1.4.1:2.0

Ich war bisher der Meinung der richtige Treiber sei der rtl8153b - wie unter Windows aufgeführt und Linux hat eine Art "Universaltreiber" geladen 😳

Dav0 schrieb:

[…]

johnny@MATERUS17YE5:~$ journalctl -b  | grep usb | grep -i 30f3
[…]
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4.1: Product: USB 10/100/1000 LAN
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4.1: Manufacturer: Realtek
Jan 27 11:21:08 MATERUS17YE5 kernel: usb 4-1.4.1: SerialNumber: 101000001
Jan 27 11:21:08 MATERUS17YE5 kernel: cdc_ether 4-1.4.1:2.0 eth0: register 'cdc_ether' at usb-0000:00:0d.0-1.4.1, CDC Ethernet Device, c0:ea:c3:62:27:07
[…]
johnny@MATERUS17YE5:~$ find /sys/bus/usb/drivers/ -type l -name '4-1*'
[…]
/sys/bus/usb/drivers/cdc_ether/4-1.4.1:2.1
/sys/bus/usb/drivers/cdc_ether/4-1.4.1:2.0

OK. Kernel-Modul cdc_ether kümmert sich um die Hardware, die wohl von Realtek stammt, aber ob das ein RTL8153 ist, wissen wir noch nicht. Denn die Selektion dieses Treibers erfolgt nicht über den Hersteller (Vendor-ID 30f3), sondern über generische USB-Eigenschaften:

modinfo cdc_ether | grep -i -e v30f3 -e 'v\*' 

alias:          usb:v*p*d*dc*dsc*dp*ic02isc0Aip00in*
alias:          usb:v*p*d*dc*dsc*dp*ic02isc06ip00in*

Mit dem Namen des Treibermoduls kann man im Systemlog weiter suchen:

journalctl -b  | grep cdc_ether 

Interessant ist auch, was im Systemlog zu der von Treiber angelegten Software-Schnittstelle steht, deren Namen z.B.

ip link 

ausgibt.

Ich war bisher der Meinung der richtige Treiber sei der rtl8153b - wie unter Windows aufgeführt

Der Name des Treibers für Windows ist ohne Belang für die Funktion des Chips unter Linux. Genau so wenig erlaubt der Name des Treibers irgendwelche sicheren Rückschlüsse auf den verbauten Chip. Für manche Chips des Typs RTL8153 ist unter Linux der Treibermodul r8152 zuständig, allerdings nicht unter der USB-ID Deiner Hardware. Das mag ein Fehler sein oder auch nicht. Wenn das ein Fehler ist, dann mag er zukünftig behoben werden oder auch nicht. Wenn man den Chip sicher identifiziert hat, mag zielführend sein, dem Quellcode des Moduls r8152 einfach die fehlende USB-ID Deiner Hardware hinzuzufügen und dann zu übersetzen. Oder auch nicht.

Ok, dann gilt es denn richtigen Chipsatz heraus zu finden.

Die Suche im Log nach dem Treibermodul ergab:

johnny@MATERUS17YE5:~$ journalctl -b  | grep cdc_ether 
Jan 29 18:14:00 MATERUS17YE5 kernel: cdc_ether 4-1.4.1:2.0 eth0: register 'cdc_ether' at usb-0000:00:0d.0-1.4.1, CDC Ethernet Device, c0:ea:c3:62:27:07
Jan 29 18:14:00 MATERUS17YE5 kernel: usbcore: registered new interface driver cdc_ether
Jan 29 18:14:00 MATERUS17YE5 kernel: cdc_ether 4-1.4.1:2.0 enxc0eac3622707: renamed from eth0

ip link sagt:

johnny@MATERUS17YE5:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp46s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
    link/ether d8:5e:d3:88:78:7c brd ff:ff:ff:ff:ff:ff
3: enxc0eac3622707: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether c0:ea:c3:62:27:07 brd ff:ff:ff:ff:ff:ff
4: wlo1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DORMANT group default qlen 1000
    link/ether 8c:b8:7e:cc:36:e8 brd ff:ff:ff:ff:ff:ff
    altname wlp0s20f3

...das bringt wohl nicht so richtig weiter, oder doch?

Kann ich nicht einfach probieren die HardwareID in den Modulquellcode zu ergänzen?

Dav0 schrieb:

[…]

johnny@MATERUS17YE5:~$ journalctl -b  | grep cdc_ether 
Jan 29 18:14:00 MATERUS17YE5 kernel: cdc_ether 4-1.4.1:2.0 eth0: register 'cdc_ether' at usb-0000:00:0d.0-1.4.1, CDC Ethernet Device, c0:ea:c3:62:27:07
Jan 29 18:14:00 MATERUS17YE5 kernel: usbcore: registered new interface driver cdc_ether
Jan 29 18:14:00 MATERUS17YE5 kernel: cdc_ether 4-1.4.1:2.0 enxc0eac3622707: renamed from eth0

Das sind die Namen der vom Treiber angelegten Schnittstelle für die Hardware.

johnny@MATERUS17YE5:~$ ip link
[…]
3: enxc0eac3622707: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether c0:ea:c3:62:27:07 brd ff:ff:ff:ff:ff:ff
[…]

...das bringt wohl nicht so richtig weiter, oder doch?

Erst, wenn Du das Systemlog nach den Namen der Schnittstelle durchsuchst.

Kann ich nicht einfach probieren die HardwareID in den Modulquellcode zu ergänzen?

Wenn Du Erfahrung und Kenntnisse in der Treiberdprogrammierung hast, kannst Du das natürlich versuchen. Ich halte nichts von solchen Schüssen ins Blaue.

Ich hätte da noch eine Idee, die mag etwas einfach klingen, aber es wäre auch einfach auszuprobieren, als Live-System, das noch in Entwicklung befindlichen Ubuntu 24.04 (Noble Numbat) Daily Build:

• https://cdimage.ubuntu.com/daily-live/current/

Falls das funktioniert und es wird installiert, wird die Installation dann durch die Updates zum normalen Ubuntu 24.04 Noble Numbat im April. Und bekommt von da an auch die normalen Updates.

Das syslog nach der angelegten Device durchsucht ergibt folgendes:

johnny@MATERUS17YE5:~$ journalctl -b  | grep enxc0eac3622707
Jan 30 20:11:33 MATERUS17YE5 kernel: cdc_ether 4-1.4.1:2.0 enxc0eac3622707: renamed from eth0
Jan 30 20:11:34 MATERUS17YE5 networkd-dispatcher[1120]: ERROR:Unknown state for interface NetworkctlListState(idx=3, name='enxc0eac3622707', type='ether', operational='n/a', administrative='unmanaged'): n/a
Jan 30 20:11:34 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641894.6298] manager: (enxc0eac3622707): new Ethernet device (/org/freedesktop/NetworkManager/Devices/3)
Jan 30 20:11:34 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641894.6302] settings: (enxc0eac3622707): created default wired connection 'Kabelgebundene Verbindung 2'
Jan 30 20:11:34 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641894.6302] device (enxc0eac3622707): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Jan 30 20:11:34 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641894.6306] device (enxc0eac3622707): carrier: link connected
Jan 30 20:11:34 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641894.6320] device (enxc0eac3622707): state change: unavailable -> disconnected (reason 'none', sys-iface-state: 'managed')
Jan 30 20:11:34 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641894.6335] device (enxc0eac3622707): Activation: starting connection 'Kabelgebundene Verbindung 2' (658e26b5-633b-33d3-9029-6dcca07c4b2a)
Jan 30 20:11:34 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641894.6335] device (enxc0eac3622707): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jan 30 20:11:34 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641894.6337] device (enxc0eac3622707): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jan 30 20:11:34 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641894.6339] device (enxc0eac3622707): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Jan 30 20:11:34 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641894.6340] dhcp4 (enxc0eac3622707): activation: beginning transaction (timeout in 45 seconds)
Jan 30 20:11:34 MATERUS17YE5 avahi-daemon[1102]: Joining mDNS multicast group on interface enxc0eac3622707.IPv6 with address fe80::733e:b03e:7461:bd26.
Jan 30 20:11:34 MATERUS17YE5 avahi-daemon[1102]: New relevant interface enxc0eac3622707.IPv6 for mDNS.
Jan 30 20:11:34 MATERUS17YE5 avahi-daemon[1102]: Registering new address record for fe80::733e:b03e:7461:bd26 on enxc0eac3622707.*.
Jan 30 20:11:39 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641899.3694] dhcp4 (enxc0eac3622707): state changed new lease, address=192.168.178.130
Jan 30 20:11:39 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641899.3720] device (enxc0eac3622707): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Jan 30 20:11:39 MATERUS17YE5 avahi-daemon[1102]: Joining mDNS multicast group on interface enxc0eac3622707.IPv4 with address 192.168.178.130.
Jan 30 20:11:39 MATERUS17YE5 avahi-daemon[1102]: New relevant interface enxc0eac3622707.IPv4 for mDNS.
Jan 30 20:11:39 MATERUS17YE5 avahi-daemon[1102]: Registering new address record for 192.168.178.130 on enxc0eac3622707.IPv4.
Jan 30 20:11:39 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641899.3758] device (enxc0eac3622707): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Jan 30 20:11:39 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641899.3760] device (enxc0eac3622707): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Jan 30 20:11:39 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641899.3768] policy: set 'Kabelgebundene Verbindung 2' (enxc0eac3622707) as default for IPv4 routing and DNS
Jan 30 20:11:39 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641899.3773] device (enxc0eac3622707): Activation: successful, device activated.
Jan 30 20:11:39 MATERUS17YE5 systemd-resolved[939]: enxc0eac3622707: Bus client set search domain list to: fritz.box
Jan 30 20:11:39 MATERUS17YE5 systemd-resolved[939]: enxc0eac3622707: Bus client set default route setting: yes
Jan 30 20:11:39 MATERUS17YE5 systemd-resolved[939]: enxc0eac3622707: Bus client set DNS server list to: 192.168.178.1
Jan 30 20:11:40 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641900.1376] dhcp6 (enxc0eac3622707): activation: beginning transaction (timeout in 45 seconds)
Jan 30 20:11:40 MATERUS17YE5 avahi-daemon[1102]: Leaving mDNS multicast group on interface enxc0eac3622707.IPv6 with address fe80::733e:b03e:7461:bd26.
Jan 30 20:11:40 MATERUS17YE5 avahi-daemon[1102]: Joining mDNS multicast group on interface enxc0eac3622707.IPv6 with address fd00::fc8d:a458:3cd7:f2d0.
Jan 30 20:11:40 MATERUS17YE5 avahi-daemon[1102]: Registering new address record for fd00::fc8d:a458:3cd7:f2d0 on enxc0eac3622707.*.
Jan 30 20:11:40 MATERUS17YE5 NetworkManager[1108]: <info>  [1706641900.1408] dhcp6 (enxc0eac3622707): state changed new lease
Jan 30 20:11:40 MATERUS17YE5 avahi-daemon[1102]: Withdrawing address record for fe80::733e:b03e:7461:bd26 on enxc0eac3622707.
Jan 30 20:11:41 MATERUS17YE5 avahi-daemon[1102]: Registering new address record for fd00::d138:fe59:e074:54d1 on enxc0eac3622707.*.

Daraus kann ich auch nichts hilfreiches entnehmen. Es gibt bestimmt ein paar Sachen, die ich kann, aber Erfahrung und Kenntnisse in der Treiberprogrammierung gehören noch nicht dazu 😉

@trollsportverein

Danke für den Hinweis. Ich habe tatsächlich ein Ubuntu-Live-System 23.*irgendwas* probiert, aber damit keinen Erfolg gehabt. Ich werde aber auch die 24.04 mal versuchen und sag Bescheid, wie es ausgegangen ist.

Edit: ...gerade 24.04 ausprobiert - leider gleiche Ausgaben wie hier bereits gepostet und auch mit 100Mbit ☹

Viele Grüße

Dav0 schrieb:

Das syslog nach der angelegten Device durchsucht ergibt folgendes: […] Daraus kann ich auch nichts hilfreiches entnehmen.

Außer, dass die Hardware mit dem Kernel-Treiber cdc_ether problemlos funktioniert und automatisch mit IP-Adressen und DNS-Servern versorgt wird und es gar keine Symptome für irgend einen Fehler gibt.

...außer dass das Gerät nicht die versprochenen 1000Mbit liefert, funktioniert es ja auch ordnungsgemäß.

Dann werde ich das Gerät zurück schicken. Danke trotzdem für die Mühe.

Dav0 schrieb:

...außer dass das Gerät nicht die versprochenen 1000Mbit liefert, funktioniert es ja auch ordnungsgemäß.

Dann werde ich das Gerät zurück schicken.

Da das Gerät ja lt. Deiner Mitteilung unter Windows die 1000Mbit/s liefert, kann es auch an unter Linux fehlender Firmware liegen. Du betreibst den Adapter nicht direkt am Rechner, sondern indirekt über ein Dock, daher ist hier die Firmware für das Dock gemeint, diese mag fehlen oder unter Linux gar nicht als temporär ladbare Komponente verfügbar sein. Vielleicht gibt es aber auch schon beim Hersteller ein permanent flashbares Firmware-Update für das Dock.

Danke nochmal für den Hinweis, aber mit dem Hersteller stehe ich bereits in Kontakt. Bisher gab es von dessen Seite aber nichts, was mich weiter bringen würde.

Mich wundert, dass

modinfo r8152

nichts von Firmware aufführt. Das sieht hier anders aus (unter einem anderen Linux)

modinfo r8152
filename:       /lib/modules/6.6.16-1-lts/kernel/drivers/net/usb/r8152.ko.zst
version:        v1.12.13
license:        GPL
description:    Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
author:         Realtek linux nic maintainers <nic_swsd@realtek.com>
firmware:       rtl_nic/rtl8156b-2.fw
firmware:       rtl_nic/rtl8156a-2.fw
firmware:       rtl_nic/rtl8153c-1.fw
firmware:       rtl_nic/rtl8153b-2.fw
firmware:       rtl_nic/rtl8153a-4.fw
firmware:       rtl_nic/rtl8153a-3.fw
firmware:       rtl_nic/rtl8153a-2.fw
srcversion:     65F57EE9C8C8F6348094830
alias:          usb:v0B05p1976d*dc*dsc*dp*ic*isc*ip*in*

# Ausgabe gekürzt, da der Rest hier nicht weiter wichtig ist

Zeige doch mal die Ausgabe von den beiden folgenden Befehlen:

journalctl -b  | grep r815

und

ls -l /lib/firmware/rtl_nic