10-28-2015 06:36 AM
Is a vap required to run a mesh network when I'm only using the wired Ethernet jack I really don't want any broadcasting of SSID's on this network. It's going to be used for a process control network only needs the wired port to work? I tested it with AP105's and it work perfectly without a vap but with AP175 it's not working. I'm using a 7010 controller on 18.104.22.168. When I called support he put a vap in there it seemed to work but later stopped working again. I haven't called support back again I'm planning on it today. I haven't found in any of the documentation where it says you must have a VAP. Searching I found a couple of post on this forum about the AP175 having a problem with the mesh psk encryption. I have used AP175's before but not using the encryption.
10-28-2015 06:40 AM
Lead Mobility Engineer @ Integration Partners
AMFX | ACMX | ACDX | ACCX | CWAP | CWDP | CWNA
10-28-2015 09:09 AM - edited 10-28-2015 09:11 AM
Thanks for the reply I figured out the issue the AP-175 does not support mesh encryption if I set the mesh profile to opensystem it works but when I add a PSK key and turn on WPA2/PSK I'm not able to provision the mesh point only the portal. I have a case open with Aruba the last support engineer said my problem was due to not having a VAP. I have asked my case be sent to another engineer.
If I'm using tunnel mode what security risk do I have with using an Opensystem mesh profile?
10-28-2015 10:10 AM - edited 10-28-2015 10:14 AM
EDIT- I have asked for Jason's notes as I haven't seen this before nor was I notified. I am going to look in to the bugs noted, etc in the release notes to see if this is the same issue as Jason found. Sorry for the trouble. Am leaving the below intact in case it applies to you, or someone else...
That is likely not the issue. You would need to get into the console of the mesh point to find out for sure, is that something you can do?
If a point comes up under 'open' but NOT as WPA2-PSK, that usually means that the MeshRecovery profile doesn't match, and that either the mesh point was provisioned on a different controller than the portal is on, *OR* the controller has since been replaced from when the AP was first deployed and the mesh point wasn't re-provisioned.
The only fix is to either do one of two things:
1. pull the mesh point down, bring it onto the LAN, purge, reprovision as a mesh point, and return to the pole.
2. Find a spare controller, make it a local of your master controller (so that it gets the required meshrecovery profile), then take the controller out to the AP, configure a DHCP scope on the local controller out at the pole, console in to the AP-175, purge, let it come up on your local with a DHCP so that the AP will find the local, provision the Mesh point into the correct group, disconnect and reboot the mesh point and watch it come up in the console to make sure it works, then check on the controller on the LAN.
Let me know if any of the above conditions ring a bell in regards to how the point was deployed or if the controller has since been replaced from when the AP mesh point was first deployed.
Sr. Techical Marketing Engineer
10-28-2015 11:54 AM
Working with Aruba support we were able to get it working by disabling ARM and VHT setting a static channel for radio A. I also shorted the PSK down some I had been using 63 digits. Thanks for the reply.