Virtual WiFi on Linux?

[Jim Thompson]

On Oct 19, 2005, at 8:55 AM, coderman wrote:

> On 10/19/05, Jim Thompson <jim at netgate.com> wrote:
>
>> ...
>> Please show us how you run more than one radio in 2.4GHz without
>> impacting the noise floor of both.
>>
>
> there is an impact; i did not intend to imply that you could run 8
> radios in the same spectrum.  as you describe, 3-4 radios saturates
> available subcarriers in 2.4.  (i'm using atheros hardware so 4-5
> radios are in 5Ghz while 3-4 are in 2.4Ghz)

*two* radios is one too many in 2.4GHz, unless they're operating co- 
channel.

http://www.netgate.com/zz_faq.php#67

> there are some other tricks like antenna polarization and
> directionality which can be useful for such situations (but you get
> into limited returns here)

those tricks don't work, except in very specialized circumstances.

>> 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.
>>
>
> indeed.  i'm using IPsec between endpoints and there is an equivalent
> gain here.  i'd really like to see someone develop this capability.

There is work to leverage here
http://nms.csail.mit.edu/projects/divert/#related

and other places.

>> 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).
>>
>
> IPsec again, although there are some good advances in group key
> management for more limited devices.

I don't understand how IPsec fits.   You need to securely communicate  
the same set of data (keys)
to a (potentially quite large) group of (potentially untrusted)  
machines over what is essentially a broadcast medium.

BIBA seems like one way to get this done.
http://www.ece.cmu.edu/~adrian/projects/biba/

>> 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).
>>
>
> i'd be interested to know what kind of latency is introduced when a
> virtual AP switches radios.  what about 802.11a for backhaul?  [again,
> it would be nice to have an implementation to experiment with].

You can do the math for synchronizing transmits on an envelope.   Its  
relatively straight-forward
with a solid wire path.  Its much less so trying to do the same thing  
with a protocol over even a
low-latency medium.

> GigE at least is getting cheaper...

Yep.

>> 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.
>>
>
> i've been experimenting with TAP devices to do this sort of thing, but
> i have no idea how well it would work in practice.  with a TAP device
> you essentially place a bridge between a device and the network it is
> on.  this simply offloads the problem to whatever is handling TAP
> device traffic, as it now has to determine where to send a given frame
> according to which radio device is acting as the intended virtual AP.

Projects such as MIT's "Click Router" also make it relatively  
straight-forward to play
with the semantics of the linux IP stack without having to re- 
structure everything.

> as for this coordination, decentralized messaging/control protocols
> are an interest of mine for a while.  i'm hoping a lightweight
> datagram based messaging protocol over IPsec will be fast and flexible
> enough.  as you describe, this is far from trivial but certainly
> doable.

I don't think you're going to be able to meet the latency bounds.    
802.11's MAC
wants any "collision event" to happen within the preamble.   We're  
talking usec here.

>> 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.)
>>
>
> i'm not sure how fine a grain of control over timing and scheduling
> you would need to get something mostly workable.

It all comes down to how a given person wants to define "workable".

All the research and modeling says you either satisfy the 802.11 MAC  
timing requirements,
or you start blowing frames.

Put it this way, many people are convinced that they can run 3 radios  
in the 2.4GHz band (on
the 'non-overlapping' channels 1, 6 and 11.)   They've "seen it  
work", and thats good enough for
them, no matter how many times you show that they've created a huge  
adjacent channel interference problem.

Sending data over a wireless medium is expensive.  There is only "so  
much" of it, and you can't scale it like
you can wired networking technologies by (just) pulling more wire.     
Three parallel Ethernet links in the same
piece of conduit work fine, and you get 3X the bandwidth. You can't  
do that with radio.

I probably have a tighter definition of "it works" than many when it  
comes to 802.11.

> there are some tricks that could be used to help transitions from  
> radio to radio (for
> example, two radios in proximity know that they often transition
> virtual AP's between them: could they listen to each others traffic to
> assist with state handoff?)

One of my ideas here is to have the 'virtual AP' (which only handles  
one STA) use the *STA's* MAC as the BSSID.

(So a set of APs could answer any probe request with a probe response  
from a 'virtual' AP using the BSSID set to that
of the STA.)

I haven't tried this, so I don't know if there is card resident  
firmware out there that will get upset if it gets a frame with FromDS  
set
and its own MAC address in addr2 (and addr3, of course).

If that doesn't work we could always create "link local" addresses,  
potentially by munging the STA's MAC address.

I'm not sure what optimization is to be gained by two APs  
collaborating (.vs having all the APs in a network collaborating).

> could you try and schedule virtual AP transitions at opportune times?
> (between PS states to avoid transferring queued frames, during a DIFS
> timeout, etc)

You'll get more traction if you start considering EDCF (802.11e).

> this reminds me of long shot 802.11b links.  the MAC layer starts
> causing problems when you get to 10+ mile links, but it doesn't melt
> down completely.  it just starts to get inefficient and introduce
> unnecessary timeouts and latencies.

And these result in re-transmits, and we're back to the slippery  
definition of "works" again.

>
>> 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.
>>
>
> i'm looking forward to it!
>
> BTW: is anyone licensing the "Distributed Network Communication System
> which Enables Multiple Network Providers to Use a Common Distributed
> Network Infrastructure" technology you describe in the afore mentioned
> patent?

I don't know.  You'd have to talk to Wayport.  (I was employed there  
when I wrote the patent description).

I think Wayport really wanted someone to implement "virtual APs" so  
they could use it in their service.  (Cisco finally did.  Symbol  
followed,
now "everyone" has it.)  I remember having a lot of trouble  
convincing Cisco and Symbol that they wanted to do this
for reasons entirely unrelated to Wayport's needs.

So, for the most part, I think they've turned a blind eye, even as  
their competitors have implemented similar techniques.