Maîtrisons l'USB/IP

Il se pose régulièrement la question de la connexion d'un périphérique USB à un PC distant via un réseau local. Cet article retrace mon parcours dans ce domaine et présente une solution prête à l'emploi basée sur un projet open-source. USB/IP avec une description des divers obstacles soigneusement installés par différentes personnes en cours de route, ainsi que des moyens de les contourner.

Partie un, historique

Si la machine est virtuelle, tout cela n'est pas compliqué. La fonctionnalité de redirection USB de l'hôte vers la machine virtuelle existe depuis VMWare 4.1. Mais dans mon cas, la clé de protection, reconnue comme WIBU-KEY, devait être connectée à différentes machines au fil du temps, et pas seulement virtuelles.
Le premier tour de recherche, en 2009, m'a conduit à un appareil appelé TrendNet TU2-NU4
Avantages :

• qui fonctionne parfois

Inconvénients :

• mais pas toujours. Par exemple, la clé de protection Guardant Stealth II ne s'active pas à travers elle, affichant une erreur « l'appareil ne peut pas être lancé ».
• Le logiciel de gestion (entendez par là, le montage et le démontage des périphériques USB) est terriblement limité. Les clés de ligne de commande, l'automatisation — non, ce n'est pas au programme. Tout doit être fait manuellement. Un véritable cauchemar.
• Le logiciel de gestion recherche le matériel sur le réseau par diffusion, donc cela ne fonctionne que dans une même segment de diffusion. On ne peut pas spécifier l'adresse IP de l'appareil manuellement. Un appareil sur un autre sous-réseau ? Alors, vous avez un problème.
• Les développeurs ont abandonné l'appareil, envoyer des rapports de bogues est inutile.

Le deuxième tour a eu lieu à une époque moins lointaine et m'a conduit au sujet de cet article — projet USB/IP. Il attire par sa transparence, d'autant plus que l'équipe de ReactOS a signé des drivers pour Windows, de sorte qu'aujourd'hui, même sur x64, tout fonctionne sans recourir à des astuces comme le mode test. Un grand merci à l'équipe de ReactOS ! Tout semble beau, essayons de voir si cela fonctionne réellement ? Malheureusement, le projet semble aussi abandonné, et il ne faut pas compter sur un support — mais nous ne sommes pas à court de ressources, le code source est là, nous allons nous débrouiller !

Partie deux, serveur et Linux

Un serveur USB/IP, partageant des appareils USB sur le réseau, ne peut être installé que sur un système d'exploitation basé sur Linux. Très bien, Linux soit, installons-le sur une machine virtuelle Debian 8 en configuration minimale, routine standard :

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

Nous sommes installés. Ensuite, Internet nous indique qu'il faudrait charger le module usbip, mais voici le premier obstacle. Il n'y a pas de tel module. C'est parce que la plupart des guides en ligne concernent une version plus ancienne 0.1.x, tandis que dans la version 0.2.0, les modules usbip portent d'autres noms.

Donc :

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

Ajoutons donc dans /etc/modules ces lignes afin de les charger automatiquement au démarrage du système :

usbip-core
usbip-host
vhci-hcd

Lançons le serveur usbip :

sudo usbipd -D

Ensuite, l'intelligence mondiale nous indique qu'avec usbip, il existe des scripts qui nous permettent de gérer le serveur — montrer quel appareil il partagera sur le réseau, vérifier le statut, etc. Ici, un autre obstacle se présente — ces scripts dans la version 0.2.x, encore une fois, ont été renommer. On peut obtenir la liste des commandes grâce à

sudo usbip

Après avoir lu la description des commandes, il devient clair que pour partager le périphérique USB requis, usbip souhaite connaître son Bus ID. Chers spectateurs, voici le troisième obstacle : ce Bus ID, que nous fournira lsusb (apparemment, le chemin le plus évident) — ne convient pas ! En effet, des périphériques tels que les hubs USB sont ignorés par usbip. Donc, utilisons la commande intégrée :

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

Remarque : dans les listings suivants, je vais tout décrire en prenant pour exemple ma clé USB spécifique. Les noms de vos appareils et quelques VID:PID peuvent varier. La mienne s'appelle Wibu-Systems AG: BOX/U, VID 064F, PID 0BD7.

Nous pouvons maintenant partager notre appareil :

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

Hurrah, mes amis !

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)

Trois fois hurrah, mes amis ! Le serveur a partagé l'appareil sur le réseau, et nous pouvons le connecter ! Il ne reste plus qu'à ajouter le démarrage automatique du démon usbip dans /etc/rc.local

usbipd -D

Partie trois, le client, et c'est complexe

J'ai essayé de connecter le périphérique partagé sur un ordinateur fonctionnant sous Debian immédiatement sur le même serveur et tout s'est bien connecté :

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

Passons à Windows. Dans mon cas, il s'agissait de Windows Server 2008R2 Standard Edition. Le guide officiel demande d'abord d'installer le pilote. La procédure est parfaitement décrite dans le readme fourni avec le client Windows, faisons tout comme indiqué, tout fonctionne. Cela fonctionne aussi sur XP sans aucun problème.

Après avoir décompressé le client, essayons de monter notre clé :

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) impossible de trouver le dispositif

Oh là là. Quelque chose s'est mal passé. Utilisons notre talent pour Google. Il y a des mentions sporadiques que quelque chose ne va pas avec les constantes, dans la partie serveur, les développeurs ont changé la version du protocole lors du passage à la version 0.2.0, mais cela a été oublié dans le client sous Windows. La solution proposée consiste à modifier la constante dans le code source et à recompiler le client.

Sauf que je n'ai vraiment pas envie de télécharger Visual Studio pour cela. Heureusement, j'ai le bon vieux Hiew. Dans le code source, la constante est déclarée comme un double mot. Cherchons dans le fichier 0x00000106, remplaçant par 0x00000111. N'oublions pas que l'ordre des octets est inversé. Résultat — deux correspondances, faisons un patch :

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

Et… oui !

C:Program FilesUSB-IP>usbip -a %server-ip% 1-1
nouveau périphérique USB attaché au port usbvbus 1

On pourrait s'arrêter là, mais la musique n'a pas duré longtemps. Après avoir redémarré le serveur, j'ai découvert que le dispositif ne se monte pas sur le client !

C:Program FilesUSB-IP>usbip -a %server-ip% 1-1
usbip err: usbip_windows.c: 829 (attach_device) impossible de trouver le dispositif

Et voilà. Même Google, tout-puissant, n'a pas pu répondre à cela. Pourtant, la commande pour afficher les dispositifs disponibles sur le serveur fonctionne tout à fait correctement — voici la clé, vous pouvez monter. J'essaie de monter depuis Linux — ça marche ! Et si j'essaie maintenant depuis Windows ? Oh horreur — ça fonctionne !

Dernier point : quelque chose dans le code du serveur n'est pas correctement écrit. Lors du partage du dispositif, il ne lit pas le nombre de descripteurs USB. Cependant, lorsque le dispositif est monté depuis Linux, ce champ est rempli. Malheureusement, je ne connais le développement sous Linux qu'à un niveau de « make && make install ». Par conséquent, le problème a été résolu par un hack plutôt sale — en ajoutant dans /etc/rc.local

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

Partie finale

Après quelques péripéties, cela fonctionne. L'objet souhaité est obtenu, le clé peut maintenant être montée sur n'importe quel PC (et démontée, bien sûr), y compris en dehors du segment de diffusion du réseau. Si vous le souhaitez, cela peut être fait à l'aide d'un script de shell. Ce qui est agréable, c'est que c'est entièrement gratuit.
J'espère que mon expérience aidera les membres de Habr à éviter les pièges que j'ai rencontrés. Merci de votre attention !

Source : habr.com