08-04-2014 08:55 PM
I am trying to configure an Aruba 7210 Mobility Controller for VoWLAN with Spectralink 8440 handsets. I've followed the Spectralink "VIEW CERTIFIED CONFIGURATION GUIDE - SpectraLink 8020/8030 and 8400 Series Wireless Telephones with Aruba Networks" document, but the handsets are intermittently unable to send/receive traffic. They appear to join the network properly, but the handset will display “network down” every few seconds. While on a call, the audio drops and resumes in sync with the frequency of the “network down” message.
I think I've narrowed down the cause of this to the EDCA settings. The configuration guide instructs to create station and ap EDCA profiles with mandatory admission control enabled. All other EDCA settings in the profiles are left as default. The EDCA profiles are then applied to the SSID profile. I have tried leaving the SSID profile with the EDCA profiles as part of its settings, with mandatory admission control turned off within each EDCA profile, but this does not work. The only way to get a stable connection is to set no EDCA profile on the SSID profile. I have also tried enabling and disabling the “AC Required” setting on the handset with all combinations of the settings already mentioned above.
The Spectralink handset logs contain a lot of the following entries:
processEvent:Initiating handoff due to TSPEC failure for UP :4
processEvent:Retrying control TSPEC with UP:4
Thanks in advance.
Solved! Go to Solution.
08-22-2014 06:39 AM
Has anyone got Spectralink 8400 series handsets working reliably with an Aruba 7210 controller? If so, please could you post an example of a working controller config, and what settings were enabled on the phone?
09-03-2014 10:15 AM
We have just started to see this issues as well. We are seeing the exact same behavior between our 8400's and the Aruba Controller (we have 6000 series controllers). We just upgraded from version 22.214.171.124 to version 126.96.36.199. The 8400's were working on the 188.8.131.52 version with the ECDA Parameter Station Profile applied before we upgraded. Now on version 184.108.40.206 I needed to turn this back to unconfigured before I could get a solid connection to our 802.1x authenticated wireless network.
09-04-2014 07:11 PM
Hi jmihalow, have you noticed a negative impact on call quality or any other effects since disabling EDCA?
Aruba TAC have been working with me to get the network properly configured for the handsets, and their advice was not to bother with EDCA.
The SSID I'm connecting the phones to is authenticated with WPA2-PSK, so I guess the auth method has nothing to do with it.
The controller I am having the issue on is also at 220.127.116.11. I have 2 campuses where I am rolling these devices out, the controller at the second site still being on 18.104.22.168. Before upgrading I will configure EDCA parameters and see if the problems occurs there.
09-05-2014 05:31 AM
Thanks for getting back to me feroscare, I really appreciate it. We currently only have a couple users using the wifi networks for voice-over-wireless so I don't really have a large pool to get a good response to judge. I will follow up with the couple I do have and see what they have to say. I'll let you know what I find out.
09-21-2014 08:26 PM - edited 09-21-2014 08:29 PM
Hi Jason, sorry I didn't respond to this topic sooner.
I was unable to reproduce the problem at my other site in the end. I think reason for this is that both the Spectralink handsets had been fully patched with the latest firmware. My guess is that the issue probably arose from some combination of earlier firmware versions. Both the controller and handsets are now updated at both sites where I've deployed these phones and the users are happy. Controller is 22.214.171.124 and phones are 4.6.1L.0038.
09-29-2014 01:04 PM
We ended up having to roll back to 6.3.5 because we were having connection issues with some critical laptops just dropping packets. I think this had to do with a 802.1K profile I had configured to help the polycoms no be so sticky with the APs. Now with the possible bash shellshock vuln we will have to patch again. I'll let you know if I run into any issues with the polycoms if we have to patch for this vulnerability.