Virtual WiFi on Linux?

[Tom Sharples]

Yes it (multiple radios on 2.4) works, and with very good throughput even 
through multiple hops. We do it all the time. Yes, you do have to be rather 
careful with antenna selection, placement, and gain-staging. Depending on 
the specifics, this may even include judicious use of in-line attenuation to 
reduce the effective receive sensitivity of one or both of the radios. In a 
ptp link the resultant signal loss is easy to make up at the other end.

Having said that, mesh gateways / repeaters equipped with 2.4 and 5.8 work 
better than multiple 2.4 radios in the same box, but there are times (for 
example when extending an existing 2.4 mesh cloud) when 5.8 is just not 
necessary or cost-effective.

Tom Sharples
President
Qorvus Systems, Inc.
www.qorvus.net
360.243.7371

----- Original Message ----- 
From: "coderman" <coderman at gmail.com>
To: "Jim Thompson" <jim at netgate.com>
Cc: <hostap at shmoo.com>
Sent: Wednesday, October 19, 2005 1:56 PM
Subject: Re: Virtual WiFi on Linux?


> 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*
> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap