Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] LE12 on Rpi5 - RTL8153-based USB3.0 to wired ethernet adapter doesn't come up across a boot #8648

Open
rkershenbaum opened this issue Feb 22, 2024 · 9 comments

Comments

@rkershenbaum
Copy link

Describe the bug

RTL8153-based USB3.0 to wired ethernet adapter doesn't come up across a boot. It does not appear in Settings/LibreELEC/ Connections. Unplugging it and replugging it causes it to activate until the next reboot.

How to reproduce

Steps to reproduce the behavior:

  1. Plug a RTL8153-based Ethernet adapter into a USB 3.0 port on Rpi5.
  2. Check that it is active in the settings screen
  3. Reboot the Rpi5
  4. Check the settings screen and note that the eth1 interface is not there.
  5. Unplug and replug the adapter.
  6. Note that the eth1 interface now appears in the setting scren.

Information

  • LibreELEC Version: LibreELEC-RPi5.aarch64-12.0-nightly-20240222-96ea547
  • Hardware Platform: Rpi5

Log file

https://paste.libreelec.tv/happy-bonefish.log

@rkershenbaum
Copy link
Author

The problem does not exist in LE 11.0.6, but appears to have been introduced in LE 12.

@115ek
Copy link

115ek commented Feb 24, 2024

I had a similar problem on rpi4 with a normal ubuntu. It turned out that the vendor implemented two usb modes for the RTL8153-based device:

  1. Ethernet device (vid: 0bda, pid: 8153)
  2. CD Rom drive (vid: 0bda, pid: 8152)

The CD rom mode is thought to be used for installing windows drivers and to avoid shipping an additional mini cd. [1]
If the adapter is plugged before boot, the cd rom mode is active and no network device driver will be loaded.

To fix that, you for example could apply a udev rule which simply ejects the cdrom and reloads the usb device as per [2]. That worked fine for me.

I'm not familiar with LibreELEC in detail, but I guess there is some way to add udev rules. If no experienced developer jumps in, I could also have a look into where to add it.

[1] https://forums.raspberrypi.com/viewtopic.php?t=336517#p2021375
[2] https://forums.raspberrypi.com/viewtopic.php?t=336517#p2022215

@115ek
Copy link

115ek commented Feb 24, 2024

It would be helpful to see the output of
lsusb
with adapter plugged before boot (non-working) and adapter plugged after boot (working). Then we could find the correct usb pids for the udev rule.

@rkershenbaum
Copy link
Author

rkershenbaum commented Feb 24, 2024

Actually , it's the other way around --

After boot = non-working:

login as: root
root@libreelec's password:
##############################################
#                 LibreELEC                  #
#            https://libreelec.tv            #
##############################################

LibreELEC (community): nightly-20240224-9992601 (RPi5.aarch64)
LibreELEC:~ # ifconfig
eth0      Link encap:Ethernet  HWaddr D8:3A:DD:CA:DE:2B
          inet addr:192.168.1.144  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5099 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1803 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2822509 (2.6 MiB)  TX bytes:386593 (377.5 KiB)
          Interrupt:110

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:44 errors:0 dropped:0 overruns:0 frame:0
          TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:14406 (14.0 KiB)  TX bytes:14406 (14.0 KiB)

LibreELEC:~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0471:060c Philips (or NXP) Consumer Infrared Transceiver (HP)
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 003 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 004 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
LibreELEC:~ #
`
After unplugging and replugging (working):

`LibreELEC:~ # ifconfig
eth0      Link encap:Ethernet  HWaddr D8:3A:DD:CA:DE:2B
          inet addr:192.168.1.144  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13792 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2026 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3504477 (3.3 MiB)  TX bytes:494651 (483.0 KiB)
          Interrupt:110

eth1      Link encap:Ethernet  HWaddr 4C:E1:73:42:54:E9
          inet6 addr: fe80::4ee1:73ff:fe42:54e9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:929 errors:0 dropped:0 overruns:0 frame:0
          TX packets:83 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:69704 (68.0 KiB)  TX bytes:42751 (41.7 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:84 errors:0 dropped:0 overruns:0 frame:0
          TX packets:84 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:17626 (17.2 KiB)  TX bytes:17626 (17.2 KiB)

LibreELEC:~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0471:060c Philips (or NXP) Consumer Infrared Transceiver (HP)
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 004: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 004: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 004 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

This is with the workaround described installed that's described here (udev rule):

https://io.24hoursmedia.com/tech-notes/help-my-rpi4-thinks-my-usb-ethernet-is-a-storage-device

Without that, the device does show in lsusb as RTL8151 instead of RTL8153. IIRC, with the udev rule installed, the device does come up across a boot -- but only on the Rpi4, and not on the Rpi5, running the same nightlies.

@heitbaum
Copy link
Contributor

@heitbaum
Copy link
Contributor

heitbaum commented Nov 4, 2024

Is this still happening in LE13 nightlies. Note it is expected that RPi5 will be updated to 6.12 in the “near future” which is expected to be the LTS release of linux for 2024. So the testing will need to be done on that release too.

@rkershenbaum
Copy link
Author

I just tried the latest (20241103) LE13 nightly and -- good news -- the problem is fixed. The connection is recognized across a boot.

If you post here when the 6.12 test is needed, I'll try it again then.

FYI, I also tried my AX88179-based Ugreen USB3.0 to Ethernet adapter -- and it's still not recognized.

Thanks for staying on top of this!

@heitbaum
Copy link
Contributor

Now the LE13 nightly builds are running kernel 6.12 - so if you can test / ... - then we will know if this is resolved for the LE13. https://test.libreelec.tv/13.0/RPi/RPi5/ - Please use the latest (2024-12-09 or newer)

@rkershenbaum
Copy link
Author

Unfortunately, the problem is back in the 2024-12-09 LE13 release. The RTL8153-based adapter is not activated across a boot. It does work when I unplug it from the USB3.0 port and plug it back in while the system is up.

FYI, the AX88179-based adapter is still not recognized at all

Hope this helps. Let me know if and when I can do more testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants