Virtual WiFi on Linux?

[coderman]

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)

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


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

yes, apologies for not making this clear.


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


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


> 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].  GigE
at least is getting cheaper...


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

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.


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

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

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.


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