Il arrive parfois que l'on souhaite travailler avec un appareil connecté par USB sans avoir à le garder sur le bureau, à côté de son ordinateur portable. Cet appareil pour moi est une graveuse laser chinoise de 500 mW, un gadget plutôt désagréable à proximité. En plus du danger immédiat pour les yeux, le fonctionnement du laser génère des produits de combustion toxiques, donc l'appareil doit être utilisé dans une pièce bien ventilée et de préférence isolé des personnes. Mais comment contrôler un tel appareil ? J'ai trouvé la réponse à cette question en explorant le dépôt OpenWRT dans l'espoir de donner une nouvelle vie à mon ancien routeur D-Link DIR-320 A2. Pour la connexion, j'ai décidé d'utiliser ce qui a été décrit précédemment sur Habr. Tunnel USB sur IP, mais toutes les instructions de son installation ont perdu leur pertinence, donc je rédige la mienne.
OpenWRT est un système d'exploitation qui n'a pas besoin d'être présenté, donc je ne décrirai pas son installation. Pour mon routeur, j'ai pris la dernière version stable d'OpenWrt 19.07.3 et l'ai connecté au point d'accès principal par Wi-Fi en tant que client, en sélectionnant le mode lan, afin de ne pas trop solliciter le pare-feu.
Partie serveur
Nous agissons selon . Après la connexion SSH, nous installons les paquets nécessaires.
root@OpenWrt:~# opkg update
root@OpenWrt:~# opkg install kmod-usb-ohci usbip-server usbip-clientEnsuite, nous connectons notre appareil au port USB du routeur (dans mon cas, les appareils sont : un hub USB, une clé USB sur laquelle le système de fichiers du routeur est monté (en raison d'un manque d'espace sur le stockage interne), et, directement, la graveuse).
Essayons de lister les appareils connectés :
root@OpenWrt:~# usbip list -lAucun.
Après quelques recherches sur Google, j'ai trouvé le coupable, qui s'est avéré être la bibliothèque libudev-fbsd.
Nous extrayons manuellement la dernière version fonctionnelle du dépôt libudev_3.2-1 de la version OpenWRT 17.01.7 pour mon architecture, dans mon cas c'est libudev_3.2-1_mipsel_mips32.ipk. Avec wget/scp, nous la chargeons dans la mémoire du routeur et la réinstallons.
root@OpenWrt:~# opkg remove --force-depends libudev-fbsd
root@OpenWrt:~# opkg install libudev_3.2-1_mipsel_mips32.ipk
Vérifions :
root@OpenWrt:~# usbip list -l
- busid 1-1.1 (090c:1000)
Silicon Motion, Inc. - Taiwan (anciennement Feiya Technology Corp.) : Clé USB (090c:1000)
- busid 1-1.4 (1a86:7523)
QinHeng Electronics : Adaptateur série USB HL-340 (1a86:7523)Le Chinois, connecté au hub USB, a reçu un bsuid 1-1.4. À retenir.
Nous lançons maintenant le démon :
root@OpenWrt:~# usbipd -Det nous lions le Chinois.
root@OpenWrt:~# usbip bind -b 1-1.4
usbip: info: attacher le périphérique sur busid 1-1.4 : completVérifions que tout fonctionne :
root@OpenWrt:/home# netstat -alpt
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale Adresse étrangère État PID/Programme
TCP 0 0 0.0.0.0:3240 0.0.0.0:* LISTEN 1884/usbipdPour lier automatiquement le périphérique plus tard, modifions /etc/rc.local, en ajoutant avant exit 0 ce qui suit :
usbipd -D &
sleep 1
usbip bind -b 1-1.4Partie cliente
Essayons de connecter le périphérique à Windows 10, en utilisant l'instruction mentionnée ci-dessus sur openwrt.org. Je le dis tout de suite : l'initiative est vouée à l'échec. Tout d'abord, uniquement Windows 7 x64 est pris en compte. Deuxièmement, un lien est donné vers un fil sur sourceforge.net, proposant de télécharger un pilote patché en 2014 depuis Dropbox. En essayant de l'exécuter sous Windows 10 et de se connecter à notre appareil, nous obtenons l'erreur :
c:Utilsusbip>usbip -a 192.168.31.203 1-1.4
usbip pour windows ($Id$)
*** ERREUR : impossible de trouver le périphérique Cela est dû au fait que le client ne fonctionne pas avec le serveur construit sous un noyau plus ancien que la version 3.14.
Le serveur usbip sous OpenWRT 19.07.3 est construit sur le noyau 4.14.180.
En poursuivant mes recherches, je tombe sur un développement actuel d'un client Windows sur . Ok, la prise en charge de Windows 10 x64 est annoncée, mais le client est uniquement en test, donc il y a plusieurs limitations.
Ainsi, ils demandent d'installer le certificat, et même deux fois. Ok, plaçons-le dans Autorité de certification racine de confiance et Éditeurs de confiance.
Ensuite, il est nécessaire de passer le système d'exploitation en mode test. Ceci se fait avec la commande
bcdedit.exe /set TESTSIGNING ONJe n'ai pas réussi du premier coup, le secure bootm'a gêné. Pour le désactiver, il faut redémarrer dans UEFI et le régler sur secure boot — désactivé. Sur certains modèles de portables, il peut être nécessaire de définir un mot de passe administrateur.
Après cela, nous démarrons Windows et faisons bcdedit.exe /set TESTSIGNING ON
Windows dit que tout est ok. Nous redémarrons à nouveau et voyons en bas à droite l'inscription Mode Test, la version et le numéro de build du système d'exploitation.
Pourquoi toutes ces manœuvres ? Pour installer un pilote non signé USB/IP VHCI. Cela est proposé en téléchargeant les fichiers usbip.exe, usbip_vhci.sys, usbip_vhci.inf, usbip_vhci.cer, usbip_vhci.cat, et en exécutant avec les droits d'administrateur
usbip.exe installou la deuxième méthode, l'installation de Matériel Héritage en mode manuel. J'ai choisi la deuxième option, j'ai reçu un avertissement sur l'installation d'un pilote non signé et j'ai accepté.
Ensuite, nous vérifions que nous avons la possibilité de nous connecter à un périphérique USB distant en exécutant la commande :
usbip.exe list -rnous recevons la liste des appareils :
c:Utilsusbip>usbip.exe list -r 192.168.31.203
usbip : erreur : échec de l'ouverture de la base de données d'identifiants USB
Appareils USB exportables
======================
- 192.168.31.203
1-1.4 : vendeur inconnu : produit inconnu (1a86:7523)
: /sys/devices/ssb0:1/ehci-platform.0/usb1/1-1/1-1.4
: classe inconnue / sous-classe inconnue / protocole inconnu (ff/00/00)sur l'erreur usbip : erreur : échec de l'ouverture de la base de données d'identifiants USB nous n'y prêtons pas attention, cela n'affecte pas le fonctionnement.
Maintenant, nous attachons l'appareil :
c:Utilsusbip>usbip.exe attach -r 192.168.31.203 -b 1-1.4C'est bon, Windows a détecté un nouvel appareil, nous pouvons maintenant travailler avec comme s'il était physiquement connecté à l'ordinateur portable.
Avec le graveur chinois, cela a été un peu compliqué, car lors de la tentative d'installation de son pilote CH341SER via l'installateur fourni (oui, le graveur est sur Arduino), USB/IP VHCI faisait planter Windows avec un BSOD. Cependant, l'installation du pilote CH341SER à la connexion de l'appareil via usbip.exe résolvait le problème.
En résumé : le graveur fait du bruit et fume dans la cuisine avec la fenêtre ouverte et la porte fermée, je surveille le processus de gravure depuis une autre pièce via le logiciel d'origine, qui ne soupçonne rien.
Sources utilisées :
Source : habr.com
