Virtual WiFi on Linux?

[Jim Thompson]

On Oct 19, 2005, at 9:00 AM, Jean Tourrilhes wrote:

> On Wed, Oct 19, 2005 at 08:24:04AM -1000, Jim Thompson wrote:
>
>>
>> On Oct 19, 2005, at 7:35 AM, coderman wrote:
>>
>>
>>> On 10/19/05, Jean Tourrilhes <jt at hpl.hp.com> wrote:
>>>
>>>
>>>> ... Basically, you connect to multiple network at once. Of
>>>> course, because you have only a single transmitter/receiver in your
>>>> hardware, what you really do is time slotted hopping, you
>>>> periodically
>>>> hop between each AP.
>>>>
>>>>
>>>
>>> with multiple radios this becomes more efficient/effective.  MIMO  
>>> plus
>>> multiple devices for example. (I've used as many as 8 mini-PCI  
>>> radios
>>> on a single host and you could probably double this if you tried  
>>> hard
>>> enough.)
>>>
>>
>> Great.
>>
>> Please show us how you run more than one radio in 2.4GHz without
>> impacting the noise floor of both.
>>
>> Without co-ordination, this doesn't work.
>>
>> (I've been through this discuss so many times that I wince every time
>> it comes up now.)
>>
>
>     Performance is not everything. Sometime, you want more
> flexibility. I can see scenario where I would be willing to trade
> performance for the flexibility given by this scheme. I can see
> scenario where I would even be willing to use the AP scheduling
> described above, which in term of performance is really a drag.

I think you don't understand the issues at the PHY layer.

>
>>> one of my favorite ideas for AP virtualization is client mobility:
>>> instead of worrying about association/authentication hand off  
>>> between
>>> distinct AP's as a client moves, make each client a supplicant of
>>> their own virtual AP that moves from radio to radio as they move; to
>>> them it would appear to be a single AP with an incredibly pervasive
>>> signal :)
>>>
>>
>> This wasn't a big deal until WPA/WPA2 showed up. If the STA knows
>> its still part of the same BSS, then
>> there isn't much reason to re-run things like DHCP.   With WPA, being
>> able to 'virtualize' the AP across a set of APs means that
>> you don't have to get all that encryption state going again, and
>> thats a major bonus.
>>
>
>     Correct.
>     And personally, I believe there may be other way to deal with
> this particular problem that may be simpler. Usually, fixing things in
> the infrastructure ends up being more efficient. The APs can easily
> share security info without having to create a distributed AP. It's a
> shame that IAPP got shot down.

Right, there are all kinds of "pre-caching" proposals in and around  
802.11i.

But virtualizing the AP eliminates the need somewhat.

Its just different views of the same problem.

>
>> But ... given that there is code released soon that *can* serve as a
>> basis for this kind of technology, the "WiFi switch" vendors
>> had better watch out.  :-)   (they typically simplify the problem by
>> having most of the 802.11 stack run in a central controller,
>> and use Ethernet to extend all but 802.11's "control frames" back to
>> this central (virtual) AP.
>>
>
>     Maybe, maybe not. There are many legacy 802.11 clients that
> you want to support, especially with 802.11 going into embedded
> systems, which are usually difficult to upgrade.

If you're an 802.11 technology vendor, you have to support *all* of  
the legacy 802.11 clients.

> Entreprise have to update their 802.11 infra every few years just  
> to keep up with the
> array of new features the vendors throw in, removing the need for a
> single feature won't make that much difference.

I don't see where this follows.

Jim