Header Only - DO NOT REMOVE - Extreme Networks

Adding new APs, and they are showing up as "Inactive"


Userlevel 1
I'm installing new APs, and I can approve the APs, but they are showing up as "Inactive". They have a 00.00.00.00 addresses. I have tried rebooting, pending, moving to a different data drop, but I still can't get the APs to come up.

17 replies

Userlevel 7
Could you provide model number and serielnumber just to check it's not this issue...

https://community.extremenetworks.com/extreme/topics/new-aps-show-as-inactive
Userlevel 1
Ron wrote:

Could you provide model number and serielnumber just to check it's not this issue...

https://community.extremenetworks.com/extreme/topics/new-aps-show-as-inactive

12461288235N0000 is the Serial#
AP3605 is the model
Userlevel 1
12461288235N0000 is the Serial#
AP3605 is the model


[i]
Userlevel 4
Hi Laura,

try to set the AP to factory default and clear it from the Controller.
Chnage the Controller to controlled upgrade.
Maybe it's trying to do an uodate and it's not possible.
If you change to controlled upgrade it should maybe come with his own code.

Maybe the AP FW code is to old and the upgrade to this version is not possible.
Do you have another AP3605 on cour controller?

Otherwise attache to the console of the AP and look what he is trying.

Serial port for the console
115200

username:admin
password:new2day

Ask for his version

# cd /etc

# cat ap_version.txt
#!/bin/sh
export AP_VERSION=09.21.11.0004
export AP_IMAGE_TYPE=00000006
export BOARD_TYPE=ngap_p2

# cget c g ( config of the AP)

# tail -f /tmp/log/ap.log

Another option would be configure the AP manually.

Telnet/ssh to the AP or over the console port:

Login to AP, type following command:

cset dhcpc disable

cset ipaddr x.x.x.x ( IP Address of the AP)

cset ipmask x.x.x.x



cset authip 1 x.x.x.x #HWC esa port IP address

or this it depends on AP Type

set authipaddrs 1 x.x.x.x

(You can check this if you ask for the AP config via # cget c g)
capply

csave

reboot


If this doesn't help also please open a case with GTAC.

Good luck.

regards

Umut Aydin
Userlevel 1
Umut Aydin wrote:

Hi Laura,

try to set the AP to factory default and clear it from the Controller.
Chnage the Controller to controlled upgrade.
Maybe it's trying to do an uodate and it's not possible.
If you change to controlled upgrade it should maybe come with his own code.

Maybe the AP FW code is to old and the upgrade to this version is not possible.
Do you have another AP3605 on cour controller?

Otherwise attache to the console of the AP and look what he is trying.

Serial port for the console
115200

username:admin
password:new2day

Ask for his version

# cd /etc

# cat ap_version.txt
#!/bin/sh
export AP_VERSION=09.21.11.0004
export AP_IMAGE_TYPE=00000006
export BOARD_TYPE=ngap_p2

# cget c g ( config of the AP)

# tail -f /tmp/log/ap.log

Another option would be configure the AP manually.

Telnet/ssh to the AP or over the console port:

Login to AP, type following command:

cset dhcpc disable

cset ipaddr x.x.x.x ( IP Address of the AP)

cset ipmask x.x.x.x



cset authip 1 x.x.x.x #HWC esa port IP address

or this it depends on AP Type

set authipaddrs 1 x.x.x.x

(You can check this if you ask for the AP config via # cget c g)
capply

csave

reboot


If this doesn't help also please open a case with GTAC.

Good luck.

regards

Umut Aydin

What is the difference between these 2 "Upgrade Behavior" settings? What should it be on? It was on "Always upgrade", but I just changed it to "Upgrade when", because the APs that I have installed are not coming up, they are still saying Inactive in the Topology.

Userlevel 1
Umut Aydin wrote:

Hi Laura,

try to set the AP to factory default and clear it from the Controller.
Chnage the Controller to controlled upgrade.
Maybe it's trying to do an uodate and it's not possible.
If you change to controlled upgrade it should maybe come with his own code.

Maybe the AP FW code is to old and the upgrade to this version is not possible.
Do you have another AP3605 on cour controller?

Otherwise attache to the console of the AP and look what he is trying.

Serial port for the console
115200

username:admin
password:new2day

Ask for his version

# cd /etc

# cat ap_version.txt
#!/bin/sh
export AP_VERSION=09.21.11.0004
export AP_IMAGE_TYPE=00000006
export BOARD_TYPE=ngap_p2

# cget c g ( config of the AP)

# tail -f /tmp/log/ap.log

Another option would be configure the AP manually.

Telnet/ssh to the AP or over the console port:

Login to AP, type following command:

cset dhcpc disable

cset ipaddr x.x.x.x ( IP Address of the AP)

cset ipmask x.x.x.x



cset authip 1 x.x.x.x #HWC esa port IP address

or this it depends on AP Type

set authipaddrs 1 x.x.x.x

(You can check this if you ask for the AP config via # cget c g)
capply

csave

reboot


If this doesn't help also please open a case with GTAC.

Good luck.

regards

Umut Aydin

Also, when I SSH into the AP, it says:

# cat ap_version.txt
#!/bin/sh
export AP_VERSION=08.11.01.0161
export AP_IMAGE_TYPE=00000006

, but the controller and other working APs say 9.21.10.5
Userlevel 7
Always upgrade = as the AP connects to the controller the software is upgraded/downgraded to the default AP image which is generally/default the same software version that is running on the contoller

Upgrade when = you as a admin of the system could perform the upgrade/downgrade manually

It comes handy if you upgrade a controller pair and don't want to upgrade all APs at once (always upgrade) instead you could upgrade some APs at a time, wait till they are up and then upgrade some more (=upgrade when).

If the AP is not connected to the controller it's normal that you don't have the same software as the controller.
So fix the connection issue and the AP will connect and upgrade (if always is selected which you should set),
Userlevel 1
Ron wrote:

Always upgrade = as the AP connects to the controller the software is upgraded/downgraded to the default AP image which is generally/default the same software version that is running on the contoller

Upgrade when = you as a admin of the system could perform the upgrade/downgrade manually

It comes handy if you upgrade a controller pair and don't want to upgrade all APs at once (always upgrade) instead you could upgrade some APs at a time, wait till they are up and then upgrade some more (=upgrade when).

If the AP is not connected to the controller it's normal that you don't have the same software as the controller.
So fix the connection issue and the AP will connect and upgrade (if always is selected which you should set),

I'll just leave it on, "Always.." My APs are still showing as 'Inactive" and not coming up in the controller. MAC address shows 0000000s. They are on the network. I can ping and ssh to the AP. But the controller wont update the APs settings. I put in a work order, but havn't heard anything yet.

I also did the #tail -f /tmp/log/ap.log
I got this:

an 1 00:04:22 cap: 00180:ru_mgmt.c:2083-whsl_trans()-S_EDISC 64
Jan 1 00:04:23 cap: 00180:ru_mgmt.c:2083-whsl_trans()-S_EDISC 63
Jan 1 00:04:24 cap: 00180:ru_mgmt.c:2083-whsl_trans()-S_EDISC 62
Jan 1 00:04:25 cap: 00180:ru_mgmt.c:2083-whsl_trans()-S_EDISC 61

Where do I look to find out what this means?
Userlevel 7
could you ping the controller interface that is enabled for AP registration from the AP CLI ?

also if you do "cget config global" please check the result for DHCP mode, IP, mask, gateway....
does the output show a IP that a AP should get in this subnet
Userlevel 1
I was able to ping from the AP to the controller. I compared a working APs output to an Inactive AP:
I notice the Inactive AP doesn't have the ip addresses for:
lastAcIp (controllers ip)
authIpAddr 1
failover bmIp [1]
failover bmIp [1]

It does have it's correct ip address: These settings are there.
dhcp mode enable (1)
ip 10.17.29.45
mask 255.255.0.0
gateway 10.17.255.254
Userlevel 7
if the DHCP server is configured to provide the controller IP (option 78) I'd factory reset the AP to try if that solves it.

# cset fact

In case that doens't work try to set it static with ... (x.x.x.x = controller IP)

# cset authip 1 x.x.x.x
# capply
# csave

wait til it's saved and reset the AP
Userlevel 7
Might be also a good idea to delete the AP from the controller before you do what I've mentioned above.
Userlevel 4
Hi Laura,

could you please confirm if it's working now with the recomendations for other audience.

If not you should open a case with GTAC.

Thanks

Regards
Umut Aydin
Userlevel 1
Umut Aydin wrote:

Hi Laura,

could you please confirm if it's working now with the recomendations for other audience.

If not you should open a case with GTAC.

Thanks

Regards
Umut Aydin

It's not working yet. I have a ticket in with GTAC.
Userlevel 7
Umut Aydin wrote:

Hi Laura,

could you please confirm if it's working now with the recomendations for other audience.

If not you should open a case with GTAC.

Thanks

Regards
Umut Aydin

Hi Laura, was GTAC able to provide you with a resolution that you can share here?
i had this issue...it was resolved by approving the AP and turning ON both radios, they were admin'd down for some reason
Userlevel 3
The issue is now resolved. When APs are using DNS discovery method for controllers there should be two DNS records pointing to both controllers in a High Availability Pair:

https://gtacknowledge.extremenetworks.com/articles/How_To/How-To-Configure-an-AP-to-find-the-IdentiF...

Reply