ssmithxandClaude Sonnet 5
a9dd08ac4d
Deploy / deploy (push) Successful in 2s
pciutils/usbutils aren't guaranteed present, especially on minimal or live-boot systems — exactly the kind of environment someone testing Archipelago compatibility is likely to be running. Rewrote WiFi/ethernet detection to read /sys/class/net/$iface/device directly first (vendor, device, driver via uevent — always available, no package needed), the same approach as manually finding a chip by hand: enumerate interfaces, read vendor/device IDs from sysfs, get the driver from uevent/modalias. Only reaches for lspci/lsusb, when installed, to turn a hex ID into a friendly name; falls back to a small built-in vendor-ID table (Intel, Broadcom, Realtek, Atheros, MediaTek, Ralink) plus the raw ID + driver name otherwise. Also now handles USB and SDIO wifi chips, not just PCI. Found and fixed a real bug while testing this against actual hardware (this box's virtio NIC): the naive `basename` of the resolved device path breaks for drivers like virtio-net that wrap the real PCI function one level deeper in sysfs (.../0000:00:12.0/virtio2) — basename alone grabs "virtio2", which lspci -s rejects as "Invalid slot number". Fixed by extracting the last domain:bus:device.function-shaped path component instead of trusting the final one. Verified for real, not just written: ran with lspci installed (gets the friendly "Red Hat, Inc. Virtio network device" name), then genuinely removed lspci/lsusb from the system (moved the binaries aside, restored after) and reran — falls back correctly to vendor ID + driver name instead of erroring or going blank. Passes shellcheck clean both times. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>