Virtual WiFi on Linux?

[Jim Thompson]

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

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

But you need some protocol to securely communicate "the keys used by  
STA x are..." among the APs.
I suggest looking at things like BIBA (bins and balls).

> [this has its own share of technical difficulties, mainly the inter AP
> protocol and backhaul for managing the scheduling of various virtual
> AP's among a fixed set of radio devices. not to mention extremely
> flexible hardware/driver requirements]

these aren't the problem (they are relatively straight-forward to  
implement, except for the scheduling of transmits,
which is impossible to do over Ethernet frames with low enough  
latency to have any effect.   GigE is potentially
fast enough, but 100BaseT is not).

One (real) problem is "how do you tell a layer 2 network that "this"  
device has the intended MAC address?

Switches do this by recording the port that "this" MAC address last  
used as a STA.

Essentially, to make this work, you have to implement a distributed  
layer-2 switch.  Which is harder than it sounds, but
not impossible.   All the APs need a common protocol to say "I see X  
as a source address on my port <now>", and you
probably want to have an associated TTL with these.

And, the distributed AP needs a protocol to distribute some state  
associated with each STA for which its forwarding.  All the APs
need to know about things like the PS state of any associated  
client.  (And you'll want to be able to move any queued frames.)

Then the problem becomes a straight-forward "distributed database"  
implementation.

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.

jim