From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753661AbcGSNRl (ORCPT ); Tue, 19 Jul 2016 09:17:41 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:57017 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753215AbcGSNRh (ORCPT ); Tue, 19 Jul 2016 09:17:37 -0400 From: "Machani, Yaniv" To: Johannes Berg , Bob Copeland CC: "linux-kernel@vger.kernel.org" , "Kama, Meirav" , "David S. Miller" , "linux-wireless@vger.kernel.org" , "netdev@vger.kernel.org" Subject: RE: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template Thread-Topic: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template Thread-Index: AQHR3PuO+VtOrkEJIk2rXiuP3xHqfaAeF9EAgAB5R82AATLPIA== Date: Tue, 19 Jul 2016 13:17:31 +0000 Message-ID: References: <20160713114542.24937-1-yanivma@ti.com> <20160718133824.GA11996@localhost> (sfid-20160718_153832_665157_D129D05B) <1468867942.2944.0.camel@sipsolutions.net> In-Reply-To: <1468867942.2944.0.camel@sipsolutions.net> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.167.188.42] x-exclaimer-md-config: f9c360f5-3d1e-4c3c-8703-f45bf52eff6b Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u6JDHjlu016860 On Mon, Jul 18, 2016 at 21:52:22, Johannes Berg wrote: > linux- wireless@vger.kernel.org; netdev@vger.kernel.org > Subject: Re: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon > template > > On Mon, 2016-07-18 at 09:38 -0400, Bob Copeland wrote: > > On Wed, Jul 13, 2016 at 02:45:40PM +0300, Yaniv Machani wrote: > > > The HT capab info field inside the HT capab IE of the mesh beacon > > > is incorrect (in the case of 20MHz channel width). > > > To fix this driver will check configuration from cfg and will > > > build it accordingly. > > > > > +    /* determine capability flags */ > > > + cap = sband->ht_cap.cap; > > > + > > > +    /* if channel width is 20MHz - configure HT capab > > > accordingly*/ > > > + if (sdata->vif.bss_conf.chandef.width == > > > NL80211_CHAN_WIDTH_20) { > > > + cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40; > > > + cap &= ~IEEE80211_HT_CAP_DSSSCCK40; > > > + } > > > > Is it required that HT capability match the HT operation in this case? > > > > Is there ever a case that HT *capability* should be restricted > artificially like that? I can't remember any cases - we do something > like that to work around broken APs in some cases, but here? > It was done to overcome another mismatch with the defaults of the hostap configuration, We'll have another look on it. There is an IOP question here, how to handle a case where you have mixed capabilities of peers. is it possible to dynamically change the channel bandwidth to allow new peers to join ? Yaniv