Virtual WiFi on Linux?
Jim Thompson
jim
Wed Oct 19 11:05:41 PDT 2005
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:
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.
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.
But the public is only getting 1/2 the story.
> 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".)
> 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?
Or the specialized firmware required to drive a Prism-based card in
this mode?
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.
Why are only half the facts being talked about here?
Why did Devicescape choose to release this code now?
>> My goal is to use this for testing purposes to do AP loading and
>> such.
>>
>
> This is indeed one of the main uses for this feature (though not the
> only one). I've emulated more than 2000 stations with one Atheros
> radio
> with this implementation.
Let me guess, the size of the AID space?
> Another use is to do this virtual Wi-Fi thing properly ;-), i.e.,
> without triggering re-association and jumping between APs or being
> limited to plaintext mode.
I ask you to 'show us', and release the rest of the code.
> 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.
More information about the Hostap
mailing list