The Core of USB Redirection

USB redirection makes a physical device attached to one host accessible to another host over a network, as if it were locally connected. The goal is not to share files or relay a high-level protocol, but to forward USB bus-level requests and responses between two machines. On Linux, usbip is the reference implementation that exposes this concept clearly.

When a USB device is plugged into a Linux machine, applications do not talk to the hardware directly. The path flows through the USB core, a host controller driver, and the physical controller. Redirection splits this chain: the client (the machine that needs the device) must see a virtual device, while the server (the machine with the real hardware) must take over the physical device and forward its bus traffic. The fundamental unit of work in this exchange is the USB Request Block (URB).

Architecture: VHCI and the Stub Driver

The usbip framework assigns two distinct roles:

• Server side: runs a stub driver that detaches a real USB device from its native driver and exports it over TCP.
• Client side: employs a Virtual Host Controller Interface (VHCI) driver that presents a synthetic USB host controller, making imported devices appear to have been physically connected.

Client Linux host
    Application / in-kernel class driver
        -> USB Core
        -> VHCI (virtual host controller)
        -> usbip TCP connection

Server Linux host
    usbip TCP connection
        -> Stub driver
        -> USB Core
        -> Physical host controller
        -> Real USB device

The VHCI driver captures every URB that the local class driver submits for a remote device and serializes it into a usbip prottocol message. On the server, the stub driver deserializes the message, submits the URB to the physical device, and returns the completion status and data back to the client.

Operational Flow

Exporting a device on the server

1. Load the server-side module: modprobe usbip-host
2. Start the daemon that listens on TCP port 3240: usbipd -D
3. Identify the bus identifier of the target device: usbip list -l
4. Bind the device to the stub driver: usbip bind -b <busid>

After binding, the local native driver no longer owns the device. Only the stub driver can submit URBs to it.

Importing a device on the client

1. Load the VHCI module: modprobe vhci-hcd
2. Query the remote server for exported devices: usbip list -r <server_ip>
3. Attach a specific device: usbip attach -r <server_ip> -b <busid>
4. Verify the new virtual port: usbip port

Once attached, the Linux USB stack enumerates the device normally, probes for drivers, and creates device nodes. A mass storage device, for example, appears under /dev and can be mounted like any local disk.

Detaching and unbinding

On the client, usbip detach -p <port_number> removes the virtual device. On the server, usbip unbind -b <busid> returns the device to its original driver.

Protocol Overview

usbip exchanges two categories of messages over TCP:

• Management messages: handle device discovery and session establishment.
• URB messages: carry actual USB requests, responses, and cancellations.

The documented protocol version 1.1.1 uses a binary version value 0x0111 in the header, and all integer fields are in network byte order.

Device List and Import

Before a device can be imported, the client requests the exported device list with OP_REQ_DEVLIST. The server replies with OP_REP_DEVLIST, describing each device’s busid, vendor/product IDs, speed, and interface information. The client then sends OP_REQ_IMPORT for the chosen device, and the server responds with OP_REP_IMPORT. This establishes the session and prepares the VHCI slot.

URB Submission and Cancellation

• USBIP_CMD_SUBMIT – The client sends a URB submission containing the transfer direction, endpoint, flags, data payload (for OUT transfers), and setup packet (for control transfers).
• USBIP_RET_SUBMIT – The server returns the URB status, actual transfer length, and IN data payload.
• USBIP_CMD_UNLINK – The client requests cancellation of an outstanding URB.
• USBIP_RET_UNLINK – The server acknowledges the unlink operation.

These four messages cover the full lifecycle of a USB transfer, including error handling and early termination.

Strengths and Transparency

Because usbip works at the URB layer and leverages standard Linux USB stack APIs, client-side class drivers operate without modification. A USB HID class driver, a USB-serial driver, or a mass-storage driver all treat the remote device as local. This transparency makes usbip a valuable reference for designing cross-platform redirection solutions.

Limitations to Consider

• Network latency – USB was designed for low-latency local buses. Long round-trip times, jitter, and packet loss can degrade performance, especially for isochronous transfers used by cameras and audio devices.
• Exclusive server ownership – A bound device cannot be used simultaneously by local drivers. The server must explicitly unbind it to restore normal operation.
• No authentication – The usbipd daemon does not authenticate clients. In production environments, it must be shielded by firewalls, VPNs, or application-layer gateways.
• Device compatibility – Commplex or vendor-specific devices may exhibit issues with descriptor handling, timing, or multi-interface configurations.

Diagnostic Approach

When troubleshooting, verify each step in sequence:

• Server hardware visibility: lsusb, then usbip list -l to obtain busid.
• Successful binding: confirm the busid appears as bound in local list output.
• Daemon reachability: check ss -lntp | grep 3240.
• Client remote discovery: usbip list -r <server> should return the exported device.
• Enumeration on attach: monitor dmesg -w, run lsusb, and inspect usbip port for the virtual connection.

Cross-Platform Insights

On Windows, achieving virtual device presentation requires a bus driver or device emulation framework, while hardware-level redirection on Android heavily depends on platform privileges and UsbManager APIs. The usbip model provides a universal mental map: virtual host controller on the consumer, hardware takeover on the provider, and a reliable URB message exchange over the wire.