Re: [Qemu-devel] Qemu + wireless

[Shahar <fesh.mail@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3979 bytes --]

>
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 4541 bytes --]