Large delay from active PROBE to AUTHENTICATE when connection to Wi-Fi AP

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
BaRu_3629256
Level 1
Level 1
10 sign-ins 5 replies posted 5 sign-ins

I am looking into speeding up the time it takes for my device to connect to an AP. A network packet capture is showing a delay of about 2.2 seconds between the active probe response from my AP, and the device sending the Authentication packet to start the connection process.

 

My device uses an STM32F412 MCU + CYW4343W Wi-Fi/BLE chip, and application is built using WICED Studio 6.6.1 with ThreadX/NetX Duo.

 

The application performs a Wi-Fi scan, finds the proper AP, updates the DCT with the appropriate channel, BSSID, security for the AP, and then calls wiced_network_up().

 

I have added debug to WICED, and narrowed down the delay inside of wwd_wifi_join_specific(). The delay is encompassed in the process of sending the JOIN command to the chip and waiting for it to finish –
Call to wwd_sdpcm_send_iovar( SDPCM_SET, buffer, 0, interface ) (where the buffer points to ext_join_params)...

to...

wwd_wifi_join_wait_for_complete( &join_semaphore, interface ) returning success.

 

I tried changing the parameters for dwell times (to very small values) and number of probes (to 1) in ext_join_params as they were set to use the default values, but this didn’t seem to change behavior.

 

I captured a network sniff from my Google Pixel of the same process and saw next to no delay between PROBE and AUTHENTICATE, so the delay doesn't seem to be required.

 

I don’t see where the PROBE to AUTHENTICATE is controlled anywhere in the WICED SDK, so I am assuming this is somehow baked into the chip/firmware?

 

Am I missing any type of configuration that would speed this up? Is there anything I can change in the SDK, or is this process controlled by the chip/firmware?

 

My network sniff can't see what is happening on all the channels. Is it possible that the process of traversing the channels during the active probe is the cause of the delay? Does anyone know if the channel traversal stops once it gets a probe response? In my case, the channel has either been 2 or 3. I can try changing this to a higher number to see if it changes the timing at all.

0 Likes
1 Solution
Phanindra_I
Moderator
Moderator
Moderator
250 sign-ins 10 likes given 25 likes received

Hi,

This issue needs further testing and as a result moving it to a tech support case. Going forward, We'll interact in the case.

Thanks 

View solution in original post

0 Likes
10 Replies
Phanindra_I
Moderator
Moderator
Moderator
250 sign-ins 10 likes given 25 likes received

Hi,

Are you using any default application present in Wiced SDK or a custom application that you've created?

In case if it's a custom application, kindly use default application like "snip.httpbin_org" and let me know if the same delay is still observed.

Thanks

0 Likes

We are using a custom application. Our application is using 2-way SSL and it appears that "snip.httpbin_org" is using 1-way SSL, so I'm not sure if this will provide an accurate comparison.

My apologies for leaving out some details. Our application is using an AWS/MQTT TLS connection. Should I try one of the "demo/aws/iot/*" default applications, and report back?

Thanks

0 Likes

Hi,

Yes, you can use one of the default applications and let me know the result of your testing.

Thanks

0 Likes

Sorry for the confusion about the SSL handshake. I am looking at something else related to SSL and got it mixed up with this thread.

I ran the default "snip.httpbin_org" application and a network sniff shows the same delay from PROBE to AUTHENTICATE. The sniff I captured shows a delay of about 2.53 seconds.

0 Likes
Phanindra_I
Moderator
Moderator
Moderator
250 sign-ins 10 likes given 25 likes received

Hi,

I've captured the air traces during connection process and i've observed the delay as well. Firmware algo does a lot of things during connection process and i'm guessing that might be reason. I am closely looking into the firmware algorithm to pin point cause of this delay. If this delay can be reduced, i'll let you know the way to do it.

Thanks

0 Likes
CoreyW_81
Employee
Employee
50 sign-ins 50 replies posted 25 replies posted

PRI - what have you found in the firmware that could help reduce the delay?

0 Likes
Phanindra_I
Moderator
Moderator
Moderator
250 sign-ins 10 likes given 25 likes received

Hi,

This delay doesn't seem to be reducible. One thing i found is that we can use assoc params (wl_join_assoc_params_t) to limit the scan and there by speeding up the join process. To be specific, we can use chanspec_num, chanspec_list (part of "wl_join_assoc_params_t" structure). A test can be done by using these two parameters to check if the delay can be reduced.

Thanks

0 Likes
BaRu_3629256
Level 1
Level 1
10 sign-ins 5 replies posted 5 sign-ins

PRI,

Can you provide specifics on how I might change these values to affect the delay? I see where  chanspec_num, chanspec_list are set in wwd_wifi_join_specific(), but I see no comments or documentation in the code that describe these variables and how they are used.

0 Likes
Phanindra_I
Moderator
Moderator
Moderator
250 sign-ins 10 likes given 25 likes received

Hi,

I've tested the chanspec on my end and scan is not the thing that is causing the delay here. I am looking at other things and will let you know the result.

Thanks

0 Likes
Phanindra_I
Moderator
Moderator
Moderator
250 sign-ins 10 likes given 25 likes received

Hi,

This issue needs further testing and as a result moving it to a tech support case. Going forward, We'll interact in the case.

Thanks 

0 Likes