USB Ethernet works after replug, but not when connected at boot

Help
1

Hello everyone,

I’m new to the Haiku community and I’ve recently been experimenting with running it on my Surface Go (1st gen).

When my Microsoft USB Ethernet adapter (RTL8153 chipset) is connected before boot, Haiku detects the device but never brings the interface up — no IP, no connectivity.

If I unplug and replug the dongle after the desktop appears, it works perfectly every single time.

I need this fixed for a headless Surface Go setup (before I can finish writing a native driver for its Atheros Wi-Fi), so a manual replug is not an option.

Has anyone found a way to simulate a USB replug in software or force the driver to reload automatically during startup?

Full details

Problem

On Haiku (R1/Beta5), my Microsoft-branded USB Ethernet dongle (VID 0x045e, PID 0x07c6, RTL8153 GigE) works flawlessly only when plugged in after the system reaches the desktop.

If it’s plugged in at boot, the device appears in /dev/net/usb_ecm/0 but never acquires an IP address. ifconfig auto-config has no effect in this state.

Observations

  • Hotplug works 100%: unplug → replug → instant connection.

  • At boot, the interface node is present, but the stack behaves as if the device is half-initialised.

  • The /dev/net/usb_ecm/ index changes (0 → 1) after a manual replug.

Attempts so far

  • Startup scripts in UserBootscript to call ifconfig auto-config → no effect.

  • Scripts to poll /dev/net/usb_ecm/* and retry ifconfig until IP → fails when the device is in this “half-initialised” state.

  • Manual launch_roster restart net_server after boot → works, but doing it automatically at boot via UserBootscript doesn’t seem to help (likely timing-related).

  • Attempted to use usb_raw for low-level replug simulation, but the raw device node never appeared early enough.

  • Tried load_driver/unload_driver approach, but couldn’t locate working userland hooks for kernel driver reload.

Why I need it

This system is intended to run headless on a Surface Go (1st gen) where I’m also developing a Haiku Wi-Fi driver for the onboard Atheros card.

For now, the USB Ethernet dongle is my only way to get networking on this machine, so physically replugging it is not an option.

Example device info (from listusb -v)

Vendor ID …………… 0x045e (Microsoft Corp.)
Product ID …………… 0x07c6 (RTL8153 GigE [Surface Ethernet Adapter])
Product Version ……… 0x3000
Manufacturer String …. “Microsoft”
Product String ………… “Ethernet Adapter”

Any hints on scripting a USB replug in software, forcing a network driver reload at boot, or fixing this initialisation timing problem would be greatly appreciated.

2

Not sure if it’s the same issue, but what helps me using an Android phone using USB tethering is to restart the net_server process:

Ctrl+alt+delete on keyboard to bring up Team monitor GUI and then find “net_server” in the list and click on ‘Kill application’ button when ‘net_server’ is selected.

This restarts the net_server process automatically which then recognizes and starts up the usb ethernet with a good live network connection.

3

Then the simplest way may be to add a sleep 30 or similar in the UserBoutScript before restarting net_server.

It would be interesting to have a syslog to see why the net_server doesn’t manage to work with the device on the first try however.

4

Unfortunately, this does not work for me.

When I kill ‘net_server’ I can see a new, small pop-up window informing that the network adapter is being configured - but it never succeeds in the configuration job.

5

Update with logs (Beta 5, Surface Go 1st gen)

Logs collected with:

tail -n 200 /var/log/syslog | grep -iE "usb|ecm|dhcp"

On a cold boot, I only see DHCP retries on /dev/net/usb_ecm/0 (DISCOVER with increasing timeouts) and no kernel lines from usb_ecm itself (no “publish device … usb_ecm/…”, no “read mac address”, etc.). No DHCP_OFFER ever arrives.

After a physical unplug/replug I get:

publish device: path net/usb_ecm/1, module drivers/network/usb_ecm/device_v1
usb_ecm: read mac address: 50:1a:c5:fe:a9:8c

and then DHCP on /dev/net/usb_ecm/1 immediately receives OFFER and ACK.

This suggests the boot-time instance never reaches the “read mac address”/full attach stage, so the interface ends up half-initialised (likely with a zero MAC and/or link down), and DHCP is ignored by the router. A hotplug forces a clean attach and everything works.

Happy to capture whatever extra traces would help (e.g. enabling verbose logging for usb_ecm/USB during early userland). Please advise which knobs to turn on Beta 5.