[EXT] Re: [PATCH] Issue: Non-HE capable interface advertising HE IEs

Deepti Panchal deepti.panchal at nxp.com
Sun Oct 9 09:49:23 PDT 2022

Hi Jouli,

Related to the HE IE discussion below, I too had submitted a patch (on 18th Jul 2022) for blocking/removing the HE IEs if the underlying AP HW interface itself does not support HE mode. 
But the "hostapd.conf" file has the setting "ieee80211ax=1".

Can you please review and comment on this patch.

>From e19bf318ce2a27ccc03f72023b2fc7f1bf6cd496 Mon Sep 17 00:00:00 2001
From: Deepti Panchal <deepti.panchal at nxp.com>
Date: Mon, 18 Jul 2022 15:59:10 +0530
Subject: [PATCH] Issue: Non-HE capable interface advertising HE  IEs/Capabilities in Beacon/Probe Response/Association Response frames if  "ieee80211ax=1" configuration is used

Change Description:
    1. The HE capability for an AP iface was read from the driver, but was not used to update the "drv_flags" for the iface
    2. Change is now added to update the HE capability in the "drv_flags" of the interface
    3. If the interface does not support HE capability, the "iface->conf->ieee80211ax" flag is set to 0
    4. Hence now Beacons/Probe response/Association Response will advertise HE capabilities ONLY if the interface is HE capable
 src/ap/hw_features.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/ap/hw_features.c b/src/ap/hw_features.c index ed5ff41d3..87d7b52bd 100644
--- a/src/ap/hw_features.c
+++ b/src/ap/hw_features.c
@@ -679,7 +679,19 @@ static int ieee80211ac_supported_vht_capab(struct hostapd_iface *iface)  #ifdef CONFIG_IEEE80211AX  static int ieee80211ax_supported_he_capab(struct hostapd_iface *iface)  {
-       return 1;
+    struct hostapd_hw_modes *mode = iface->current_mode;
+    struct he_capabilities *he_cap =
+ &(mode->he_capab[IEEE80211_MODE_AP]);
+    /* Check iface HE capability, update drv_flags and HE config setting */
+    if (he_cap && he_cap->he_supported) {
+        wpa_printf(MSG_DEBUG, "iface hw he_supported: %d", he_cap->he_supported);
+        iface->drv_flags |= WPA_DRIVER_FLAGS_HE_CAPABILITIES;
+    } else {
+        wpa_printf(MSG_DEBUG, "iface does not support HE capability");
+        iface->conf->ieee80211ax = 0;
+    }
+    return 1;
 #endif /* CONFIG_IEEE80211AX */


-----Original Message-----
From: Hostap <hostap-bounces at lists.infradead.org> On Behalf Of Jouni Malinen
Sent: Thursday, October 6, 2022 19:29
To: Howard Hsu <howard-yh.hsu at mediatek.com>
Cc: Felix Fietkau <nbd at nbd.name>; Ryder Lee <ryder.lee at mediatek.com>; Shayne Chen <shayne.chen at mediatek.com>; Evelyn Tsai <evelyn.tsai at mediatek.com>; hostap at lists.infradead.org
Subject: [EXT] Re: [PATCH] AP: Do not include HE related IE in assoc rsp if receiving invalid HE capa IE

Caution: EXT Email

On Tue, Oct 04, 2022 at 02:57:08PM +0800, Howard Hsu wrote:
> If station sends association request with invalid size HE capabilities 
> IE, current implementation will find the error and clear WLAN_STA_HE 
> bit of sta->flags. While in this case, AP still sends association 
> response with HE related IEs, which may confuse station that thay can 
> connect in HE mode. Before sending association response, it shall 
> check whether WLAN_STA_HE bit of sta->flags is set to decide if HE 
> related IEs can be included.

This seems to be non-compliant with the IEEE Std 802.11ax-2021 expectations. In particular, Table 9-35 (Association Response frame
body) indicates that the HE Capabilities and HE Operation elements are included if the AP itself has enabled HE regardless of the non-AP STA capabilities. In other words, that would mean these elements would go out to the station even if it did not try to negotiate HE, never mind having tried and failed to do so.

Is there some other place in the standard that would support the proposed change in behavior or do you have some other justification for needing to change behavior in a manner that does not match the standard?

Jouni Malinen                                            PGP id EFC895FA

Hostap mailing list
Hostap at lists.infradead.org

More information about the Hostap mailing list