[PATCH] Add an option to set secondary channel in hostapd conf

[Orr Mazor]

On Sun, Apr 18, 2021 at 11:12 AM Aaron Komisar <akomisar at maxlinear.com> wrote:
> On 8/04/2021 14:51, Arnout Vandecappelle wrote:
>  As far as I understand, the goal is to be able to specify the starting
> secondary channel in case ht_capab=[HT40+][HT40-] just like it's possible to
>
> > specify it in the chan_switch command with the sec_channel_offset parameter.
> >
> >  However, I guess that's just a misunderstanding of what ht_capab is doing in
> > that case. AFAIU, ht_capab=[HT40+] gives the HT40 capability and sets the
> > starting secondary channel to +1, but subsequent channel switches can still set
> > it to -1.
> >
> >  So I think this patch is indeed not needed, and instead it's just a matter of
> > setting either [HT40+] or [HT40-] in the configuration file, and not both.
> >
> >  Of course this way of specifying the secondary channel is fairly warty, but it
> > is what it is :-)
>
>  Still, we currently don't have the option to set a 20 MHz channel without
> losing the 40 MHz capabilities.
> Using a 20 MHz channel with 40 MHz capabilities can only be done using
> chan_switch command, which can't be used when channel is not set yet (in our
> scenario we use disable in order to cancel CAC and need to be able to start
> using a specified channel).
>
>  The suggested patch provides this ability.

It has been a while, but I think this patch is still required.
As Aaron stated, this patch gives the user the ability to start hostapd on
20 MHz bandwidth with 40 MHz (or more) capabilities.
This can be achieved by using the suggested patch which allows
setting the secondary channel to zero in conf file.

This ability currently exists in the dynamic chan_switch command,
but does not exist currently when starting hostapd, which seems
to me like inconsistency.

Setting capabilities that are different than the operating bandwidth
is supported in higher bandwidths (using vht_oper_chwidth),
which enables the AP to increase the bandwidth dynamically.

Thanks,
Orr