[Qemu-devel] Qemu + wireless

[Qemu-devel] Qemu + wireless

[S.P.T.Krishnan]

Hi,

This is my first post to this list.

I have been using qemu for the last several versions.  Works great, in
fact I just booted off a Vista beta 2 yesterday from a linux host.

My query is whether Qemu either now or in the near future will support
wireless interface ?

Example: Qemu_VM could be configured to use wireless (in a different
subnet) while the host be on wired interface.

regards,
Krishnan

Re: [Qemu-devel] Qemu + wireless

[Ben Taylor]

---- "S.P.T.Krishnan" <sptkrishnan@gmail.com> wrote: 
> Hi,
> 
> This is my first post to this list.

Welcome.

> I have been using qemu for the last several versions.  Works great, in
> fact I just booted off a Vista beta 2 yesterday from a linux host.
> 
> My query is whether Qemu either now or in the near future will support
> wireless interface ?

In what sense?  I have used qemu with -net user with my hosts' wifi interface.
However, due to the nature of how wifi works, I think it would be impossible
to setup a bridge (like you can do with a wired lan) and use the tap interface
to provide full access to a qemu guest.  One reason is one-to-one mapping between
a wifi interface and it's AP.  

> Example: Qemu_VM could be configured to use wireless (in a different
> subnet) while the host be on wired interface.

I suspect that using a tap interface, and some ipfilt rules, you might be able
to make this work.  Assuming that the host doesn't have anything to do with
that interface, you could write the ipfilt rules to push all the packets to the 
tap interface with a rewrite rule.  However, I can't give you much help beyond
that.  I don't do ipfilt these days.

HTH

Ben
> 
> regards,
> Krishnan
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu + wireless

[S.P.T.Krishnan]

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)

regards,
Krishnan

On 8/4/06, Ben Taylor <sol10x86@cox.net> wrote:
>
> ---- "S.P.T.Krishnan" <sptkrishnan@gmail.com> wrote:
> > Hi,
> >
> > This is my first post to this list.
>
> Welcome.
>
> > I have been using qemu for the last several versions.  Works great, in
> > fact I just booted off a Vista beta 2 yesterday from a linux host.
> >
> > My query is whether Qemu either now or in the near future will support
> > wireless interface ?
>
> In what sense?  I have used qemu with -net user with my hosts' wifi interface.
> However, due to the nature of how wifi works, I think it would be impossible
> to setup a bridge (like you can do with a wired lan) and use the tap interface
> to provide full access to a qemu guest.  One reason is one-to-one mapping between
> a wifi interface and it's AP.
>
> > Example: Qemu_VM could be configured to use wireless (in a different
> > subnet) while the host be on wired interface.
>
> I suspect that using a tap interface, and some ipfilt rules, you might be able
> to make this work.  Assuming that the host doesn't have anything to do with
> that interface, you could write the ipfilt rules to push all the packets to the
> tap interface with a rewrite rule.  However, I can't give you much help beyond
> that.  I don't do ipfilt these days.
>
> HTH
>
> Ben
> >
> > regards,
> > Krishnan
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>

Re: [Qemu-devel] Qemu + wireless

[Ottavio Caruso]

Just guessing, if the device was a usb wireless
adaptor, provided the host os has the right driver
installed, it could be picked up by qemy with the -usb option...(?)

Ottavio Caruso
--

No individual replies, please!

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Qemu-devel] Qemu + wireless

[Shahar]

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