Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Feb 2013 19:33:25 +0100
From:      Bernhard Schmidt <bschmidt@techwires.net>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        freebsd-bugs@freebsd.org, PseudoCylon <moonlightakkiy@yahoo.ca>, freebsd-wireless@freebsd.org
Subject:   Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
Message-ID:  <201302221933.25718.bschmidt@techwires.net>
In-Reply-To: <CAJ-VmomCtXoDWfpc%2B-XK-xBFb7dCCzPtrLDMegCT%2BZWL1Ye=xQ@mail.gmail.com>
References:  <201302180246.r1I2kocv064092@freefall.freebsd.org> <201302221859.31446.bschmidt@techwires.net> <CAJ-VmomCtXoDWfpc%2B-XK-xBFb7dCCzPtrLDMegCT%2BZWL1Ye=xQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, February 22, 2013 07:04:39 PM Adrian Chadd wrote:
> Hm, we need to use MIN(rxmax) and MAX(density) regardless, right?
> 
> If an AP is transmitting to a STA that has a lower rxmax or higher
> density, it should obey that.
> 
> The same rules apply for mesh, ibss, tdma operational modes.
> 
> So yes, what we should do is:
> 
> * initialise rxmax/density with the VAP capabilities
> * track what the remote node rxmax/density is
> * have a couple of functions that return the density and rxmax based
> on the destination node and current VAP config
> * teach the 11n drivers to use that.

Don't make it to complex, it's one-liner, not sure it's worth a function.

The STA case is handled here because there is no later position to do so, AP 
already told us what it is capable of (ni_htparams) now it's the STA's job to 
do the same. The AP case is handled somewhere else, assoc req I guess, and 
that just uses the VAP params to verify the limits aren't above device caps. 
Using plain ni_htparams after that is just fine. If also done right in STA 
mode, ni_htparams will always contain a value which doesn't exceed either the 
AP's or the STA's or the device's limits (might have to change the value 
exactly there), so, using it directly is fine in drivers.

I don't want to get into IBSS mode just yet, it's way to complex to get my 
head around that atm. Though, I think, it's a per-node and not a global 
parameter so the handling should match that from the AP?

-- 
Bernhard



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201302221933.25718.bschmidt>