lsusb

What it does

lsusb lists USB devices connected to the system — keyboards, mice, flash drives, USB hubs, webcams, and the USB host controllers themselves. It reads device information from the kernel's usbfs/sysfs interfaces and resolves vendor/product IDs into human-readable names using the usb.ids database, similar in spirit to how lspci works for the PCI bus. It's part of the usbutils package on most distributions.

Beginner examples

• lsusb — list all connected USB devices with vendor/product IDs and names
• lsusb -t — show devices as a tree reflecting USB bus/hub topology
• lsusb -v — show verbose descriptor details (often needs sudo for full output)
• lsusb | grep -i logitech — find a specific device by name

lsusb

Advanced examples

• Show the tree with negotiated link speeds and driver info: lsusb -tv
• Get full descriptor detail for troubleshooting a misbehaving device (needs root for complete output): sudo lsusb -v -d 046d:c52b
• Filter to a specific bus/device address found in a plain lsusb listing: lsusb -s 001:004 -v
• Diagnose a USB storage device not mounting by first confirming it's even detected: lsusb | grep -i storage
• Watch for a device appearing/disappearing (e.g. flaky USB connection) by re-running lsusb after replugging, or use udevadm monitor for live events.

sudo lsusb -v -d 046d:c52b

Common mistakes

• Running lsusb and expecting to see internal PCI hardware like the GPU or network card — those live on the PCI/PCIe bus and appear in lspci, not lsusb.
• Running lsusb -v as a normal user and getting incomplete output without realizing root privileges are needed to read full device descriptors.
• Assuming a device missing from lsusb output means faulty hardware, without first checking dmesg/journalctl for kernel-level USB errors (e.g. power negotiation failures) that occur before enumeration even completes.
• Expecting lsusb to work out of the box on macOS — it's a Linux-specific tool from usbutils; macOS uses system_profiler SPUSBDataType instead.

Tips

• Use lsusb -t first when troubleshooting hub/port issues — it shows exactly which hub and port a device is attached to, plus its negotiated speed.
• Cross-check lsusb's vendor:product ID against dmesg output when a device isn't behaving, since kernel logs often reference the same ID.
• Keep the usb.ids database current (often bundled with the usbutils package update) so devices resolve to friendly names instead of raw hex IDs.

Best practices

• When writing udev rules for a specific USB device, get its exact vendor:product ID from lsusb first rather than guessing or hardcoding a common value.
• In hardware troubleshooting workflows, check lsusb before diving into dmesg — confirm enumeration succeeded before investigating driver or permission issues.
• Document vendor:product IDs (not just device names) in inventory or provisioning scripts, since names can vary slightly between systems while IDs stay constant.

Real-world use cases

• Diagnosing why a USB flash drive, webcam, or peripheral isn't being recognized by the system.
• Finding a device's vendor:product ID to write a matching udev rule for consistent permissions or device naming.
• Auditing which USB peripherals are connected to a server or workstation, especially in security-conscious environments.
• Confirming a USB device negotiated the expected speed (e.g. USB 3.0 at 5000M) rather than falling back to a slower mode.

Common interview questions

• What's the difference between lsusb and lspci? lsusb lists devices on the USB bus (keyboards, mice, flash drives, hubs); lspci lists devices on the PCI/PCIe bus (GPUs, network cards, storage controllers) — they enumerate different hardware buses.
• How would you find a USB device's vendor and product ID? Run lsusb; the ID xxxx:yyyy field in each line gives the vendor:product ID pair.
• Why might lsusb -v show incomplete information for a normal user? Reading full USB device descriptors typically requires root privileges; running it with sudo gets the complete verbose output.