Oswajanie USB/IP

Regularnie pojawia się zadanie podłączenia urządzenia USB do zdalnego komputera za pośrednictwem sieci lokalnej. Pod wycięciem przedstawiona jest historia moich poszukiwań w tym kierunku oraz ścieżka do gotowego rozwiązania opartego na projekcie open source USB/IP z opisem przeszkód starannie ustawianych przez różne osoby na tej ścieżce, a także sposobów ich ominięcia.

Część pierwsza, historyczna

Jeśli maszyna jest wirtualna - wszystko to jest łatwe. Funkcjonalność przekazywania USB z hosta do maszyny wirtualnej pojawiła się w VMWare 4.1. Ale w moim przypadku klucz bezpieczeństwa, rozpoznawalny jako WIBU-KEY, musiał być podłączony w różnym czasie do różnych maszyn, i to nie tylko wirtualnych.
Pierwsza tura poszukiwań w odległym 2009 roku doprowadziła mnie do kawałka żelaza tzw TrendNet TU2-NU4
Plusy:

• czasami to nawet działa

Wady:

• nie zawsze działa. Załóżmy, że klucz ochronny Guardant Stealth II nie uruchamia się przez niego, przeklinając z błędem „nie można uruchomić urządzenia”.
• Oprogramowanie do zarządzania (odczyt - montowanie i odmontowywanie urządzeń USB) jest żałosne do granic możliwości. Przełączniki wiersza poleceń, automatyzacja - nie, nie słyszałem. Wszystko jest tylko ręcznie. Koszmar.
• oprogramowanie sterujące samo wyszukuje kawałek żelaza w sieci poprzez rozgłaszanie, więc działa to tylko w jednym segmencie sieci rozgłoszeniowej. Nie możesz ręcznie określić adresu IP kawałka żelaza. Kawałek żelaza w innej podsieci? Wtedy masz problem.
• programiści ocenili urządzenie, wysyłanie raportów o błędach jest bezcelowe.

Druga tura wydarzyła się w nie tak odległych czasach i doprowadziła mnie do tematu artykułu - Projekt USB/IP. Przyciąga otwartością, zwłaszcza że faceci z ReactOS podpisali sterownik dla systemu Windows, więc teraz wszystko działa nawet na x64 bez żadnych kul, takich jak tryb testowy. Za co bardzo dziękuję zespołowi ReactOS! Wszystko brzmi pięknie, spróbujmy to poczuć, czy naprawdę tak jest? Niestety sam projekt też jest porzucony, a na wsparcie nie można liczyć - ale gdzie nasz nie zniknął, tam jest źródło, wymyślimy!

Część druga, serwer-linux

Serwer USB/IP udostępniający urządzenia USB przez sieć można skonfigurować tylko w systemie operacyjnym opartym na systemie Linux. Cóż, Linux to Linux, instalujemy Debiana 8 na maszynie wirtualnej w minimalnej konfiguracji, standardowym ruchem ręki:

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

Zadomowiony. Ponadto Internet sugeruje, że będziesz musiał pobrać moduł usbip, ale - witaj, pierwszy rake. Nie ma takiego modułu. A wszystko dlatego, że większość instrukcji w sieci odnosi się do starszej gałęzi 0.1.x, aw najnowszej 0.2.0 moduły usbip mają inne nazwy.

Dlatego:

sudo modprobe usbip-core
sudo modprobe usbip-host
sudo lsmod | grep usbip

Cóż, dodajmy następujące wiersze do /etc/modules, aby ładowały się automatycznie podczas uruchamiania systemu:

usbip-core
usbip-host
vhci-hcd

Uruchommy serwer usbip:

sudo usbipd -D

Co więcej, uniwersalny umysł mówi nam, że usbip zawiera skrypty, które pozwalają nam zarządzać serwerem - pokazywać, które urządzenie będzie udostępniać w sieci, sprawdzać status i tak dalej. Tutaj czeka na nas kolejne narzędzie ogrodnicze - te skrypty w gałęzi 0.2.x ponownie otrzymały zmienione nazwy. Możesz uzyskać listę poleceń za pomocą

sudo usbip

Po przeczytaniu opisu poleceń staje się jasne, że aby udostępnić wymagane urządzenie USB, usbip chce znać jego identyfikator magistrali. Drodzy widzowie, prowizja numer trzy jest na arenie: Identyfikator Autobusu, który nam poda lsusb (wydawałoby się to najbardziej oczywistym sposobem) - to jej nie pasuje! Faktem jest, że usbip ignoruje sprzęt, taki jak koncentratory USB. Dlatego użyjemy wbudowanego polecenia:

user@usb-server:~$ sudo usbip list -l
 - busid 1-1 (064f:0bd7)
   WIBU-Systems AG : BOX/U (064f:0bd7)

Uwaga: w dalszej części zestawień opiszę wszystko na przykładzie mojego konkretnego klucza USB. Twoja nazwa sprzętu i para VID:PID mogą się różnić i będą się różnić. Mój nazywa się Wibu-Systems AG: BOX/U, VID 064F, PID 0BD7.

Teraz możemy udostępnić nasze urządzenie:

user@usb-server:~$ sudo usbip bind --busid=1-1
usbip: info: bind device on busid 1-1: complete

Hurra, towarzysze!

user@usb-server:~$ sudo usbip list -r localhost
Exportable USB devices
======================
 - localhost
        1-1: WIBU-Systems AG : BOX/U (064f:0bd7)
           : /sys/devices/pci0000:00/0000:00:11.0/0000:02:00.0/usb1/1-1
           : Vendor Specific Class / unknown subclass / unknown protocol (ff/00/ff)

Trzy okrzyki, towarzysze! Serwer udostępnił kawałek żelaza w sieci i możemy go podłączyć! Pozostaje tylko dodać autostart demona usbip do /etc/rc.local

usbipd -D

Część trzecia, po stronie klienta i myląca

Próbowałem od razu połączyć udostępnione urządzenie przez sieć z maszyną Debiana na tym samym serwerze i wszystko połączyło się dobrze:

sudo usbip attach --remote=localhost --busid=1-1

Przejdźmy do Windowsa. W moim przypadku był to Windows Server 2008R2 Standard Edition. Oficjalny przewodnik prosi o najpierw zainstalowanie sterownika. Procedura jest doskonale opisana w pliku readme dołączonym do klienta Windows, robimy wszystko tak, jak jest napisane, wszystko działa. Na XP też działa bez problemów.

Po rozpakowaniu klienta próbujemy zamontować nasz klucz:

C:Program FilesUSB-IP>usbip -a %server-ip% 1-1
usbip err: usbip_network.c: 121 (usbip_recv_op_common) recv op_common, -1
usbip err: usbip_windows.c: 756 (query_interface0) recv op_common
usbip err: usbip_windows.c: 829 (attach_device) cannot find device

och och. Coś poszło nie tak. Korzystamy z umiejętności Google. Pojawiają się fragmentaryczne wzmianki, że coś jest nie tak ze stałymi, w części serwerowej programiści zmienili wersję protokołu przy przejściu na wersję 0.2.0, ale zapomnieli to zrobić w kliencie Win. Proponowanym rozwiązaniem jest zmiana stałej w kodzie źródłowym i przebudowanie klienta.

Ale naprawdę nie chcę pobierać programu Visual Studio ze względu na tę procedurę. Ale mam starego, dobrego Hiewa. W kodzie źródłowym stała jest zadeklarowana jako podwójne słowo. Poszukajmy w pliku 0x00000106, zastępując go 0x00000111. Pamiętaj, kolejność bajtów jest odwrócona. Rezultatem są dwa mecze, patch:

[usbip.exe]
00000CBC: 06 11
00000E0A: 06 11

Eeee... tak!

C:Program FilesUSB-IP>usbip -a %server-ip% 1-1
new usb device attached to usbvbus port 1

To mogło zakończyć prezentację, ale muzyka nie grała długo. Po ponownym uruchomieniu serwera stwierdziłem, że urządzenie na kliencie nie jest zamontowane!

C:Program FilesUSB-IP>usbip -a %server-ip% 1-1
usbip err: usbip_windows.c: 829 (attach_device) cannot find device

I to wszystko. Nawet wszechwiedzący Google nie mógł mi na to odpowiedzieć. A jednocześnie całkiem poprawnie wyświetla się polecenie wyświetlenia urządzeń dostępnych na serwerze - oto klucz, możesz go zamontować. Próbuję zamontować spod Linuksa - działa! A jeśli teraz spróbuj z poziomu systemu Windows? O cholera - działa!

Ostatnia prowizja: coś nie jest dodane w kodzie serwera. Podczas udostępniania urządzenia nie odczytuje z niego liczby deskryptorów USB. A podczas montowania urządzenia spod Linuksa to pole jest wypełnione. Niestety, jestem zaznajomiony z programowaniem pod Linuksem na poziomie „make && make install”. Dlatego problem został rozwiązany przez dość brudny hack - dodanie do /etc/rc.local

usbip attach --remote=localhost --busid=1-1
usbip port
usbip detach --port=00

Część finałowa

Po kilku manipulacjach działa. Pożądany rezultat został osiągnięty, teraz klucz można zamontować na dowolnym komputerze (i oczywiście odmontować), w tym poza segmentem sieci rozgłoszeniowej. Jeśli chcesz, możesz to zrobić za pomocą skryptu powłoki. Co jest miłe - przyjemność jest całkowicie bezpłatna.
Mam nadzieję, że moje doświadczenie pomoże habrazhiteli ominąć grabie, które mam odciśnięte na czole. Dziękuję za uwagę!

Źródło: www.habr.com