On Mon, Jul 18, 2016 at 21:52:22, Johannes Berg wrote:
> linux- wireless@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx
> 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
��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
