Virtual WiFi on Linux?

[Jean Tourrilhes]

On Wed, Oct 19, 2005 at 08:05:41AM -1000, Jim Thompson wrote:
> 
> 
> On Oct 19, 2005, at 7:23 AM, Jouni Malinen wrote:
> 
> >On Wed, Oct 19, 2005 at 09:37:08AM -0700, Ben Greear wrote:
> >
> >
> >>If someone could implement the ability to make one WiFi NIC appear to
> >>be multiple NICs, even if connected to the same AP, it would be  
> >>something
> >>that my company is interested in sponsoring.
> >>
> >>The requirements would be something like:
> >>
> >>* Each virtual interface is a real net-device with it's own IP,  
> >>MAC and (potentially) WiFi settings.
> >>* To the AP, it appears as if N laptops/PCs are connected to it  
> >>sending & receiving pkts.
> >>
> >
> >The IEEE 802.11 stack released by Devicescape couple of weeks ago  
> >under
> >GPLv2 (see netdev mailing list for some discussion) supports this kind
> >of functionality.
> 
> 
> At the risk of igniting a flame war here, I'm gonna jump in:

	Up to now, the discussion was pretty civil. There is no need
to degenerate into a flame war, unless you want to. I am personally
shocked by the tone of your response which was uncalled.
	Do I need to remind you that this mailing list is graciously
provided to us by Jouni, and that there are plenty of other good
mailing lists if you don't like this one or the people on this one.

> First, its great to see "virtual AP" implementations start to show up  
> on the scene.
> 
> Especially since I developed the idea in 1999.  See, for example US  
> patent 6,732,176.
> 
> Now, thats not a patent threat, so don't get all wonky on me.   I  
> just like to be able to prove
> that I really did think of this back in '99.

	I think the tone of my response was along those lines, saying
that the idea was not new. I think nobody in this thread claimed to
have invented it, we were just discussing how it could work and
potential uses.

> And I think its great that Jouni continues to get things released  
> under GPL that advance the state of the art
> in linux and 802.11.

	I do too.

> But the public is only getting 1/2 the story.

	Or maybe you are only reading half of the e-mail :
Jean Tourrilhes wrote:
> Obviously, if you
> want the performance to not suck, you need fast AP switching
> (currently available only with HostAP, doable with any card using the
> kernel ieee stack).

> >In other words, you can create multiple virtual
> >netdevs and have each one act as a separate client. Since each clients
> >shows up as a netdev in the kernel, you can do whatever you want with
> >them, i.e., own IP address and all other protocols supported by Linux
> >should work fine. However, sending IP packets between different IP
> >addresses of the same host is going to require some kernel patching.
> 
> But in a BSS there is no communication between associated STAs  
> without going
> through the AP.  (Yes, I understand that the linux IP stack is going  
> to make assumptions
> because the intended destination IP address is "on this machine".)

	The IP routing of Linux is quite clever at shortcutting, I
don't see the issue.

> >Since this is using multiple MAC addresses over air, one will of  
> >course
> >have to use hardware that actually supports this.
> 
> Wonderful.  When will Devicescape be releasing the lower layers (as  
> GPLv2 source code)
> in order to show a working system?

	Everybody is free to contribute, so why not you ?
	Note that the support for multiple MAC addresses is only
required for *some* applications, some of the other applications we
have been discussing don't require this. You only need multiple MAC
addresses if your virtual IBSS are in the same subnet.

> Or the specialized firmware required to drive a Prism-based card in  
> this mode?

	Well, maybe you should start talking with our friends at
Conexant, they have been very supportive lately.

> There is code (on the way from Atheros, implemented in madwifi) that  
> *will* fully implement this (on Atheros chipsets).
> 
> You'd still need the specialized (Neesus) prism firmware in order to  
> make it run on a Prism based card of course.
> 
> But ports of 'virtualized 802.11' function to other cards which don't  
> require firmware changes to be able to deal with
> multiple MAC addresses should be straight-forward.  Perhaps Ralink  
> will be supported soon, or perhaps Intel will see
> fit to change the Centrino (or its replacement) firmware in order to  
> properly implement 'virtualized 802.11' functionality.

	Support for multiple MAC addresses is not required to make
this feature useful. Maybe *you* need it, but that's another story.

> Why are only half the facts being talked about here?

	They are not.

> Why did Devicescape choose to release this code now?

	Everybody can guess. But, better late than never. But,
personally the question on my mind is what are your motive with such
an inflamatory e-mail.

> >The current implementation does not support
> >multiple channels (i.e., you need to have one radio for each channel),
> >but if someone had real use for being able to talk with one radio to
> >multiple APs on different channels, some kind of more intellegent
> >channel hopping with power save use could be implemented.
> 
> Right, the key here is that you have to tell the AP you're going into  
> PS mode, (so it queues frames for you),
> then switch channels, getting back to 'this' channel before the PS  
> period you've announced expires.

	Yep, it's messy, but not rocket science. This is exactly what
has been proposed for years in BlueTooth to implement ScatterNets.

	Have fun...

	Jean