[PATCH] ACS: fix VHT20

[Jouni Malinen]

On Fri, Feb 28, 2014 at 05:11:48PM +0100, Johannes Berg wrote:
> On Fri, 2014-02-28 at 15:57 +0100, Michal Kazior wrote:
> > On 28 February 2014 15:43, Johannes Berg <johannes at sipsolutions.net> wrote:
> > > On Fri, 2014-02-28 at 15:19 +0100, Michal Kazior wrote:
> > >> The center segment0 calculation for VHT20 ACS was
> > >> incorrect. This caused ACS to fail with:
> > >> "Could not set channel for kernel driver".
> > >
> > > 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?

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?

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.

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

-- 
Jouni Malinen                                            PGP id EFC895FA