Throw USB devices, video card, sound and disk to remote machine

Throw USB devices, video card, sound and disk to remote machine

If we want to access not a remote or local service, but the devices of the remote machine? Say, throw a USB port on a local machine and use the devices connected to it as local ones.

The feature of Unix-like system – to treat any of its components as a file – has long ago become a commonplace in conversations about its internal device. And countless articles about the same Linux are proof of that. Hardware is no exception. A video card, an audio card, an external device connected via USB is nothing but a file in the Linux sense.

It is therefore surprising that of all the operating systems, only Plan 9 (except for a couple of projects with a similar fate), where this approach has been brought to its logical end, is able to recognize the hardware of the remote computer and manage it as its own without any extra effort.

In Plan 9, RPC-protocol 9P is responsible for hardware injection. It provides access to all files and devices, both local and network. Unfortunately, Linux cannot boast of such a versatile tool. On the other hand it has a few tools (crutches to say the least) to access the hardware of a remote machine.


When it comes to sneaking equipment into another computer, perhaps the first thing that comes to mind is a webcam on a home laptop or a smartphone connected to it, which should be accessed from a remote desktop. For example, from an office on the other side of town (in another city, in another country).

In such a case, the utility USB/IP can help. It has been a long time since anyone has developed this tool, but its functionality has not yet been affected – in the repositories of most popular distributions this package is present.

The first thing to do is to install the USB/IP packet on a machine that needs to be accessed from outside. Then we load the necessary modules:

$ sudo modprobe usbip-core
$ sudo modprobe usbip-host

Let’s check if everything was loaded correctly:

$ sudo lsmod | grep usbip

And we start the server:

$ sudo usbipd -D

Since USB/IP has its own, independent of the built-in addressing system, the device search is performed with the command

$ sudo usbip list -l

It will show a list of all devices currently connected to the USB bus.

Utility setup USB/IP

Now you can proceed directly to broadening the device (let’s say, it will be a webcam with an index of 2-3 from the resulting list):

$ sudo usbip bind --busid=2-3

Another check of the correctness of the performed actions:

$ sudo usbip list -r localhost

I’m done with the source computer. Next, you need to configure the one on which the first one will be used.

So, going to the client machine we install USB/IP on it and run it:

$ sudo modprobe usbip-core
$ sudo modprobe vhci-hcd

We check the availability of paired equipment on the server by the list:

$ sudo usbip --list ADRES_SERVERA

And we attach our camera:

$ sudo usbip --attach ADRES_SERVER 2-3

We check the result:

$ sudo usbip --port

Now the remote USB device should appear in the local list and you can work with it like with any other device. To check if the connection is correct we execute the lsusb command:

$ lsusb

There is a USB/IP client part for Windows. However, because of a bug in the version of the protocol in its executable file from the box, it does not work properly. Additional motions are required with constant spoofing in the sources.



The most concise solution to the mutual loosening in Linux can boast COM ports. No additional drivers are needed for this. One small utility is responsible for everything remserial available in the sources. It is suitable both for access from Linux to equipment connected via RS232 on a remote computer and for bundling two devices with COM ports connected to different machines connected via network.

Expand RS232, specifying the network port (-p), speed, mode stty (-s) and the name of the port (here /dev/ttyS0), you can so:

$ remserial -d -p 23000 -s "9600 raw" /dev/ttyS0 &

Connect to a COM-device located on the remote machine (server) – so:

$ remserial -d -r server address -p 23000 -s "9600 raw" /dev/ttyS0 &

It is allowed to run several instances of the program with different ports and addresses of connected devices.

Compile and run remserial


Video card

Going to scatter the video card, it is appropriate to ask yourself a question: why do you need it? After all, there is no lack of ready-made solutions from proprietaries. Here you will find TeamViewer, which recently pleased the Linux client, and cloud solutions embedded in your browser. However, things are not always so smooth.

Video subsystems of modern notebooks have become hybrid everywhere, when there are two video cards on board: the first is a powerful, but headless – discrete, which is used for labor-intensive tasks and turns on as needed to broadcast streams through the second – a modest integrated, working all the time.

Scaling up the situation to a network size and imagining that a powerful video card is located on a remote computer, and the user has direct access only to an old netbook, for which the launch of a modern browser is sometimes impermissible luxury, you come to a solution adopted by all in the same hybrid graphics. The toolset is also the same – VirtualGL.

In fact, it’s the opposite, and VirtualGL was originally conceived for network solutions, and the hint with hybrids matured later.

The VirtualGL package is present in most popular distributions, so all you have to do is to install it with a regular package manager on both machines and, depending on which directory the package is installed, run the configurator on the server. In Arch Linux and its derivatives this is done by the command

$ sudo vglserver_config -config +s +f -t

If the package is installed in /opt on your system, you need to specify the full path:

$ /opt/VirtualGL/bin/vglserver_config -config +s +f -t

Then restart the display manager, and the server can be left alone.

VirtualGL configuration work

Nothing needs to be configured on the client machine after installing VirtualGL itself. Here we will only need vglconnect and vglclient. On the other hand we need to install and configure SSH. Open the configuration file /etc/ssh/sshd_config and add this line:

X11Forwarding yes

Restart sshd service. On systems based on systemd, this can be done as follows:

$ systemctl start sshd

To get the image of the program running on the server and thus check the functionality of the bundle the command

$ ssh -X [email protected] NAME_Program.

Now you can use vglconnect to connect to the server by encrypting X11 traffic and VGL image:

$ vglconnect -s [email protected]

and try to run some application:

$ vglrun -q 40 -fps 25 NAME_Program

The -q (JPEG compression ratio) and -fps (frame rate) values can be varied by selecting the maximum possible on the channel in use (not rubber). JPEG compression on remote access is the default.

If you want to return the system to its original state, the command

$ sudo vglserver_config -unconfig


Sound card

Until the appearance of sound in movies, it remained silent for almost thirty years. We have a little less time, so after the video we’ll start throwing audio. It’s still easier here if you take advantage of the ubiquitous PulseAudio.

On client and server we open the configuration file ~/.config/pulse/ or /etc/pulse/ and comment on the line load-module module-native-protocol-tcp. On the server we will also add one of the following lines:

auth-ip-acl= # For IP-specific client access
auth-anonymous=true # For access from any IP

Also on the client, open the ~/.config/pulse/client.conf or /etc/pulse/client.conf (depending on whether you want to set these settings for one user or for all) and add:

default-server = server address

Instead of editing client.conf, you can use pax11publish to output to a remote server:

$ pax11publish -e -S server address

Disabling the output on the remote machine:

$ pax11publish -e -r

For the changes to take effect for a particular program that uses PulseAudio, you must restart it.



In the maze of the Internet, you can find the project of audio broadcasting over the network in a slightly neglected form – TRX, based on ALSA, Opus codec and oRTP library. The program is easy to use as a Kalashnikov machine, but inferior to it in reliability – the sources have not been updated since 2014. It is suspected that this only applies to publicly available materials, because the online audio exchange service based on it from the same author Cleanfeed looks quite fresh.



For many, the term “scale-up” is firmly associated with opening access to disk drives, their partitions and the information stored on them. Even unsophisticated users can boast of knowing the word Samba (and are not afraid to hammer the word into a search engine to find a short tutorial on quick setup, while bumping into news about another discovered vulnerability and mass epidemics caused by insidious viruses).

Those who are used to finding nontrivial solutions, will probably be interested in the variant of exporting a disk device by a method of implementation close to industrial standards. Within the Linux capabilities such an export is done with the help of the DRBD software system, which has been included in the kernel itself since 2009. The essence of the system is reflected in its name – a distributed replicated block device. It provides instant synchronization between local and remote block devices.

The preparatory work is to install the drbd-utils package. You can configure it step by step with drbdsetup, but it is easier to edit the contents of the /etc/drbd.conf configuration file on both machines:

global { usage-count no; }
common { resync-rate 100M; }
resource r0 {
  protocol C;
  startup {
    wfc-timeout 15;
    degr-wfc-timeout 60;
  net {
    cram-hmac-alg sha1;
    shared-secret "PAROL";
  on_host name1 {
    device /dev/drbd0;
    disk /dev/sda5;
    meta-disk internal;
  on_host name2 {
    device /dev/drbd0;
    disk /dev/sda7;
    meta-disk internal;

The cram-hmac-alg option defines the encryption algorithm supported on both computers. They are listed in the /proc/crypto file. The shared-secret password can contain up to 64 characters.

Host names are defined by the uname -n command, running on each machine separately. The disk options are assigned the names of the disk drives or their partitions that belong to each machine. This is followed by IP addresses and ports involved. Their size is proportional to the size of the device itself.

Also on both machines we start the storage initialization:

$ sudo drbdadm create-md drbd0

And start the DRBD demon:

$ sudo systemctl enable drbd
$ sudo systemctl start drbd

Next, we move on to the machine that will work with the data (only one of them can access the storage at a time), and make it a wizard:

$ sudo drbdadm primary all

Then we create and mount the storage file system:

$ sudo mkfs.ext4 /dev/drbd0
$ sudo mount /dev/drbd0 /mnt

The result is a kind of RAID array over a network with only one of the existing hosts accessing it at a time. However, it is also possible to access the data from another machine. All you need to do is to unmount the file system on the current wizard, make the second machine the wizard and mount the storage on it. Three elementary commands, one of which can be hung on a keyboard shortcut at once and the other two pre-installed in the script, will suffice.



Linux is not ideal and can at times seriously lose to other systems in terms of functionality, exactly as in the case of the Plan 9 system and remote access to hardware resources of the computer. At the same time, when there is a need to solve a specific task, the chances of finding a suitable set of tools for this are almost 100%.

WARNING! All links in the articles may lead to malicious sites or contain viruses. Follow them at your own risk. Those who purposely visit the article know what they are doing. Do not click on everything thoughtlessly.


0 0 vote
Article Rating
Notify of
Inline Feedbacks
View all comments

Do NOT follow this link or you will be banned from the site!
Would love your thoughts, please comment.x

Spelling error report

The following text will be sent to our editors: