Reset Search
 

 

Article

Why am I getting a "comm error, re" CFG-STAT when adopting an AP on a WiNG controller?

« Go Back

Information

 
TitleWhy am I getting a "comm error, re" CFG-STAT when adopting an AP on a WiNG controller?
Symptoms
The AP is not broadcasting the SSID. When the command: "#show adoption status" is executed from the controller, the following results are displayed:
#sh adoption status
not adopted to any wireless controller

Adopted Devices:
---------------------------------------------------------------------------------------------------------------
DEVICE-NAME       VERSION         CFG-STAT         MSGS ADOPTED-BY        LAST-ADOPTION              UPTIME
---------------------------------------------------------------------------------------------------------------
AP7532-lab       5.8.2.0-030R    comm error, re..  No   RFS4000-lab     0 days 00:01:55     0 days 00:03:42



 
Environment
  • RFS4000/6000/7000
  • NX5500/7500/9xxx
  • VX9000
  • AP75xx series
  • AP65xx series
  • AP76xx series
  • WiNG 5.x
Cause
1. In this particular case, the AP model does not adhere to the regulatory requirements of the country in which it is installed.

An example of this would be a US model AP such as an
AP-7532-67030-US which is being used in Canada.

Although the county code in the RF-domain on the adopting controller is set to "ca", it will not be configured on the AP since this country code does not exist on US models and thus will prevent it from properly operating:


Config example:
  1. Output from controller:
#show run
!
!deleted for brevity
!
rf-domain default
location lab
timezone EST5EDT
country-code ca
use smart-rf-policy Standard
control-vlan 1
!
  1. Output from AP:
#show run
Model number is AP-7532-67030-US
!
!deleted for brevity
!
rf-domain default
no country-code
use nsight-policy default
!

2. Another scenario in which one could see 'comm error' is when adoption is going through multiple routers and MPLS networks. This can cause timeouts when the controller is trying to push the config to the APs:
Jun 20 08:58:13 2018: %USER-3-ERR: main.pyo: * * ERROR: receive update error: timed out
Jun 20 08:59:24 2018: USER: main.pyo: config-update-receiver blocking on accept()
Jun 20 08:59:24 2018: USER: main.pyo: config-update-receiver connection from 5E.86.4A.80
Jun 20 08:59:34 2018: %USER-3-ERR: main.pyo: * * ERROR: receive update error: timed out
Jun 20 09:00:40 2018: USER: main.pyo: config-update-receiver blocking on accept()
Jun 20 09:00:40 2018: USER: main.pyo: config-update-receiver connection from 5E.86.4A.80
Jun 20 09:00:50 2018: %USER-3-ERR: main.pyo: * * ERROR: receive update error: timed out
Jun 20 09:02:04 2018: USER: main.pyo: config-update-receiver blocking on accept()
Jun 20 09:02:04 2018: USER: main.pyo: config-update-receiver connection from 5E.86.4A.80
Jun 20 09:02:14 2018: %USER-3-ERR: main.pyo: * * ERROR: receive update error: timed out
Jun 20 09:03:54 2018: USER: main.pyo: config-update-receiver blocking on accept()
Jun 20 09:03:54 2018: USER: main.pyo: config-update-receiver connection from 5E.86.4A.80
Jun 20 09:04:04 2018: ap7532-733A74 : %DIAG-6-NEW_LED_STATE: LED state message unadopted-event from module cfgd
Jun 20 09:04:04 2018: %USER-3-ERR: main.pyo: * * ERROR: receive update error: timed out
Resolution
1. In the first scenario, the AP model must adhere to the regulatory standards of the country in which it is going to be installed. Before purchasing, configuring and installing an AP, make sure that the model is the correct one for the country it's going to be shipped to. 

Amongst others, the list of models might include:
  • US
  • WR
  • EU
  • IL
2. In the second scenario (multiple routers and MPLS networks) it is recommended to change the MTU size to a minimum and then try to push the config to the APs again.

CLI commands:
>en
#conf t
#mint-policy global-default
#mtu ?
  <900-1500>  Maximum packet size. Will be rounded down to nearest (4 + a
              multiple of 8).
#mtu 900
#com wr
#show context
mint-policy global-default
 mtu 900
If this step solves the problem, the MPLS network should be further investigated as there may be an issue with fragmentation.
Additional notes
If further assistance is required please contact Global Technical Assistance Center (GTAC).

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255