Wireless Access

Hey Guys ! 

Hoping you can help on this one...

So we've had a few RAP 109's go into regulatrory domain mismatch mode the past few weeks. ( E Flag )

This is a bit of an odd one as the RAP's in question have been working for fine on their own for months, then all of a sudden they get the E flag and stop broadcasting. Other RAP's on the site, also on the same controller are not affected at all.

The trend i have noticed is that the RAP's in question seem to get moved into the AP Specific folder on the controller. When i remove the RAP from that folder and powercycle the RAP, it comes right back up again and broadcasts the SSID's

In one or 2 cases, the issue has returned where i have repeated the process and they have come back up and seem stable

Has anyone ever seen this before?

Thanks in advance for any info :)

Currently running version 6.3.1.5 on the controller

HI,

You said, RAPs are moved to a specific folder. you mean moved to "AP-Group" ?

if they are moved to an other AP-group there is a chance for this domain mismatch.

we can configure different "Regulatory Domain" for each of AP-group.

As a work around, verify the Regulatory domain of the AP-group with which you have issue.

for your ref:

By Ap-specific , i meant the actual AP Specific tab ( As in the screen shot attached )

These RAP's were originally in their intended AP Group, but the problem is, some of them seem to move into this " Ap Specific " group on their own and then they stop broadcasting ( E flag )

I just hit the delete button on the RAP i want to get back online and once its powercycled, it comes back up

Hi,

It should not happened, AP can not change it's AP-group with out reprovision it. to know the reason you can use "show audit-trail | include <Apname>" this will give us some idea.

Please feel free for any further help on this.

chewbacca

AP's dont move to ap-specific config (aka ap-name), it is not a group - it is an override to the AP group; it just means someone has decided to add some specific config.

As it turns out, there is a bug in early 6.3.1.x that causes this exact issue if a RAP reboots and there is an ap-specific config existing and that config doesnt have a regulatory domain profile.

Either remove the ap-name directives for now and reboot the AP, or upgrade to 6.3.1.x latest and it will be solved. I am not sure if you can just add the regulatory domain explicitly to each ap-name, you can try it.

bug id for your reference is 98432, fixed in 6.1.3.6, but please only use latest 6.3.1.x if you upgrade.

regards

-jeff