Virtual WiFi on Linux?

[Jim Thompson]

On Oct 19, 2005, at 8:44 AM, Jean Tourrilhes wrote:

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

I'm blunt.

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

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

the people who maintain linux seem to have chosen the 'hostap' stack,  
and this is fine.

They're free to do so.

I think they made a mistake, but Free Software means that I can put  
the madwifi 802.11 stack back in.

fastAP switching can work with other drivers (such as madwifi) too.

The Devicescape code uses the Atheros "vxworks" style HAL and a stub  
driver.   There is essentially ZERO
chance that Devicescape will be able to "open source" the rest of the  
solution for Atheros chipsets.

The Devicescape code uses proprietary firmware (from Neesus) in  
Prism2/2.5 chipsets in order to implement mBSSID.
There is essentially ZERO chance that Devicescape will be able to  
release this code, too.

Does Devicescape have plans to implement support for another chipset  
and release that?

Or did we get a gift of code that will be very difficult to use in a  
real-world situation?

Perhaps Devicescape hopes that someone will make their released VAP  
code work over the madwifi HAL, but this is
essentially duplication of effort, since madwifi has it already (tho  
its not released).

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

If I have IP addresses A, B and C on interfaces a, b and c, and I  
'ping' any of them, will the packet leave the box?

Now, if I have IP addresses A, B and C on three 'virtual netdevs' (a,  
b and c) and each of these is in a separate BSS, the *proper*
behavior is that if I ping 'A' that the packet first goes out over  
the wireless media to the AP where 'a' is associated.


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

See above.

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

Perhaps true for IBSS (aka adhoc) modes of operation.  I haven't  
thought about it much in terms of IBSS operation.

Not true for BSS (cells with an AP) modes of operation.

In 802.11 ADDR1 is always used as the discriminate on receive.

If 'ToDS' is set, then ADDR1 is the BSSID, and the packet is flying  
toward the AP.   All APs with that BSSID will potentially forward that
frame to the intended DA.

is If 'FromDS' is set then ADDR1 is the DA, and the packet came from  
somewhere behind (or beyond) the AP (potentially
another associated STA).

If the DA is a "group address" (essentially a broadcast or multicast  
packet), then the only way for the STA to determine if *this* frame  
should be forwarded up the stack is to look at the BSSID in the  
frame, and determine if its currently associated to an AP with the  
same BSSID.

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

Devicescape certainly has the contacts at Conexant.    We don't even  
know if the contract between Intersil (now Conexant) and Neesus
allows Conexant to duplicate the functionality.

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

see above.

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

Because I'm an *sshole.   Go ahead and say it.

But my opinion remains that Devicescape released code early to  
prevent being "one upped".

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