Sometimes there is a desire to work with a device connected via USB without keeping it on the table next to the laptop. I have such a device is a Chinese engraver with a 500 mW laser, a rather unpleasant thing in close contact. In addition to the immediate danger to the eyes, toxic combustion products are released during the operation of the laser, so the device should be located in a well-ventilated area, and preferably isolated from people. But how to manage such a device? I accidentally found the answer to this question while browsing the OpenWRT repository in the hope of finding a worthy use for the old D-Link DIR-320 A2 router. To connect, I decided to use the one described on HabrΓ© earlier USB over IP tunnel, however, all instructions for installing it have lost their relevance, so I am writing my own.
OpenWRT is an operating system that needs no introduction, so I will not describe its installation. For my router, I took the latest stable release of OpenWrt 19.07.3, and connected it to the main Wi-Fi access point as a client, selecting the mode lanso as not to torment the firewall.
Server part
We act according to
root@OpenWrt:~# opkg update
root@OpenWrt:~# opkg install kmod-usb-ohci usbip-server usbip-client
Next, we connect our device to the USB port of the router (in my case, the device: a USB hub, a flash drive on which the file system of the router is mounted (due to lack of space on the internal drive), and, directly, the engraver).
Trying to display a list of connected devices:
root@OpenWrt:~# usbip list -l
Is empty.
By googling, the culprit was found, it turned out to be a library libudev-fbsd.
We pull out the latest working version from the repository with our hands libudev_3.2-1 from the OpenWRT 17.01.7 release for your architecture, in my case it is libudev_3.2-1_mipsel_mips32.ipk. Using wget / scp, download it into the router's memory and reinstall
root@OpenWrt:~# opkg remove --force-depends libudev-fbsd
root@OpenWrt:~# opkg install libudev_3.2-1_mipsel_mips32.ipk
We check:
root@OpenWrt:~# usbip list -l
- busid 1-1.1 (090c:1000)
Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) : Flash Drive (090c:1000)
- busid 1-1.4 (1a86:7523)
QinHeng Electronics : HL-340 USB-Serial adapter (1a86:7523)
Chinese man plugged into USB hub gets bsuid 1-1.4. Remembered.
Now we start the daemon:
root@OpenWrt:~# usbipd -D
and bindim chinese
root@OpenWrt:~# usbip bind -b 1-1.4
usbip: info: bind device on busid 1-1.4: complete
Let's check that everything works:
root@OpenWrt:/home# netstat -alpt
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:3240 0.0.0.0:* LISTEN 1884/usbipd
To further bind the device automatically, edit /etc/rc.localby adding before exit 0 following:
usbipd -D &
sleep 1
usbip bind -b 1-1.4
Client part
Let's try to connect the device to Windows 10 using the above instructions from openwrt.org. Let me tell you straight away: the idea is doomed to failure. First, only Windows 7 x64 is considered. Secondly, a link is given to a thread on sourceforge.net, in which it is proposed to download a driver patched in 2014 from a dropbox. When we try to run it under Windows 10 and connect to our device, we get an error:
c:Utilsusbip>usbip -a 192.168.31.203 1-1.4
usbip for windows ($Id$)
*** ERROR: cannot find device
This is due to the fact that the client does not work with a server built for a kernel older than version 3.14.
The usbip server under OpenWRT 19.07.3 is built on the 4.14.180 kernel.
Continuing the search, I stumble upon the current development of a Windows client on
So, first they ask you to install a certificate, moreover, twice. Ok, we put it in the Trusted Root Certification Authority and Trusted Publishers.
Next, you need to put the operating system into test mode. This is done by the team
bcdedit.exe /set TESTSIGNING ON
The first time I did not succeed, prevented secure boot. To disable it, you need to reboot into UEFI, and set secure boot - disable. Some laptop models may require a supervisor password to be set.
After that, boot into Windows and do bcdedit.exe / set TESTSIGNING ON
Windows says everything is ok. We reboot again, and we see in the lower right corner the inscription Test Mode, version and build number of the OS.
Why all these manipulations? To install an unsigned driver USB/IP VHCI. It is proposed to do this by downloading the files usbip.exe, usbip_vhci.sys, usbip_vhci.inf, usbip_vhci.cer, usbip_vhci.cat, and running with administrator rights
usbip.exe install
or the second way, installing Legacy Hardware in manual mode. I chose the second option, received a warning about installing an unsigned driver and agreed with it.
Next, we check that we have the ability to connect to a remote USB device by executing the command:
usbip.exe list -r <ip Π²Π°ΡΠ΅Π³ΠΎ ΡΠΎΡΡΠ΅ΡΠ°>
get a list of devices:
c:Utilsusbip>usbip.exe list -r 192.168.31.203
usbip: error: failed to open usb id database
Exportable USB devices
======================
- 192.168.31.203
1-1.4: unknown vendor : unknown product (1a86:7523)
: /sys/devices/ssb0:1/ehci-platform.0/usb1/1-1/1-1.4
: unknown class / unknown subclass / unknown protocol (ff/00/00)
for a mistake usbip: error: failed to open usb id database we do not pay attention, it does not affect the work.
Now bind the device:
c:Utilsusbip>usbip.exe attach -r 192.168.31.203 -b 1-1.4
Everything, Windows has detected a new device, now you can work with it as if it were physically connected to a laptop.
I had to suffer a little with the Chinese engraver, because when I tried to install its CH341SER driver through the installer that came with the engraver (yes, the Arduino engraver), USB / IP VHCI dropped Windows into a BSOD. However, installing the CH341SER driver to connecting the device via usbip.exe solved the problem.
Bottom line: the engraver makes noise and smokes in the kitchen with the window open and the door closed, I watch the process of burning from another room through my native software, which does not feel a dirty trick.
Used sources:
Source: habr.com