Having problems with discovery of a select few APs

We are having a problem adding 5 out of the 6 APs at a site. We successfully added the CMM, both backhauls and 1 AP with subscribers. All settings are same and no issues with the network or IPs. Has anyone else had this problem?

How many free licenses do you have left?

Not sure of the exact number but we did check that and there were plenty free licenses.

Can you ping the AP’s or get to their web interface?

In Prizm, every single problem we have had getting components in, was either License or SNMP settings.

If you delete the one AP that you can see, can you accept one of the others?

Something to try anyway.

No problem with pinging the APs that won’t add. Also CNUT on the same server can manage them with no problems. Can access through IE with no problems. Have removed the one that adds and can only add that one back. IP addressing is not an issue because we changed the IPs between one that adds and one that does not, the same AP continues to add while the other 5 do not!

What kind of IP scheme are you using?

Are all six AP’s using the same scheme with sequential numbers?

ie: 10.17.200.xx1

Have you tried using the IP address that works on the other AP’s?
Remember that you can’t have the same IP in two units at the same time on the network.

If you are using VLAN? All AP’s need to be on the same Management VID.

If you can ping these accross your network and get to each via the web interface, it sure sounds like a setting in the Prizm setup under the Define Networks tab or an SNMP setting.

Double check the community string settings in the AP’s to the community string set in Prizm.

When you run the “discover new element” and type in the IP of the AP’s, what message comes back?

All testing shows that the problems is not an IP issue. All snmp settings are correct. Results in the discovery process say that the element was found but not added.

Does it say “Discovered Linked?”

Just had a similar issue with an SM. It was “Discoverd Linked” and would not accept for management.

In the SM,I deleted the community string, saved changes re-entered the community string, saved changes and rebooted. It came up “Discovered SNMP” the next time and accepted in.

We have seen this before, it seems that sometimes the initial programming does not take.

We have even reset radio to factory defaults and entered everything again and next time it works.

Who knows?

Have not tried the service affecting method of restoring the AP back to factory defaults. I did try changing the community string to something different and then back again.

One other idea.

In Prizm, delete the found AP Element if it comes in “Discovered Linked” and re-discover the AP with the IP address.

If any unit discovered, states under the “Mode” column, “Discovered Linked” instead of " Discovered SNMP", the unit will not be manageable in Prizm.

The SM I mentioned yesterday came in as “Linked” the first time.
I deleted it after checking all the settings in the radio and rebooted the SM.

I then deleted and re-discovered the SM and the second time it came in as "Discovered SNMP"

Once you get it in as “Discovered SNMP”, it will work.

That pretty much covers all the quirks we have run into accepting units into Prizm.

Good Luck, let us know how it ends up.


I will try it again and see what I can come up with.

Turns out that these APs that would not add into prizm, are from the same “KIT” when we installed the site. The DO have to be set to factory defaults and then reprogrammed, then they will add into prizm without any resistance. But until this is done, sorry they just won’t add! This will pose a serious service distuption during this process for APs with a high number of SMs. It will also require on site programming for EACH AP that won’t add without this process. I hope for others installing prizm that there are not many of these APs with this issue.