wpilibsuite / wpilibsuite/SystemcoreTesting
USB Static IP Hot-Plug Unconfigured
Nobody has claimed this yet.
- 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
- Power on Systemcore with the device already attached →
usb0gets172.27.0.1/24, up. Reliable across all 4 USB-A ports, with or without a second USB device attached (ex. CANivore). - With Systemcore still running, disconnect/reconnect the device's USB link (replug or A driver-level unbind/rebind).
dmesgshows a clean unregister/register ofusb0with the same MAC.ip addrafterward:
Nousb0: <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:ffinetline. 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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