Assigning to Matthew who committed 802.11r change. We're working to gather specifics of customer networks where disabling fast transition on AP resolved.

+ dwmclary - based on b/76021402 it looks like there were plans to put 802.11r behind an enterprise policy. Did that happen?

There is an issue where WiFi chips that don't support 11r can still pick the FT auth suites if the AP side supports them. The symptom of this would be inability to associate with a WiFi network that supports 11r for non-Intel devices. Do we have any logs I can take a look at, or do we know what boards have been experiencing connectivity problems?

Also, dwmclary is no longer with us. Removing him from the cc.

One customer has reported they are using Cisco APs with WPA Enterprise PEAP and fast transition set to "adaptive" and they are seeing connectivity issues with 68.

Do you know which devices have been experiencing issues?

One customer reported issue from WOLF device (3.8 kernel). We can ask what other devices are in use.

Logs at:

https://drive.google.com/file/d/1Ot7l5lVojgvPnHSePRbCgmhJZc-el4rY/view?usp=sharing

shared with google.com

attempt to connect in logs was at 12:01-12:02.

It looks like the issue is as I described. I'll get a few opinions on how we can best resolve this and come back with a fix as soon as I can.

based on offline conversation with Matthew:

- this issue affects devices which don't have Intel WiFi (and thus don't support 802.11r).
- those devices will not be able to connect to WiFi APs with 802.11r enabled.

so raising this to P0. My recommendation is we rollback 802.11r for now with a new M68 build so we don't break EDU during back to school. We can figure out how to enable 802.11r for Intel devices later.

Can we confirm that this would not impact any device that uses only Intel based WiFi chipsets (including all Intel WiFi chipets that we use, even the older ones)?

I am trying to see if we can sanely restart pushing 68 to some users.

Also, how quickly can we get a fix in place?

It sounds like we need to revert stuff from https://bugs.chromium.org/p/chromium/issues/detail?id=791202 ?

I'm looking at some of our autotest logs and it looks like Wolf actually does support FT, so there may be another problem I have yet to identify. I'm currently looking through the logs to see if I can find anything.

Jay, 
While we work on finding the root-cause, we'll keep the reverts ready.
However, if 802.11r was indeed an issue, we should have feedback reports from dev channel as well?

I think we've identified the issue:

The AP advertises its FT support via the Mobility Domain Information Element (MDIE). However, for normal FT networks, it must also support one of the FT Authentication Key Management (AKM) suites (either FT PSK or FT 802.1X) According to the logs, the AP indicates that it does support FT (via the presence of the MDIE), but fails to also support one of the FT AKM suites (it only supports regular 802.1X). As a result, wpa_supplicant attempts to do an FT auth/assoc with the AP using regular 802.1X and receives a status code 43 (invalid AKMP).

This is a direct result of adaptive FT that many Cisco APs support, which are configured to advertise an MDIE, but not any FT AKM suites. As far as I know, only iOS devices currently support adaptive FT.

Our current plan is to revert the change for M68 (https://chromium-review.googlesource.com/c/aosp/platform/system/connectivity/shill/+/1175152), verify the problem with our own setup, and provide support for adaptive FT if that is indeed the issue.

Re. #27, we are setting up our APs to test this. FYI as part of new feature testing, we already tested against Intel wifi chipsets 7260 and 7265 but we'll recheck again. We'll also check on some devices with Marvel and QCA chipsets.

Consider this merge approved for 68 and 69. 

Wolf has the older ath9k chipset. Lets check against that as well.

On the case 16641375, the previous owner requested a list of the brand of the affected devices, she replied mentionning: dell, and also Asus or a Lenovo.

I hope that helps.

Can we confirm a list of WiFi models we know supports this? Are we sure it is all Intel chipsets?

If we start rolling 68 out again we need to be sure, by default I am assuming this has been verified to work with:

Wilkins Peak 2: Intel 7260 (0x08b1)
Stone Peak 2: Intel 7265 (0x095a)

And after a few HWID spot checks, I believe all recent Intel systems to be using Intel WiFi, we can do a more thorough analysis on this but in general I believe we can unblock all Intel systems BayTrail and newer if the above chipsets are ok.

https://docs.google.com/spreadsheets/d/1bR3k_chfhVCRRU9KhcXYXrCKqHReeRm50k07V3U-2NU/edit#gid=1633601921 looks like it will be helpful in determining what we can keep pushing here.

It also makes me think we should verify against the various kernel versions, in case there is a problem not in the WiFi silicon itself, but in the underlying driver.

Once we have some results from Harpreet we can start pushing R68 systems again.

based on comment #32 it's not clear to me if Cisco 802.11r adaptive is a problem for just non-Intel WiFi devices or *all* devices.

@matthewmwang: can we get some clarity on our current understanding of scope?

I'd really like to see the CL to disable 802.11r submitted and merged down, I don't believe we have time to do full testing in stable, we just need to punt 802.11r past 68.

It should be a problem for all devices, although I think it might work (or not) depending on the Cisco AP that is used as well.

The revert CL is +2ed, so we're just waiting on the CQ.

+Alex: Is there anything we can do to make the handling of assoc-reject with status code 43 better? See https://bugs.chromium.org/p/chromium/issues/detail?id=874063#c14 logs 
Can we add this case to our testing? 

@Jay: the bug title is a bit misleading. from what we know so far, this is an AP quirky we are still trying to understand. Not sure if it applies to a sub-set 
of non-Intel wifi devices or if thats plain co-relation.

Pushed the cherry-pick to R68: https://chromium-review.googlesource.com/c/aosp/platform/system/connectivity/shill/+/1175153

Quick update: according to autotest results, all Intel devices can do FT reliably except glimmer (we're looking into this) and wizpig (tests are flaky). There are also a few non-Intel devices that can do FT. Devices that don't support FT might have trouble connecting to networks advertising FT support.

In regards to the adaptive FT problem, I used a Wolf device with Cisco APs in adaptive FT mode and WPA Enterprise PEAP, but I was unable to reproduce the problem - I had no trouble connecting. My best guess is that the AP/controller firmware version is outdated.

The next steps are to ensure that all devices can connect to networks that support FT and non-FT devices, and make devices more robust to Cisco's adaptive FT.

Given the revert has landed in 68, we can drop the 68 milestone label, we can fix this up in 69 or later.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

removing Merge-Approved-68 as afaik no further changes other than disabling 802.11r should be made to 68 on this bug.

I'm not convinced we should merge to 69 either, it seems like 802.11r really needs to go through full testing and baking from canary on down again.

I'd also suggest we consider NOT turning 802.11r on for older platforms that may be flaky or unstable on 802.11r.

Can we work to understand what the current plan is with 802.11r support and full testing?

Per crbug.com/791202#c78 with the 802.11r feature turned off in M68, devices are able to connect to AP that have AUTH(PSK) & AUTH (FT PSK) OR Auth(802.1x) & Auth(FT 802.1x) enabled together.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/hostap/+/14d097faf8b1966352a93193e93509836643ae96

commit 14d097faf8b1966352a93193e93509836643ae96
Author: Matthew Wang <matthewmwang@chromium.org>
Date: Thu Aug 23 19:09:26 2018

Add check for FT AKM use before setting MDIE

Make sure that a Fast Transition Auth Key Management suite (FT PSK
or FT 802.1X) is selected before setting the Mobility Domain IE.
Setting the MDIE without a FT AKM suite can result in assoc reject
status code 43 (invalid AKMP).

Per crbug/874063, some enterprise customers were unable to connect
to Cisco APs with adaptive FT configured because the AP would send
the MDIE without a FT AKM suite. Our device would send the MDIE
back without an FT AKM suite and proceed to get an assoc reject.

This fix is speculative - we haven't been able to reproduce the
assoc reject with our own Cisco AP set up.

BUG= chromium:874063 
TEST=1) Set Cisco AP to adaptive FT with 802.1X authentication, ran
        `wpa_debug excessive` on Caroline and attempted connection.
        Before this change, under the IE section of the Associate
        frame, the MDIE (ID 0x36) would be present. With this change,
        the IE is no longer present.
     2) Ran all network_WiFi_RoamFT autotests and they still pass.

Change-Id: I9ed9e39969d1f73ea3184a28ef2c4436829f625e
Reviewed-on: https://chromium-review.googlesource.com/1184251
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Matthew Wang <matthewmwang@chromium.org>
Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org>

[modify] https://crrev.com/14d097faf8b1966352a93193e93509836643ae96/wpa_supplicant/sme.c

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Friendly ping to get an update as it is marked as RBS. Thanks

The 802.11r change was reverted, so this should be fixed.

We now care about R69 though, we go stable next week, did we disable in 69 also?

We didn't. Just cherry-picked to R69 here: crosreview.com/1207733

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I am very uncomfortable re-enabling 802.11r in 69 unless we are certain of the fix.

Sorry, perhaps I was unclear. The change I just cherry-picked to 69 is the revert.

my bad then, yes, I"m ok with keeping 802.11r off in 69.

This is marked with both merge-approved-69 and merge-review-69, what action is needed at this time?

The following revision refers to this bug:
  https://chromium.googlesource.com/aosp/platform/system/connectivity/shill/+/c7c1be02ca6a8b66d38e0fff183ed08869bfc102

commit c7c1be02ca6a8b66d38e0fff183ed08869bfc102
Author: Matthew Wang <matthewmwang@chromium.org>
Date: Tue Sep 11 16:31:08 2018

Revert "shill: Enable FT by default"

This reverts commit 23162a0a60eef31e8611d9c94a845c8cd89c1676.

Reason for revert: crbug/874063

Original change's description:
> shill: Enable FT by default
>
> Enable Fast Transition by default.
>
> BUG=chromium:791202
> TEST=unittests, network_WiFi_RoamFT autotests, and manually connected
> to FT networks.
>
> Change-Id: Ibba52c52afe53a9d121515cfaac22892b729af6e
> Reviewed-on: https://chromium-review.googlesource.com/1020236
> Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
> Tested-by: Matthew Wang <matthewmwang@chromium.org>
> Reviewed-by: Kevin Cernekee <cernekee@chromium.org>

TBR=cernekee@chromium.org,kirtika@chromium.org,matthewmwang@chromium.org,chromiumos-cl-exonerator@appspot.gserviceaccount.com

# Not skipping CQ checks because original CL landed > 1 day ago.

BUG=chromium:791202,  chromium:874063 

Change-Id: I308609a395b49a301e46ed7da732c376b45cb604
Reviewed-on: https://chromium-review.googlesource.com/1175152
Commit-Ready: Matthew Wang <matthewmwang@chromium.org>
Commit-Ready: Bernie Thompson <bhthompson@chromium.org>
Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org>
Tested-by: Matthew Wang <matthewmwang@chromium.org>
Tested-by: Kirtika Ruchandani <kirtika@chromium.org>
Reviewed-by: Matthew Wang <matthewmwang@chromium.org>
Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org>
(cherry picked from commit 5631438588b29be19377fd2436a9ba710b11e31a)

[modify] https://crrev.com/c7c1be02ca6a8b66d38e0fff183ed08869bfc102/wifi/wifi_service.cc

It looks like Matthew *tried* to land this, but failed:

https://chromium-review.googlesource.com/c/aosp/platform/system/connectivity/shill/+/1207733

That would disable 802.11r for M69, as discussed previously. I just submitted it. It was also merged to M68 here:

https://chromium-review.googlesource.com/c/aosp/platform/system/connectivity/shill/+/1175153

The only thing remaining is to ensure that all regressions are resolved by the potential fix (only on M70+?):

https://chromium-review.googlesource.com/c/chromiumos/third_party/hostap/+/1184251

AFAIK, we don't have a proven local repro case so far, so the fix is only speculative, and probably should be tracked for M70.

I think I've got the appropriate labels now, and I'll leave it assigned to Matthew until he's satisfied that we're completely done on M70.

I also have another pending fix for an issue that affects our non-11r-capable devices: https://chromium-review.googlesource.com/c/chromiumos/third_party/hostap/+/1042869.

Also, I've discussed with Sameer and we've decided it would probably be best to do a progressive rollout. As I'm OOO for the next two and a half weeks and don't have time to implement this before I leave tomorrow, it's probably better that we push this to M71 (FT should already be disabled on ToT).

Sounds good.

> (FT should already be disabled on ToT)

Ah, right. So let's just call this Fixed, and we can track issues like this in bug 791202 (or new sub-bugs), since the Launch was never really closed.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/hostap/+/5f1be6ae1d9d95c778d3f8ebf02dca3b126fa618

commit 5f1be6ae1d9d95c778d3f8ebf02dca3b126fa618
Author: Matthew Wang <matthewmwang@chromium.org>
Date: Fri Oct 05 22:43:18 2018

CHROMIUM: wpa_supplicant: check for driver SME support when selecting FT suites

Fast BSS Transition (802.11r) cannot be performed without driver support for
Station Management Entity (SME). However, wpa_supplicant will select FT suites
(FT-PSK and FT-EAP) even when the driver does not support it. This change has
wpa_supplicant select the FT suites only if the driver supports SME.

BUG= chromium:874063 , chromium:791202
TEST=1) With a Kevin, which does not support SME, ran network_WiFi_RoamFT. Test
        fails with "Association timed out", and logs say "Failed to select key
        management type". Modified the test so that the AP supports both
        WPA-PSK and FT-PSK, and the test passed (prior to the change, supplicant
        would still select FT-PSK despite lack of driver support, and test would
        proceed to fail).
     2) With a Caroline, which supports SME, replicate above tests to make sure
        that suite selection logic remains intact. supplicant should default to
        FT-PSK and tests should pass in all circumstances.

Change-Id: Ida22f31a7bccc1e9f673c4b14ad80cd4d18d3a07
Reviewed-on: https://chromium-review.googlesource.com/1042869
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Matthew Wang <matthewmwang@chromium.org>
Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>

[modify] https://crrev.com/5f1be6ae1d9d95c778d3f8ebf02dca3b126fa618/wpa_supplicant/wpa_supplicant.c