• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 1395 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/WL1831MOD: Failing to reconnect to access point

Neil Atkinson
Intellectual 270 points
Part Number: WL1831MOD
Other Parts Discussed in Thread: WL1831

Tool/software: Linux

Hi


I am investigating an issue with a linux based platform with a WL1831 Murata module. The issue occurs after the following events:

1. Boot up the linux platform and load the wl18xx kernel modules
2. Start the wpa_supplicant daemon and wait for the WL1831 to connect to the access point
3. Change the channel of the access point OR disable / re-enable the access point
4. Wait for the WL1831 to reconnect to the access point
5. Again change the channel of the access point OR disable / re-enable the wifi

The issue is that the WL1831 fails to reconnect to the access point the second time.

The WL1831 firmware is from the R8.5 tag.
The firmware versions are:
PHY firmware version: Rev 8.2.0.0.224
firmware booted (Rev 8.9.0.0.31)

The linux kernel we are using is 2.6.33.7.2-rt30
The driver modules for the WL1831 are backported from Linux version v3.14.22
The wpa_supplicant is v2.6

The access point is an EDIMAX pro WAP1200

I have attached logs from the driver and the wpa supplicant.

What I can see from the logs and some extra debugging is that during reconnection to the access point at step 4, the reconnection reaches the 4WAY HANDSHAKE state and then fails. The wpa supplicant then attempts to reconnect again but this time succeeds.

At the point when the 4WAY HANDSHAKE fails, the wpa supplicant log shows a NL80211_CMD_DEL_STATION event and NL80211_CMD_DISASSOCIATE event received from the driver. During the handling of the disassociation, the wpa supplicant log shows it deauthenticates (at 82.359115: wlan0st: SME: Deauthenticate to clear driver state).

I looked at the wpa supplicant code that handles deauthentication and found that a flag called ignore_next_local_deauth is set. This appears to be used by the MLME deauthentication event handler to ignore deauthentication events if the deauthentication event was locally generated.

The next deauthentication event that follows this is after step 5 when the connection drops from the second channel change. In the wpa supplicant log you can see that the deauthentication event is ignored (at 130.254574: nl80211: Ignore deauth event triggered due to own deauth request) due to the above flag still being set. This results in the wpa supplicant still indicating it is connected, when the driver isn't.

Its at this point I am a bit lost so I would be grateful for any suggestions on how to fix this issue.

wl18xx_driver_module.log

wpa_supplicant.log

  • 0
    TI__Mastermind 35795 points
    Hi Neil ,
    You are using a very old version of WiLink8 driver with latest wpa supplicant. I guess this is mostly since you are on linux kernel 2.6.x . This seems to be mostly a wpa supplicant bug. I see an online patch that should be part of wpa supplicant 2.6 but you can still consult it since it seems for similar issue : patchwork.ozlabs.org/.../

    Saurabh
  • 0 in reply to S
    Intellectual 270 points

    Hi Saurabh

    Thanks for your suggestion.

    You are right in that we are currently stuck with this old version of the WiLink8 driver until we can update the linux kernel.

    The description of the patch you mention is not quite the behaviour I am seeing as the wpa supplicant log does not show that a mlme deauthenticate event has occured after the 'Deauthenticate to clear driver state' (see at timestamp 82.359115). So the flag will not get cleared.

    I do have a work around that I have implemented in our application, which detects this scenario and then sends a 'reattach' to the wpa supplicant. However, I was curious to know if this issue was reproducable on the latest versions of the wpa supplicant and driver. Unfortunately, I do not have a platform I can try this on.

    Kind regards

    Neil

  • 0 in reply to Neil Atkinson
    TI__Mastermind 35795 points
    Hi Neil ,
    I tested a scenario where i connected WiLink8 DUT to AP on channel 6 successfully. Then i changed AP channel to 1, DUT reported beacon loss, got disconnected and re-connected successfully to the AP. Then i changed AP channel to 11 and saw the same behavior - beacon loss, disconnection and successful connection. So DUT connected ok the second time as well. I am using wpa supplicant 2.6 and a very recent version of WiLink8 driver.

    Saurabh
  • 0 in reply to S
    Intellectual 270 points

    Hi Saurabh

    Thanks for confirming that this issue is not reproduceable on a recent version of the driver. At least, I know if and when we do update the kernel and subsequently the driver, we (hopefully) won't see this issue.

    Thanks again for your help.

    Kind regards
    Neil