USB przez IP w warunkach domowych

Czasami pojawia się chęć pracy z urządzeniem podłączonym przez USB, nie trzymając go na biurku obok laptopa. Moim urządzeniem jest chiński grawer z laserem o mocy 500 mW, całkiem nieprzyjemny przy bliskim kontakcie. Oprócz bezpośredniego niebezpieczeństwa dla oczu, podczas pracy lasera wydzielają się toksyczne produkty spalania, dlatego urządzenie powinno znajdować się w dobrze wentylowanym pomieszczeniu i najlepiej izolowane od ludzi. Jak więc sterować takim urządzeniem? Odpowiedź na to pytanie znalazłem przypadkiem, przeglądając repozytorium OpenWRT w nadziei na znalezienie godnego zastosowania dla starego routera D-Link DIR-320 A2. Do połączenia postanowiłem wykorzystać opisaną wcześniej tunel USB over IP, ale wszystkie instrukcje dotyczące jego instalacji straciły aktualność, więc piszę swoją.

OpenWRT to system operacyjny, który nie potrzebuje przedstawienia, więc nie będę opisywał jego instalacji. Dla mojego routera pobrałem najnowszą stabilną wersję OpenWrt 19.07.3 i podłączyłem go do głównego punktu dostępowego przez Wi-Fi jako klient, wybierając tryb lan, aby nie męczyć zapory.

Część serwerowa

Działamy zgodnie z oficjalnej instrukcji. Po połączeniu przez ssh instalujemy niezbędne pakiety.

root@OpenWrt:~# opkg update
root@OpenWrt:~# opkg install kmod-usb-ohci usbip-server usbip-client

Następnie podłączamy nasze urządzenie do portu USB routera (w moim przypadku urządzenia: hub USB, pendrive, na którym zamontowany jest system plików routera, z powodu braku miejsca na wewnętrznym dysku, oraz sam grawer).

Próbujemy wyświetlić listę podłączonych urządzeń:

root@OpenWrt:~# usbip list -l

Pusto.

Poprzez googlowanie znalazłem winowajcę, którym była biblioteka libudev-fbsd.
Wyciągamy ręcznie z repozytorium najnowszą działającą wersję libudev_3.2-1 z wydania OpenWRT 17.01.7 dla swojej architektury, w moim przypadku jest to libudev_3.2-1_mipsel_mips32.ipk. Za pomocą wget/scp ładujemy ją do pamięci routera i reinstalujemy

root@OpenWrt:~# opkg remove --force-depends libudev-fbsd
root@OpenWrt:~# opkg install libudev_3.2-1_mipsel_mips32.ipk

Sprawdzamy:

root@OpenWrt:~# usbip list -l
 - busid 1-1.1 (090c:1000)
   Silicon Motion, Inc. - Taiwan (dawniej Feiya Technology Corp.) : Flash Drive (090c:1000)

 - busid 1-1.4 (1a86:7523)
   QinHeng Electronics : HL-340 adapter USB-Serial (1a86:7523)

Chińczyk podłączony do huba USB otrzymał bsuid 1-1.4. Zapamiętaliśmy.

Teraz uruchamiamy demon:

root@OpenWrt:~# usbipd -D

i bindujemy Chińczyka

root@OpenWrt:~# usbip bind -b 1-1.4
usbip: info: bind device on busid 1-1.4: complete

Sprawdzamy, czy wszystko działa:

root@OpenWrt:/home# netstat -alpt
Aktywne połączenia internetowe (serwery i zestawione)
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

Aby zautomatyzować bindowanie urządzenia, dokonamy edycji /etc/rc.local, dodając przed exit 0 następujące:

usbipd -D &
sleep 1
usbip bind -b 1-1.4

Część kliencka

Spróbujemy podłączyć urządzenie do Windows 10, korzystając z powyższej instrukcji z openwrt.org. Od razu mówię: przedsięwzięcie jest skazane na niepowodzenie. Po pierwsze, rozważana jest tylko Windows 7 x64. Po drugie, podano link do wątku na sourceforge.net, w którym proponuje się pobranie z dropboxa zaaktualizowanego w 2014 roku sterownika. Przy próbie uruchomienia go w Windows 10 i połączenia z naszym urządzeniem otrzymujemy błąd:

c:Utilsusbip>usbip -a 192.168.31.203 1-1.4
usbip for windows ($Id$)

*** ERROR: cannot find device

Jest to związane z tym, że klient nie działa z serwerem skompilowanym pod jądro starsze niż wersja 3.14.
Serwer usbip pod OpenWRT 19.07.3 został skompilowany na jądrze 4.14.180.

Kontynuując poszukiwania, natykam się na aktualny rozwój klienta Windows na github. Ok, zapewniona jest obsługa Windows 10 x64, ale klient jest wyłącznie testowy, dlatego występują pewne ograniczenia.

Najpierw proszą o zainstalowanie certyfikatu, i to dwukrotnie. Ok, umieszczamy go w Trusted Root Certification Authority i Trusted Publishers.

Następnie trzeba przestawić system operacyjny w tryb testowy. Robi się to poleceniem

bcdedit.exe /set TESTSIGNING ON

Za pierwszym razem się nie udało, przeszkodził secure boot. Aby go wyłączyć, trzeba uruchomić ponownie UEFI i ustawić secure boot — disable. Na niektórych modelach laptopów może być wymagane ustawienie hasła administratora.

Po tym uruchamiamy Windows i robimy bcdedit.exe /set TESTSIGNING ON
Windows mówi, że wszystko jest w porządku. Ponownie uruchamiamy komputer i widzimy w prawym dolnym rogu napis Tryb testowy, wersję i numer buildu systemu operacyjnego.

Po co te wszystkie manipulacje? Aby zainstalować niepodpisany sterownik USB/IP VHCI. Można to zrobić, pobierając pliki usbip.exe, usbip_vhci.sys, usbip_vhci.inf, usbip_vhci.cer, usbip_vhci.cat, i wykonując polecenie z uprawnieniami administratora

usbip.exe install

lub drugi sposób, ręczna instalacja klasycznego sprzętu. Wybrałem drugi wariant, otrzymałem ostrzeżenie o instalacji niepodpisanego sterownika i zgodziłem się na to.

Następnie sprawdzamy, czy mamy możliwość podłączenia się do zdalnego urządzenia USB, wykonując polecenie:

usbip.exe list -r

otrzymujemy listę urządzeń:

c:Utilsusbip>usbip.exe list -r 192.168.31.203
usbip: błąd: nie udało się otworzyć bazy danych identyfikatorów USB
Eksportowalne urządzenia USB
======================
 - 192.168.31.203
      1-1.4: nieznany producent : nieznany produkt (1a86:7523)
           : /sys/devices/ssb0:1/ehci-platform.0/usb1/1-1/1-1.4
           : nieznana klasa / nieznana podklasa / nieznany protokół (ff/00/00)

na błąd usbip: błąd: nie udało się otworzyć bazy danych identyfikatorów USB nie zwracamy uwagi, nie wpływa na działanie.

Teraz wiążemy urządzenie:

c:Utilsusbip>usbip.exe attach -r 192.168.31.203 -b 1-1.4

Gotowe, Windows rozpoznał nowe urządzenie, teraz można z nim pracować jakby było fizycznie podłączone do laptopa.

Z chińskim grawerem miałem trochę kłopotów, ponieważ przy próbie zainstalowania jego sterownika CH341SER za pomocą dołączonego instalatora (tak, grawer jest na Arduino), USB/IP VHCI powodował BSOD w Windows. Jednak instalacja sterownika CH341SER do podłączenia urządzenia przez usbip.exe rozwiązała problem.

Wynik: grawer hałasuje i dymi w kuchni przy otwartym oknie i zamkniętych drzwiach, obserwuję proces wypalania z innego pokoju przez rodzimą aplikację, która nie podejrzewa niczego złego.

Źródła użyte:

https://openwrt.org/docs/guide-user/services/usb.iptunnel
https://github.com/cezanne/usbip-win

Źródło: habr.com

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster