hostapd + channel bonding + 5GHz

[Lara Deek]

Thank you Jouni and Johannes for your replies. They were very helpful. I was
not aware that the 802.11n standard itself allows channel bonding only on
particular channel pairs. That restriction is generally not made very clear
(I think). I definitely do not intend to build a system that does not comply
with the 802.11n standard, so I understand that I should not get support to
do that :)

As for hostapd's "802.11n: scan for overlapping BSSes before starting
20/40MHz channel", I am aware that the restriction exists to reduce
interference between overlapping APs and to avoid performance degradations.
I just want to take the control from hostapd about when to proactively
start/enable 20/40MHz operation.

Thanks again!
Lara


Date: Mon, 21 Feb 2011 17:05:26 +0100
From: Johannes Berg <johannes at sipsolutions.net>
 Subject: Re: hostapd + channel bonding + 5GHz
To: Jouni Malinen <j at w1.fi>
Cc: hostap at lists.shmoo.com
 Message-ID: <1298304326.3707.14.camel at jlt3.sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"

On Mon, 2011-02-21 at 17:57 +0200, Jouni Malinen wrote:

> On Thu, Feb 17, 2011 at 05:40:14PM -0800, Lara Deek wrote:
> > The ht_capab parameter in hostapd.conf enables 40MHz operation
> > ([HT40-][HT40+]). I understand hostapd enables channel bonding only if
there
 > > will be no channel/bandwidth overlap with neighboring APs (802.11n:
scan for
> > overlapping BSSes before starting 20/40MHz channel). Is there some way
where
> > I can control 40MHz vs. 20MHz operation myself without it being censored
by
 > > hostapd?
>
> Not without modifying the source code. hostapd will enforce 20/40 MHz
> coexistence rules based on the mandatory standard requirements.

Also note that these restrictions don't just exist to annoy you -- if
 you have BSSs that overlap in certain ways performance in both can
severely degrade in both.

johannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20110222/90335b47/attachment.htm