WL1837MOD: Reassociation request takes too long

Hi,

I'm sorry but I don't understand. Can you please explain from your screenshot where you see the entire 500 ms? Furthermore, can you provide linux kernel logs of those association requests? From this, we can try determine where the slowdown is, be it CPU or WL8 firmware. 

Lastly, it looks like you are using an old FW firmware version, can you update it from this repo? https://git.ti.com/cgit/wilink8-wlan/wl18xx_fw/ 

Hi,

1. In screenshot Relative Time column line 2 and 3 has difference of 0.28 s, sometimes it is more, sometimes it is less.

2. wpa_supplicant log, dmesg log, crash log

I attach wpa_supplicant log, the issue can be seen around "May 17 15:44:20 imx6sleg-mcg wpa_supplicant[239]: 1652802260.699903"
When I enable wlcore Driver Kernel Messages the issue can't be reproduced.
Also I attach a wlcore crash that is probably unrelated.

Please specify exactly what logs are you interested in.

3. Same issue with new firmware:
wlcore: PHY firmware version: Rev 8.2.0.0.246
wlcore: firmware booted (Rev 8.9.0.0.90)

Hi Arturs,

Could you also upload the wireshark capture? I find it strange that a re-association request occurs immediately. 

Can you verify that the SDIO frequency is measuring 50 MHz? I would like to ensure that there is not a data rate issue. 

1. Capture_1_full, Capture_1_roam_only
In Capture_1_roam_only you can see the issue occurs around packets 57, 65, 76, 86, 107 etc.

2.

# cat /sys/kernel/debug/mmc1/ios
clock: 50000000 Hz
vdd: 7 (1.65 - 1.95 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)

Or do you want me to measure SDIO clock with oscilloscope?

Hi Arturs,

It would also be good to probe the SDIO clock just to ensure. We will look over these logs and provide you an update.

Please give us until early next week.

Hi!

I'm sorry, but I can't probe the SDIO clock, I'm just a software guy.
Do you have any success with this case? I can provide any additional info if needed.

Arturs,

FYI - WiLink8 doesn't support fast roaming ( 802.11r ) by default . 3rd party "intelligraphics" provides support for fast roaming on WiLink8

Since you are concerned about fast roaming , you may want to contact them regarding the support . 

Seems like your SDIO bus speed is 50MHz , 4-bits wide - so that shouldn't be an issue unless signal integrity is compromised.

Best

SN

Hi,

Thanks for your answer.

In this case we are not interested in 802.11r. And this issue is not related to 802.11r.

Arturs,

802.11r can help you achieve faster roaming times in case that's a priority.

Are you able to ascertain that the delay is not on the supplicant side ? And what is the outcome if you enable wlcore logs ?

SN

The delay happens when wpa_supplicant issues a netlink command to change operstate to IF_OPER_DORMANT. After this change is done (after delay) wpa_supplicant continues normal operation.

With enabled more than one or two wlcore log topic the issue can't be reproduced. Which topic are you interested in?

Roaming is almost entirely handled by wpa supplicant i.e. scanning , selecting the AP, connecting to it etc. Seems like this issue is mostly related to supplicant 

We are using wpa_supplicant which is patched by TI from here git.ti.com/.../

Most of the supplicant patches are around adding 802.11s mesh support. These patches won't effect roaming timing .