netdev - RE: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <AE1C82FB3D0EC64DB1F752C81CBD110139206259@DFRE01.ent.ti.com>
Date:	Tue, 19 Jul 2016 13:17:31 +0000
From:	"Machani, Yaniv" <yanivma@...com>
To:	Johannes Berg <johannes@...solutions.net>,
	Bob Copeland <me@...copeland.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Kama, Meirav" <meiravk@...com>,
	"David S. Miller" <davem@...emloft.net>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template

On Mon, Jul 18, 2016 at 21:52:22, Johannes Berg wrote:
> linux- wireless@...r.kernel.org; netdev@...r.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