On Fri, 2017-09-22 at 12:09 +0200, Richard Schütz wrote: > > The way I see it, this would make us assume that all 2.4 GHz > > clients support ERP in IBSS, which may not be true? > > I disagree. On a HR/DSSS PHY this would still only return HR/DSSS > rates because there should not by any ERP rates present in sband- > >bitrates in the first place. Sure, but that means that if you're an ERP PHY (which all users of this code are likely to be), you'd assume that *everyone else* you're talking to also is - and that's not necessarily desired. > The reason for suggesting this change is that the basic rate set for > a mesh STA is initialized with this function if not explicitly > configured beforehand. Exactly! So if you mark all the rates as basic that are mandatory for you, you can never peer mesh with a HR/DSSS PHY. Now, that's probably unlikely to happen - but for IBSS I'd argue it's reasonable, and the same would happen there afaict. > IEEE Std 802.11-2016 (10.7.4 Basic rate set, basic HT-MCS set, and > basic VHT-MCS and NSS set for mesh STA) states: A mesh STA shall not > establish a mesh peering with a mesh STA using a different > BSSBasicRateSet (see 14.2.7 and 14.2.8). The SME of a Mesh STA should > use the mandatory PHY rates as the default BSSBasicRateSet in the > MLME-START.request primitive to reduce the risk that a candidate peer > mesh STA utilizes a different BSSBasicRateSet. "Should" isn't "shall" > Selecting only HR/DSSS mandatory rates for a mesh STA default basic > rate set on an ERP PHY violates this requirement in my opinion. It does seem to violate the "should", but arguably that's just a configuration choice. > wpa_supplicant explicitly configures all ERP mandatory rates for ERP > mesh points in its default configuration, whereas iw relies on the > kernel to do the selection. This currently leaves us with the > unfortunate situation that you can not join such a mesh BSS created > by wpa_supplicant using iw without further configuration and the > other way round. So now we've finally gotten to the bottom of why you're doing all this? Anyway, I disagree with the patch. I can get behind a patch changing the mesh code, but not in a way that affects the IBSS like this. johannes
