[PATCH] ACS: fix VHT20

[Johannes Berg]

On Fri, 2014-03-14 at 16:42 +0200, Jouni Malinen wrote:

> > > > Interesting.  But see my previous patch - the kernel part obviously
> > > > needs to be fixed but maybe in the beacon it should be set to 0?
> > > 
> > > Won't setting it to 0 break older kernels with hostapd ACS for
> > > VHT20/VHT40? I'm not sure if that's what we want?
> > 
> > Well the *kernel* value in the chandef has to be set correctly,
> > obviously. I'm merely pointing out that since my recent patch it's
> > possible to (correctly, the spec says it's reserved) set the field to 0
> > in the VHT operation IE.
> 
> I'm having hard time trying to understand this discussion or well, more
> accurately, what was the outcome of the discussion that ended here.. The
> proposed change here seems to be changing vht_oper_centr_freq_seg0_idx
> value from pri_chan + 2 to pri_chan for 20 MHz channel width case. Is
> there any objection to that change and if so, why?

No, there's no objection to that change - that part is certainly
correct. This just triggered my memory of the other patch that you
recently applied, allowing the field to be set to zero in the IEs.

> As far as the Beacon frame is concerned, is the comment just pointing
> out that hostapd_eid_vht_operation() should ignore
> vht_oper_centr_freq_seg0_idx and set the field to 0 if this is a 20 MHz
> channel? If so, is anyone interesting in providing such patch?

Yeah, pretty much. I sent you (and you applied) a patch that was
allowing to set it to 0 in the config file instead, which is technically
required for spec compliance (field is reserved in 20/40 MHz case), but
in practice interoperability may be better with the field getting set,
particularly with old broken mac80211 ;-)

> I agree that these fields seems to be marked Reserved in IEEE Std
> 802.11ac-2013 for this case and per IEEE Std 802.11-2014, reserved
> fields/subfields are set to 0 upon transmission.

802.11-2014? I guess I need to find that.

> Does setting this field to 0 cause interop issues with earlier
> implementations before that "recent patch" mentioned above? (And if so,
> do we care?)

It does, setting it to 0 means that mac80211 until commit cb664981607a
("mac80211: fix association to 20/40 MHz VHT networks") will connect as
an HT client, and ignore VHT. We probably shouldn't care though, and
it's not a major issue (HT connection still works fine.)

johannes