Hi,
I need to enable HE extended range SU PPDU format. I think to achieve that, you have to enable BIT64 and BIT68 in HE PHY capabilities(correct me if I am wrong).
I figure out that you can set HE PHY capabilities to any value via mlanutl(e.g I tried to set both bits to 1)
$ /usr/share/nxp_wireless/mlanutl r0ap0 11axcfg 11axcfg.conf
Set 11axcfg: len=55
02 ff 00 1a 00 23 01 08 00 82 00 08 04 70 7e c9
fd 01 a0 0c 11 3d 00 fa ff fa ff e1 ff c7 71 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00
11axcfg: len=55
02 ff 00 1a 00 23 01 08 00 02 00 08 04 70 7e c9
fd 01 a0 0c 11 3d 00 fa ff fa ff e1 ff c7 71 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00
But in driver code, I see that when driver is being registered to cfg80211, these bits are masked.
woal_cfg80211_setup_he_cap function:
woal_request_get_fw_info(priv, MOAL_IOCTL_WAIT, &fw_info);
if (band->band == NL80211_BAND_5GHZ) {
phe_cap = (mlan_ds_11ax_he_capa *)fw_info.hw_he_cap;
hw_hecap_len = fw_info.hw_hecap_len;
woal_uap_update_11ax_ie(BAND_5GHZ, phe_cap); ---> this funtion will mask those bits
} else {
phe_cap = (mlan_ds_11ax_he_capa *)fw_info.hw_2g_he_cap;
hw_hecap_len = fw_info.hw_2g_hecap_len;
woal_uap_update_11ax_ie(BAND_2GHZ, phe_cap);
}
woal_uap_update_11ax_ie function:
hecap_ie->he_phy_cap[7] &= UAP_HE_PHY_CAP7_MASK;
hecap_ie->he_phy_cap[8] &= UAP_HE_PHY_CAP8_MASK;
and masks are as follow:
/*
===============
11AX CAP for uAP
===============
Note: bits not mentioned below are set to 0.
5G
===
HE MAC Cap:
Bit0: 1 (+HTC HE Support)
Bit25: 1 (OM Control Support. But uAP does not support
Tx OM received from the STA, as it does not support UL OFDMA)
HE PHY Cap:
Bit1-7: 0x2 (Supported Channel Width Set.
Note it would be changed after 80+80 MHz is supported)
Bit8-11: 0x3 (Punctured Preamble Rx.
Note: it would be changed after 80+80 MHz is supported)
Bit12: 0x0 (Device Class)
Bit13: 0x1 (LDPC coding in Payload)
Bit17: 0x1 (NDP with 4xHE-LTF+3.2usGI)
Bit18: 0x1 (STBC Tx <= 80 MHz)
Bit19: 0x1 (STBC Rx <= 80 MHz)
Bit20: 0x1 (Doppler Tx)
Bit21: 0x1 (Doppler Rx)
Bit27-28: 0x1 (DCM Max Constellation Rx)
Bit31: 0x1 (SU Beamformer)
Bit32: 0x1 (SU BeamFormee)
Bit34-36: 0x7 (Beamformee STS <= 80 MHz)
Bit40-42: 0x1 (Number of Sounding Dimentions <= 80 MHz)
Bit53: 0x1 (Partial Bandwidth Extended Range)
Bit55: 0x1 (PPE Threshold Present.
Note: PPE threshold may have some changes later)
Bit58: 0x1 (HE SU PPDU and HE MU PPDU with 4xHE-LTF+0.8usGI)
Bit59-61: 0x1 (Max Nc)
Bit75: 0x1 (Rx 1024-QAM Support < 242-tone RU)
*/
#define UAP_HE_MAC_CAP0_MASK 0x00
#define UAP_HE_MAC_CAP1_MASK 0x00
#define UAP_HE_MAC_CAP2_MASK 0x00
#define UAP_HE_MAC_CAP3_MASK 0x02
#define UAP_HE_MAC_CAP4_MASK 0x00
#define UAP_HE_MAC_CAP5_MASK 0x00
#define UAP_HE_PHY_CAP0_MASK 0x04
#define UAP_HE_PHY_CAP1_MASK 0x23
#define UAP_HE_PHY_CAP2_MASK 0x3E
#define UAP_HE_PHY_CAP3_MASK 0x88
#define UAP_HE_PHY_CAP4_MASK 0x1D
#define UAP_HE_PHY_CAP5_MASK 0x01
#define UAP_HE_PHY_CAP6_MASK 0xA0
#define UAP_HE_PHY_CAP7_MASK 0x0C
#define UAP_HE_PHY_CAP8_MASK 0x00
#define UAP_HE_PHY_CAP9_MASK 0x08
#define UAP_HE_PHY_CAP10_MASK 0x00
My question is why this masking has been done? Does that mean firmware does not support extended range format?
if yes, why are we able to set any value via mlanutl?
Regards,
Javad
已解决! 转到解答。
Hi @ocourson,
I thought HE capability should be same for all interfaces(mlan0, uap0), because it is radio-specific, but interestingly we realized that interfaces can have different HE capabilities(for example you can have ER set for mlan0 but not set for uap0).
We are using hostapd for starting AP and wpa_supplicant for starting STA. Fortunately wpa_supplicant(default build) unlike hostapd, doesn't change HE capabilities.
We are only interested to support ER in STA mode, so all we need is to setthose bits via IOCTL command before starting a STA.
Regards,
Javad
Dear @javadR3
I am not sure if the 88W9098 FP68 specific SW you are using is supporting HE extended range feature, I am checking that internally.
But for sure the generic FP92 SW available on github is supporting that feature.
Here is the test I did, with this setup:
- i.MX8MQ Linux 6.1.36
- 88W9098 base Azurewave AW-XM458-MA module, with PCIE9098--17.92.1.p136.131-MM6X17408.p2-GPL-(FP92) SW
- default wifi_mod_para.conf driver parameters (see attached file)
- using 88W9098 as STA (see attached wpa_supplicant.conf file)
By default HE extended range is not enabled, as we can see in the probe requests:
I stopped mlan0 interface, changed 11ax config using the attached 11axcfg.conf file:
mlanutl 11axcfg config/11axcfg.conf
Then started mlan0 interface; we can see the HE extended range is enabled:
Hi @ocourson,
thank you for testing, but you have tested in STA mode. Could you repeat your test in AP mode and see HE capabilities in propagated beacon packets?
In that case you would see the problem.
I believe driver is doing differently in case of STA and AP. I mean if you run a STA, driver doesn’t change pre-set HE capabilities via mlanutil.
Or you can change HE capabilities via mlanutil and then query them via netlink(iw phy). You would see that they are not same.
Dear @javadR3
It seems we do support partial ER (please see below reference snippet from captures on beacons), that's why that bit is enabled and we already verified we can transmit and receive in 106 RU tone.
Sniffer reference for beacon:
Regards,
Olivier
Hi @ocourson,
I thought HE capability should be same for all interfaces(mlan0, uap0), because it is radio-specific, but interestingly we realized that interfaces can have different HE capabilities(for example you can have ER set for mlan0 but not set for uap0).
We are using hostapd for starting AP and wpa_supplicant for starting STA. Fortunately wpa_supplicant(default build) unlike hostapd, doesn't change HE capabilities.
We are only interested to support ER in STA mode, so all we need is to setthose bits via IOCTL command before starting a STA.
Regards,
Javad
Hi @ocourson,
1, 2: custom yoco linux, using IMX8 as processor
3:
$ /usr/share/nxp_wireless/mlanutl r0ap0 version
Version string received: PCIE9098--17.68.1.p136.58-MXM5X17366.p32-GPL-(FP68)-dbg
4:
sudo insmod mlan-dbg.ko
sudo insmod moal-dbg.ko mod_para=nxp/wifi_mod_para.conf
attached wifi_mod_para.conf(renamed file because .conf was not allowed to be attached).
BTW, I don't think the problem would be related to any requested info.
Regards,
Javad