Unreliable USB connection

[mauromol]

I don't know if this is the right forum section. I have two Linux hosts (a Linux Mint 16 KDE, based on Ubuntu 13.10, as system A and a Debian Wheezy as system B) and two Windows XP SP3 guests.
On both configurations the symptoms I have are the following.
USB connection and forwarding to the VM works perfectly: the guest OS sees the device once connected, drivers are installed if needed and the connection stays alive until I disconnect the device or I uncheck it from the Devices menu of VirtualBox (well, I have a problem with VirtualBox 4.3.14 on physical disconnection: the VM stops immediately, as of bug https://www.virtualbox.org/ticket/13239).
However, even though Windows sees the device as connected, the software that must communicate with the USB device have problems.

On system A I'm trying to connect a Tom Tom GO 500 GPS device to my Windows guest: Tom Tom's software to update the device is for Windows and Mac only. The device is seen by both the host Linux OS and the guest Windows OS as a new network interface. When I try to make a big update (like software or maps updates, which can range from hundreds of megabytes to some gigabytes in size) the update process frequently stops. The software suddenly doesn't see the device connected any more, although it is (and Windows also sees is as connected). If I look at the logs of the Tom Tom software, I see errors like this:

Code: Select all

2014-07-20 18:18:22.388|10|Information|ServerRequest::onTimer|URL: http://169.254.255.1:80/mpnd/progressupdate?api=2.0
2014-07-20 18:18:22.401|10|Information|ServerRequest::onTimer|Data: 
2014-07-20 18:18:22.401|30|Warning|DeviceNavEthernetManager::onDeviceNotResponding|No response for request: /mpnd/progressupdate?api=2.0
2014-07-20 18:18:22.401|10|Information|DeviceNavEthernetManager::onDeviceNotResponding|Schedule timer to check unresponsiveness
2014-07-20 18:18:22.413|20|Trace|ServerRequest::~ServerRequest|Parent: DeviceNavEthernetManager, 1
2014-07-20 18:18:23.185|10|Information|DeviceNavEthernetManager::AppendRequest|Sending /mpnd/progressupdate?api=2.0
2014-07-20 18:18:23.185|20|Trace|ServerRequest::ServerRequest1|Parent: DeviceNavEthernetManager, 1
2014-07-20 18:18:23.198|20|Trace|DeviceRequest::SendRequest|URL: http://169.254.255.1:80/mpnd/progressupdate?api=2.0
2014-07-20 18:18:23.198|20|Trace|DeviceRequest::SendRequest|checking for https
2014-07-20 18:18:23.198|20|Trace|DeviceRequest::SendRequest|request url is http://169.254.255.1:80/mpnd/progressupdate?api=2.0
2014-07-20 18:18:23.198|20|Trace|DeviceRequest::SendRequest|encoded request url is http://169.254.255.1:80/mpnd/progressupdate?api=2.0
2014-07-20 18:18:23.198|20|Trace|DeviceRequest::SendRequest|------
2014-07-20 18:18:23.198|20|Trace|DeviceRequest::SendRequest|Header. User-Agent: TomTomSA/3.3.0.1502
2014-07-20 18:18:23.198|20|Trace|DeviceRequest::SendRequest|Header. Accept: application/xml
2014-07-20 18:18:23.198|20|Trace|DeviceRequest::SendRequest|------
2014-07-20 18:18:23.198|20|Trace|DeviceRequest::SendRequest|After done 'get' method.
2014-07-20 18:18:23.439|10|Information|RelayProxy::reverseServerDisconnected|
2014-07-20 18:18:23.439|10|Information|RelayAgent::connectionError|error: 1, The remote host closed the connection
2014-07-20 18:18:23.439|10|Information|RelayAgent::reverseServerDisconnected|
2014-07-20 18:18:23.439|10|Information|RelayProxy::Stop|
2014-07-20 18:18:23.439|10|Information|DeviceNavEthernetManager::AppendRequest|Sending /sa/goodbye?api=2.0
2014-07-20 18:18:23.439|20|Trace|ServerRequest::ServerRequest1|Parent: DeviceNavEthernetManager, 2
2014-07-20 18:18:23.439|20|Trace|DeviceRequest::SendRequest|URL: http://169.254.255.1:80/sa/goodbye?api=2.0
2014-07-20 18:18:23.439|20|Trace|DeviceRequest::SendRequest|checking for https
2014-07-20 18:18:23.439|20|Trace|DeviceRequest::SendRequest|request url is http://169.254.255.1:80/sa/goodbye?api=2.0
2014-07-20 18:18:23.439|20|Trace|DeviceRequest::SendRequest|encoded request url is http://169.254.255.1:80/sa/goodbye?api=2.0
2014-07-20 18:18:23.439|20|Trace|DeviceRequest::SendRequest|------
2014-07-20 18:18:23.439|20|Trace|DeviceRequest::SendRequest|Header. User-Agent: TomTomSA/3.3.0.1502
2014-07-20 18:18:23.439|20|Trace|DeviceRequest::SendRequest|Header. Accept: application/xml
2014-07-20 18:18:23.439|20|Trace|DeviceRequest::SendRequest|------
2014-07-20 18:18:23.439|20|Trace|DeviceRequest::SendRequest|After done 'get' method.
2014-07-20 18:18:23.439|10|Information|DeviceNavEthernetManager::StopDevice|done.
2014-07-20 18:18:23.439|20|Trace|ServerRequest::~ServerRequest|Parent: DeviceNavEthernetManager, 2
2014-07-20 18:18:23.464|20|Trace|DeviceNavEthernetManager::onDeviceRequest|Request 2, /sa/goodbye?api=2.0, response: "<?xml version='1.0' encoding='utf-8' ?><goodbye xmlns="http://www.tomtom.com/ns/device/2.0" deviceid="QJ6213G05957" rescue="false" />", status code: 200
2014-07-20 18:18:23.464|10|Information|SupporterManager::onDeviceManagerGoodbye|
2014-07-20 18:18:23.464|20|Trace|ServerRequest::~ServerRequest|Parent: DeviceNavEthernetManager, 1

Apart from the protocol details, what is clear here is that the device suddenly does not respond any more.

On system B the situation is a bit different, but not so much. There I have two printers, an Epson one and a Canon one. The Epson printer seems not to work at all ("not responding" errors), although Windows sees it as connected. Anyway, I don't have too much precise information on this, since it's my father's system and I don't have investigated on it too much. However I have better information on the Canon printer. This does work correctly if Windows is started after the printer has already been turned on and connected to the host system. Instead, if I turn on the printer after Windows has been already started, any printing attempt ends with a "printer not responding" error: I have to uncheck the printer from the "Devices" menu of VirtualBox and check it again to make the printer work again. Also, the same problem (printer not responding) happens if I leave the USB printer on and inactive for some minutes and then try to print something: it seems like it enters a standby state from which it can't resume anymore. Again, the solution is to uncheck and check again the printer from the VirtualBox Devices menu in order to disconnect and re-connect again the printer to the guest OS. I already described this problem at: viewtopic.php?f=7&t=62198

Useless to say that all of these devices work correctly when connected to a physical Windows system.

On both systems I'm using VirtualBox 4.3.14 with the USB extension pack (of the same version). Guest Additions are installed and their version matches that of the VirtualBox used to run the VMs.

So, I was wondering if these kind of issues with USB devices is known. Has anyone some good advice to make the situation better?
Also, might be another Windows version (like Vista or 7) as the guest OS more reliable for this kind of usage with VirtualBox?

Thanks in advance for any reply.

[iMissMyOldNickName]

Not much help - but I can tell you that my Win7 on VirtualBox also have this problem.

Which make my TomTom exceptionally expensive since I have to buy a separate laptop just to update the maps.

I miss the old TomToms where you could use any file manager to copy the data over.

TomTom lost their way when they let the money guys run the company and not the enthusiuastic engineers.

[mauromol]

The change in the TomTom device update process might have been due to the legal problems TomTom had with Microsoft because of the use of FAT32, but this may not be an excuse (there could be other ways to solve this problem).

Anyway, since I wrote that post I have not made any significant progress. I hoped the issue was with Windows XP only, but you say that with a Windows 7 guest there's the same problem...

Using printers on my dad system is still a big problem... newer versions of VirtualBox didn't make the USB support much more reliable and I even wonder if it can be really usable on any scenarios...

I could make some progress with the TomTom device by compiling and installing usbip daemon on the Linux host system and by using a patched client on the Windows guest system (found in usbip website forum... the official client is obsolete and does not work any more), so that a virtual USB port is installed on the guest and USB commands are tunnelled through TCP/IP packets from the guest to the host: the update process goes a bit better, but with huge updates (like map updates) it still gets interrupted, even if less frequently. But this might not be a problem of VirtualBox itself, who knows?

[scottgus1]

I don't play around much with USB in guests, but I do remember that 4.3.14 is the version Virtualbox started to harden the processes on Windows hosts for security reasons. I do see your hosts are Linux - I don't know if there's any interaction under the hood with the stuff that's been tried for the Windows hardening - with a program as powerful as Virtualbox, there's no telling what might be interconnected. 4.3.14 was essentially not usable for Windows hosts, and the solution was to wait for further builds or go back to 4.3.12, with proper security caveats in mind.
I have no idea if any of this will make your USB work better, but it's worth a try to go back to 4.3.12.

[ChipMcK]

USB Printers - general comment

• Most VirtualBox users do not attach the USB printer(s) to virtual machine(s). They have the virtual machine(s) access the printer(s) as network printer(s).
• For your environment, Linux host with Windows virtual machines, google search: linux shared printer windows

[mauromol]

@scottgus1: 4.3.14 was almost unusable (the VM crashed as soon as you physically disconnected a USB device from the host system), but my problem is present in 4.3.12 too. Honestly, I never tried a 4.2.x version to see if USB is more reliable there.

@ChipMcK: I tried to share printers on the host system and connect to them from the guest using network sharing, but... I have at least two problems with the two printers I need to use from Windows.
The first one is a Canon PIXMA iX 4000, the second one is an Epson Stylus Photo 1290. In theory, they should be both compatible with Linux, in practice I experience this:

• with the first one (Canon) as soon as I try to print something from Windows with a non-standard paper size (i.e.: a custom size set up with the appropriate "custom" paper format preset, as offered by the Windows driver) nothing will be printed anymore... any printing jobs queued from either the guest Windows OS or the Linux host OS remains in the queue forever and doesn't get printed. You have to uninstall and reinstall the printer on the Linux host system... it must be a bug of the Linux printer driver. This however prevents me to follow this route, because my need is to print on custom paper sheets. I also tried to set a default custom paper size directly on the Linux printing driver, but the only option is to set the paper size to "custom" without the ability to set WHAT exactly this "custom" means... ahem...
• with the Epson printer, first of all the software that measures the ink level does not work when the printer is connected through network; also, if seems like it interferes in some way with the standard printing process, so that printing jobs are not correctly queued and nothing gets printed. I tried many many times, sometimes I could print something, but then the second attempt failed and from that moment on I had to uninstall and reinstall the printer driver in the Windows guest system to make the printer be usable again (until the next "jam").

I tried both the IPP sharing and the Samba sharing: nothing changes regarding these problems.

So, even if in theory I have plenty of options, and all of them should be quite straightforward (direct USB connection to the VM, sharing through IPP, sharing through Samba...), none of them works reliably. I even tried to use the USB/IP technique for printers, but apart from the fact that it's not so straightforward to set all things up (client programs are rudimentary command-line tools that are not adequate for my father skills...), at least the Epson printer still has problems (communication errors) whenever i don't follow the right sequence between guest OS starting, printer switch on, USB/IP binding, printing, etc..

The last chance I have is to try another virtualization software with USB capabilities... Of course, it would be nice to have a fixed VirtualBox though...