qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Qemu + wireless


From: Shahar
Subject: Re: [Qemu-devel] Qemu + wireless
Date: Sun, 18 Mar 2007 11:51:38 +0200

S . P . T . Krishnan
Sat, 05 Aug 2006 02:27:17 -0700

Hi Ben,

Thanks for your insightful reply.
Allow me to re-phrase my question. Hope you can comment further.

Basically, we have a need to run a application that needs a wifi
interface in a virtual machine. You can think of the application as
this command "iwlist eth1 scan". What this does is that it scans the
airspace and lists all the networks(essid) it detects. Now if I want
to run this command in a VM, the VM should see a wifi interface.
This is my query. The virtual wifi interface must support the
upward/downward movement of layer2 wifi frames.

Can we have a wifi interface in a VM that can support queries like the above ?
There is a physical wifi device at the host. I am thinking that just
as Qemu links the virtual device to the actual nic card in the host,
can it links the virtual wifi device to the actual wifi device ?
(assuming the new functionaly is developed)

Krishnan  & Ben,

As Krishnan already described, there are two not fully related issues here:

1. Virtual guest side wireless device that supports standard wireless tool and utilities.
2. Wireless backend - meaning connecting the virtual device to a wired/wireless host side device.

The first issue should be relatively straight forward (even thought it requires substantial efforts)- you have to add a virtual wireless device to the QEMU hardware model. Once properly done, linux/windows (etc.) wireless infrastructure can be used to manipulate it. Theoretically, if you have a wireless USB device you may use the QEMU USB infrastructure to gateway the device. My own experience with the USB functionally is not the best. In most cases I failed to operate USB devices that are not trivial. I suspect that there are bunch of issues there, from timing and to multi-function support, USB2.0 support, etc.. But, hey you may have better luck than I do...

The second issue is less trivial that it may seem at first glance, at least if the backend device is a real wireless device (and not a wired one). The main problem is that some (all?) wireless HW implementations insist to use the physical MAC on transmits (In fact, I understand that the spec requires it, but this was not implemented for a while). This makes things a bit more complicated - you somehow have to generate proper MAC addresses. It can be done by forcing the guest side to use the proper mac, but in that case it will be hard to share that wireless device with other clients. If you require sharing, you will have to do some sort of NATing. It may be layer 3 NATing, or (preferably) layer 2 NATing. IMHO layer 2 solution is better because the host's IP stack is not used. Layer 3 approach requires NAT and routing. Note that in any case you may have to relay/proxy DHCP/ARP.
In fact, wireless device sharing is even more problematic in the general case. Until now I assumed that all local clients want to use the same access point, with the same settings (SSID, key). If this is not the case, the only solution I see is to use WDS (which is supported to some extent by the modern station and access point devices, but I am not sure how compliant it is across vendors). Even then, it may be required to use the local wireless HW as access point and not as station.

On the other hand, if the backend device is wired Ethernet, then it seems straight forward to implement a solution for it. In fact, if the TAP interface is kept from the QEMU's side, it is trivial to setup a bridge and connect both the backend Ethernet device and the TAP to it.

If you are interested doing something in this area, I would be glad to help. In fact I would like to widen the discussion and include also Cellular modems it it (a completely different device, I admit). In particular I would like to know what people thinks about the backend/front end issues, and what are the best general solutions in both cases.

Shahar

regards,
Krishnan

 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]