If you’re running OpenWrt on a Raspberry Pi 5 with a USB-to-Ethernet adapter based on the Realtek RTL8153B chipset, you may have noticed that the adapter stops working after a power outage. It works fine after a manual unplug/replug, but never comes up on its own after a cold boot. Here’s why, and how to fix it permanently.

The Problem

Many RTL8153B-based USB Ethernet adapters (including models from TP-Link, Ugreen, and others) use a dual-mode design. When first plugged in, they present themselves as a USB CD-ROM drive (product ID 0bda:8151) containing a Windows driver installer. A special kernel driver called r8152-cfgselector is supposed to intercept this, switch the device to Ethernet mode (product ID 0bda:8153), and hand it off to the r8152 network driver.

The problem is a boot-time race condition. On the Raspberry Pi 5 running OpenWrt, the USB device enumerates at around t=4s during boot, but r8152-cfgselector doesn’t load until around t=8s. In that 4-second gap, the usb-storage driver claims the device as a CD-ROM, and the Ethernet driver never gets a chance.

You can confirm this by checking dmesg after a cold boot:

1
2
3
4

[    4.3s] usb 4-1: New USB device found, idVendor=0bda, idProduct=8151
[    4.3s] usb-storage 4-1:1.0: USB Mass Storage device detected
[    5.4s] scsi 0:0:0:0: CD-ROM            USB CD-ROM       2.00
[    8.2s] usbcore: registered new device driver r8152-cfgselector  <-- too late!

When you manually unplug and replug the adapter, r8152-cfgselector is already loaded and intercepts the device before usb-storage can grab it. That’s why a replug always fixes it.

What Doesn’t Work

Before finding the real fix, I tried two approaches that both failed:

1. OpenWrt Hotplug Script (/etc/hotplug.d/usb/)

I wrote a script to detect 0bda:8151 and trigger a USB reset. It never fired. OpenWrt’s hotplug.json (procd) short-circuits USB device events – when a USB device has MAJOR/MINOR set (which all USB devices do), it takes the makedev code path and returns before reaching the generic hotplug-call dispatcher. Scripts in /etc/hotplug.d/usb/ are simply never executed for USB device add events on OpenWrt.

2. Init.d Script with USB Deauthorize/Reauthorize

I created an init.d service that waited for the device, detected 8151 mode, unbound it from usb-storage, then deauthorized/reauthorized the USB port to trigger re-enumeration. The script ran correctly (confirmed by syslog), but the deauthorize/reauthorize cycle doesn’t actually power-cycle the USB hardware on the Raspberry Pi 5. The device kept its internal state and re-enumerated in CD-ROM mode again, with usb-storage immediately reclaiming it.

The Fix

The solution is a single kernel boot parameter. On OpenWrt for RPi5, usb-storage is compiled as a built-in kernel module (not a loadable module), so the only way to pass it parameters is via the kernel command line.

Edit /boot/cmdline.txt and append:

1

usb-storage.quirks=0bda:8151:i

The i flag means ignore – the kernel will prevent usb-storage from ever binding to a device with vendor ID 0bda and product ID 8151. The full line should look something like:

1

console=tty1 console=serial0,115200 root=PARTUUID=xxxxx-02 rootfstype=ext4 rootwait usb-storage.quirks=0bda:8151:i

Important: Everything must stay on a single line.

Reboot, and you’re done. After reboot, dmesg should show the device enumerating directly as 0bda:8153 (Ethernet mode):

1
2
3
4

[    2.6s] usb 4-1: New USB device found, idVendor=0bda, idProduct=8153
[    8.3s] r8152-cfgselector 4-1: reset SuperSpeed USB device number 2
[    8.8s] r8152 4-1:1.0: load rtl8153b-2 v2 successfully
[   12.8s] r8152 4-1:1.0 eth1: carrier on

No race condition, no userspace workarounds, no scripts. The kernel simply never lets usb-storage touch the device.

Why This Works

The RTL8153B’s dual-mode behavior is identical to how old 3G USB modems worked – they’d present a virtual CD-ROM with Windows drivers, and usb_modeswitch would switch them to modem mode. The usb-storage.quirks parameter is the same mechanism the kernel provides for those devices.

By ignoring 0bda:8151 at the usb-storage level, the device sits unclaimed until r8152-cfgselector loads. The cfgselector driver then switches the USB configuration, the device re-enumerates as 0bda:8153, and the r8152 Ethernet driver takes over.

Environment

  • Raspberry Pi 5
  • OpenWrt 24.10.4 (bcm27xx/bcm2712)
  • Kernel 6.6.110
  • USB Ethernet adapter: Realtek RTL8153B (0bda:8151 / 0bda:8153)
  • Connected via the RPi5’s USB 3.0 xHCI controller (xhci-hcd.1, bus 4)

TL;DR

Add usb-storage.quirks=0bda:8151:i to /boot/cmdline.txt on your Raspberry Pi 5 running OpenWrt. Reboot. Your RTL8153B USB Ethernet adapter will survive power outages without needing a manual replug.