青云最近推出了云桌面功能，用户可以像使用本地计算机一样访问远程主机，支持USB重定向，不禁让我想起了2年前调试的一个开源项目USB/IP，当时还用英文写了一个总结性文档，放在这里方便以后查看。
USB/IP Summary
Abstract
The USB/IP project aims to provide users with the ability to access remote USB devices via IP network.
From a user’s perspective, there is no difference from accessing USB devices those plugged into your
local machine physically. The project is opened source and could be built into newer Linux kernel by
proper configuration. The shortage is that there is no official document demonstrating the architecture
and overall structure of it. This is part of the reason for the coming of this document.
Client/Server Model
The machine which a USB device physically attached is the server with a Linux system running upon, and the
machine from where a user access USB resource is the client, it can either be a Linux or a Windows box.
In the following section we will describe the structure of this project, how client talks to server and vice versa.
For simplicity, we will omit case that using a Linux box as the client side machine, and only discuss the topic
according to the following diagram.
Windows Client
There are two parts in client side, the user space tool and the underlying virtual bus driver; within this document
we will refer them to usbip.exe and USBIPEnum.sys, respectively. Firstly, a user launch usbip.exe to query exported
USB devices from a server, and he or she might decide to import a device if there is one available. If the import
request succeeded, usbip.exe would send an IRP to USBIPEnum.sys informing it to create a physical device object
which representing a real USB device plugged into the client machine. Certainly, there is no real device attached to
the client machine, but our system will treat it as a real one without aware. The system will then send many IRPs to
our virtual bus driver for querying purpose, such as device capability querying, device hardware ID querying and so
on. Some queries have nothing to do with the actual device on server side, and our virtual bus driver will finish them
immediately. But when the user access the data store on the remote USB device, our bus driver would receive IRPs
those associated with URBs (USB request block), the bus driver could not give her back the data required immediately.
In this case, USBIPEnum.sys will look up whether there is a pending read request from usbip.exe, and if
(1):
There is indeed one pending read request; USBIPEnum.sys will feed the read quest with a URB properly, the IRP is
enqueued and set to pending state. Till this time, the read operation from usbip.exe will successfully returned,
usbip.exe will then imbed the URB in a package according to the protocol between client and server and send this
package to the server. Usbip.exe always waits on a socket, when it receives a package from the server, it will call
WriteFile() API to write the package to our virtual USB device. Upon receiving the write IRP, USBIPEnum.sys gets
data from this write IRP and feeds the former pending IRP with appropriate data, and then that pending IRP would
be completed successfully, it would be de-queued subsequently.
(2):
There is no pending read request; the IRP will be enqueued and set to pending state. If there comes
a read request from usbip.exe some times later, USBIPEnum.sys will search through the queue to get
an IRP which has not been sent to the server. When it finds one, it will feed the read operation with info
from that found IRP, and all subsequent behaviors will be exactly the same as (1) above.
Linux Server
Similar to the client side, there are also two parts in server side, the user space tool usbipd and the driver part. Here
we will omit the discussion of usbip tool which used to list USB devices in the system or bind the USB device to our
driver. Usbipd is a tool to meet the requirement from the client side, for example exported devices querying and import
requesting.After usbipd exported a device to a client, a TCP connection would be established between them. Usbipd
will then send this TCP connection information to the underlying usbiphost driver, the latter will then start two threads
for receiving and sending purposes, respectively. The receiving thread will then wait on the established TCP connection
port to get request from client side. When the receiving thread gets a submit command from the client, it extract info
from the package and allocate an URB, set info into this URB appropriately and submit it to the USBCore. When the
system finish handling this URB, the sending thread in usbip-
host driver will be awaked, it will package the result of this URB and send to the client. There is also another driver named
usbip-core, which maintains an event handler loop. The event handler loop is started by usbip-host driver by invoking a
method exported by usbip-core. Before starting the event handler, usbip-host driver set some procedures for usbip
core for calling back purpose. For example, when a shutdown event happens, usbip-host will set the event bit, and usbip-
core will be noticed latterly, it then invokes the shutdown event handler which defined in usbip-host driver.
Kernel Debugging
Client: VMWare+Windbg
Windbg runs on your host machine, it connects to Windows client (XP, Win7) runs on virtual machine via named pipe.
System that runs on virtual machine imports USB device from remote Linux server.
Server: VMWare+KGDB
Both systems can run on a virtual machine, one is a debugger that run GDB and the other is a debug gee which act as
a server.Your physical USB device attached to the latter one. The debug gee must be built with kernel debugging switch
enabled and some other switch enabled if needed. One might encounter some configuration problems while playing with
this stuff, and there are many web sites you could go for help.
Prerequisite Knowledge
The developer should be familiar with these concepts: Windows Driver Model, IRP, URB, Pending state, etc.