cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4315
Views
0
Helpful
5
Replies

WAP371 Firmware V1.2.0.2 - Wireless Client Incompatibility

matthew1471
Level 1
Level 1

Hi Cisco,

Just deployed the really new firmware V1.2.0.2 (12 June 2015) for the WAP371 and noticed that 2 x Nexus 5 phones could no longer connect to the WiFi (no other devices seemed affected) on either 2.4Ghz or 5Ghz. I rolled back to the previous version (V1.1.2.3) and both phones connected again.

Of course it's possible it's a bug in the Nexus 5, but the Cisco should probably have a workaround for these devices to prevent user frustration.

I seem to find lots of little bugs in Cisco Small Business products and would love to help beta test some of these software versions before they get released, is there a way I could help get involved in testing (happy to sign an NDA if required)?

Thanks,
Matthew

1 Accepted Solution

Accepted Solutions

Hi Taylor,

Apologies from the ambiguity, from the other devices being connected I thought it was implied that the WiFi connection is present just it can't connect, but on reading my message back again it wasn't explicitly clear and I should have included it.

I have now spent lots of my time with Cisco this morning and Cisco have very kindly spent a lot of their time going through this issue over a remote session. Together we found a workaround and likely cause.

The new firmware adds support for what Cisco call "MFP" ("Management Frame Protection") and the new firmware enables this functionality by default, the release notes lists under "New in This Release" as "802.11w - PMF" which is for "Protected Management Frames" (note it's PMF in the standard but Cisco refer to it as MFP on the actual device).

The Cisco support engineer noticed that in the "Associated Clients" list, the "Up Time" was 00:00:00 with 0 packets from the station and 0 packets to the station. The WAP371 had caused the client to get stuck where it thought it was connected but not.

So I think the Cisco is losing track of some devices (bug?) and this is messing up it signing each of the control packets which is how a client can then get "stuck":

Jun 26 2015 13:02:24errhostapd[2642]trying to deauthenticate to station f8:a9:xx:xx:xx:xx, but not authenticated
Jun 26 2015 13:02:24errhostapd[2642]trying to update accounting statistics, station f8:a9:xx:xx:xx:xx not found
Jun 26 2015 13:02:24infohostapd[2642]STA f8:a9:xx:xx:xx:xx deauthed from BSSID 7c:69:xx:xx:xx:xx reason 3: STA is leaving IBSS or ESS
Jun 26 2015 13:02:11infohostapd[2642]STA f8:a9:xx:xx:xx:xx associated with BSSID 7c:69:xx:xx:xx:xx
Jun 26 2015 13:02:11infohostapd[2642]

Assoc request from f8:a9:xx:xx:xx:xx BSSID 7c:69:xx:xx:xx:xx SSID WIRELESS

 

Perhaps the Cisco implementation of PMF is defective (which I am inclined to believe given the mis-accounting in the WAP371 logs) or the Nexus 5 is terrible at PMF support (which for the Nexus 4 this was certainly true) but either way this new firmware can cause issues for some (and not all) specific wireless clients.

The MFP options are configured on a per-network basis and the new firmware sets it to "Capable" (in the picture I have overridden it to "Not Required"):

Setting it to "Not Required" causes the client to be able to connect again.

I have also raised with Cisco that the documentation states: "This field is visible only when WPA1 security and CCMP fields are enabled." .. which is incorrect, it is enabled only when WPA1 security is disabled.

Cisco know this issue as SR635440027

I will raise the issue with Google also.

I have signed up for the Cisco connect program as of this morning, let's see what happens :-).

View solution in original post

5 Replies 5

slstratt
Level 1
Level 1

Hello Matthew,

Thank you for using the Small Business Support Community!

When you say that the Nexus 5 phones aren't able to connect to the WiFi network, do you mean that the phones are able to see the network but not join it, or are they unable to see it entirely?

It doesn't sound like you made any changes to your wireless configuration after upgrading the firmware, but if you are able to include details or post a screenshot of your settings, it might let me get a better sense of the problem. If no other devices are experiencing issues, the problem may lie in the Nexus phones, as you pointed out. Until we can figure out what's going on, I would recommend that you rolled back to v1.1.2.3 if you want to keep your phones connected.

As for beta programs, I don't know of any other than the Customer Connection Program, and they only have betas for computer software. It wouldn't hurt to ask around, though!

Thanks,

Taylor

 

Hi Taylor,

Apologies from the ambiguity, from the other devices being connected I thought it was implied that the WiFi connection is present just it can't connect, but on reading my message back again it wasn't explicitly clear and I should have included it.

I have now spent lots of my time with Cisco this morning and Cisco have very kindly spent a lot of their time going through this issue over a remote session. Together we found a workaround and likely cause.

The new firmware adds support for what Cisco call "MFP" ("Management Frame Protection") and the new firmware enables this functionality by default, the release notes lists under "New in This Release" as "802.11w - PMF" which is for "Protected Management Frames" (note it's PMF in the standard but Cisco refer to it as MFP on the actual device).

The Cisco support engineer noticed that in the "Associated Clients" list, the "Up Time" was 00:00:00 with 0 packets from the station and 0 packets to the station. The WAP371 had caused the client to get stuck where it thought it was connected but not.

So I think the Cisco is losing track of some devices (bug?) and this is messing up it signing each of the control packets which is how a client can then get "stuck":

Jun 26 2015 13:02:24errhostapd[2642]trying to deauthenticate to station f8:a9:xx:xx:xx:xx, but not authenticated
Jun 26 2015 13:02:24errhostapd[2642]trying to update accounting statistics, station f8:a9:xx:xx:xx:xx not found
Jun 26 2015 13:02:24infohostapd[2642]STA f8:a9:xx:xx:xx:xx deauthed from BSSID 7c:69:xx:xx:xx:xx reason 3: STA is leaving IBSS or ESS
Jun 26 2015 13:02:11infohostapd[2642]STA f8:a9:xx:xx:xx:xx associated with BSSID 7c:69:xx:xx:xx:xx
Jun 26 2015 13:02:11infohostapd[2642]

Assoc request from f8:a9:xx:xx:xx:xx BSSID 7c:69:xx:xx:xx:xx SSID WIRELESS

 

Perhaps the Cisco implementation of PMF is defective (which I am inclined to believe given the mis-accounting in the WAP371 logs) or the Nexus 5 is terrible at PMF support (which for the Nexus 4 this was certainly true) but either way this new firmware can cause issues for some (and not all) specific wireless clients.

The MFP options are configured on a per-network basis and the new firmware sets it to "Capable" (in the picture I have overridden it to "Not Required"):

Setting it to "Not Required" causes the client to be able to connect again.

I have also raised with Cisco that the documentation states: "This field is visible only when WPA1 security and CCMP fields are enabled." .. which is incorrect, it is enabled only when WPA1 security is disabled.

Cisco know this issue as SR635440027

I will raise the issue with Google also.

I have signed up for the Cisco connect program as of this morning, let's see what happens :-).

The more I read about PFM / MFP the more I'm learning:

..and this morning a Windows 7 PC (but with a new 802.11ac adapter and new drivers) could no longer connect until I disabled this feature.. I think the WAP371 MFP has some bugs and itself may need to be more tolerant of buggy client implementations also (and this feature should probably not be enabled by default!).

You can check packet captures (needs to be of a radio interface) for where the WAP371 has rejected a client due to it already being associated by filtering on "wlan_mgt.fixed.status_code == 0x001e" which will show the client being refused : 0x001e = "Status code: Association request rejected temporarily; try again later (0x001e)".

The WAP371 sets a "Association Comeback time (TUs)" (wlan_mgt.timeout_int.value) time that is quite large also (201000) so maybe some of the timeouts should be reduced for these buggy clients at a minimum.

That you VERY much for your thorough (and accurate) post! I've been struggling with this for a couple-few hours, and I'm pleased to report that your workaround works in my case.

You wouldn't believe some of the crazy stuff people are suggesting about this out there :)

Thanks again.

David,

No problem. Glad it was useful.

Thanks for taking the time to let me know the post was useful.

Regards,
Matthew

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: