IOS 9 device and Hidden SSID

[markvall]

HI

MC4200

v6.1-2-29

ANy IOS9 device cannot connect to hidden SSID in meru. There seems to be a fix with v8.0-5-0, will this fix be backported to my version, since i cannot upgrade to 8 since it does not support AP320?

thanks

[MartJoha]

Hi Mark,

One customer of mine reported the iOS9 issue was solved when they upgraded to 7.0-9-1 and they are unsing AP320. However I have not confirmed myself on site so it might be some other reason they dont see the issue.

Mabye try this version and see? I think the release is stable so its fine to upgrade.

Edit: they are using a Virtual MC3200 

Br Martin

[JohaKarl]

Hello.

From what i heard from a Meru SE the problem will persist until Apple fixes it and its related to Vport on AP320 and IOS9. But is only on certain IOS dveices too so its very tricky. From what i understand no SD version has been able to fix this completly.

This issue is also with hidden SSID across multiple vendors i think.

[mnantel_FTNT · Accepted solution]

What is technically happening regarding the IOS9 issues specifically impacts virtual port SSIDs and has to do with Apple having implemented MAC address randomization during scans / probe requests sent by IOS9 devices. This was initially rolled out in IOS8, but was more unilaterally used in IOS9 (see https://nabla-c0d3.github.io/blog/2015/06/16/ios9-security-privacy/).

Virtual port derives a unique per-device BSSID partly from the MAC address information and thus at association time, the real device MAC, rather than the random MAC, gets used and causes association to fail due to the above assumption made by virtual port. One of the solution involves moving to native cell, at least if virtual cell isnt supported by your particular AP/SD version (generally, more of an AP chipset limitaton as far as virtual cell is concerned). Native cell will essentially result in unique BSSID per SSID per AP (not per client), and virtual cell will have unique BSSID per SSID (for all participating APs with support for virtual cell). Native cell will however result in a hard handoff when clients move from one AP to another. You can accelerate this handoff with 802.11r but I dont think it ever goes away (and then, do you have 802.11r support is the other question).

Apple incorporated these features as part of a privacy effort given that mobile device beaconing is getting increasingly used for shopper tracking. It had the unfortunate side effect of causing issues with virtual port, pushing for a switch towards virtual cell/native cell as far as Meru/FortiWLC is concerned.

Edit: this might have been obvious from the above, but an alternative is to push your Apple users to an SSID operating in native cell mode, meaning you dont need to completely turn off virtual port if you have devices that depend on its controller-managed roaming to perform well...

Hope this makes sense!

--

Mathieu Nantel

Principal System Engineer / Consultant Technique Senior, Office of the CTO

Fortinet

[NeilOlso1]

Just adding what I'm seeing on our campus.  Upgraded to SD 8.05 in early February to fix crash_service_manager issues.  We are AP832e in our Res Halls, ESS is Native Cell, SSID is broadcast.  Since then, Apple iphone 6 devices will not stay connected.  Iphone, 4s, 5, all work flawlessly. Android perfect.  Have not tested a iphone 6S.  Iphone 6 (IOS 9.2.1) will connect, and then just drop the wifi connection and not connect until the wifi on the iphone is turned off/on.  While this is happening, no new records display in the staition-log.  Only information shown in the log is the initial connection and the 2nd connection when the wifi card is turned off/on.  We are scheduled to revert back to 7.09 on March 3rd.  Any others seeing this issue or have a patch/fix on SD 8.05?

[markvall]

Just upgraded the Ipad to 9.3 and still the same problem. Meru has escalated this to Apple under BUG ID #

22800345, which has been outstanding for more than 6 months what are they waiting for to fix this?