kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet

[Bernhard Schmidt]

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