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@greatscottgadgets.com > http://nine.pairlist.net/mailman/listinfo/hackrf-dev >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ HackRF-dev mailing list HackRF-dev@greatscottgadgets.com http://nine.pairlist.net/mailman/listinfo/hackrf-dev
