🧣 🌸 🙏🏽 Forwarding USB ports from Windows 10 for remote work 👍🏻 👨🏿‍🚒 🧙🏽

When a person has been digging a bunker for many years and storing food there, he must experience deep moral satisfaction if the bunker is needed. He will be pleased to say: "And I say-and-and-il!" The same applies to those who stockpiled food in the pantry, when everyone was purchased in stores only for today. But with our Redd remote work complex, I don’t feel like gloating. It was designed for remoteness in peacetime. And it was used long before the first news from China.

For a long time I did not write anything about him. Other projects are distracting, and interest, judging by the rating of the last of the published articles, has already fallen. It takes a lot of effort to prepare an article, and it makes sense to do it only if it is needed by a sufficient number of readers.

But since everyone is on the lips now, there was a desire to share one thing that could help someone. This is not our development, I conducted research as part of the work on the remote work with All-Hardware debug boards. Here I’ll describe their results now. The USB / IP project is known to many. But it has long been curtailed by the authors. The latest drivers were under WIN7. Today I will describe where to download the option for WIN10, and show how I tested it. In addition, the developers of the modern analogue assure that they made not only a Windows client, but also a Windows server (although in this mode I did not conduct testing: the task did not require that). But for someone this may also be useful.

Previous cycle articles

Introduction

First, a short story about what USB / IP is. This is a set of programs that allow you to forward a USB device through the network. The device itself is connected to the server. The client is located on another machine. At the same time, there is an application on the client machine that is completely not designed to work with the network. It wants a real USB device. And it receives information that this device is connected. A standard driver is installed on this device. In general, the client believes that it works with a local USB device.

Someone is throwing security keys. We checked the possibility of remote access to the JTAG adapter.

The USB / IP project was actively developing until 2013. Then the Windows branch stopped. In general, even a binary signed was releaseddriver. But it was under Windows 7. The Linux branch continued its development, and this service was built into the operating system itself. At the very least, it’s definitely built into the Debian build. Moreover, for Linux there is both a client and a server, and for Windows, only the client was originally made. Server under Windows was not made.

There is a very good article on Habré , which can be used both as a reference for working with this service, and as a tip about working with it.

Option for the current version of Windows

But no matter how good Windows 7 is, it’s already dead. As part of the work on All-Hardware, we considered various options for solving one of the problems, and we just had to check a number of alternatives on the basis of “fit - not fit”. It was impossible to spend many man-hours checking. And alteration of the driver under Windows 10 could drag in itself. Therefore, a search was made on the network, which brought usbip-win to the project . At the time of its discovery, the fresh version was dated February 23, 2020, that is, the project is live. It can be built under both WIN7 and WIN10. In addition, unlike the original project, not only a Windows client, but also a Windows server can be built.

I checked, the project is perfectly assembled and installed, so further work was carried out with him. In readme file There is a link to ready-made binary code for those who do not want to build on their own.

The sad part of checking: the server side

First, I will tell you how the verification was carried out as part of our project. It didn’t end very well there. We checked the ST-LINK adapter installed in the case of the Redd complex, since I already noted that the complex uses the Linux OS of the Debian assembly, and this assembly contains the built-in USB / IP service.

According to the article, install the service:

sudo apt-get update 
sudo apt-get upgrade 
sudo apt-get install usbip

The rest of the article details how to automate the process of loading a service. As I understand Linux, I have already written many times. Poorly versed. I have no habit of quoting other people's texts with a smart face, poorly understanding the essence. Therefore, I will once again recall a link to a wonderful article , where everything is told, and I will show myself what I did at each start of the OS (since everything was necessary only for verification):

sudo modprobe usbip-core
sudo modprobe usbip-host
sudo usbipd -D

The purpose of the first two of the above spells is unknown to me, but without them some directories are not created, and without these directories then there will be no export of a USB port. Directories are created only until the system is restarted. So you need to create them every time. The third line - everything is clearer with it, it starts the service.

Now we look at the name of the device:

user@redd:~$ sudo usbip list -l
- busid 1-3 (046d:082d)
   Logitech, Inc. : HD Pro Webcam C920 (046d:082d)

 - busid 1-4 (1366:0101)
   SEGGER : J-Link PLUS (1366:0101)

 - busid 1-5.1 (067b:2303)
   Prolific Technology, Inc. : PL2303 Serial Port (067b:2303)

 - busid 1-5.4.1.1 (0483:5740)
   STMicroelectronics : STM32F407 (0483:5740)

 - busid 1-5.4.1.3 (0483:3748)
   STMicroelectronics : ST-LINK/V2 (0483:3748)
<...>

It turns out that we need a device and busid equal to 1-5.4.1.3.

We give the command:

sudo usbip bind --busid=1-5.4.1.3

Everything, the server is ready to work.

The sad part of the check: the client part

We install the driver on Windows (we do this only once, then it will always be installed). To do this, run on behalf of the administrator the usbip.exe file with the argument install :

usbip.exe install

Now we look at whether the device is available to us:

usbip.exe list --remote=192.168.10.123

We make sure that it is on the list. Well, and connect it:

usbip.exe attach --remote=192.168.10.123 --busid=1-5.4.1.3

A new USB device appears in the device manager, Keil sees it perfectly ...

But this is where the pleasant ends. A small program is poured into a flash drive for about a minute. Attempts to step through the lines go from 5 to 20 seconds per line. This is unacceptable. During a pause, traffic of approximately 50 kilobits per second goes in both directions. Goes long and thoughtfully.

Honestly, the time limit has led me to only guess why everything was so bad. I suspect that there is JTAG traffic running through the network. And he runs in small packets in both directions, hence the problems. So the study was completed with the result: "Not suitable for the project."

The fun part: preparation

Even then, it occurred to me that out of the corner of my eye I saw that in the CMSIS DAP JTAG adapter USB was used to send not pure JTAG traffic, but commands. JTAG-traffic itself is already formed inside the adapter. I have long wanted to check it, but all my hands did not reach. Mass transfer to a remote site forced it to do (a problem arose). What is CMSIS DAP? This is a JTAG adapter recommended by ARM for Cortex-M controllers. The source codes for different controllers are posted on GitHub, you can solder the adapter based on any of them. I will now give a link to a clone of the project adapted for the Blue Pill breadboard: https://github.com/x893/CMSIS-DAP , but search engines can also display the official ARM account.

In order not to spend a whole PC on the server, for verification, I made a sort of Yelloww complex (purely by the color of the plastic from which the case is made):

The server role is played by Raspberry Pi with the installed Raspbian OS (this is the same Debian, which means that there is the required server ) One of the blue pills acts as a CMSIS DAP adapter, the second as a debugged device.

We set and configure the service in the same way. Unless here the list of devices allowed for export is much more modest:

pi@raspberrypi:~ $ sudo usbip list -l
 - busid 1-1.1 (0424:ec00)
   Standard Microsystems Corp. : SMSC9512/9514 Fast Ethernet Adapter (0424:ec00)

 - busid 1-1.4 (c251:f001)
   Keil Software, Inc. : unknown product (c251:f001)

It is clear that here we export and import the device busid = 1-1.4.

And here it is specifically with CMSIS DAP that I periodically have a small problem. In the device manager, I see such a nuisance:

Let me remind you that the article is written on the principle “Better is not bad, but today than ideal, but tomorrow.” Remote work problems are emerging right now. I hope that in the foreseeable future they will no longer be relevant. In the meantime, they are relevant - I show how I bypass this problem manually. First I turn off the device:

Then immediately turn on:

And it starts to work without problems. In Keil we change the debugger to CMSIS DAP:

And here it is:

When working on a local network, everything just flies. But it is clear that no one is interested in the local network. I tried to forward the device port at home, and then remotely log into the machine at work and route the “firmware” from there. The connection at my home provider is very, very slow, especially - from me outside. The controller is flashed about three times slower than when connected directly to USB. Tracing ... Well, about a second per line, exactly no more. In general, bearable. With good providers, I hope it will be better.

Conclusion

The usbip-win project is a modern replacement for the USB / IP project. He lives and develops. At the same time, it provides not only the client function for Windows, but also the server function. Compatibility with the Linux version is saved.

The stability of the remote USB device was unexpectedly amazing. I was sure that timeouts would occur. Perhaps they will arise somewhere, but for JTAG adapters, there was not a single failure. Unfortunately, not all USB devices can be forwarded through the network due to the low speed of the resulting system. But in the case of JTAG adapters, you can consider alternative things. In particular, CMSIS-DAP instead of ST-LINK.

Both reviewed projects (usbip-win and CMSIS-DAP) can be downloaded from GitHub as source codes.

If this helps someone organize remote access to equipment, I will be glad. Using the Raspberry Pi will allow you to drop equipment in arbitrary places.