AP migration - Stuck in downloading status

[mkardos1]

Hello all,

We are trying to migrate access-points 2702 from the WLC 5508 (8.0.152.0) to the different controller WLC 5508 (8.5.140.0). Once the AP joins a new controller, it downloads a new softare, reloads and is in the donwloading status again - showing it has a new software.. Have you ever seen such a behaviour?

Many thanks for any advice!

[Rich R]

Glad to hear it Nilton.  That's why it's important to be clear about your issue - what the problem is, what error messages you see, what WLC and AP hardware is involved, what version of code is involved - rather than just "I have the same problem" type posts when (as in this case) it's often a completely different problem.

[tdennehy]

Anyone have any clue why some 1532i series won't join a 2504 and move past downloading?  I have tried four of them so far to no avail.  I have tried three different 2504 controllers.  I upgraded the controllers to 8.5.182.0, along with FUS 2.0, the AP Bundle kr.8.5.182.0 and code 8.5.182.0 on the controller.  These guys just will NOT join a controller and finish downloading.  I know what you are thinking...  put the mac address in the Security-->AAA--> AP policy.  Did that too.  Checked the date of the controller and its good.  The controller has a 3802 and a 3702 on it.  I'm at a loss as to why these 1532s will not move past downloading.  Thoughts?

[Rich R]

@tdennehy Did you bother to read the Field Notices in my signature above and below?

The ONLY non-IRCM version of 8.5 you should be using now is 8.5.182.7.

[tdennehy]

These access points were previously working and are now on the bench. There are 3 2504s. None of them would allow these 1532 series to join. I’m pretty sure they previously joined. I don’t think it has anything to do with the code. Unless all three versions of code previously worked with these access points magically stopped on its own. It really doesn’t make any sense. They obviously find the controller because they’re stuck in download it. All these access points did the same thing on all three controllers that were running different versions of code,. Next time I hooked them up, they didn’t work. it’s very strange. They were all set the local mode, but I put the MAC address in anyway. I still join and get stuck in downloading. It is if something happened to them. .

[Rich R]

So you still haven't bothered to read the field notices then?
It's not magic - it's science - a certificate expired - why is that so difficult for you to accept?
Upgrade the software to get the fix or keep wasting your time on the old software with the expired certificate.

[tdennehy]

Rich,

Your comments are NOT helpful in any way, shape or form.  Why do you talk down to people, as if you are some sort of God?

People join this community to help one another, not talk down to them.  Turns out you were WRONG.  I re-installed the same version of code over the version that was running and that fixed the problem.  The bundle was corrupt.

Have a great day.  Hopefully you meet Karma one day.

[Rich R]

Then you must have had to change the date to earlier than Dec 4 2022 because the certificate verification fails if you use the current date on 8.5.182.0, although the workaround config for FN63942 will allow APs with SHA-1 certificates to install the image.  Those with SHA-2 certificates will only work with the date set back or the new certificate from 8.5.182.7.  Those are the facts of the matter.  You are of course welcome to ignore those facts if you choose not to believe them but if you ask for advice here then you should probably be prepared to accept it.

Hope you have a great day too.

Ps: It's not just me saying that - refer to the TAC recommended link below where you'll currently see:
"For 8.5 Mainline deployments, TAC recommends 8.5.182.7 (hidden post)."
"Note: However, TAC does not recommend running 8.5.182.0 in production, due to:

• • CSCvz84912, which can cause frequent unexpected reloads, in any deployment where the WLC has mobility peers
    
  • Field Notice: FN - 72524 (CSCwd80290), which prevents IOS APs from downloading software
• The above issues are fixed in 8.5.182.7."

[tdennehy]

Lets see....

You assume I have NOT read the release notes, twice.  No, wait, three times.  Did I ever say that I have not read them, or did you simply assume?  We all know the answer.  You assumed... and we all what that really means...

Did you read my post?  Apparently not.  I clearly stated "These access points were previously working and are now on the bench", which means they are NOT in production.  Therefore, this "Note: However, TAC does not recommend running 8.5.182.0 in production, due to: does not apply".  Bench = NOT PRODUCTION.  Doh.

I clearly stated "Checked the date of the controller and its good".  Shall I translate that for you, since I DID read the documentation.  I turned the clock back to today's date, 2018, on all three BENCH (not production) controllers.

All three controllers are on the BENCH.  All 192.168.1.x/24.  WLC1, WLC2 & WLC3.  All 2504s.  Licenses: WLC1 = 5 APs, the other two = 25.  The APs will join the other two, but NOT the 5 AP licensed one.  The only way I could get it to actually join WLC1 was to put it on one of the other two controllers and have it download code.  And it did.  I could move the BENCH 1532 AP between both controllers with 25 licenses.  But a 1532 would NOT join WLC1 if I simply plugged it in and went to WLC1 in Master mode..  It would stay in download until the cows come home.  The only way to get one to join (and I have a pile of 1532s to play with) is to set one of the 25 AP licensed controllers that are NOT in production into Master mode and have it join and download.  Then move it to WLC1.  That works.

I will write this one more time, just in case you are still having problems comprehending.  ALL THREE BENCH controllers have the SAME CODE.  SAME FUS. SAME BUNDLE. Identical.  Same date.  Same config, except for the obvious.  All ignoring.

The APs will NOT download their code from this one controller for some stupid reason.  I actually had this happen to me in production one time.  We were jumping up a version and were N+1.  I moved everything to N, then upgraded the +1 to the new flavor and started moving APs to it.  They would stick in download, and this had NOTHING to do with certs expiring, etc.  This was a pair of 5508s and 3502s in 2015.  Those certs hadn't even started to go to kindergarten they were so new.  TAC said download the code AGAIN, reinstall and reboot.  That was the fix.

So now you know...

[Rich R]

Thanks for the detailed explanation - good reference for anyone encountering the same issue on those controllers.

[Leo Laohoo]

Are any of the APs getting valid IP addresses? If they are, proceed below: 

1. Download "ap1g3-rcvk9w8-tar.153-3.JK9.tar" and put the file into a TFTP server. 
2. Connect the AP to the switch.  Let it get an IP address. 
3. Console into the AP and do the following:

• debug ap console cli
• del /f /r flash:ap1g3*
• archive tar /x tftp://<IP_ADDRESS>/ap1g3-rcvk9w8-tar.153-3.JK9.tar flash:

After the process is complete, reboot the AP.  

See if the AP is able to work again or not. 

[Leo Laohoo]

Console into the AP and post the complete output to the command "sh capwap client rcb".

[omz]

might be worth a try - 

ssh to the AP, save config, reload 

[Rich R]

You should always read the release notes ... eg https://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn85mr6.html#upgrade-software_85mr6
- The image format of Cisco Aironet 1700, 2700, 3700, and IW3702 APs have been changed from ap3g2 to c3700. Therefore, if you are upgrading to Release 8.5 or a later release from Release 8.3 or an earlier release, these APs will download the image twice and reboot twice.

[Leo Laohoo]

---

@Rich R wrote:
The image format of Cisco Aironet 1700, 2700, 3700, and IW3702 APs have been changed from ap3g2 to c3700. Therefore, if you are upgrading to Release 8.5 or a later release from Release 8.3 or an earlier release, these APs will download the image twice and reboot twice.

---

The workaround I've posted was used to successfully migrate 150 APs to 8.5 and not one AP double-downloaded. 

[mkardos1]

Hi again!

So this was about the double-download issue, but another issue appeared.. We have now two testing APs registered on the WLC and in case of the WLC reset, those APs will join the WLC after a long time, like 20 mins and then they are in downloading status again! I don't understand this.. I supposed they will join ok if the image is downloaded already..