5 ways to disconnect and connect a USB device without taking your hands off the keyboard

On many occasions, when we are using our computer we disconnect a USB device (safely, as it has to be) and, immediately afterwards, we realize that we forgot to copy a file or that we had to make sure that a data was in our unit. For these cases, it is usually very useful to virtually disconnect the USB drives when we work remotely.

Having ejected the device, we no longer see it in our list of devices, but the hard drive or pendrive is still connected through the USB port, and in many distributions today, having ejected the drive safely, we do not see the device either and We can not do mount from our terminal. The quickest solution is to disconnect the cable and reconnect it, in some cases, either due to laziness of having to get up or because we are accessing a computer that we are not in front of and there is no one around, we cannot do it.

Information about USB devices

Before we start, let's see how to get information about USB devices connected to the system. For this, we can use lsusb, which will list the connected devices right now. I put examples of what I get on my computer right now, but maybe it is very different from what you get:

$ lsusb Bus 002 Device 001: ID 1d6b: 0003 Linux Foundation 3.0 root hub Bus 001 Device 006: ID 8087: 0a2a Intel Corp. Bus 001 Device 007: ID 046d: c52b Logitech, Inc. Unifying Receiver Bus 001 Device 005: ID 1a40 : 0101 Terminus Technology Inc. Hub Bus 001 Device 010: ID 125f: c93a A-DATA Technology Co., Ltd. 4GB Pen Drive Bus 001 Device 003: ID 04f2: b424 Chicony Electronics Co., Ltd Bus 001 Device 001: ID 1d6b : 0002 Linux Foundation 2.0 root hub

If we want more information, we can use the -t modifier that will show us an output in the form of a tree with information about the modules:

$ lsusb -t /: Bus 02.Port 1: Dev 1, Class = root_hub, Driver = xhci_hcd / 8p, 5000M /: Bus 01.Port 1: Dev 1, Class = root_hub, Driver = xhci_hcd / 16p, 480M | __ Port 4: Dev 3, If 0, Class = Video, Driver = uvcvideo, 480M | __ Port 4: Dev 3, If 1, Class = Video, Driver = uvcvideo, 480M | __ Port 5: Dev 10, If 0, Class = Mass Storage, Driver = usb-storage, 480M | __ Port 6: Dev 5, If 0, Class = Hub, Driver = hub / 4p, 12M | __ Port 4: Dev 7, If 0, Class = Human Interface Device, Driver = usbhid, 12M | __ Port 4: Dev 7, If 1, Class = Human Interface Device, Driver = usbhid, 12M | __ Port 4: Dev 7, If 2, Class = Human Interface Device, Driver = usbhid, 12M | __ Port 9: Dev 6, If 0, Class = Wireless, Driver = btusb, 12M | __ Port 9: Dev 6, If 1, Class = Wireless, Driver = btusb, 12M

If we want much more information, we can use lsusb -v (the output is very large), we could also, for example, know the maximum power that is delivered to the device, in the following way:

$ lsusb -v 2> / dev / null | egrep "^ Bus | MaxPower" Bus 002 Device 001: ID 1d6b: 0003 Linux Foundation 3.0 root hub MaxPower 0mA Bus 001 Device 006: ID 8087: 0a2a Intel Corp. MaxPower 100mA Bus 001 Device 007: ID 046d: c52b Logitech, Inc. Unifying Receiver MaxPower 98mA Bus 001 Device 005: ID 1a40: 0101 Terminus Technology Inc. Hub MaxPower 100mA Bus 001 Device 010: ID 125f: c93a A-DATA Technology Co., Ltd. 4GB Pen Drive MaxPower 480mA Bus 001 Device 003: ID 04f2: b424 Chicony Electronics Co., Ltd MaxPower 500mA Bus 001 Device 001: ID 1d6b: 0002 Linux Foundation 2.0 root hub MaxPower 0mA

Other very useful commands are usb devices, hwinfo, or, for example, if we have the path of a device (inside / dev /), we can ask the system for all possible information about it and the subsystems it has to go through. For example, if we connect a USB hard drive, for us to be able to see how the device is used, we need a SCSI driver (for being / dev / sdX), we also need a USB storage driver, which works through the USB port, which belongs to a hub, which is plugged into a PCI port, among other intermediate systems. All that we could see with

$ udevadm info --query = path --name = / dev / sdX --attribute-walk

o

$ udevadm info -a -n / dev / sdX

If we want to venture, we can also enter / sys / bus / usb and look at everything there is, we will see a lot of information, but fortunately the above commands classify all this information.

Privileges and devices

To carry out this task we will need to know which device we are going to reconnect. To do this, we can run:

$ dmesg | tail [Thu Nov 24 19:50:04 2016] sd 7: 0: 0: 0: Attached scsi generic sg3 type 0 [798339.431677] sd 7: 0: 0: 0: [sdc] 15806464 512-byte logical blocks: ( 8.09 GB / 7.54 GiB) [798339.431840] sd 7: 0: 0: 0: [sdc] Write Protect is off [798339.431848] sd 7: 0: 0: 0: [sdc] Mode Sense: 00 00 00 00 [798339.431988] sd 7: 0: 0: 0: [sdc] Asking for cache data failed [798339.431996] sd 7: 0: 0: 0: [sdc] Assuming drive cache: write through [798339.434157] sdc: sdc1 sdc2 [798339.446812] sd 7 : 0: 0: 0: [sdc] Attached SCSI removable disk [798360.808588] ISO 9660 Extensions: Microsoft Joliet Level 3 [798360.809353] ISO 9660 Extensions: RRIP_1991A

In this output, we will see that the device we are working with is ndc (sdc1 and sdc2 would be partitions within that disk). For the examples I will use this device, in your case you will have to see which one you have.

In the examples below I will use sudo to execute the commands with the privileges of root. Although it would be enough to have a user with sufficient permission. If we want to see the necessary privileges, just do ls to device:

$ ls -latr / dev / sdc brw-rw ---- 1 root disk 8, 32 Nov 24 19:50 / dev / sdc

There we see that the owner is root and the group Disks. It would be enough to have a user belonging to the group disk.

Method 1. Treat it like a CD / DVD

It is the simplest of all. Surely if you have been using GNU / Linux for years, when you worked with CD-ROM or DVD you used the eject command. Well, eject was used to open the CDROM and eject -t was used to close the tray. Well, if we do this before the USB device:

$ sudo eject -t / dev / sdc

The device should appear as if we have connected it again.

Method 2. Unplugged and Virtual Plugged In

On some systems (as long as the hardware supports it), when you safely remove the USB device, the device stops powering and the device no longer appears. It is the same as when you do:

udisksctl power-off -b / dev / sdc

In this case, / Dev / sdc it's my device, and with this command it simulated a virtual power disconnect.

The problem is that now / dev / sdc does not exist, what's more, if we look at dmesg, we will get something like this:

$ dmesg | tail [281954.693298] usb 1-5: USB disconnect, device number 3

So if we try with the method of ejector it will not work. Note: I have highlighted usb 1-5 and we'll see why shortly.

If you work remotely, this may be a good idea. Imagine that you have USB drives attached to backup. When you are making the copies, it is good for the system to know that there are disks connected but, when we are not using them on the one hand we must save energy and avoid the wear of the discs, so it is better to cut the current, on the other hand, we don't want malicious apps to see that they exist these disks so they don't get infected. (Yes, in GNU / Linux there are viruses).

How do we connect the current now?

We must make a call to the USB port, for this there is a project called hub power (I link to a fork of the original project because here a bug is fixed that can remove the current from more devices and not just the one we want). There are more projects (like uhubctl), but this has no dependencies for when we go to compile, it is also just a hubpower.c file.
First, we compile it,

$ gcc -o hubpower hubpower.c

Now, do you remember the numbers in bold from the dmesg? Well, we are going to use them, we will have to disconnect the device and reconnect it, like this:

$ sudo ./hubpower 1: 1 power 5 off Port 5 status: 0000 Power-Off $ sudo ./hubpower 1: 1 power 5 on Port 5 status: 0100 Power-On

If the device does not detect us, we can try to do:

$ sudo ./hubpower 1: 1 bind Bind-driver request sent to the kernel

In this way, we will see our connected USB device again.

If we don't want a C program ... I have it in perl

A C program is hard to compile and test if what we are going to do is very simple, so we can try this small port in 10 lines made in perl:

#! / bin / perl require "sys / ioctl.ph"; $ device = "05"; open (my $ usbdev,"> "," / dev / bus / usb/ 001/001 "); $ data = pack ("H *", "23010800". $ device. "000000FFFFFF8813"); ioctl ($ usbdev, 0xC0185500, $ data); $ data = pack ("H *", "23030800". $ device. "000000FFFFFF8813"); ioctl ($ usbdev, 0xC0185500, $ data); close ($ usbdev);

We must respect $ device, the port number (in my case it was 5), it is a value in hexadecimal, therefore 10 will be A, 11 will be B, 15 will be F, 16 will be 10 ... We also have to monitor the device and the bus, which we access from / dev / bus / usb /001/001, the numbers must go with leading zeros since we are calling that file.

As we can see, the key is in ioctl (), it is a function that manipulates parameters of a device from a special file in the file system. Among the hexadecimal values ​​used, we find 0xC0185500, a constant called USBDEVFS_CONTROL with which we will send a control command to the USB device, The other codes belong to the disconnection and connection request (you can find more information in the program made in C).

Method 3. Hiding and showing the device

Another way to disconnect the device could be:

echo '1-5' | sudo tee / sys / bus / usb / drivers / usb / unbind

And we can recover it by doing:

echo '1-5' | sudo tee / sys / bus / usb / drivers / usb / bind

This method does not cause a complete disconnection of the device. It only makes the operating system not talk to it and many devices, when a computer does not want to know anything about them, are put into low power mode, since we are not going to ask for anything.

Method 4. Device authorization

The downside of this method is that in many systems more devices can be temporarily disabled, which are not only the one we need, but we also attack an entire USB hub. For example:

$ echo 0 | sudo tee / sys / bus / usb / devices / usb1 / authorized $ echo 1 | sudo tee / sys / bus / usb / devices / usb1 / authorized

Which, of course, we can run everything in a row:

$ echo 0 | sudo tee / sys / bus / usb / devices / usb1 / authorized; echo 1 | sudo tee / sys / bus / usb / devices / usb1 / authorized

We have to be careful, if there are more disks connected to the same USB port (and almost always in our computers, several USB ports than those we see are internally connected to a hub, so there are groups of ports with the same USB father, put it in some way.

Method 5. Reboot the USB subsystem

If we want to restart the USB subsystem. That is, refresh all USB devices, such as unplugging and plugging all of them, on the one hand we can download and reload the USB kernel module:

$ sudo modprobe -r ehci_hcd; sudo modprobe ehci_hcd #For USB2 $ sudo modprobe -r xhci_hcd; sudo modprobe xhci_hcd #For USB3

Although some distributions, the latest versions of Ubuntu and derivatives included, have the integrated USB modules and they cannot be downloaded. On the other hand, the system may not let us download them because they are in use because of other modules (printers, storage, interface devices, etc.), and if we start to download modules and break things, we may have to restart the computer. at the end. So, in another way we can do:

$ echo '0000:00:14.5'| sudo tee / sys / bus / pci / drivers / xhci_hcd / unbind $ echo '0000:00:14.5'| sudo tee / sys / bus / pci / drivers / xhci_hcd / bind

To find our device, we can do ls inside / sys / bus / pci / drivers / xhci_hcd, several things will appear, we have to look for one that looks like this aaaa: bb: cc: dd.e. Your USB port may not come as xhci_hcd (USB3), but rather ehci_hcd (USB2)