Enabling 802.11ac (VHT) mode

When an AP is trying to be enabled in 802.11ac (VHT) mode by setting its 
parameter disable_vht to 0, it is not actually enabled and it's set to HT. 

Looking at the source code it was found that the variable used to check 
whether to enable or not the VHT is ssid->vht but it has not been set 
before. Instead, the variable ssid->disable_vht stores the actual network 
parameter which indicates if the VHT has been disabled or not. 

Is it OK? Or there is something I am missing to correctly set wpa_supplicant 
in AC mode?

---
 wpa_supplicant/ap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On Mon, Jun 13, 2016 at 04:53:08PM +0200, Jose Blanquicet wrote:
> When an AP is trying to be enabled in 802.11ac (VHT) mode by setting its 
> parameter disable_vht to 0, it is not actually enabled and it's set to HT. 
> 
> Looking at the source code it was found that the variable used to check 
> whether to enable or not the VHT is ssid->vht but it has not been set 
> before. Instead, the variable ssid->disable_vht stores the actual network 
> parameter which indicates if the VHT has been disabled or not. 
> 
> Is it OK? Or there is something I am missing to correctly set wpa_supplicant 
> in AC mode?

ssid->vht is used when setting up a P2P GO. However, it looks like the
configuration parser does not provide means for enabling this for
non-P2P use cases (i.e., when setting up an AP mode operation with
wpa_supplicant).

> diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c
> @@ -166,7 +166,7 @@ int wpa_supplicant_conf_ap_ht(struct wpa_supplicant *wpa_s,
> -			if (mode->vht_capab && ssid->vht) {
> +			if (mode->vht_capab && !ssid->disable_vht) {
>  				conf->ieee80211ac = 1;
>  				wpas_conf_ap_vht(wpa_s, conf, mode);
>  			}

This would break builds without CONFIG_VHT_OVERRIDES defined. In
addition, this would break the expected P2P behavior on how VHT is being
enabled. I guess it could be fine to make the non-P2P AP case enable VHT
automatically based on driver capabilities (and allow that to be
prevented that with ssid->disable_vht).

Hi Jouni,

Thanks for your feedback.

On Sat, Jul 23, 2016 at 7:22 PM, Jouni Malinen <j@w1.fi> wrote:
>
> On Mon, Jun 13, 2016 at 04:53:08PM +0200, Jose Blanquicet wrote:
> > When an AP is trying to be enabled in 802.11ac (VHT) mode by setting its
> > parameter disable_vht to 0, it is not actually enabled and it's set to HT.
> >
> > Looking at the source code it was found that the variable used to check
> > whether to enable or not the VHT is ssid->vht but it has not been set
> > before. Instead, the variable ssid->disable_vht stores the actual network
> > parameter which indicates if the VHT has been disabled or not.
> >
> > Is it OK? Or there is something I am missing to correctly set wpa_supplicant
> > in AC mode?
>
> ssid->vht is used when setting up a P2P GO. However, it looks like the
> configuration parser does not provide means for enabling this for
> non-P2P use cases (i.e., when setting up an AP mode operation with
> wpa_supplicant).
>

You are right, I didn't take into account P2P-GO.

I used the following network configuration, is something missing?

add_network

set_network 0 ssid "Marvell-AP"
set_network 0 psk "01234567"
set_network 0 mode 2
set_network 0 proto RSN
set_network 0 key_mgmt WPA-PSK
set_network 0 frequency 5180
set_network 0 disable_vht 0
set_network 0 disable_ht 0

select_network 0


> > diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c
> > @@ -166,7 +166,7 @@ int wpa_supplicant_conf_ap_ht(struct wpa_supplicant *wpa_s,
> > -                     if (mode->vht_capab && ssid->vht) {
> > +                     if (mode->vht_capab && !ssid->disable_vht) {
> >                               conf->ieee80211ac = 1;
> >                               wpas_conf_ap_vht(wpa_s, conf, mode);
> >                       }
>
> This would break builds without CONFIG_VHT_OVERRIDES defined. In
> addition, this would break the expected P2P behavior on how VHT is being
> enabled. I guess it could be fine to make the non-P2P AP case enable VHT
> automatically based on driver capabilities (and allow that to be
> prevented that with ssid->disable_vht).
>

Also true, it will not work without CONFIG_VHT_OVERRIDES definition.

Enabling VHT by default if it is available is the best idea. In fact,
according to comments in config_ssid.h, that should be the normal
behavior: "By default, use it (disable_vht) if it is available, but
this can be configured to 1 to have it disabled.".
Therefore, I used iwconfig to check which capabilities my driver
reports and I saw "IEEE 802.11-DS". Looking on Internet for it, I
found an old discussion on this mailing-list where you answered that
IEEE 802.11-DS could be caused by an error inside firmware. I think
this could be the reason I haven't been able to enable AP in VHT mode,
wpa_supplicant is not aware my chip supports VHT. How could I confirm
this? What do you suggest?

Thanks for you help!

Best regards,

Jose Blanquicet

> --
> Jouni Malinen                                            PGP id EFC895FA

Hi,

In order to understand why wpa_supplicant is not enabling VHT when setting up an AP mode operation, I peformed further tests using two different WiFi chips, one from Mavell and another from Realtek.
For the purpose of check that both chips and drivers are able to deal with VHT, I used hostapd with the following configuration:

interface=uap0
ctrl_interface=/var/run/hostapd
driver=nl80211
ssid=Testing-AC
hw_mode=a
ieee80211n=1
ieee80211ac=1
channel=36
auth_algs=1

With both chips hostapd correctly started. I confirmed it by looking at the beacons with the sniffer and checking the presence of the VHT IEs.

Instead, on the other hand I used wpa_supplicant with the following configuration:

add_network
set_network 0 ssid "Testing-AC"
set_network 0 psk "01234567"
set_network 0 mode 2
set_network 0 disable_ht 0
set_network 0 disable_vht 0
set_network 0 frequency 5180
set_network 0 key_mgmt NONE
select_network 0

Both chips started AP mode operations, but none of them set VHT. Again, it was checked with the sniffer and VHT IEs were not present on none of the cases, only HT IEs were there.

After these tests we can conclude both chips and drivers are VHT-capable and work. Therefore, what is missing for wpa_supplicant to enable VHT? Where could I specifically check inside the code what is asked by wpa_supplicant to enable VHT (Set ssid->vht to 1)?
Thanks in advance for your help.

Best regards,

Jose Blanquicet


> -----Original Message-----
> From: Hostap [mailto:hostap-bounces@lists.infradead.org] On Behalf Of Jose
> Blanquicet
> Sent: Monday, July 25, 2016 11:20 AM
> To: Jouni Malinen
> Cc: hostap@lists.infradead.org
> Subject: Re: [PATCH] Enabling 802.11ac (VHT) mode
>
> Hi Jouni,
>
> Thanks for your feedback.
>
> On Sat, Jul 23, 2016 at 7:22 PM, Jouni Malinen <j@w1.fi> wrote:
> >
> > On Mon, Jun 13, 2016 at 04:53:08PM +0200, Jose Blanquicet wrote:
> > > When an AP is trying to be enabled in 802.11ac (VHT) mode by setting
> > > its parameter disable_vht to 0, it is not actually enabled and it's set to HT.
> > >
> > > Looking at the source code it was found that the variable used to
> > > check whether to enable or not the VHT is ssid->vht but it has not
> > > been set before. Instead, the variable ssid->disable_vht stores the
> > > actual network parameter which indicates if the VHT has been disabled or
> not.
> > >
> > > Is it OK? Or there is something I am missing to correctly set
> > > wpa_supplicant in AC mode?
> >
> > ssid->vht is used when setting up a P2P GO. However, it looks like the
> > configuration parser does not provide means for enabling this for
> > non-P2P use cases (i.e., when setting up an AP mode operation with
> > wpa_supplicant).
> >
>
> You are right, I didn't take into account P2P-GO.
>
> I used the following network configuration, is something missing?
>
> add_network
>
> set_network 0 ssid "Marvell-AP"
> set_network 0 psk "01234567"
> set_network 0 mode 2
> set_network 0 proto RSN
> set_network 0 key_mgmt WPA-PSK
> set_network 0 frequency 5180
> set_network 0 disable_vht 0
> set_network 0 disable_ht 0
>
> select_network 0
>
>
> > > diff --git a/wpa_supplicant/ap.c b/wpa_supplicant/ap.c @@ -166,7
> > > +166,7 @@ int wpa_supplicant_conf_ap_ht(struct wpa_supplicant
> *wpa_s,
> > > -                     if (mode->vht_capab && ssid->vht) {
> > > +                     if (mode->vht_capab && !ssid->disable_vht) {
> > >                               conf->ieee80211ac = 1;
> > >                               wpas_conf_ap_vht(wpa_s, conf, mode);
> > >                       }
> >
> > This would break builds without CONFIG_VHT_OVERRIDES defined. In
> > addition, this would break the expected P2P behavior on how VHT is
> > being enabled. I guess it could be fine to make the non-P2P AP case
> > enable VHT automatically based on driver capabilities (and allow that
> > to be prevented that with ssid->disable_vht).
> >
>
> Also true, it will not work without CONFIG_VHT_OVERRIDES definition.
>
> Enabling VHT by default if it is available is the best idea. In fact, according to
> comments in config_ssid.h, that should be the normal
> behavior: "By default, use it (disable_vht) if it is available, but this can be
> configured to 1 to have it disabled.".
> Therefore, I used iwconfig to check which capabilities my driver reports and I
> saw "IEEE 802.11-DS". Looking on Internet for it, I found an old discussion on
> this mailing-list where you answered that IEEE 802.11-DS could be caused by
> an error inside firmware. I think this could be the reason I haven't been able
> to enable AP in VHT mode, wpa_supplicant is not aware my chip supports
> VHT. How could I confirm this? What do you suggest?
>
> Thanks for you help!
>
> Best regards,
>
> Jose Blanquicet
>
> > --
> > Jouni Malinen                                            PGP id EFC895FA
>
> _______________________________________________
> Hostap mailing list
> Hostap@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap