Às vezes, há vontade de trabalhar com um dispositivo conectado via USB, sem mantê-lo na mesa ao lado do laptop. O meu dispositivo é uma gravadora chinesa com laser de 500 mW, que é bastante desagradável em contato próximo. Além do perigo direto para os olhos, durante o funcionamento do laser são liberados produtos tóxicos de combustão, por isso o dispositivo deve estar em um ambiente bem ventilado e, de preferência, isolado de pessoas. Mas como controlar um dispositivo assim? A resposta a essa pergunta eu encontrei por acaso, enquanto analisava o repositório OpenWRT na esperança de encontrar uma aplicação adequada para meu antigo roteador D-Link DIR-320 A2. Para a conexão, decidi usar o que foi descrito anteriormente no Habr. túnel USB sobre IP, mas todas as instruções de instalação se tornaram obsoletas, por isso estou escrevendo a minha.
O OpenWRT é um sistema operacional que não precisa de apresentações, então não irei detalhar sua instalação. Para o meu roteador, peguei a última versão estável do OpenWrt 19.07.3 e conectei-o ao ponto de acesso principal via Wi-Fi como cliente, escolhendo o modo lan, para não sobrecarregar o firewall.
Parte do servidor
Agimos de acordo com . Após a conexão via ssh, instalamos os pacotes necessários.
root@OpenWrt:~# opkg update
root@OpenWrt:~# opkg install kmod-usb-ohci usbip-server usbip-clientEm seguida, conectamos nosso dispositivo à porta USB do roteador (no meu caso, os dispositivos: hub USB, um pen drive, no qual está montado o sistema de arquivos do roteador, devido à falta de espaço na memória interna, e, diretamente, a gravadora).
Vamos tentar listar os dispositivos conectados:
root@OpenWrt:~# usbip list -lVazio.
Através de pesquisa no Google, encontramos o culpado, que se revelou ser a biblioteca libudev-fbsd.
Retiramos manualmente do repositório a última versão funcional libudev_3.2-1 do lançamento OpenWRT 17.01.7 para nossa arquitetura, no meu caso é libudev_3.2-1_mipsel_mips32.ipk. Com o wget/scp, enviamos para a memória do roteador e reinstalamos
root@OpenWrt:~# opkg remove --force-depends libudev-fbsd
root@OpenWrt:~# opkg install libudev_3.2-1_mipsel_mips32.ipk
Verificamos:
root@OpenWrt:~# usbip list -l
- busid 1-1.1 (090c:1000)
Silicon Motion, Inc. - Taiwan (antigamente Feiya Technology Corp.) : Flash Drive (090c:1000)
- busid 1-1.4 (1a86:7523)
QinHeng Electronics : adaptador USB-Serial HL-340 (1a86:7523)O dispositivo chinês conectado ao hub USB recebeu o bsuid 1-1.4. Lembre-se.
Agora vamos iniciar o daemon:
root@OpenWrt:~# usbipd -De vinculamos o chinês
root@OpenWrt:~# usbip bind -b 1-1.4
usbip: info: bind device on busid 1-1.4: completeVamos verificar se tudo está funcionando:
root@OpenWrt:/home# netstat -alpt
Conexões Internet ativas (servidores e estabelecidas)
Proto Recv-Q Send-Q Endereço Local Endereço Remoto Estado PID/Programa
tcp 0 0 0.0.0.0:3240 0.0.0.0:* LISTEN 1884/usbipdPara vincular automaticamente o dispositivo a seguir, vamos editar /etc/rc.local, adicionando antes exit 0 o seguinte:
usbipd -D &
sleep 1
usbip bind -b 1-1.4Parte do cliente
Vamos tentar conectar o dispositivo ao Windows 10, usando as instruções mencionadas em openwrt.org. O que já posso dizer: a ideia está condenada ao fracasso. Em primeiro lugar, só se considera o Windows 7 x64. Em segundo lugar, há um link para um tópico no sourceforge.net, que propõe baixar um driver alterado em 2014 via Dropbox. Ao tentar executá-lo no Windows 10 e conectar ao nosso dispositivo, recebemos o erro:
c:Utilsusbip>usbip -a 192.168.31.203 1-1.4
usbip para windows ($Id$)
*** ERRO: não é possível encontrar o dispositivo Isso se deve ao fato de que o cliente não funciona com um servidor construído sob o núcleo anterior à versão 3.14.
O servidor usbip sob OpenWRT 19.07.3 é construído na versão do núcleo 4.14.180.
Continuando a busca, me deparo com um desenvolvimento atual do cliente para Windows em . Ok, foi declarada a compatibilidade com Windows 10 x64, mas o cliente é exclusivamente de teste, o que traz uma série de limitações.
Assim, primeiro pedem para instalar o certificado, e ainda por duas vezes. Ok, colocamos ele na Autoridade de Certificação Raiz Confiável e em Editores Confiáveis.
Em seguida, é necessário colocar o sistema operacional em modo de teste. Isso é feito com o comando
bcdedit.exe /set TESTSIGNING ONNa primeira tentativa não consegui, foi atrapalhado pelo secure boot. Para desativá-lo, é necessário reiniciar o UEFI e definir secure boot — disable. Nos laptops de alguns modelos, pode ser necessário definir uma senha de supervisor.
Após isso, iniciamos o Windows e fazemos bcdedit.exe /set TESTSIGNING ON
O Windows diz que tudo está ok. Reiniciamos novamente e vemos no canto inferior direito a mensagem Modo de Teste, versão e número da build do sistema operacional.
Por que todas essas manobras? Para instalar um driver não assinado USB/IP VHCI. Isso é proposto, baixando os arquivos usbip.exe, usbip_vhci.sys, usbip_vhci.inf, usbip_vhci.cer, usbip_vhci.cat, e executando com privilégios de administrador
usbip.exe installou a segunda forma, instalação de Hardware Legado manualmente. Eu escolhi a segunda opção, recebi um aviso sobre a instalação do driver não assinado e concordei.
Depois, verificamos se temos a possibilidade de nos conectar ao dispositivo USB remoto, executando o comando:
usbip.exe list -rrecebendo a lista de dispositivos:
c:Utilsusbip>usbip.exe list -r 192.168.31.203
usbip: erro: falha ao abrir o banco de dados de IDs USB
Dispositivos USB exportáveis
========================
- 192.168.31.203
1-1.4: fornecedor desconhecido : produto desconhecido (1a86:7523)
: /sys/devices/ssb0:1/ehci-platform.0/usb1/1-1/1-1.4
: classe desconhecida / subclasse desconhecida / protocolo desconhecido (ff/00/00)ao erro usbip: erro: falha ao abrir o banco de dados de IDs USB não se preocupe, não afeta o funcionamento.
Agora vamos vincular o dispositivo:
c:Utilsusbip>usbip.exe attach -r 192.168.31.203 -b 1-1.4Pronto, o Windows detectou um novo dispositivo, agora ele pode ser usado como se estivesse fisicamente conectado ao laptop.
Tive que me esforçar um pouco com o gravador chinês, pois ao tentar instalar seu driver CH341SER através do instalador fornecido (sim, o gravador é baseado em Arduino), o USB/IP VHCI fazia o Windows travar com BSOD. No entanto, a instalação do driver CH341SER até conectando o dispositivo via usbip.exe resolveu o problema.
Resultado: o gravador faz barulho e solta fumaça na cozinha com a janela aberta e a porta fechada, eu observo o processo de queima de outra sala através do software original, que não percebe o truque.
Fontes utilizadas:
Fonte: habr.com
