Unable to enumerate product, serial, and manufacturer when connected to VMWare VM

[ghostop14]

When connecting the airspy to a virtual machine, the OS cannot enumerate the manufacturer, product, and serial # preventing device from being recognized. I've tested the hackrf on hardware with Windows, on a kali laptop and it works fine, however connecting it to a kali vm (same versions as the hardware version), those parameters come up with an error preventing the OS from recognizing it. It is recognized in an lsusb and lsb -v.

I know folks are going to go on about not running these in VMs but the mix of hardware and OS's I have (the kali laptop doesn't have the horsepower for gnuradio but the Windows laptop is very capable). I've run the hackrf and rtl dongles plugged into a virtual USB 3.0 VM interface and it works fine.

Any help would be appreciated!

[bvernoux]

There is no any problem with USB 3.0 + VirtualBox (5.1.10) + Xubuntu 16.04.01 LTS
You just need to think to blacklist airspy kernel driver see
https://github.com/airspy/host/wiki/Troubleshooting#linux-debianubuntu

Example streaming with VirtualBox (5.1.10) + Xubuntu 16.04.01 LTS + CoreI7-3630QM @2.4GHz
10MSPS results:
airspy_rx -r /dev/null -t 0 -a 10000000
Streaming at 9.752 MSPS
Streaming at 9.491 MSPS
Streaming at 9.395 MSPS
Streaming at 9.321 MSPS
Streaming at 9.267 MSPS
Streaming at 9.259 MSPS
...

6MSPS results:
airspy_rx -r /dev/null -t 0 -a 6000000
Streaming at 5.997 MSPS
Streaming at 5.988 MSPS
Streaming at 5.986 MSPS
Streaming at 5.982 MSPS
Streaming at 5.982 MSPS
Streaming at 5.980 MSPS
Streaming at 5.980 MSPS
...

2.5MSPS results:
airspy_rx -r /dev/null -t 0 -a 2500000
Streaming at 2.500 MSPS
Streaming at 2.498 MSPS
Streaming at 2.497 MSPS
Streaming at 2.495 MSPS
Streaming at 2.495 MSPS
Streaming at 2.494 MSPS
Streaming at 2.494 MSPS
Streaming at 2.493 MSPS
Streaming at 2.493 MSPS
...

For information the streaming on those sample rate is perfect on a native Linux or native Windows ...

If you have any issue please add more information on setup hardware/software and exact error with command used ...

[ghostop14]

Thanks for responding Ben.

It is weird. HackRF and RTL-SDR pass through to the VM fine. Here's a little more info....

VM is running on VMWare
Running Kali Rolling fully updated
pulled down airspy from github and built it
New Airspy R2 (just came in last week)
Works fine directly under Windows and on the same kali setup on physical hardware.

Here's some debug/version info:
uname -a
Linux kalivm 4.8.0-kali1-amd64 #1 SMP Debian 4.8.5-1kali1 (2016-11-04) x86_64 GNU/Linux
airspy_lib_version
AirSpy lib version: 1.0.9

I can run the windows build of airspy_info from the host OS. Here's the info back:
airspy_info
airspy_lib_version: 1.0.9

Found AirSpy board 1
Board ID Number: 0 (AIRSPY)
Firmware Version: AirSpy NOS v1.0.0-rc10-0-g946184a 2016-09-19
Part ID Number: 0x6906002B 0x00000030
Serial Number: 0x573064DC313227C1
Supported sample rates:
10.000000 MSPS
2.500000 MSPS
Close board 1

I know it seems weird but I have an app I'm trying to use that is using a gnuradio with a TCP sink. Works fine in linux but running gnuradio on Windows immediately crashes. The laptop I have Linux on doesn't have the horsepower to run gnuradio but the Windows box does. So I'm trying to bridge the gap somehow.

The answer may be get a new laptop to run linux on but I figured I'd see if I can get the airspy working in a VM first.

[ghostop14]

One more piece of info... running lsusb it shows up in the list, but an lsusb -v shows errors in those 3 fields... again only in the VM.

[bvernoux]

1. Do you have blacklisted the kernel mod airspy ?
2. Could you try on Virtual Box 5.1.10 ?
3. Do you have some information on the hardware used ? (CPU, USB chipset ...)

[ghostop14]

I do have it blacklisted. The OS installed on the hardware on this box is Windows 7. It's a Dell Precision M4700, i7 CPU, intel chipset I believe for the controllers.

I don't have VirtualBox installed. I'd have to build out a fresh VM with it. I do wonder if the VMWare USB throughput may work okay with the SDRs? I've done some other gnuradio grcs in the VM and sound, etc. seems to work okay.

Just some benchmarks, here was the VM passing through the hackrf, so the throughput looks good (which makes me hopeful the VM performance wouldn't be terrible if the airspy was visible. What do you think?
hackrf_transfer -r /dev/null -a 0 -f 1691MHz -s 10000000
call hackrf_sample_rate_set(10000000 Hz/10.000 MHz)
call hackrf_baseband_filter_bandwidth_set(9000000 Hz/9.000 MHz)
call hackrf_set_freq(1691 Hz/0.002 MHz)
call hackrf_set_amp_enable(0)
Stop with Ctrl-C
19.9 MiB / 1.001 sec = 19.9 MiB/second
19.9 MiB / 1.001 sec = 19.9 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.001 sec = 19.9 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.001 sec = 19.9 MiB/second
19.9 MiB / 1.001 sec = 19.9 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.001 sec = 19.9 MiB/second
19.9 MiB / 1.000 sec = 19.9 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.001 sec = 19.9 MiB/second
19.9 MiB / 1.001 sec = 19.9 MiB/second
20.2 MiB / 1.000 sec = 20.2 MiB/second

[ghostop14]

Quick update... decided to test if it was in ANY VM of just the Kali VM so I tested it in a Windows 10 VM (still a VMWare VM) and it was detected fine. So it seems like the problem is something related to the latest Kali Rolling linux in a VM? May be reproducible that way.

[bvernoux]

I'm pretty sure it is related to blacklisting the airspy kernel driver which is not blacklisted correctly
Could you share this VM (compressed with 7Zip ultra) for test ? (if possible a minimal version)

[ghostop14]

Okay, I ran a few more tests. Downloaded the latest gnuradio liveCD and booted the VM with the CD. airspy_info did the same thing. I found a VMWare KB article talking about issues (https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=774) and some "USB Quirk" workarounds for some devices. Of course it was the last one I tried.

I'm trying to redownload the latest kali VM image from their site to confirm it's in there too but it's reproducible. VMWare Player installation. Latest Kali Linux VM. Followed airspy troubleshooting for blacklisting (I did also confirm lsmod | grep airspy and the blacklist did work, it's not loaded). Downloaded and built latest github code. If you add this line to the VMWare config file airspy_info can now find the device. Wanna run some tests with gnuradio to make sure it works there too. But same functionality with the gnuradio liveCD.

usb.quirks.device0 = "0x1d50:0x60a1 skip-setconfig"

So something about whatever setconfig does in a VM that's hanging the device.

You'll know right away after connecting the USB device to the VM. If you run "lsusb -v" and get this in the results, it's the error:
iManufacturer 1 (error)
iProduct 2 (error)
iSerial 3 (error)

Once I added the quirk line, those lines came back as:
iManufacturer 1 www.airspy.com
iProduct 2 AIRSPY
iSerial 3 AIRSPY SN:<my serial #>

and airspy_info worked. Hope that helps reproduce it and track it down!

[ghostop14]

Just confirmed, stock Kali VM image download with the same scenario produces the same results. Without the line, doesn't work, with the line does. One other interesting thing is that once it does error, returning it to the host OS produces a USB error, as if whatever that setconfig is doing is causing an issue on the device. Disconnecting and reconnecting the device fixes that.

[ghostop14]

Hi Ben,

Were you able to reproduce the issue as well?

I also had one other question... the airspy web site says "up to 80 Msps with custom firmware". How's performance above 10 Msps and where does it drop off? If it was kept to have that, say 20 Msps and 40 Msps as options is it relatively stable? Is it just a matter of adding the sample rates as options in airspy.c in this code (changing the count and adding the additional entries)?

	lib_device->supported_samplerate_count = 2;
	lib_device->supported_samplerates = (uint32_t *) malloc(lib_device->supported_samplerate_count * sizeof(uint32_t));
	lib_device->supported_samplerates[0] = 10000000;
	lib_device->supported_samplerates[1] = 2500000;

[bvernoux]

About sampling rate it is not possible to use airspy with USB 2.0 HS at more than 20MSPS because of USB 2.0 HS bandwidth (limited to less than 400Mbit/s even if in theory it is 480Mbit/s) as it requires 40MB/s so 320Mbit/s at 20MSPS (as each sample are stored as 16bits data per default or 12bits when using packing)
The only way to go up to 80MSPS is with a custom firmware using internal SRAM to store samples and retrieve them later a bit like an oscilloscope ...
In order to fully use 80MSPS the use of airspy SGPIO extension is mandatory to output the samples at up to 80MSPS ... but that requires hardware like FPGA connected to extension to retrieve those samples in real-time and do something with them ...

[ghostop14]

Makes complete sense. Thanks!

Has there been any talk about moving it to a USB 3.0 connection to push the throughput up? Or are the ADC's the limiting factor?

[bvernoux]

To add USB 3.0 is an other story and clearly not the same type of product ...
The limiting factor will be ADC, Tuner ... to use the full USB 3.0 bandwidth and it will also requires a very fast PC to do something with all those data in real-time so it is clearly an other type of product with other use case.

[labomb]

I'm a bit late to this discussion, but I wanted to confirm that adding the line "usb.quirks.device0 = "0x1d50:0x60a1 skip-setconfig" to my Ubuntu 14.04.5 LTS virtual machine configuration file got my airspy to work under VMWare Workstation 9 as well. It wouldn't work without it, works fine with it.

Appreciate your due diligence ghostop14!

[bvernoux]

Yes you should try with usb.quirks.device0 = "0x1d50:0x60a1 skip-setconfig"

[bvernoux]

Thanks to confirm if that solve your issue
I have added those information in https://github.com/airspy/host/wiki/Troubleshooting#vmware-linux

[shicks8471]

Adding the line usb.quirks.device0 = "0x1d50:0x60a1 skip-setconfig" to my config fixed the problem with the VM.

Thanks!!