Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS)

6,558件の閲覧回数

Hi All

After analysis of the HostCmd_CMD_802_11_ASSOCIATE command constructed when connecting to an access point as a station I conclude that there are some fields not set and random data is sent instead.

This concerns the global routine wlan_cmd_802_11_associate():

The first location is at

/* Set the listen interval */

passo->listen_interval = wlan_cpu_to_le16(pmpriv->listen_interval);

/* Set the beacon period */

passo->beacon_period = wlan_cpu_to_le16(pbss_desc->beacon_period);

Here the listening and beacon periods are inserted into the header but there is a further field called
t_u8 dtim_period;
which follows that is not filled out and so has a random value (depending on what was originally in the buffer used)

The second location is at

pss_tlv = (MrvlIEtypes_SsParamSet_t *)(void *)pos;
pss_tlv->header.type = wlan_cpu_to_le16(TLV_TYPE_CF);
pss_tlv->header.len = sizeof(pss_tlv->cf_ibss.cf_param_set);
pos += sizeof(pss_tlv->header) + pss_tlv->header.len;

Here is is seen that an entry of type TLV_TYPE_CF is inserted, with a fixed length of 6 bytes but the 6 bytes are not written and so have random values (depending on the original buffer content).
It looks as through the content of cf_param_set can be optionally filled by scan data if the CF_PARAM_SET ID is received. If it is not received it may be best to not insert the filed but it if has been received it may be correct to copy that data in here.

Comments are welcome.

Regards

Mark

1 解決策

4,762件の閲覧回数

Hi, @mjbcswitzerland

Please see below for our internal team's feedback:

Attaching new updated patch with modifications.

Root Cause Analysis

DTIM Period: This field is optional in 802.11 association requests. The current code allocates space for it but never initializes it, resulting in random data being transmitted.
CF Parameter Set: This is a conditional parameter that should only be included if the AP advertises CF capabilities in its beacon or probe response. The current implementation:
- Always inserts the TLV_TYPE_CF entry
- Allocates 6 bytes for cf_param_set
- Never populates the actual data

Recommendations

Based on the issue analysis and customer feedback:

For DTIM Period:

Initialize to 0 or a sensible default value
Since it's optional, setting it to 0 is acceptable per 802.11 standard

For CF Parameter Set:

Conditional inclusion: Only add TLV_TYPE_CF if CF_PARAM_SET was received from AP
Proper data copy: If CF capabilities are advertised by AP, copy the actual CF parameter data
Remove if not needed: If AP doesn't advertise CF capabilities, don't include this TLV at all

Impact

Protocol Compliance: Current implementation violates proper 802.11 protocol implementation
Interoperability: Random data in association frames could affect compatibility with some APs
Security: Sending uninitialized memory content could be a minor information disclosure

Based on the above data, it seems like both of these values are either mandatory or optional based on received from AP, and that is the reason these two parameters are not set.

Please note that, since these two parameter are optional and not creating any other issue (at other locations), these changes are not required for other chipsets and codebase, You may need to test it and keep the changes at your end.

Please let me know whether have any other concerns on this case.

If no other concerns, please do not hesitate to mark my answer as a solution, so that we can close this case.

And please do not hesitate to create new case to us if you meet any other issue during using our products.

Best regards,

Christine.

元の投稿で解決策を見る

29 返答（返信）

1,817件の閲覧回数

Hello Christine

I have updated the SDK and can see various changes in the file mlan_join.c, however the uninitialised data exists still - there are no changes with regard to that.

Embedded Artists supplies a patch for their BSP (so that the board starts - eg. it can have a different HyperFlash that it needs to boot from) and this has nothing to do with the WiFi code. The WiFi code comes purely from the SDK.

Therefore this issue still exists in the most up-to-date WiFi code in the SDK.

Regards

Mark

1,773件の閲覧回数

Hi, @mjbcswitzerland

Our internal expert request to provide the patch.

I am not sure whether because they also have this board.

Would you mind share the patch to me?

You can send to my private working email so that protect the patch code.

I sent an email to you using my email address.

Best regards,

Christine.

1,905件の閲覧回数

Hi, @mjbcswitzerland

Thanks for your reply, Ok, I understood.

Can you help to confirm whether our understandings is sync/same with you？

============

Uninitialized Fields in Association Command
During the construction of the HostCmd_CMD_802_11_ASSOCIATE command inside wlan_cmd_802_11_associate(), certain fields within the command structure are never explicitly initialized. These include:

dtim_period (1 byte) following listen_interval and beacon_period.
The 6-byte cf_param_set inside the TLV of type TLV_TYPE_CF.

Impact of Uninitialized Data
Because the command buffer is reused, these fields retain random leftover values from previous memory content. This can lead to:

Incorrect DTIM period being sent to the AP, potentially affecting power-save and multicast delivery.
Random CF parameter values being included in the TLV, which may cause unpredictable AP behavior or negotiation failures.

Your Verification

You confirmed this by initializing the buffer with known patterns (0x55 and 0xAA) before the function runs and observing unchanged bytes after execution.
Screenshots show these bytes remain as the initial pattern, proving they were never written by the code.

Your Expectation
These fields should not remain uninitialized. They should either:

Be populated with valid data from scan results (e.g., pbss_desc->dtim_period for DTIM).
Or explicitly zeroed out if no valid data is available.
For TLV_TYPE_CF, if CF parameters were not received during scan, the TLV should be skipped or filled with zeros.

Root Cause

The association command builder does not fully initialize the command structure.
Optional fields are added without proper handling for missing scan data.

===========

Best regards,

Christine.

1,298件の閲覧回数

Hi Christine

I agree with the report - it is exactly as I understand (and see) the issue.

Regards

Mark

1,743件の閲覧回数

Hi, @mjbcswitzerland

Are you using 88W8801 on RTOS or on Linux?

If on RTOS, can you please let me know your host platform name? Is it our I.MX RT series? What is your SDK version and IDE version?

If on Linux, can you please let me know your host platform name? Is it our I.MX 6,7,8,9 series? What 's your Linux kernel version, what is your Wi-Fi driver version?

Do you have logs for this? or How could you detect this issue?

Please help to share more background of this issue, then we can discuss further.

Thanks,

Christine.

1,697件の閲覧回数

Hello Christine

I am working on an i.MX RT 1062 with the NXP WiFi library that is included in the MCUXpresso SDK.

MCUXpresso IDE v11.9.1 [Build 2170] [2024-04-19]

I don't know for sure what the SDK version number is but the project was originally installed on 26.8.2024. My SDk builder dash board however shows

SDK_2.14.0_EVK-MIMXRT1060

Below is a screen shot showing its mlan files and the first code issue where the dtim_period entry is not added to the command that it generates.; I see random data at the relevant byte locations in the command buffer that is created when looking at it with the debugger.

Regards

Mark

1,598件の閲覧回数

Hi, @mjbcswitzerland

I downloaded the same SDK version and checked what you mentioned.

The parameter is passed through IN HostCmd_DS_COMMAND *cmd.

Please see below:

 HostCmd_DS_802_11_ASSOCIATE *passo = &cmd->params.associate;

If my understandings is not correct, please let me know.

Or you can provide your debugger screenshot, so that I can better understand your concerns.

Best regards,

Christine.

1,539件の閲覧回数

Hi Christine

cmd

is an output buffer that is originally empty, and is filled during the routine and so cmd doesn't pass any values.

I'll send you debugger screen shots to show the issue the next time I am working with the debugger.

Regards

Mark

Regards

Mark

1,476件の閲覧回数

Hi, @mjbcswitzerland

Sure, please help to send the screenshot, so that we can better understand your meanings.

Best regards,

Christine.