Products > Computers
Windows Sandbox and USB over Ethernet
Zbig:
I'm a bit paranoid when it comes to installing random stuff on my PC. I hate it when I have to install some piece of software of dubious quality for a one-off job. Even after uninstalling it, I can often find it's left some dependencies behind or otherwise messed with my system in one minor way or another. That's why I love "Windows Sandbox" - a feature recently introduced in Windows 10 Pro build 1903. It relies on Hyper-V virtualization and basically is a clean, disposable Windows 10 installation within your main Windows 10 installation. You can launch it, install some dodgy software in it, play around with it for a bit. When you close your Sandbox windows, it nukes all the changes made to its underlying virtual disk and wipes itself clean.
What I missed with this solution alone was inability to use physical USB devices within Windows Sandbox. Some other virtualization platforms like VirtualBox do offer USB pass-through but Windows Sandbox and its underlying Hyper-V hypervisor doesn't. The way to solve it is to use a third party "USB over IP" software solution. I noticed something called "VirtualHere" available for install on my Synology NAS. Tried it out and it's awesome. Now I can attach a USB device to my Synology's USB port, launch Windows Sandbox on my PC, install VirtualHere Client there and "attach" remote USB device there. Now the OS inside Sandbox behaves as if there was a physical USB device connected to its virtual USB hub exposed by the VirtualHere client. This completes my "throwaway", no-trace-left solution for one-off, disposable USB devices' software installations.
I've already performed a HDD test using the vendor-provided, proprietary disk testing software that I was reluctant to install on my main "productive" OS. Also, as I write this, I'm updating a TomTom SatNav device. Their software installs a virtual network adapter (NDIS over USB) for talking to the SatNav device but after I'm done, I'll just close the Windows Sandbox and there'll be zero footprint left behind.
I see a great potential in that, for instance when you have to use this dodgy piece of programmer software of dubious provenience for some obscure chip that you just need to use this one time.
aandrew:
--- Quote from: Zbig on July 27, 2019, 10:22:35 am ---The way to solve it is to use a third party "USB over IP" software solution. I noticed something called "VirtualHere" available for install on my Synology NAS.
--- End quote ---
I've tried damn near every "USB over Ethernet" scheme I've found. The problem isn't with the technology in this software, it's in the stupid USB driver writers who insist on microsecond timeouts before declaring the USB device non-responsive. Drives me up the fucking wall!
VirtualHere, Nomachine's extender, various ipkvms... all mediocre at best for anything other than thumb drives.
The best luck I've had to date is with a virtual machine running on ESXi and then using VMWare Fusion (Workstation should work as well) to attach a local USB device to the ESXi VM. This seems to work well over the (100M and 1G) LAN even with FPGA JTAG dongles and the Segger J-Links I usually have to connect to.
Zbig:
--- Quote from: aandrew on July 27, 2019, 02:19:06 pm ---I've tried damn near every "USB over Ethernet" scheme I've found. The problem isn't with the technology in this software, it's in the stupid USB driver writers who insist on microsecond timeouts before declaring the USB device non-responsive. Drives me up the fucking wall!
VirtualHere, Nomachine's extender, various ipkvms... all mediocre at best for anything other than thumb drives.
The best luck I've had to date is with a virtual machine running on ESXi and then using VMWare Fusion (Workstation should work as well) to attach a local USB device to the ESXi VM. This seems to work well over the (100M and 1G) LAN even with FPGA JTAG dongles and the Segger J-Links I usually have to connect to.
--- End quote ---
Are you sure that was caused by USB timeouts and not by the USB device in question re-enumerating as different things in quick succession and the USBoIP solution failing to "grab" each of its subsequent "incarnation" properly? I have learned that programmers/debuggers tend to do that where, e.g. during the debugging session, they first appear as a bootloader device to load appropriate firmware, then they switch to programmer mode, only to became a debugger a second later. The trick is to configure the USBoIP solution so it properly captures all of these, i.e. capturing one particular VID/PID could not be enough. You have to either capture the whole USB port, no matter what appears on it, or include all the VID/PID pairs.
Againgly:
This is a really useful solution. Now a large amount of software is simply cluttering up a laptop and it takes a long time to get rid of it.
aandrew:
--- Quote from: Zbig on July 28, 2019, 09:53:23 am ---Are you sure that was caused by USB timeouts and not by the USB device in question re-enumerating as different things in quick succession and the USBoIP solution failing to "grab" each of its subsequent "incarnation" properly? I have learned that programmers/debuggers tend to do that where, e.g. during the debugging session, they first appear as a bootloader device to load appropriate firmware, then they switch to programmer mode, only to became a debugger a second later. The trick is to configure the USBoIP solution so it properly captures all of these, i.e. capturing one particular VID/PID could not be enough. You have to either capture the whole USB port, no matter what appears on it, or include all the VID/PID pairs.
--- End quote ---
Pretty sure; I know of a lot of those types of devices (usually involving an FX2LP). I can't speak for *all* devices but for devices where I had control over the timeouts (i.e. my own USB devices) USBoIP worked reasonably well, which led me to this conclusion.
Navigation
[0] Message Index
[#] Next page
Go to full version