350 AP upgrade to IOS issues

[tcggg0]

We have recently upgrade 17 cisco 350 AP's running 12.01 T1 VxWorks to IOS 12.2(13) JA1 via WLSE 2.7.1

The upgrade was a struggle but all were finally upgraded. We are now noticing that these upgraded AP's are frequently leaving the network and have to be physically rebooted. This warehouse never had a problem before when running VxWorks but since the upgrade it is becoming painful. The caveats don't list this as a problem. Any ideas?

[rmushtaq]

Could be a problem with the AP setup/config.WLSE simply converts the AP to IOS and nothing else.

[Mel Popple]

I just upgraded one of ours using the CAC tool, after the upgrade it started playing up. I've since telneted in and did an 'erase start', reloaded & reconfigured it through the web interface and it has now been stable for a few days.

Fingers crossed.

[tcggg0]

Cisco found a bug, #CSCed25530

AP350 Ethernet interface input queue running IOS may hang after a period of

operation. Output queue still works, but all input traffic are dropped on the

ethernet interface.

Workaround: clear fastethernet interface or reboot access point

The fix is to upgrade to 12.2(15)XR1 which we did but we still see some weirdness in the 350's.

[eerten]

We also have many 350's. I upgraded one of them using Cisco Conversion Tool. But strange things happen like the radio interface blocks all traffic once in while. I reboot, everything goes normal, but after some time happens again. Since this is not acceptable in a production network, I had to throw away the 350, I would not recommend upgrading VXWorks to IOS. I also upgraded to 12.2(15)XR1, but didn't solve the problem (btw, Cisco TAC could not solve this either, case 600450147).

[tz535d]

We've also encountered stability issues with the conversion where we found that APs with high usage would occasionally reboot with a watchdog-timer reset error. We've been working with the TAC on this and one of the things we discovered was that the conversion activated the creation of RSA keys. These keys are regenerated every hour and the regeneration process is CPU intensive. You can tell if you are generating RSA keys on your access points by issuing a "show crypto key mypubkey rsa" command. This will display the RSA keys if they are being created. To get rid of the keys, you need to issue in configure terminal mode "crypto key zero rsa". You also need clear out any defined domain names on the AP. It seems that the AP will keep trying to create the RSA keys, but if the domain name isn't defined, it will be unsuccessful in the task. When we cleared the RSAs from our APs, our stability markedly improved. We are also testing the 12.2(15)XR2 code and so far, it appears that the combination of the new code with the removal of the RSA keys has either solved our instability problems or dramatically increased the time between reboots.