3702 LWAPP to standalone: AP reboots b4 completing the read from TFTP.

[Gioacchino]

Hi,

I'm following the standard procedure to upload the k9 image onto the AP, i.e.

debug capwap console cli
archive download-sw /force-reload /overwrite tftp://x.y.z.w/ ap3g2-k9w7-mx.153-3.JC1

however the AP keeps searching for the controller and after a while it decides to reboot.
Because of this the image transfer of the standlone image from the TFTP stops.
I see that while the image is transferred the AP decompress and read it, this slows down the process and leads to the reboot of the AP.

Is there another way of having the AP read the new image? Maybe by trasferring the image first on the local flash and then having the AP reading it from there? OR there won't be any space left. eventually?

Gio

[marce1000]

  - What happens if you abandon the  /force-reload flag on your image transfer command  (?) , also check the tftp server's logs , 
for image transfer completeness (check!)
 M.

[Gioacchino]

Thanks @marce1000 , I will give it a try.

As to the logs, the TFTP seervers says it doesn't receives the ACK from the client and everything times out.

Gio

[marce1000]

                       >.. .It doesn't receives the ACK from the client and everything times out.
                                           That should be resolved !

 M.
  

[Gioacchino]

Well, the client is the AP.... at the same time when I see the timeout, I see the AP starting a reboot. Again the reboot seems driven by the fact that it doesn't find a controller, and by default an AP reboots to see if that fixes the issue of not finding the WLC.
I'm not sure now wheather your suggestion will work, but once at home I will give it a try anyway.

[marce1000]

   - If you need the AP to become standalone , then you need to focus on getting the tftp transfer completing successfully , 

 M.

[Gioacchino]

Indeed, that's why I'm asking tyhe community if there is a faster way for the AP to read the image or a way to stop it rebooting after not having found any WLC within a timeout period.

[marce1000]

                            >... if there is a faster way for the AP to read the image....
  There isn't , basically you need to resolve the tftp transfer problem and make sure that a full download of the image can be achieved on the AP from the tftp server , otherwise it reboots with the on-flash capwap-client image and (still)  tries to find a controller indeed , 

 M.
 

[Rich R]

Presume that's a typo with a space between / and ap in your TFTP command above?

15.3(3)JC1 is very old (9 years) so I'd suggest using a more up to date image like:
https://software.cisco.com/download/home/285029865/type/284180979/release/15.3.3-JPN2

I've never had a problem with APs rebooting while tftping the image so I wonder if it's a problem with the TFTP server you're using?  What exact messages are you seeing on the console when it reboots?

Yes you can copy the .tar file to flash: and then install from there (using the same archive download command with flash:filename instead of tftp), but you'll have to delete all other images from flash to make sure there's enough space.  When you do the install from the tar file on flash: there needs to be at least as much free space as the size of the tar file.  It will delete other installed images (including the running image) automatically to make space.

If you can't stop it rebooting mid-transfer then you could also do the TFTP from ROMMON (deleting all existing images and reloading will force that) and then do the transfer from ROMMON CLI.

The only thing that will make TFTP "faster" is making sure the TFTP server and AP are directly connected over a fast, error free connection which you're probably already doing.  Unpacking the tar file always takes a few minutes.

[Gioacchino]

Hi @Rich R ,

Once at home again I will try your suggestions and let the community know.

Thanks!

Gio

[Gioacchino]

So while trying to enter RONMON to  do TFTP from there, here it is the log messages that explain why the AP reboots

*Mar 1 00:06:12.303: %DOT11-5-EXPECTED_RADIO_RESET: Restarting Radio interface Dot11Radio0 due to the reason code 11
*Mar 1 00:06:12.303: %DOT11-5-EXPECTED_RADIO_RESET: Restarting Radio interface Dot11Radio1 due to the reason code 11
*Mar 1 00:06:12.311: %SYS-5-RELOAD: Reload requested by CAPWAP CLIENT. Reload Reason: Could not discover WLC using DHCP IP address, Reload to use static IP.
*Mar 1 00:06:12.327: %LWAPP-5-CHANGED: CAPWAP changed state to DOWN
Write of event.log done

IOS Bootloader - Starting system.
flash is writable
Tide XL MB - 40MB of flash
Xmodem file system is available.

[Rich R]

Hmmm ok switching to DHCP is actually a standard recovery mechanism for APs when configured with static IPs so I wonder if it had previously switched from using static to DHCP?

[Gioacchino]

Actually it was configured with static IP address, I eventually unset the variables carrying the values for static IP address.

[Gioacchino]

So, going through RONMON, it looks way better, but... when the AP reads the image I get (regardless of the oldness)

Loading "flash:ap3g2-k9w7-mx.153-3.JPJ3/ap3g2-k9w7-xx.153-3.JPJ3"...flash:ap3g2-k9w7-mx.153-3.JPJ3/ap3g2-k9w7-xx.153-3.JPJ3: magic number mismatch: bad mzip file

Error loading "flash:ap3g2-k9w7-mx.153-3.JPJ3/ap3g2-k9w7-xx.153-3.JPJ3"

Interrupt within 5 seconds to abort boot process.
Loading "flash:/ap3g2-rcvk9w8-mx/ap3g2-rcvk9w8-mx"...##########################

File "flash:/ap3g2-rcvk9w8-mx/ap3g2-rcvk9w8-mx" uncompressed and installed, entry point: 0x2003000
executing...

Secondary Bootloader - Starting system.
Tide XL MB - 40MB of flash
Xmodem file system is available.
flashfs[0]: 549 files, 22 directories
flashfs[0]: 0 orphaned files, 0 orphaned directories
flashfs[0]: Total bytes: 41158656
flashfs[0]: Bytes used: 39230464
flashfs[0]: Bytes available: 1928192
flashfs[0]: flashfs fsck took 35 seconds.
Base Ethernet MAC address: 7c:0e:ce:08:91:14
Boot CMD: 'boot flash:ap3g2-k9w7-mx.153-3.JPJ3/ap3g2-k9w7-xx.153-3.JPJ3;flash:/ap3g2-rcvk9w8-xx/ap3g2-rcvk9w8-mx'
Loading "flash:ap3g2-k9w7-mx.153-3.JPJ3/ap3g2-k9w7-xx.153-3.JPJ3"...flash:ap3g2-k9w7-mx.153-3.JPJ3/ap3g2-k9w7-xx.153-3.JPJ3: magic number mismatch: bad mzip file

[Gioacchino]

Despite the hash of file provided by the TFTP server guarantees on its integrity for the third time I get

Loading "flash:/ap3g2-k9w7-mx.153-3.JPI4/ap3g2-k9w7-xx.153-3.JPI4"...flash:/ap3g2-k9w7-mx.153-3.JPI4/ap3g2-k9w7-xx.153-3.JPI4: magic number mismatch: bad mzip file

I think the next step is going to check the flash, maybe there is a way to squeeze it or to format it from scratch again, isn't there?

Gio