On 27 January 2015 at 11:24, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2015-01-27 at 09:44 +0100, Janusz Dziedzic wrote: > >> +u8 *ieee80211_ie_build_vht_oper(u8 *pos, struct ieee80211_sta_vht_cap *vht_cap, >> + const struct cfg80211_chan_def *chandef) > >> + /* 1 stream, MCS0-7 as a min Basic VHT MCS rates */ >> + vht_oper->basic_mcs_set = cpu_to_le16(0xfffc); > > Unless I'm mistaken in my reading of the spec, this will make any > well-behaved client (i.e. not mac80211) not join this network since it > supports VHT MCSes. > > We seem to do the same for HT: > > /* It seems that Basic MCS set and Supported MCS set > are identical for the first 10 bytes */ > memset(&ht_oper->basic_set, 0, 16); > memcpy(&ht_oper->basic_set, &ht_cap->mcs, 10); > > but I'm not convinced it's right. It probably only works because nobody > ever tested against a well-behaved non-HT client? Or perhaps there isn't > even one? > for HT (spec, 20.3.5) - MCS0 .. MSC7 are mandatory - but this is for all stations (not sure about ibss) for VHT (22.5, table 22-30) - MCS0...MCS7 are mandatory for nss=1 (20,40,80) Seems such set is secure? If I understand correctly case you describe with non-HT client: non-HT client should not understand HT ies, and HT-only client should not understand VHT ies? > I for one am not really comfortable with this restriction - there's very > little point in making such a restriction in IBSS since if you have it > then the other node will just form its own network on the same channel > and you've won nothing - only lost interoperability. > > johannes > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
