Discovery loop for AP 1832i

[agent00007]

I have a 1852i AP running as controller. I have been having issues where APs (19 of 1832i) not all being able to join the controller.

Controller and APs have been upgraded to 8.10.196. After troubleshooting I have disconnected all APs and factory reset the controller and configured it again. Very little configuration has to be done.
I have then factory reset one of the APs and connected it to the network again. It is not join the controller.

From the console I only see this

[*08/23/2024 13:27:34.9744] Discovery Response from 192.168.0.2
[*08/23/2024 13:27:34.9744] Discovery Response from 192.168.0.2
[*08/23/2024 13:27:44.0000]
[*08/23/2024 13:27:44.0000] CAPWAP State: DTLS Setup
[*08/23/2024 13:28:41.0422]
[*08/23/2024 13:28:41.0422] CAPWAP State: DTLS Teardown
[*08/23/2024 13:28:41.1421] upgrade.sh: Script called with args:[ABORT]
[*08/23/2024 13:28:41.1821] do ABORT, part2 is active part
[*08/23/2024 13:28:41.2021] upgrade.sh: Cleanup tmp files ...
[*08/23/2024 13:29:05.9144] Discovery Response from 192.168.0.2
[*08/23/2024 13:29:05.9144] Discovery Response from 192.168.0.2
[*08/23/2024 13:29:15.0000]
[*08/23/2024 13:29:15.0000] CAPWAP State: DTLS Setup
[*08/23/2024 13:30:12.0522]
[*08/23/2024 13:30:12.0522] CAPWAP State: DTLS Teardown
[*08/23/2024 13:30:12.1521] upgrade.sh: Script called with args:[ABORT]
[*08/23/2024 13:30:12.1921] do ABORT, part2 is active part
[*08/23/2024 13:30:12.2221] upgrade.sh: Cleanup tmp files ...
[*08/23/2024 13:30:36.9444] Discovery Response from 192.168.0.2
[*08/23/2024 13:30:47.0000]
[*08/23/2024 13:30:47.0000] CAPWAP State: DTLS Setup
[*08/23/2024 13:31:44.0222]
[*08/23/2024 13:31:44.0222] CAPWAP State: DTLS Teardown
[*08/23/2024 13:31:44.1321] upgrade.sh: Script called with args:[ABORT]
[*08/23/2024 13:31:44.1621] do ABORT, part2 is active part
[*08/23/2024 13:31:44.1821] upgrade.sh: Cleanup tmp files ...
[*08/23/2024 13:32:08.8944] Discovery Response from 192.168.0.2
[*08/23/2024 13:32:08.8944] Discovery Response from 192.168.0.2
[*08/23/2024 13:32:18.0000]
[*08/23/2024 13:32:18.0000] CAPWAP State: DTLS Setup
[*08/23/2024 13:33:15.0422]
[*08/23/2024 13:33:15.0422] CAPWAP State: DTLS Teardown
[*08/23/2024 13:33:15.1421] upgrade.sh: Script called with args:[ABORT]
[*08/23/2024 13:33:15.1821] do ABORT, part2 is active part
[*08/23/2024 13:33:15.2021] upgrade.sh: Cleanup tmp files ...
[*08/23/2024 13:33:39.9144] Discovery Response from 192.168.0.2
[*08/23/2024 13:33:49.0000]
[*08/23/2024 13:33:49.0000] CAPWAP State: DTLS Setup
[*08/23/2024 13:33:49.3399]
[*08/23/2024 13:33:49.3399] CAPWAP State: Join
[*08/23/2024 13:33:49.5198] Sending Join request to 192.168.0.2 through port 5256
[*08/23/2024 13:34:46.1321]
[*08/23/2024 13:34:46.1321] CAPWAP State: DTLS Teardown
[*08/23/2024 13:34:46.2321] upgrade.sh: Script called with args:[ABORT]
[*08/23/2024 13:34:46.2621] do ABORT, part2 is active part
[*08/23/2024 13:34:46.2921] upgrade.sh: Cleanup tmp files ...
[*08/23/2024 13:35:00.8875] Discovery Response from 192.168.0.2
[*08/23/2024 13:35:00.9075] Discovery Response from 192.168.0.2
[*08/23/2024 13:35:10.0000]
[*08/23/2024 13:35:10.0000] CAPWAP State: DTLS Setup
[*08/23/2024 13:36:07.0222]
[*08/23/2024 13:36:07.0222] CAPWAP State: DTLS Teardown
[*08/23/2024 13:36:07.1221] upgrade.sh: Script called with args:[ABORT]
[*08/23/2024 13:36:07.1621] do ABORT, part2 is active part
[*08/23/2024 13:36:07.1821] upgrade.sh: Cleanup tmp files ...
[*08/23/2024 13:36:31.9244] Discovery Response from 192.168.0.2
[*08/23/2024 13:36:31.9244] Discovery Response from 192.168.0.2
[*08/23/2024 13:36:42.0000]
[*08/23/2024 13:36:42.0000] CAPWAP State: DTLS Setup
[*08/23/2024 13:37:39.0322]
[*08/23/2024 13:37:39.0322] CAPWAP State: DTLS Teardown
[*08/23/2024 13:37:39.1421] upgrade.sh: Script called with args:[ABORT]
[*08/23/2024 13:37:39.1721] do ABORT, part2 is active part
[*08/23/2024 13:37:39.2021] upgrade.sh: Cleanup tmp files ...
[*08/23/2024 13:38:03.9244] Discovery Response from 192.168.0.2
[*08/23/2024 13:38:13.0000]
[*08/23/2024 13:38:13.0000] CAPWAP State: DTLS Setup
[*08/23/2024 13:39:10.0622]
[*08/23/2024 13:39:10.0622] CAPWAP State: DTLS Teardown
[*08/23/2024 13:39:10.1921] upgrade.sh: Script called with args:[ABORT]
[*08/23/2024 13:39:10.2321] do ABORT, part2 is active part
[*08/23/2024 13:39:10.2521] upgrade.sh: Cleanup tmp files ...
[*08/23/2024 13:39:34.9344] Discovery Response from 192.168.0.2
[*08/23/2024 13:39:44.0000]
[*08/23/2024 13:39:44.0000] CAPWAP State: DTLS Setup
[*08/23/2024 13:40:41.0222]
[*08/23/2024 13:40:41.0222] CAPWAP State: DTLS Teardown
[*08/23/2024 13:40:41.1221] upgrade.sh: Script called with args:[ABORT]
[*08/23/2024 13:40:41.1521] do ABORT, part2 is active part
[*08/23/2024 13:40:41.1821] upgrade.sh: Cleanup tmp files ...
[*08/23/2024 13:41:05.8944] Discovery Response from 192.168.0.2
[*08/23/2024 13:41:15.0000]
[*08/23/2024 13:41:15.0000] CAPWAP State: DTLS Setup

[Mark Elsen]

 - Could you also check the controller logs for this ?

 M.

[Mark Elsen]

                      - Edited   , because earlier I was on handheld and I could not provide direct links :
   Use : https://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/119286-lap-notjoin-wlc-tshoot.html
                                      For detailed troubleshooting

  Also have a checkup of the controller's configuration using : WirelessAnalyzer input (procedure) for AireOs controllers
 and feed the output from that into Wireless Config Analyzer

 M.

[Rich R]

Not enough info from those logs to say why it's failing.
Check the ME config as Marce explained above using Config Analyzer.
Then you might need to enable debugs on AP and ME to understand why it's failing.

Are those 1832 new or second hand?  If second hand they might be faulty hardware.  1832 have a higher than average failure rate (compared to other AP models) and the failure can present that way sometimes.  If that is the case then when you do a packet capture of the discovery and reply packets you will be able to see radio hardware details missing from the packets.

Capture the complete console log from the AP from power on and save to text file (.txt) then attach here for us to look at.

[Rob Getrost]

You may want to try forcing the AP to boot part1 image. 

Use the ESC sequence to get to the UBoot screen, then 

setshenv BOOT part1
saveshenv

boot

[Mark Elsen]

 @Rob Getrost  - I doubt this will help ; what the initial post tells is : the AP and controller don't agree and  want to talk with each other further ; what I look more into is : installing the corresponding AP capwap client image manually on the AP (in case the current release is too far out to have a simple capwap image upgrade).

 M.

[Rob Getrost]

@Mark Elsen I agree, but He didn't post the relevant info to understand what the primary and secondary images on the AP are, so with my suggestion its easy enough to try to see if part 1 contains a compatible image.  I've also seen some cases where the images were the same but 1 part or the other was corrupt. 

[Mark Elsen]

  - A more compatible image on part1 is a possibility , but I think chances are low , note that the AP also says 
    do ABORT, part2 is active part  , whether this means  'I or the controller made me switch to part2'  I don't know.
                                                        

 M.