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.