USB Device Diagnostics in Linux
To detect your USB device, in a terminal, you can try:
lsusb lsusb -v
The second, verbose, offering more detail.
Device are mainly identified using a pair of hexadecimal numbers, like 04b3:3108
The 4 first hexadecimal digits are the Vendor ID (04b3 = IBM).
The 4 last hexadecimal digits are the Device ID (3108 = ThinkPad 800dpi Optical Travel Mouse).
When your device is listed as "unknown" you can update your local usb-id definition by running update-usbids as root.
Try this:
lsusb -v | grep -E '\<(Bus|iProduct|bDeviceClass|bDeviceProtocol)' 2>/dev/null
Another way is to dump the information from the running kernel
sudo cat /sys/kernel/debug/usb/devices
Parse it a little
sudo cat /sys/kernel/debug/usb/devices | grep -E "^([TSPD]:.*|)$"
Contents
USB Input Devices
Input devices include keyboards, mice, remotes, etc.
They do not include flash drives.
xev - Tool that can provide keycodes from input devices. Useful after you have determined your usb input device works and if it is a hid device like a keyboard or mouse. see Multimedia Keys for details on getting the codes from those extra keys in a keyboard.
summary
Another tool that provides extensive details for USB diagnostics:
sudo lsinput
You may have to install it first, it is part of input-utils
sudo apt install input-utils
A tool to show the device being recognized when inserted is
udevadm monitor --udev
The udevadm command cannot be run by itself. You must include a parameter to tell it what to do.
input-utils package
input-utils: utilities for the input layer of the Linux kernel: This is a collection of utilities which are useful when working with the input layer of the Linux kernel (version 2.6 and later). Included are utilities to list the input devices known to the kernel, show the input events that are received by a device, and query or modify keyboard maps. Specifically the tools deal with /dev/input/event* input devices.
- lsinput - dumps out all the input devices and the associated details
- input-kbd - dump out the keyboard mapping of a particular event device, must specify the device number such as 'sudo input-kbd 3'
- input-events - observe input events for watching a specific input device, must specify the device number such as 'sudo input-events 3'
udevadm
udevadm can be used to monitor USB connections
udevadm -h Usage: udevadm [--help] [--version] [--debug] COMMAND [COMMAND OPTIONS] info query sysfs or the udev database trigger request events from the kernel settle wait for the event queue to finish control control the udev daemon monitor listen to kernel and udev events hwdb maintain the hardware database index test test an event run test-builtin test a built-in command
To monitor USB connections here are some command usage examples:
udevadm monitor --subsystem-match=usb --property udevadm monitor --subsystem-match=usb --property --udev
discover package
use the command discover
discover
a working example
I have connected a tiny USB receiver for an unknown pointing device. The manufacturer is unknown. I'm not sure if it is the correct dongle and if the device works. Here is where I start:
udevadm monitor --udev
Now that it is running, I will insert the USB receiver.
A lot of information showed up. Too many lines to share here. Whats important is this one:
UDEV [42556.827151] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7/2-1.7:1.0/0003:26E3:106C.0015 (hid)
I can find the device identification which is: 0003:26E3:106C.0015 and that it is a human interface device (hid) which includes the category of mouse and keyboard
Lets look at 0003:26E3:106C.0015, right now we care about the second and third part of the HEX values each part separated by a :
- 26E3 = the vendor or manufacturer, as a hex value 0x26e3
- 106C = the product name, as a hex value 0x106c
Now we have a way to match up the device, and we know the device was recognized by the system.
I use control-c to get out of udevadm monitor and now run 'lsusb' and I get:
Bus 002 Device 008: ID 26e3:106c Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub [...]
Now I can see that the device 008 is my device because I match the 26e3:106c up. However, lsusb isn't telling me a name. Must not be in its database.
Lets try the command 'sudo lsinput' which spits out a lot of devices. Look through the output and find the group with the matching hex value. Like this:
/dev/input/event7 bustype : BUS_USB vendor : 0x26e3 product : 0x106c version : 257 name : "EXCEL EXCELDIGI Wireless Device" phys : "usb-0000:00:1d.0-1.7/input1" uniq : "" bits ev : EV_SYN EV_KEY EV_REL EV_MSC
Ok, now I know
- 26E3 (0x26e3) = EXCEL EXCELDIGI
- 106C (0x106c) = Wireless Device
I can also tell it is an input device. Next lets see if it provides input to the computer, or more accurately, if the computer is seeing input from the device when I turn the device on and press buttons or move it.
We're going to use the command 'sudo input-events' yet we need to know the device number so we can add it to the end of the command. Above we see from the output of lsinput "event7" so the device number is 7 and we will issue the command like this: 'sudo input-events 7'
Nothing happens until the device is manipulated, such as pressing a button or moving it. Now information begins scrolling up the screen indicating the kernel is getting input from the device. here is a sample:
19:48:45.979478: EV_SYN code=0 value=0 19:48:45.987504: EV_REL REL_X 13 19:48:45.987504: EV_REL REL_Y -11
Those are input coordinates from pointer events, so now we can tell we have a pointing device.
This concludes the example using the mystery device.
Has my USB Flash Drive bit the dust?
Discussion on testing to see if a USB stick has gone bad - there is no S.M.A.R.T. data to go on when trying to determine if your USB memory stick bit the dust. We will discuss some ways to test the USB flash memory drive here.
First DETERMINE where you USB Flash is mounted so you don't wipe out your primary drive!!!
I simply use the command "fidsk -l|grep sd.." before I insert the flash and again after. It wont always be the same depending on the system and what other media is connected but as an example my flash is on /dev/sdc
badblocks
This is a data destructive test. Don't do this if you have any plans to attempt data recovery on the drive. This test will help you determine if the USB flash drive can still be used or if it needs to go in the rubbish bin.
- determine where the USB flash is mounted (for this example sdc)
- run the command:
sudo badblocks -w -s -o usbstick.log /dev/sdc
Notice there is no partition number, just the device sdc (not sdc1 or sdc2 etc...)
The badblocks command here will destroy all data on the flash drive. Failures may be due to the flash drive memory controller or capacity has been maxed on space to remap failed blocks which is another way of saying "too many failed blocks." Either of these issues indicates the drive is toast.
The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes
A Parted / GParted error message that is displayed when a failing USB flash drive has been inserted.
GParted is showing a 16MB flash drive is something odd like 58.27GB. Errors pop up when GParted is opened complaining about the driver descriptor.
This could indicate either that (A) your flash drive has a bad memory controller or other physical problem and is toast or (B) it is physically fine however someone used a low-level device tool and mistakenly wrote the incorrect block size onto the drive. You can check if the drive is bad after you attempt to correct the block size. (my examples use sdc but your assignment might be different!)
sudo dd if=/dev/zero of=/dev/sdc bs=2048 count=32 && sync
This will clear the Master Boot Record.
Result on a 16GB drive:
# fdisk -l /dev/sdc Disk /dev/sdc: 14.6 GiB, 15640600576 bytes, 30548048 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
