USB over IP for Raspberry Pi

[msbroadf]

I have written a USB-over-IP server for Raspberry pi.

The software for raspberry pi is at http://www.virtualhere.com/usb_server_software

just chmod +x and run.

And the windows client is at http://www.virtualhere.com/usb_client_software

FAQ http://www.virtualhere.com/oem_faq

[technion]

Does the "graphical UI" mean we must be running X Windows in order to use this product?

Edit: The client states:

The software will automatically find USB devices shared by VirtualHere USB Servers on the network.

Does this mean you can't use it across a layer 3 boundary?

[msbroadf]

x-windows is not required, just start it in console mode i.e vhusbdpi -o

Just start the client, right click on"Virtual USB Hubs" -> "Manually Specify Hubs" and enter the ip and port of the server there...

If you want automatic finding of the servers, since it uses bonjour/avahi/dns-sd it relies on broadcast packets. However it can work between network segments by following this guide http://www.dns-sd.org/ . Basically requires some network configuration.

[Paravis]

Hey there Michael --

I checked out your app, it's very well done. I do have a question regarding the client, however.

Is there any way to run the client as a standard user? Or is this reserved for only administrators?

Using the Administrator account on a terminal server, the performance and usage is (essentially) flawless -- aside from a random app crash when closing the vhui64.exe one time. But for a standard user, the program "freezes" while connecting to the device. I believe it is still running, but it seems the standard user is missing some type of permissions, even when the executable is set to run as administrator using compatibility mode.

Any suggestions or thoughts? Thanks!
-- Laz

[msbroadf]

Hi Laz, the client executable has a userspace component and a kernel driver. Administrator access is needed to start the client because the client needs to install the driver and verify it is the latest version before the userspace part starts up. What it is getting stuck on is probably the SetupDiGetClassDevs calls it makes to find the driver and bind to it. To tease apart the tight coupling of the client/driver combination (avoiding admin access) will require some investigation which i can put in my todo list.

[Paravis]

Hey Michael, thanks for the quick reply!

Definitely expect a license purchase from me if that issue can get worked out on the VirtualHere client side, or if you can figure out an appropriate workaround. Your work is very solid, and I would love to support the project.

Also ... Might it possible to run the client as a daemon/service under the system account on the terminal server, and provide access (without the ability to manually attach/detach, etc) to a remote USB device to the whole system and all users that may or may not need access? Or is that just a pipe dream ...

Thanks again.
-- Laz

[sdjf]

So even though it is apparently a command line client, it only works for wheezy and windows interfaces? No other linux distributions on client and server side?

I ask because I run neither Windows nor Wheezy, using Arch on Pi and an embedded Linux PDA accesses the Pi over usb using Zaurus driver. But the connection is terribly unstable, crashes often.

[Paravis]

Michael --

Just wanted to update you, as I tried running the client as a service in Windows XP. Here are my findings ...

- Running as LocalSystem account does not work as a service unless "Allow service to interact with desktop" is enabled.
- Service with desktop interaction works for first user who logs on -- client connection to server closes if user logs off, after prompting if the user really wants to disconnect. After clicking "no" and logging off, executable remains active but client is disconnected from server.
- Running service as a user in Administrators group works, however the session is disconnected upon logoff.
- After logging on first time after boot, with service running as LocalSystem account, it takes about 1 minute to actually allow use of the USB device -- the server log shows the following message after the device is successfully bound to the client, and immediately before the USB device works: "kernel: [ 4832.116953] usb 1-1.3: usbfs: process 2797 (vhusbdpi) did not claim interface 0 before use" ...

Definitely seems possible as a system service, so long as the desktop interaction does not affect the running application.

Alright well, thanks again!
~Laz

[msbroadf]

So even though it is apparently a command line client, it only works for wheezy and windows interfaces? No other linux distributions on client and server side?

I ask because I run neither Windows nor Wheezy, using Arch on Pi and an embedded Linux PDA accesses the Pi over usb using Zaurus driver. But the connection is terribly unstable, crashes often.

At the moment the server is complied for Ubuntu x64, x86 and arm6hf (debian), ARM7hf (beaglebone). Other platforms are pretty easy to compile, if i have a qemu image.

The client is windows only. I havent created a linux client yet, so it wont work on Zaurus. The USB/IP protocol is quite complicated so i doubt it would work well on Zaurus anyway because its quite CPU intensive.

[msbroadf]

Hi Laz, I will add a command line option in the client to turn off the driver install/testing functionality which may remove the need for administrator access. I cant work on this yet (at the moment im converting the client/server to use udp instead of tcp for speed gains). After i have finished that i can work on this.

[Paravis]

That's great, Michael.

I am now doing some testing with the client as a service run using "srvany.exe" in Windows 2008 R2 64-bit, attempting to make the USB/IP device accessible by any user who accesses the server. As of right now, it's looking great! Scanner doesn't get dropped when logging the user on/off, as it does in XP. Nor does the service blue screen for any reason as it did a few times in XP.

Only issue I currently have is my virtual machine disk is slightly too small, and now the page file has disappeared and the application I am attempting to test is not working. So my issues currently have nothing to do with the client.

You can definitely expect me to be donating to the cause, as soon as I am satisfied with the results. Most definitely this is a solid piece of work!

Thanks.
~Laz

[ikeyman]

Please, make a client for Mac OSX

[rchard]

Hi,

I am having a few issues: this is what I get:

wget http://www.virtualhere.com/sites/defaul ... y/vhusbdpi
<this downloads ok>
chmod +x vhusbdpi
<no problem here>
sudo vhusbdpi -o
-bash: vhusbdpi: command not found

how can I get this to run from the command line?

this is for a possible commercial application, so we would want a licene for each build, if I can get it t0 work that is.

Thanks

[Paravis]

Hey there Richard,

Try running instead as : ./vhusbdpi (with arguments here)

I think the "./" will help. Also, you can copy the file to your sbin folder (usually either /sbin or /usr/sbin) and then you should be able to run it without the "./" ...

~Laz

[msbroadf]

Paravis, I have updated the client to version 1.3.0. This version *does not require* administrator access to run after the first install. Download from http://www.virtualhere.com/usb_client_software

To setup on a machine without administrator access.

1. Run the client on a machine and share a device. It will ask you for administrator access to install bonjour and the drivers.

2. All subsequent execution of the client will not use administrator access.

Also fixed the sporadic memory exception that occurs when shutting down.

[celso]

Hi I'm curious if you modelled your project with the open source software USB/IP project? If so this would make existing client side assets that were written for that project compliant with your project. Is your project capable of supporting more than one USB device? We're Apple Mac centric, perhaps we can work together to get a MacOS version of the "client" built.

Thank you

[Paravis]

Michael --

That's great news! I have downloaded/installed, and all seems to be working flawlessly.

Expect my license purchase today for your hard work and effort!

Also, as an idea for a future version ... Installing a Windows service without GUI (configurable by GUI or configuration file) that will maintain a connection regardless of user, etc. would be a great feature!

Keep up the good work. Thanks again.
~Laz

[msbroadf]

@ celso No USP/IP code was used because it was too kernel based which i felt would affect system stability, so my server is written in userspace. Clients must be kernel based however.

The client is already cross platform, however the usb driver part is not written for mac or linux yet due to lack of time...Im hoping to start working on a mac version soon. The best way to help is to simply beta test when i write the mac version. Will let you know when thats out.

The server can share multiple devices at once

[dw515]

Hey,

it's a really nice program and mostly works like a charm.

However I've found one odd issue:

In my device tree in the client software there is a device called "ec00". It's always there, so I assume it's some internal thing of the raspberry.
Trying to -accidentally- right-click and use this device causes the pi to crash immediately. All leds apart from power shut off etc. (Replugging the power is the only solution, since it doesn't reboot either.)
Also.. I think it isn't even able to write anything to any logs. (Or maybe I just searched the wrong logs so far.)

I'm using the newest Raspbian (Overclocked - although I don't think this causes the issue.)

Thanks!

[msbroadf]

Yes please do not share the ec00, it is the USB Device that internally connects the external hub of the raspberry pi to the internal usb pins on the ARM cpu. Basically it expands the one usb port on the cpu to the two on the board.

I dont know why when it is shared it crashes the pi. I will add a default ignore for that device in a later build.

[msbroadf]

@dw515, please download server version 1.2.9 and that will automatically ignore the ec00 device so it wont be visible by clients and cant be accidentally shared

[mweinberg]

Hi,
I installed the sever on my Raspberry Pi and the client on a Windows 7 x64 machine. I attached an Olympus dslr camera to the pi and I can see it fine in my device manager on my windows machine. When I try to control it via an application, the shutter and other controls seem to work fine, but when I take a picture the server crashes during the image transfer, and the camera disappears from my device manager. It appears that I lose the server process entirely. Any ideas as to what could be causing this? I would really like to get this interface working.

Thanks,
Mark

[msbroadf]

@mweinberg Hi Mark, yes i know what crashes it, there is a bug in raspbian. Using usb isochronous transfer in certain circumstances, will lock the kernel. Transfering an image (from the viewfinder ) would use this type of transfer. Controlling the camera uses a different type of method (bulk/control) and this has no problem, hence you can adjust shutter/trigger picture etc.

Unfortunately i dont have access to hardware specifics that the raspberry pi uses for its usb subsystem (as it is proprietary) so i cant find out the problem. I think its just a matter of waiting for a fix by the raspbian team in hopefully not to distance future.

[mweinberg]

Thanks for the fast response! At least it is a known problem.
I will check for updates from the raspian team.

Thanks,
Mark

[msbroadf]

@mark. I have updated the server and client to work around the locking issue.

Could you download 1.3.0 of the server and 1.3.3 of the client and give it a try.

Note any returns codes for dpinst can be decoded here http://msdn.microsoft.com/en-us/library ... s.85).aspx