[Hackrf-dev] HackRF in a Virtualized Environment (Windows7>VmWare>Pentoo\Kali\Ubuntu)

Thu Sep 4 10:21:28 EDT 2014

I responded, but you likely have to scroll down to see that ;-)

On 09/04/2014 05:35 AM, Sohil Shah wrote:
> Background:
> 
> I received my HackRF this Tuesday and tried running it under Pentoo, Kali
> and Windows. It did not work on either. I installed the latest Zadiag
> drivers on Windows and got the latest version of SDR#. As far as Kali and
> Pentoo go I followed the guide online except that I was running it from
> within a VM using VmWare. I have not dared to update my firmware. I will
> wait till Zero releases the Pentoo build with all the necessary tools and
> Mike posts his lesson on firmware flashing.

I hope this will be soon, I'm working on it feverishly.
> 
> My question today is has anyone tried using the HackRF in a Virtualized
> environment [Windows7>VmWare_WorkStation10>Pentoo/Kali/Ubuntu]

Yes, all of us have.
> 
> I am aware of there being limits over USB in a virtualized environment, but
> for a lot of reasons I would like to use the HackRF on my Windows box using
> VmWare Workstation 10 as the  virtualized environment on either Kali/Ubuntu
> or Pentoo (Zero’s latest build when its released).
> 
Yes, everyone wants that.
> 
> 
> I can understand that there may be a lot of people who will say, use it on
> bare metal and that is fine, but I really want to see if it is possible to
> use the HackRF in a virtualized environment. I have used the RTLSDR in a
> virtualized environment for over a year now and it seems to be doing just
> fine with a lot of applications. I am not sure what the limitations of
> using the HackRF in a virtualized environment are. I do not intend to use
> it at its maximum sample rate as I am sure a lot of applications don’t
> require that high a samp_rate, E.G everything running on the RTLSDR is
> running at under 3.2MSPS.
> 
Unfortunately, the rtlsdr doesn't even require the data rates of a basic
wifi card, let alone what the hackrf needs. This is like comparing a
Ferrari to a Pinto (both cars, but one of them isn't very fast).
> 
> 
> My crude understanding is that more the MSPS more the I/O demand or
> bandwidth required on the USB bus and the driver that shuttles the samples
> between Windows through VMware to the Virtual Machine. I don’t know what
> the max_limit for such a setup is in terms of MSPS but I’d like to know if
> someone has been able to do a calculation of the amount of lost USB packets
> when going from 0MSPS to 22MSPS in a virtualized environment or if someone
> is willing to give me an idea as to how one would go about doing that as I
> am not sure if there is any existing way to calculate that. My goal is to
> figure out an ideal MSPS at which the HackRF is ideally useable in a
> Virtaul Machine running on Windows7 inside VmWare Workstation 10. As far as
> hardware goes I have the Lenovo ThinkPad T430 (Intel Chipset) which based
> on what I have read is one of the good performers on the hardware side,
> hence any losses or limitations would really be a software/virtualization
> issue as opposed to a hardware issue.
> 
There are a lot of problems here.  Your crude understanding is most
accurate, however, you miss a few things.  It's not *just* the data rate
and the I/O demand it puts on the USB bus, it's also the fact that
sometimes usb passthrough just plain does things wrong.  For example,
some linux distros, Kali for example, had to patch rfkill support out of
the rtl8187 wifi driver because when using this wifi card through vmware
it somehow managed to force the gpio pin for rfkill to alway read off.
How that is even possible I don't know, but the reality is that vm
passthrough is definitely doing more than just passing things through.

Additionally, it's putting twice the load on the computer than is
intending for usb, so even if the usb bus is flawless, and the cpu is
great, doubling the load will have an effect.  VM passthrough is reading
the usb port in software, then transfering it into the vm, then
outputting it to the virtual machine.  This will take more than twice
the cpu of a standard usb transaction, add in the fact that your cpu now
needs run the host and guest machines as well, and you are running out
of cpu much much faster.

Lastly, you say "Intel Chipset" like that means anything worthwhile, it
doesn't.  Intel makes (or at least brands) hundreds of chips, from wifi,
to video, to processors, and all kinds of things.  The fact that the usb
chip has an intel brand on it is completely useless information, and
actual model number may be more useful, but not necessarily.  No one
else can tell you at what point things will break for you, or even why.
 Dozens of odd things have happened over vm passthrough that I still
can't explain why, or even why some of my fixes worked.  For instance on
newer macs, vm passthrough seems nearly worthless on a usb3 port, but
adding a usb2 hub (physically) makes things work fairly well (sometimes,
depends on if Fortuna is in a good mood).

tl;dr, nothing anyone else tests, confirms, or "proves" may actually
work for you.  You may find that on your hardware sample rate XMSps
works great, but someone else with the same laptop model it doesn't.  Or
it might work great and then you go to write the firmware and it fails
and no one can figure out why.  If it was up to me, I'd put a check in
the software for virtualization and just abort if running in a guest, I
doubt many would agree with me, but I'd rather not have to field the
constant stream of errors which are near impossible to troubleshoot, and
typically impossible to fix.  Lot of us recommend not using a VM, we do
this because of experience, you can learn from us, or be doomed to
repeat the failures that gave us the experience we now share.
> 
> If someone still can’t wrap their head around the fact that why I would
> want to use Virtualization let me explain.
> 
> 1)    1)  I only have one computer (laptop).
This isn't really a problem since you can dual boot or just boot from a usb.

> 
> 2)     2) I really need to have windows installed on it and can’t have dual
> boot on it with any Linux flavor.
Why can't you dual boot? You would spend less time fixing this than
fixing vmware, I promise.

> 
> 3)     3) This limits me to using a live CD/USB
Liveusb distros like Pentoo and Kali support changes saving partitions
so you can save all of your changes.  You can even to a full install to
a usb stick and it's basically like having linux on a removable hard drive.

> 
> 4)     4) I would like to watch Mike’s videos and refer to online guides
> while doing the exercises in GRC.
Me too.
> 
> 5)    5)  All Live CD’s may not have all the required tools, codecs etc. to
> watch video files and or video content online. (I know this is a lame
> argument but there are certain limitations and not everything will run
> straight out of the box on all platforms, plus it adds noise on the link in
> the next point)
So find one that does, or install the needed codecs, this is again, MUCH
easier than dealing with the failures of vm.

> 
> 6)    6)  Coming to the most important point. I want to simulate an
> environment where I have one host (think drone or remote computer) to which
> the HackRF is physically connected and another host that is actually
> commanding and getting responses from the first host. All Signal processing
> etc. is happening on the drone/remote machine. Only basic periodic updates
> (command and control) are being transmitted between the two hosts. To
> simulate this I need to use virtualization on my laptop.
> 
You are in NO way simulating that.  What you are simulating is running
in a setup that pretty much everyone seems to suggest will get you
nothing but problems.  Running the hackrf on one host and dsp on another
is NOT simulated by usb passthrough (as you cannot do that with two
physical systems at all), you want perhaps hackrf_tcp (which is still a
work in progress that excites me greatly).
> 
> 
> If you had the patience to get so far in my post, I thank you. I would
> really appreciate if someone can shed some light on running the HackRF in a
> virtualized environment, maybe Mike can do a follow up to the Mysteries
> Video to see what kind of anomalies we see while using the HackRF in a
> virtual environment as opposed to running on bare metal. I am sure others
> may also have specific needs to run the HackRF in a virtualized
> environment. If not for anything else just to be able to say it’s not
> impossible is the simple motivation for my quest.

This is the max time I've wasted on virtualization in a while, and
hopefully from now on I can just point to this response instead of
typing it again.  I thank you for hilighting so many points so that I
could publicly shoot them all down at once and have a great place to
point people in the future.

Don't run in a virtual environment, I'm not saying this because I
shorted vmware's stock, I'm saying this because it's been years of
experience showing me all the failures that seem to get worse, not
better, with time.

Thanks,
Zero_Chaos
> 
> 
> 
> Thank you for your time.
> 
> 
> 
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> http://nine.pairlist.net/mailman/listinfo/hackrf-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://nine.pairlist.net/pipermail/hackrf-dev/attachments/20140904/230f8aba/attachment-0001.pgp>