- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We are working with the brcmfmac driver (version v4.14.34-2018_0716) + wpa_supplicant on CYW43455 on i.MX6 Linux.
In this case we are assocating to a WPA2-Enterprise network using PEAP-MSCHAPv2.
When roaming we often see longer than expected roaming times since the device is slow to respond to the first EAP Request. The trace extract below shows a case where there's 150 milliseconds between RX EAPOL and TX EAPOL.
The delay seems to be caused by the CYW43455 firmware being slow to send the "ROAM" event to the brcmfmac driver, which in turn prevents the wpa-supplicant from sending the first EAP response.
Here are some extracts from the driver and supplicant logs:
Aug 08 05:03:12.095765 kernel: brcmfmac: brcmf_rx_event Enter: mmc0:0001:1: rxp=86801540
Aug 08 05:03:12.095935 kernel: brcmfmac: brcmf_fweh_event_worker 1533704592.: event LINK (16) ifidx 0 bsscfg 0 addr 1c:aa:07:c7:6b:ca
Aug 08 05:03:12.095968 kernel: brcmfmac: brcmf_fweh_event_worker 1533704592.: version 2 flags 1 status 0 reason 0
Aug 08 05:03:12.098155 wpa_supplicant[536]: l2_packet_receive: src=1c:aa:07:c7:6b:ca len=69
Aug 08 05:03:12.098308 wpa_supplicant[536]: wlan0: RX EAPOL from 1c:aa:07:c7:6b:ca
Aug 08 05:03:12.098362 wpa_supplicant[536]: RX EAPOL - hexdump(len=69): 02 00 00 41 01 01 00 41 01 00 6e 65 74 77 6f 72 6b 69 64 3d 41 57 53 56 6f 69 63 65 2c 6e 61 73 69 64 3d 57 53 53 45 47 4f 54 41 57 4c 4
Aug 08 05:03:12.098551 wpa_supplicant[536]: wlan0: Not associated - Delay processing of received EAPOL frame (state=COMPLETED bssid=1c:aa:07:7b:5c:3a)
Aug 08 05:03:12.223541 kernel: brcmfmac: brcmf_rx_event Enter: mmc0:0001:1: rxp=86ac7cc0
Aug 08 05:03:12.223708 kernel: brcmfmac: brcmf_fweh_event_worker event ROAM (19) ifidx 0 bsscfg 0 addr 1c:aa:07:c7:6b:ca
Aug 08 05:03:12.223742 kernel: brcmfmac: brcmf_fweh_event_worker version 2 flags 0 status 0 reason 1
<some lines removed>
Aug 08 05:03:12.248937 wpa_supplicant[536]: TX EAPOL: dst=1c:aa:07:c7:6b:ca
Aug 08 05:03:12.248966 wpa_supplicant[536]: TX EAPOL - hexdump(len=16): 01 00 00 0c 02 01 00 0c 01 57 48 31 41 57 53 56
Any suggestions on why this delay occurs and how we can avoid it would be greatly appreciated. Could the "LINK" event from the firmware (which is not delayed) be used to trigger the start of EAP negotiation?
Best regards,
Fredrik
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Posting the firmware received in case system. Please check for roam time improvement in the attached firmware.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Could you attach the wpa_supplicant.conf that you used while setting up the connection with the enterprise network.
Regards,
Vinayak
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello vnak
We've tested various settings in wpa_supplicant.conf, for instance the following:
--
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1
eapol_version=1
network={
priority=120
ssid="AWSVoice"
scan_ssid=1
key_mgmt=WPA-EAP
eap=PEAP
identity="xxx"
password="yyy"
phase1="peaplabel=0"
phase2="auth=MSCHAPV2"
}
--
Best regards,
Fredrik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content