Trying to google ‘USB over IP’ doesn’t give much except some business web pages that give you it as a service. This brings some information about potential on the market IMHO. Main idea is well presented on open source project page for usbip. I really recommend to read USB/IP – a Peripheral Bus Extension for Device Sharing over IP Network technical paper it describe briefly technical details and capability.
In short USB over IP is a sharing system aim to expose USB devices from server to client encapsulating USB I/O messages in TCP/IP payload.
usbip contain client and server side (called stub and VHCI (Virtual Host
Controller Interface). Stub is used on server side to hijack USB traffic
from/to connected device and send/receive it over the network. VHCI expose
stubbed device on client side and also send and receive data to/from server. We
can say that stub-VHCI pair working as intermediate layer in USB stack, giving
ability to connect over the netowork.
usbip project provided both Linux and
Windows version. In mid of 2008
usbip was introduced to Linux kernel and
matured a while in staging directory. Few days ago I read
this were Greg KH mention
that if it will be possible he will include
As you can expect the biggest problem with USB over IP is how to handle
480Mbit/s (USB2.0) or more over TCP/IP payload. The answer is it can’t.
Recommended use case for
usbip is LAN environment with low latency. Of course
you can try to use it over long distance but you will get best effort, which
varies according to device and application profile. Author of the idea
(Takahiro Hirofuchi) tested his solution and created some models for queue
management for different devices – you can read about it in technical paper.
Below I present Kingston USB stick test in function of delay.
Seting up usbip
What I tried to do was setting up my Rasberry Pi and connect it through my home LAN to share USB device (Kingston DataTraveler). My configuration looks like that:
First I installed latest Raspbian.
Assuming SD card is
With fresh SD card we can boot and push finish on initial setup screen. If you have DHCP set on your router that’s great if not you have to manually configure network inside RPi.
usbip kernel modules for RPi
usbip package is available in Raspbian default repository. Fortunately for our
usbip-host.ko modules are not compiled
in the kernel. What you can see when trying to run
Let’s see if support for USBIP is in kernel:
Compiling Linux kernel on RPi can take number of hours. I saw different values like 5-6, 10 and even 22. It depends on many factors. But we should not bother and try to cross compile RPi on development machine. I will use my Y510P laptop with i7 4700MQ 2.4GHz (4 cores).
1 2 3 4 5 6
I compiled kernel on
3.12.y branch. Go to
Device Drivers -> Staging drivers ->
USB/IP support. I choose to compile usbip-core as loadable module.
Staging drivers -> USB/IP support -> Host driver also is needed it
compiles usbip-host module. Optionally
Debug messages for USB/IP can be set
if you want to see kernel debug messages from driver. After saving changes to
config file we can start compilation:
After finishing compilation we can move our image to SD card. First mount your SD card (it won’t automatically) and run compile modules with correct install path.
1 2 3 4 5 6
Now we can connect card to RPi and boot it to check if new kernel was correctly loaded.
Running usbip on RPi
Now on RPi we can load modules needed for
usbipd and run it:
1 2 3
To what USB devices are connected to our system we can use:
This will show output similar to this:
1 2 3 4 5 6 7 8 9 10
busid 1-1.2 (0951:1625) is my Kingstone pendrive. If you are unsure which
busid is for device that you want to share compare device id and vendor id with
lsusb. To bind device to
usbip-host.ko we should use:
1 2 3 4 5
As you can see communication to
usbip-host module is through writing into
NOTE : if you will try to bind device without root privileges or when modules are not loaded you will get errors like below:
1 2 3 4
usbip – client side
Our device should wait for communication. Let’s go to client side of our LAN and try to check if we can use our USB device. To check if device is available:
1 2 3 4 5 6 7 8
192.168.1.3 is an IP of RPi. Everything seems to be ok. So let’s try to
attach it and do some test:
1 2 3
Oops, looks like we don’t have driver for client side. Let’s see if it is compiled in my kernel as module:
1 2 3 4 5
Great so we can load
And attach pendriver from RPi. What we have to use is IP address and bus id.
In dmesg we can find information about our device.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
Device show correct informations in
lsusb output and
From technical paper that I mentioned above I understand that probably the most
important factor for
usbip performance is latency. Simplest method to emulate
WAN delays is
iproute2 package. It is available by as default tool
To test read speed I used
dd by simply:
So I tried few values with my Kingston pendrive:
1 2 3 4 5 6 7 8 9 10 11 12
And something from
Before we can disconnect device from RPi we have do few things. First detach port to which remote device was connected. Which port ?
Next detach device you want to disconnect:
Finally on RPi you can unbind device:
Now device can be removed.
With various results I tried other devices.
I also tried to connect my Samsung GT-I9070. Unfortunately without luck:
I think it could be related with fact that my smartphone expose multiple
devices over one USB connection. What can be observed on
1 2 3 4
I see this as opportunity to debug, understand and fix the driver.
There was no problem with Arduino. I was even able to program it successfully. Unfortunately to big delay (in my case 300ms) cause software errors:
1 2 3 4 5 6 7 8 9
usbip is usable in low delay network. It would be great to test it
in real WAN. It is possible to use
usbip with more sophisticated devices but
potential driver tweaking is required. As a telecommunication graduate I cannot
say about possible improvements in queue algorithms, like adaptive queueing
which depends on data transfer profile. It was interesting experience to play
usbip and probably I will back to it especially to testing part of this
If you have questions, suggestions or comments please let me know.