>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri May 04 19:40:05 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Bernhard Schmidt
>Release:head
>Organization:
>Environment:
FreeBSD alix1 10.0-CURRENT Free
On Tue, Jan 19, 2010 at 02:50:08PM +, Jens Thiede wrote:
> The following reply was made to PR kern/142766; it has been noted by GNATS.
>
> From: Jens Thiede
> To: bug-follo...@freebsd.org,
> wbl...@wonkity.com
> Cc:
> Subject: Re: kern/142766: ipw regression ipw(4) with Intel PRO/wireless
The patch effectively reverts a previous change, which was to cap rxmax and
density by what the AP is capable of. I think the better approach would be to
initialize rxmax and density with the VAP capabilities before the condition
and use MIN() in STA mode to limit to AP caps.
--
Bernhard
_
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.
On Friday, February 22, 2013 07:34:30 PM Adrian Chadd wrote:
> Hi,
>
> Why isn't it a per-node thing for the AP case?
>
> Ie, what should the AP do if the ampdu density it supports is 0 but
> the STA AMPDU density on the RX side is 8?
What made you think it isn't? ni_htparams is per-node(ni)?
I
On Friday, February 22, 2013 07:52:47 PM Adrian Chadd wrote:
> Hm, it's possible in my sleep deprived state that I'm on the right but
> wrong track here.
>
> The OP problem is that we're not advertising the right capabilities
> when we associate, right?
Correct.
> Why aren't we just advertising
