wpilibsuite / wpilibsuite/SystemcoreTesting

USB Static IP Hot-Plug Unconfigured

Open
#371 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Limelight
Dominant language
Java
Stars
186
Forks
24
Avg merge
8h 27m
Merged PRs (30d)
9

Description

A USB-Ethernet class (CDC-ECM) device plugged into a Systemcore USB-A port gets 172.27.0.1/24 on usb0 correctly only if it's attached before Systemcore powers on.

If it's hot-plugged into an already-running Systemcore, or its link drops and reconnects for any reason mid-session, cdc_ether re-registers usb0 cleanly at the kernel level, but the static IP/admin-up is never reapplied — usb0 is left as <BROADCAST,MULTICAST>, state DOWN, no inet line, for the rest of that boot. Only a full Systemcore power cycle recovers it; replugging the device does not.

Is this intended behavior?

  • If not, then hopefully the findings below help
  • If it is, then do you have any guidance for how to handle hot-plug events for devices like this?

Environment

  • Systemcore OS: limelightosr-2027.0.0-alpha13
  • device: a CDC-ECM class USB-Ethernet device, ex. RP2350

Root cause (confirmed via SSH)

limelight_gadget.service (Type=simple, ordered after network-online.target, no Restart=) runs its gadget --systemcore binary exactly once at boot. Confirmed directly from the journal that it executes:

sudo /usr/sbin/ifconfig usb0 up 172.27.0.1 netmask 255.255.255.0
sudo /usr/sbin/ifconfig usb1 up 172.26.0.1 netmask 255.255.255.0

matched by interface name, disregarding which physical device holds that name. Nothing else re-triggers this step. If usb0/usb1 disappear and reappear after boot for any reason, the kernel re-registers them cleanly but the static IP is never reapplied.

Steps To Reproduce

  1. Power on Systemcore with the device already attached → usb0 gets 172.27.0.1/24, up. Reliable across all 4 USB-A ports, with or without a second USB device attached (ex. CANivore).
  2. With Systemcore still running, disconnect/reconnect the device's USB link (replug or A driver-level unbind/rebind).
  3. dmesg shows a clean unregister/register of usb0 with the same MAC. ip addr afterward:
    usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
        link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
    
    No inet line. Persists until a full power cycle.

Attempted Fix

Added a udev rule that re-runs the same ifconfig commands on every usb0/usb1 add event (not just the first) resolves it:

# /etc/udev/rules.d/99-usb-gadget-hotplug-fix.rules
SUBSYSTEM=="net", ACTION=="add", KERNEL=="usb0", RUN+="/usr/sbin/ifconfig usb0 up 172.27.0.1 netmask 255.255.255.0"
SUBSYSTEM=="net", ACTION=="add", KERNEL=="usb1", RUN+="/usr/sbin/ifconfig usb1 up 172.26.0.1 netmask 255.255.255.0"

Verified across multiple simulated hot-plug cycles: without the rule, usb0 comes back unconfigured every time; with it, usb0 comes back UP with 172.27.0.1/24 and is reachable (ping succeeds) every time. It's additive-only (one new file, nothing existing modified) and idempotent with the boot-time step, so it doesn't change normal boot behavior.

Two small scripts are attached to apply/roll back this exact rule over SSH.

requirements.txt
systemcore_hotplug_fix_apply.py
systemcore_hotplug_fix_rollback.py

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review limelight_gadget.service, the attached systemcore_hotplug_fix_apply.py and systemcore_hotplug_fix_rollback.py, and the proposed /etc/udev/rules.d/99-usb-gadget-hotplug-fix.rules. Start by reproducing the usb0 disconnect/reconnect behavior and checking the udev add event. Done means usb0 and usb1 regain their static addresses and administrative UP state after hot-plugging, without changing normal boot behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux, shell
Domain
networking, operating-systems
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
76/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.