Wireless Access

We have started getting the Ascom i62 getting messaging only error after going from ArubaOS 6.4.4.19 to ArubaOS 6.5.4.14. We had swapped out AP-125/135 for AP-325, 3 months prior to doing the OS upgrade. So we have AP-225 and AP-325 I did not getting any reports of wireless VoIP issues. I had also gone around with a i62, there were no issues with signal. I did the OS upgrade walked around for about a week to see if any issues, no one mentioned any. About 3 weeks later, we started getting reports of phones going to Messaging Only for periods of 1 second to 10 minutes, a few were longer, but most in that range. Ascom TAC sent an updated version of the Ascom with Aruba guide. I went through it and made any changes that were different from the old guide. Applied the changes. It still was giving the Messaging Only error. I noticed the phones were on the 2.4 GHz channels. I had the person in charge on the phone configuration to swap one unit to the 5 GHz channels. It did not make a difference. I contacted the vendor that helped with the new design for the upgrade of APs. We did not see any thing on the wireless side.

    I contacted Aruba TAC. I worked with them. We went through the guide again. TAC made the suggestion for the Local Probe Request Threshold (dB)  and BC/MC Rate Optimization which were not in the guide. He made the suggestion after we looked at AirWave and saw the clients showing up as a sticky client even though ARM is enabled. So we enabled BC/MC and Local Probe from 30 to 20. I watched it for 3 days. I walked around with a phone showing the RSSI. I noticed that I could pass APs but the phone was still wanting to stay connected to an AP far away. The phone would raom to a new AP when it was hitting -87.

   I asked Ascom TAC, they said the phones would not do that and would roam at -70. I sent him  a picture of the phone display. He had me do a remote PCAP from the phone. I was able to capture the issue. I  sent the capture to Aruba TAC and Ascom TAC. Aruba TAC compared it to the config guide and also looked to see if anything was an issue. He did not. Ascom TAC said the beacon rate was too high, but in capture I pointed out that it was configured to what Ascom needed. Ascom said he needed an air PCAP. I did the requested capture. I sent it to the upgrade vendor, Aruba TAC and Ascom TAC. Vendor and Aruba saw nothing. Ascom said where in the capture is the issue. I told he wanted to see what was going on in the air not when the issue was happening because the issue is random. I did a search and found that other wireless vendors had issues with roaming and messaging only with the Ascom i62. I asked Ascom TAC about it. He suggested to upgrade the firmware on the phones. We did and it still is happening.

Has any one else have had this type of issue with the Ascom i62? I have attached the newer guide that the configuration is based on.

We've been using Alcatel wifi 8128 sets that are based off the Ascom i62. Over the years it's been hit or miss with working Aruba wifi and Alcatel wifi sets. We have set all the parameters that Alcatel needs but sometimes the sets do go into a "connecting..." mode when left on overnight or when roaming. Most of the 6.5.X code had issues with these wifi sets. Firmware updates on the wifi sets and multiple Aruba OS updates later we had a working partnership together. We ended up going to ArubaOS 8.x code to better stabilize this issue. We did have a working config with 6.4.x code but needed to move forward to get newer APs so we had to make the jump to 8.x. Good luck.

Thanks for the reply. We had no issues when running 6.4.x. It only appeared when we went to 6.5.x to bring an AP-365 online. I will pass this information to my boss. We might need to move to 8.x or downgrade to 6.4.x and lose the AP-365

jcameron,

 

6.5.2.0 did have a change in the power tables, that probably required anyone coming from an earlier version of ArubaOS to increase the transmit power  by 3 on each band:

https://www.arubanetworks.com/techdocs/ArubaOS/Consolidated_6.x_RN/Default.htm#Features/Features_6520.htm%3FTocPath%3DFeatures%7C_____103

That could certainly be part of your issue.

Thank you Curtis. I am not making the change on a Friday, but will do it on Monday.

hi jcameron

 

it's always good to go back to basics if your voice network has gone crazy. If possible, set up a test SSID on one AP. Lock the virtual AP to "allowed-band a". Connect a test phone to that test SSID. Note the channel and the power the AP is on. Do some testing to observe the maximum coverage radius of this AP, the behavior of the client as it gets to the edge of coverage etc.

 

Once you have a feel for it, put the same test SSID on another AP that is "next" to the first AP, e.g. the first expected roaming target. Even better (from a testing perspective, not a wifi design perspective) if that AP is same channel and same tx power. Later you can force them to be on different channels same UNII and the introduce more channel spacing. If the second AP is not on the same channel, you will need to be aware of the channel setup of the i62 etc (as per the config guide). Do the same kind of testing now with these two APs. Do you get expected roaming behavior ? Where is the handover point when walking from AP1 to AP2 ? Make sure to try AP225 to AP225 and AP225 to AP335 (and vice versa).

 

Consider (for testing) removing various config optimisations from your testing virtual-ap and ssid profiles to help rule them out, e.g. if your roaming is still bad then get rid of local probe request threshold on the test SSID profile, and as above, you can even go as far as forcing the two test APs to be on the same channel with same tx power. Related note: make sure that you have reasonably consistent tx powers across all of your APs, don't let ARM set a huge range, voice clients do not generally like it and it makes for uneven roaming. Also make sure your AP channels are matching the expectation of the i62 config (e.g. 9 max, DFS or not).

 

Regarding the intermittent connectivity issue - if you find that the voice behaviour is good, then leave the test phone on the test SSID for a longer duration and see if it develops any issue. Again, start with one AP, then move to two etc. AP 2xx and AP3xx have different chipsets, there can be variation in behaviour regarding all the knobs in the SSID profile, so perhaps start to rule them out - indeed you could start with a clean SSID profile and layer in the optimisations one by one and observe the behaviour after each (the Ascom guide touches a few things that are not so commonly tweaked, you may have hit on a combo that has issues).

 

This is a lot of work, unfortunately voice issues often can be. I'll wrap up by saying that my immediate suspicions based on your symptoms are:

 

a) AP has no target to roam to, despite starting to look at -70 it doesn't find the next AP for some reason, I'd be looking at DFS/channel mismatches, power level imbalance etc.

b) the connectivity issues may turn out to be something at the AP, rather than an RF related issue. The above testing suggestions are designed to rule in our out RF as a trigger, once that is done, it's easy enough to setup a capture (be it wifi or packet level) to catch the device and AP interaction. As it stands right now there are too many variables to know where to look (or you get into this circle of collecting all the things)

 

hth

-jeff