shill: consider delaying disconnect notification if we are reconnecting and likely to get the same IP |
||||
Issue descriptionOS: R61/R62 (This is a suggestion from Sameer during discussion on AP-roaming bugs. I dont know how this would be implemented yet). Some enterprise AP configuration force you to reauthenticate when you switch APs between the same SSID (say 2.4 GHz and 5 GHz on the same physical AP). This causes shill to register a disconnect, bring down dhcpcd (ReleaseIP step) and fire it up again, only to get the same IP. Attached is an annotated net.log that shows this symptom. Can we delay sending the disconnect notification, and wait until we are sure we actually disconnected?
,
Oct 2 2017
Kevin, when clients roam with 802.11r, they perform authentication with the target AP while still connected to the current AP. Presumably, there isn't a disconnect when 802.11r clients roams (though I'm not entirely sure).
,
Oct 2 2017
Should we consider buying couple of APs that support 802.11r and set them up to try out the fast roaming?
,
Oct 2 2017
I am not sure if our Intel drivers support 802.11r today. They don't seem to support the related 802.11k RRM (radio resource management) going from the logs of this AP-roaming-related issue that we've been debugging this week (see: https://bugs.chromium.org/p/chromium/issues/detail?id=767448) 2017-09-20T19:51:43.261107+00:00 INFO shill[1235]: [INFO:wifi.cc(396)] ScanDone 2017-09-20T19:51:43.261267+00:00 DEBUG wpa_supplicant[601]: wlan0: WPA: using PTK CCMP 2017-09-20T19:51:43.261307+00:00 DEBUG wpa_supplicant[601]: wlan0: WPA: using KEY_MGMT WPA-PSK 2017-09-20T19:51:43.261323+00:00 DEBUG wpa_supplicant[601]: wlan0: WPA: not using MGMT group cipher 2017-09-20T19:51:43.261354+00:00 DEBUG wpa_supplicant[601]: WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 2017-09-20T19:51:43.261369+00:00 DEBUG wpa_supplicant[601]: FT: Stored MDIE and FTIE from (Re)Association Response - hexdump(len=0): 2017-09-20T19:51:43.261381+00:00 DEBUG wpa_supplicant[601]: RRM: Determining whether RRM can be used - device support: 0x0 2017-09-20T19:51:43.261390+00:00 DEBUG wpa_supplicant[601]: RRM: Insufficient RRM support in driver - do not use RRM 2017-09-20T19:51:43.261403+00:00 DEBUG wpa_supplicant[601]: wlan0: Cancelling scan request 2017-09-20T19:51:43.261425+00:00 NOTICE wpa_supplicant[601]: wlan0: SME: Trying to authenticate with 54:be:53:7c:55:43 (SSID='H369A7C5543' freq=2412 MHz) 2017-09-20T19:51:43.261439+00:00 DEBUG wpa_supplicant[601]: wlan0: State: SCANNING -> AUTHENTICATING 2017-09-20T19:51:43.261549+00:00 DEBUG wpa_supplicant[601]: EAPOL: External notification - EAP success=0 2017-09-20T19:51:43.261567+00:00 DEBUG wpa_supplicant[601]: EAPOL: External notification - EAP fail=0 2017-09-20T19:51:43.261578+00:00 DEBUG wpa_supplicant[601]: EAPOL: External notification - portControl=Auto 2017-09-20T19:51:43.261590+00:00 DEBUG wpa_supplicant[601]: nl80211: Authenticate (ifindex=3) 2017-09-20T19:51:43.261607+00:00 DEBUG wpa_supplicant[601]: * bssid=54:be:53:7c:55:43 2017-09-20T19:51:43.261617+00:00 DEBUG wpa_supplicant[601]: * freq=2412 2017-09-20T19:51:43.261634+00:00 DEBUG wpa_supplicant[601]: * SSID - hexdump(len=11): 48 33 36 39 41 37 43 35 35 34 33 2017-09-20T19:51:43.261645+00:00 DEBUG wpa_supplicant[601]: * IEs - hexdump(len=0): [NULL] 2017-09-20T19:51:43.261655+00:00 DEBUG wpa_supplicant[601]: * Auth Type 0 2017-09-20T19:51:43.268609+00:00 DEBUG wpa_supplicant[601]: nl80211: Authentication request send successfully
,
Jan 3 2018
,
Jan 15
|
||||
►
Sign in to add a comment |
||||
Comment 1 by cernekee@chromium.org
, Oct 1 2017