Virtual WiFi on Linux?

[coderman]

On 10/19/05, Jim Thompson <jim at netgate.com> wrote:
> ...
> *two* radios is one too many in 2.4GHz, unless they're operating co-
> channel.
>
> http://www.netgate.com/zz_faq.php#67

this is an instance where theory diverges from practice apparently.  i
can show you a 4 radio node on channels 1, 4, 7, 11 that supports
decent throughput, all cards in the same enclosure.  multi-radio is
getting especially popular in mesh networking hardware.

is there interference?  absolutely.  does it cause massive throughput
degredation? nope.

(this is really a complex discussion of shielding, channel allocation,
antenna and connector design, etc, etc.  the short answer is that you
can absolutely use multiple radios effectively)

this does bring up an interesting point: exactly what is the real
world effect?  i'd like to see a benchmark showing how additional
radios on non overlapping channels affect throughput between them. 
are you aware of such a study?  i may try something with a crude multi
radio setup this weekend if nothing is forthcoming.

as a side note, another instance where theory diverges from practice
is the use of amplifiers for recv gain.  in theory this gains you
nothing because the amp will increase noise along with signal.  in
practice most radios are more adept at distinguising signal from noise
when the power of the signal is higher.  when operating in monitor
mode i notice a 20-30% increase in intelligible packets using an amp
for recv (and this is not a cable loss issue - the amp is on the end
of a pigtail)

long distance timing issues a third example; in theory the 802.11 MAC
SIFS would make this impossible.  in practice the MAC is never
implemented so rigidly...

any additional real world details you have on this would be
appreciated; the other links you posted were informative.


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

correct; i was referencing a different concept (security between hosts
which contain radios where you have dedicated backhaul between them).

BIBA would work nicely, and other group key management and key
predistribution schemes could also be used.


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

the click and roofnet projects are indeed relevant and interesting. 
the main reason i am looking at TAP devices is that they fit nicely
with netfilter and ip qos.  if you want you can even push further into
kernel space (via click without userspace driver perhaps) to do this
kind of mungification quickly although you lose some of the
flexibility with other networking infrastructure in the kernel and
userspace if you do so.


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

right. like you mention, some of the existing WLAN switching systems
keep all control and low latency timing functions at the dumb radio
endpoint.  anything dealing with SIFS time periods and preambles would
probably enforce this requirement.

i think the other tasks, like WLAN switching, could fit the latency
bounds acceptably.  this complicates scheduling because you have to
work around inflexible operations using short timing at a given radio.
 how complicated this would be i can only speculate...


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

i fully agree.  i guess what i am getting at is that i'd like to
experiement with these systems so the impact can be quantified in a
real world environment rather than speculated upon based on theory and
conventional wisdom.


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

what ever happened to UWB / Multi OFDM Alliance?  they were supposed
to fix this problem for us.  ;)


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

yes.  my definition of "it works" is clearly more hackish and
inefficient.  i think such a view still has value as long you are up
front about limitations.  i will readily admit that multi-radio is
"dirty" from an ideal spectrum model, but that doesn't mean it is not
useful.  (we may disagree there too though.)


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

i'll have to try this now;  i know that when a client forges it's MAC
as the BSSID / AP MAC many AP's completely freak out.  one model which
i can't recall even went into a reset loop, apparently thinking
something had gone seriously wrong internally.


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

this was what i had in mind; a secure digest or other hash function
could munge a local address based on STA MAC accordingly with little
chance of collision/dupes among a given set of clients.


> I don't know.  You'd have to talk to Wayport.  (I was employed there
> when I wrote the patent description).
> ...
> So, for the most part, I think they've turned a blind eye, even as
> their competitors have implemented similar techniques.

this is encouraging at least.  i suppose there is no need to be
concerned until patent infringement suits start flying at cisco and
crew. *grin*