From owner-freebsd-bugs@FreeBSD.ORG Fri Feb 22 22:45:59 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 09F0E453; Fri, 22 Feb 2013 22:45:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by mx1.freebsd.org (Postfix) with ESMTP id 7495BFC2; Fri, 22 Feb 2013 22:45:57 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn17so1522076wib.4 for ; Fri, 22 Feb 2013 14:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=e4GcVDR4qPcwRskMuDaGaqW+u1Kb30eh1Odd5oLMK9o=; b=f0PQHNJlXEXOVW3sL/OyyqU3X+9QDYkn8jv98Nyoepv1HBTCkuFjqHyqe2yME/GTkN yJYhp05mNKQ0RycNCoyBhCToKEHPXwNifN+TxWZqkn+jIWEkfH1pGJATt9fvTpw4pERf 9wVgO6oaclhJozNy/gC4m3sHKJecK4jA8gLzu1i7cmekACsnTHoU061gRY3XUdtFvpdD hCzBBV24PMeSJ1L9o3q6fQ1bjR/eDmuqLVW/zJzPYCmiaeIclKfF/qV0buctMXaAMKDU sfGv6Fn1YUaiDO/OXhhmV3MvmnnfVj7687LpxrrSr/ww9MO3i54VBOsX1QZGRUnqIDQx jraQ== MIME-Version: 1.0 X-Received: by 10.194.238.226 with SMTP id vn2mr6515624wjc.23.1361573151450; Fri, 22 Feb 2013 14:45:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.74.194 with HTTP; Fri, 22 Feb 2013 14:45:51 -0800 (PST) In-Reply-To: References: <201302180246.r1I2kocv064092@freefall.freebsd.org> <201302222005.36490.bschmidt@techwires.net> Date: Fri, 22 Feb 2013 14:45:51 -0800 X-Google-Sender-Auth: AWxdGObxQFZC8zKDJE2_ZAzU6ko Message-ID: Subject: Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 Cc: Bernhard Schmidt , freebsd-bugs@freebsd.org, 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 22:45:59 -0000 On 22 February 2013 13:26, PseudoCylon wrote: >>> The OP problem is that we're not advertising the right capabilities >>> when we associate, right? >> >> Correct. > > I didn't patch it right, but all of us agree on sta isn't sending > correct param at association. With current code, sta sends back > whatever it has received in probe resp packet. Right, but Bernhard points out the original code did return its own configuration, and this causes some APs to reject stations. Hence why it's doing this. >>> Why aren't we just advertising the VAP ampdumax and ampdudensity no >>> matter what the operating mode? Why are we capping those parameters to >>> the learnt-from-AP parameters? >> >> Because the AP would otherwise deny the association request. > > Should ap only allow node which caps match ap's to associate? (By the > way, can anyone point me to the code does denial? I couldn't find it.) I don't think so. The whole point here is to _support_ nodes whose density/ampdusize is less than what we have configured. The only reason we'd want to reject them is if we have some concept of "minimum acceptable density/ampdurx" (like "minimum basic rates"), rather than "what is it we support." Adrian