linux-kernel - RE: [PATCH 3/4] 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: Windows password security audit tool. GUI, reports in PDF.

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

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

On Wed, Jun 29, 2016 at 10:17:35, Johannes Berg wrote:
> Cc: Kama, Meirav
> Subject: Re: [PATCH 3/4] mac80211: mesh: fixed HT ies in beacon 
> template
> 
> On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote:
> >
> >  net/mac80211/mesh.c | 33 ++++++++++++++++++++++++++++++++-
> >  net/mac80211/util.c |  3 ---
> >  net/wireless/mesh.c |  2 +-
> 
> That's not a good patch - one change is mac80211 and the other cfg80211.
> 
> > -	.ht_opmode =
> IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED,
> > +	.ht_opmode = IEEE80211_HT_OP_MODE_PROTECTION_NONE,
> >
> How are you planning to comply with 802.11 now?

Good point, this changed should be removed.
The reason for this change was that we've noticed a difference between mesh beacon (built by the mac80211) and mesh actions (built by the supplicant) in the HT information IE.
In beacons the HT operational mode is Mixed Mode (0x11)  while in actions it is None (0x00). 
After a second look, it seems that it's the Supplicant that doesn't set the default value correctly.

We'll send an updated patch for it.
Thanks,
Yaniv

> 
> The HT Protection field in a mesh STA may be set to no protection mode 
> only if — All STAs detected in the primary or the secondary channel 
> are HT
>   STAs, and
> — All mesh STA members of this MBSS that are one-hop neighbors of the
>   transmitting mesh STA are either:
>   — 20/40 MHz HT mesh STAs in a 20/40 MHz MBSS, or
>   — 20 MHz HT mesh STAs in a 20 MHz MBSS.
> 
> johannes