From owner-freebsd-bugs@FreeBSD.ORG Fri Feb 22 18:32:09 2013 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 350DDFAC; Fri, 22 Feb 2013 18:32:09 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mx.techwires.net (mx.techwires.net [IPv6:2001:4d88:100f:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id E7AD217C; Fri, 22 Feb 2013 18:32:08 +0000 (UTC) Received: from amy.lab.techwires.net (dslb-088-067-212-155.pools.arcor-ip.net [88.67.212.155]) by mx.techwires.net (Postfix) with ESMTPSA id 9CC3A30A875; Fri, 22 Feb 2013 19:32:06 +0100 (CET) From: Bernhard Schmidt To: Adrian Chadd Subject: Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet Date: Fri, 22 Feb 2013 19:33:25 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.9.5; amd64; ; ) References: <201302180246.r1I2kocv064092@freefall.freebsd.org> <201302221859.31446.bschmidt@techwires.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302221933.25718.bschmidt@techwires.net> Cc: freebsd-bugs@freebsd.org, PseudoCylon , freebsd-wireless@freebsd.org X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 18:32:09 -0000 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