Meru IOS9 Issues

[boogster]

Hi Guys

 

I have been looking into this but have had no luck so far. Our wifi network has stopped working on Apple Ipads/Iphones on IOS9. We have no problems with laptops or android. We have a Meru MC1500 controller with 30 x AP320 APs. It recognises the SSID but constantly says wrong password etc which is not the case. This is causing no end of problems and am wondering if someone who has experienced this has found a resolution and could help us out as we would be eternally grateful.

 

I understand meru is no longer and has been taken over by another company.

 

Thanks in advance

Edited May 26, 2016 by boogster

[Sibrows]

Have you tried talking to Fortinet?

 

They've been reasonably responsive when I've raised issues.

 

We have one re-occuring issue but overall iOS devices on iOS9 are working for us without issue.

[boogster]

Tried fortinet but had no response as of yet. Anyone got an idea of how we resolve this as very frustrating for iPad users within the school.

 

Thanks

[SpaceInvader83]

There is an ongoing issues with the AP320's and iOS 9 , the updated KB is below. At my site i've turned on native cell and this seems to have cured the issue but obviously will affect some roaming capabilities eg: VOIP.

 

[h=4]Customer Support Bulletin CSB-160302-1[/h]

 

[h=4]Vport-IOS issue[/h]

[h=4]2016-03-03[/h]

 

 

 

Subject: Vport-IOS issue

Released: 2016-03-03

Modified: 2016-03-03

Product: Fortinet Infrastructure Wireless

 

Description:

[h=2]The purpose of this bulletin is to raise awareness about known interoperability issues between Apple Devices (IOS 9.0 & later) and legacy Meru branded AP models operating in Virtual Port technology mode. The Meru Virtual port technology requires a real MAC address of the client device to provide Wifi service. However, Apple introduced the following behavioral changes with their iOS 9.x releases.[/h][h=2]1) Caches the network for certain amount of time, which results delay in updating the newly created network (CSSID – aka BSSID specific to the client in VPORT).[/h][h=2]The above caching causes iOS clients send Auth request to the initially populated network, which is ignored by VPORT AP. However it succeeds after their network cache timeout, when the client updates with new network list. This results in delayed connection of iOS client to Wifi network.[/h]2) iOS mac randomization also results in creating multiple networks for the same client, and hence affects connectivity. This results in delayed connection of iOS client to Wifi network

[h=2]The further modification in the behavior of this feature in Apple IOS 9 version for probe request frames caused an interoperability issue.[/h][h=2]The altered behavior is described as follows:[/h][h=2]The Apple client devices no longer send probe frames, to prevent disclosure of mac address in the probe frame, instead they passively scan for beacon broadcasts from APs within range. Additionally, the Apple client devices use virtual mac addresses which they change randomly. These mac addresses do not correspond to any known vendors (OUI database). The combination of this new altered behavior patterns is causing the interoperability and incompatibility with legacy virtual port technology implementations.[/h]Possibly Affected Products:

Virtual port is supported only on AP300 (AP301, AP310, AP311, AP302, AP320) and AP433. Hence, this affects all the above mentioned models of APs.

Workarounds:

Fortinet has identified an interim workaround that can be applied to relieve these symptoms in most cases, but the workaround may not be applicable to all scenarios as there are different variables that may come into play.

Workaround Option 1:

Disable Virtual port:

Disabling Virtual port solves the issues with IOS9 however, this breaks the virtualization architecture and the system no longer controls the roaming of Wifi devices. Instead, the roaming decisions will be handled by the Wifi devices themselves (similar to how it works with legacy multi-channel architectures).

Upon disabling Virtual port, you can still run the network on single channel or fall back to multi-channel depending on the requirement.

If your deployment has VOIP, single channel and Virtual port supported roaming is required for seamless VOIP experience, if the VOIP is deployed on 2.4 GHz RF band, Vport can be disabled on 5 GHz (all apple devices support 5 GHz) only and keep the Virtual port enable on 2.4 GHz radio for VOIP.

To disable vport in 5 GHz radio

GUI->Configuration->radio->select interface 2 for all the Aps (do not change this for AP models that does not use virtual port) refer page 1 for AP models that requires change

Click Bulkupdate->select “native cell” under RF Virtualization mode

 

Same option in 5.3 has different naming, follow same steps as above till you select bulk-update after which

Change “Virtual cell” to “OFF”to disable Virtual port at radio level in 5.3 & older versions. No further changes required in ESS profile.

If you do not want to opt for workaround 1, you can follow the below instruction to reduce/workaround the impact.

Workaround Option 2:

Steps given below solve the issue in most cases but are not 100% effective.

With changes detailed below in place, you would see IOS 9 devices connect successfully but only after couple of failed attempts.

Note: These steps are intended for customers running System Director Versions 6.1 and Later.

Changes required on each ESS-Profile with RF virtualization mode set to Virtual port

GUI->Configuration->ESS->select the ESS profile and click edit

 

If Band steering is disabled,

Follow the items (a), (b), ©, (d), (e)

From the controller GUI navigate to Configuration > Wireless > ESS.

From here, individually select each ESS-Profile that uses Virtual port and apply the following changes if not already present:

a) SSID broadcast is set to ON

b) SSID broadcast preference on Virtual Port is set to Till-Association

c) After all ESS-Profiles reflect the above changes, from the controller GUI, go to Maintenance > File Management

On the AP Init Script tab, click New, and when the dialog box comes up, paste the following script:

For Aps with two radios:

radio parentbeacon radio0 never

radio parentbeacon radio1 never

For Aps with three radios (AP433):

radio parentbeacon radio0 never

radio parentbeacon radio1 never

radio parentbeacon radio2 never

Here's an example for the AP320 script named iOS9PB.scr :

 

click the “Save” button and you can view the script by selecting the script file name and click “View”to confirm the changes were applied.

If you already have a default boot script in place, no need of creating a new script instead just edit the file.

How to check if there is a bootscript applied?

GUI-Configuration->devices->controller->

Look for the script file (file name with .scr extension) in the section “Default AP init Script”, Edit the file (instead of creating a new one as mentioned img 03)

To edit the file

GUI->Maintenance->File management -> under AP init Script-> check the box and select “Edit”

Append already existing lines with following lines

“radio parentbeacon radio0 never”

“radio parentbeacon radio1 never”

Click Save and follow steps (d) and (e)

If Bandsteering is enabled, Small modification required in Item (c )

Eg: below (GUI->configuration->select ESS profile->edit->Bandsteering mode like shown below

 

Recommended band steering configuration

• Band steering to A band

• Band steering Timeout to 1 second

Follow items (a), (b), (d) & (e)

Small change is required in option ©, instead of two scripts lines, we only need script to be applied on radio1 which is 5 GHz band like below.

“radio parentbeacon radio1 never”

 

Below two steps are common for both the check points (with bandsteering Enabled and Bandsteering disabled)

(d) Now navigate to Configuration > Devices > APs.

From here select the AP's you want to load the AP script to:

Click the Bulk Update button on the bottom right of the screen. Now check the box on the AP Init Script row, and enter the name of the script you entered earlier, this example uses the iOS9PB.scr script:

 

Click “OK”.

(e) Reboot the AP's that need the Init Script.

Go to the Maintenance screen GUI-Maintanence, and it will take you to the page as shown below. Select the appropriate AP's for those the script to be applied, and then click “Reboot “on the bottom right side of the window.

 

The AP Init script will take affect after the AP's are rebooted, once rebooted, test iOS9 devices to ensure proper connectivity.

For Release versions on 5.3 or older: There is no GUI option to add boot-script.

Please Follow the below steps to apply through CLI. These steps are only for adding new boot-script, if you already have one and need to edit the existing boot-script. Please contact support as it requires engineer level access for customizing the scripts.

Adding Boot-script on 5.3 code version

Open Putty or teraterm or any similar application to get SSH access to the controller

Open notepad and add the following line according to the AP model

For Aps with two radios:

radio parentbeacon radio0 never

radio parentbeacon radio1 never

For Aps with three radios (AP433):

radio parentbeacon radio0 never

radio parentbeacon radio1 never

radio parentbeacon radio2 never

Save the notepad file with extension “.scr”

Eg: ios9script.scr

login to controller CLI

Controller# cd ATS/Scripts

Controller# copy ftp://anonymous@/ios9script.scr .

Controller#dir

####You should see the file in the list####

Controller#configure terminal

Controller (conf terminal)# boot-script ios9script.scr

Controller (conf terminal)#exit

Controller#show controller

####Now you should see the following line in the output ####

Default AP Init Script : ios9script.scr

####Then Reboot the Aps to push the script####

Controller#reload ap

After all the Aps comes back Enabled/Online, do the following and close the session.

Controller#cd images