I have an installation with 17 Cisco AIR-LAP1242AG's connected to a pair of AIR-WLC4402-25's. The system was running a 5.1.x.x code release and has been for over 6 months, well I decided to upgrade to the new 220.127.116.11 code which seemed to go flawlessly except for two access points. Now before I get into the issue and the resolution, I must state that all of the AP were LWAPP right out of the box and went thru several progressions of the 4.x.x.x code and have never been meshed.
So the issue was that 2 of the AP's failed to come back to the controller, I checked them and found the error lights indicated they were searching for a controller.
Here are the troubleshooting steps I went thru:
Reset the AP
Reset the AP with the mode button
Converted it to IOS and reconverted to LWAPP ( It joined, upgraded code then dropped off and never came back)
Converted it to IOS and reconverted to LWAPP a second time ( It joined, upgraded code then dropped off and never came back)
At this point I watched the boot process and noticed something about a file called mash.cfg and I converted the unit back to IOS.
From here I looked at the flash and saw there were 3 files: meshcfg.???, mesh_cfg.???, and mesh.cfg... Oddly both AP's that were behaving oddly had these files. I did another mode button reset both config and firmware recovery (and used a TFTP to reload the IOS image again) and the files were still there.
I deleted these three files and then re-converted the AP's and they are working fine; I converted one of the AP's that didn't experience the issue and checked it's flash and those files were not present.
Question: So has anyone else had this experience when converting from 5.1.x.x to 7.0.98.x with the Cisco 1242's? Hopefully if so this will save you some headache.
This is a very strange, but rare occurrence. I've never seen this behaviour before, however, I've seen similar.
A few years ago we got hold of an ASA. The problem was that you couldn't console in. If we "accidentatlly" plugged the console cable into the AUX port, it works. (Strange #1). It wouldn't do routing even though the feature set was correct. (Strange #2) Finally, you couldn't telnet/ssh into the box (Strange #3).
After a few weeks, someone senior from TAC asked the basic question: Where did you get the box from. We told `em it came from the vendor and direct from Cisco. Why? we asked.
The reply was: The box is loaded with a not-for-public-release IOS.
Upgraded the IOS to the correct version and problems solved.
So no. I've never seen this behaviour before but I've seen similar.
Just to put a smile to your face:
Remember, people make mistakes too.
I was also having real problems with my 1242APs connecting to my 4402 WLC after an upgrade from 18.104.22.168 to 22.214.171.124. If I upgraded up to 126.96.36.199 then all was well but as soon as I upgraded to version 188.8.131.52 my 1242APs would no longer connect.
The problem only manifested itself on those 1242APs that were set to Bridge mode, ie they were Mesh APs. Neither RAPs or MAPs would connect.
If my 1242APs were reset to Local mode then they connected fine. So it appeared that Meshing with the new version and 1242s didn't work.
Multi-Country codes are NOT ALLOWED in 7.0.98. Cisco documentation states this is the case also for 184.108.40.206 and previous versions but they are in fact wrong. Meshing works perfectly well using multi-country codes in versions prior to 220.127.116.11 as I was running both GB and US APs in my setup. If you want to get your 1242APs to mesh in 7.0.98 then you must only have one country code selected and operate products in the corresponding Regulatory Domain ONLY. Mixed equipment will not work!!!
802.11a has to be explicitly manually enabled in 18.104.22.168. Using versions prior to 22.214.171.124 you didn't need to actually enable 802.11a to get meshing to work - I have been running meshing over 802.11a for months using 126.96.36.199 with it turned off on the summary age explicitly but it worked fine. Somehow the mesh worked in the backgound over 802.11a with the Network Status disabled. This is no longer true, if you change to a Single country setup then your RAP will connect now but your MAPs will still not connect until you physically enable 802.11a yourself!
Once you are running in Single Country configuration with 802.11a explicitly turned on alongside 802.11b/g then your MAPs will start to connect to the RAPs within a few minues one they have downloaded the new firmware to themselves.
Hope this helps someone else out there, incidentally these are the debugs that I used (with help from Cisco TAC) to resolve this (they hadn't come across these problems themselves...so we educated each other on this one)
debug capwap events enable
debug capwap errors enable
debug pm pki enable
debug dtls all (this is a hidden command that does not appear in ? help!)
So run these debugs and perform a search for the IP address of the AP that is refusing to join. Mine popped up with:
*spamReceiveTask: Sep 01 14:42:21.028: 00:27:0c:6a:fd:00 Bridge AP can not join MultiCountry Controller: Bridge mode AP 172.16.120.13:45233 cannot be supported on Multi Country Control
which helped me resolve the first part of the problem, once I reverted my WLC to GB ONLY then the RAP connected. Enabling 802.11a explicitly came a little later on and was an educated guess!!
Happy meshing with your 1242APs with 188.8.131.52
I had similar issues after upgrading from 6.0.182 to 7.0.98 with 1142 APs. Finally I found the 1142 APs used to resolve both dns names cisco-lwapp-controller and cisco-capwap-controller. But after upgrade to 7.0.98, they only try to resolve cisco-capwap-controller. We only had DNS name entry setup for cisco-lwapp-controller before. After we added the dns entry for cisco-capwap-controller, the issue was resolved. Check if this is the same issue for you.
I've encountered a similar issue of 1242 AP's not joining, but perhaps a slightly different scenario.
I'm in the process of upgrading from 184.108.40.206 to 220.127.116.11 on a WLC 4402 (25). The APs are non-mesh, and some are in Local mode and the rest are running in H-REAP mode. The upgrade of the controller appears to go just fine, and the APs all join initially and go through downloading & then reset as expected. There is an entry for "cisco-capwap-controller" (along with the previously used 'cisco-lwapp-controller').
Here's where the problems occur. Following the reset, a variable number of APs join (dealing with 9 APs right now)... but not all of them, so I wait - Still no others join. I reboot the controller and again only get a hand full of APs - Some the same as the first time, others that were there now don't join, and a few that weren't there previously now are (most I've seen join are 5 at once). Additionally, for those that do join and show "REG", they seem like they are ready (radio's are up, etc) but no clients can connect / the SSIDs don't appear to clients, though they're defined still in the controller and are enabled.
Any thoughts, ideas, or assistance is appreciated.
Note: I have downgraded, and all the APs return / download, and become available again under 4.2, and clients can connect again.
Create a DNS entry for "cisco-capwap-controller". It is yet unknown if "cisco-lwap-controller" was omitted on purpose or by accident.
Thanks for taking the time to reply! - If you read my initial post, you'll see I already have that in place.
And of course, any other suggestions are welcome.
I am facing the same issue with 3600 AP, even though i delete the files from flash they are re-appearing...
I cannot change the multi-country behavior
when i debug capwap errors i get the below
*spamApTask4: May 14 19:32:05.247: 7c:95:f3:07:cd:f0 Bridge AP can not join MultiCountry Controller: Bridge mode AP x.x.x.x:61687 cannot be supported on Multi Country Control
*spamApTask4: May 14 19:32:05.256: 7c:95:f3:07:cd:f0 State machine handler: Failed to process msg type = 3 state = 0 from x.x.x.x:61687
*spamApTask4: May 14 19:32:05.256: 00:08:e3:ff:fc:04 Failed to parse CAPWAP packet from x.x.x.x:61687
*spamApTask4: May 14 19:32:05.291: 00:08:e3:ff:fc:04 Discarding non-ClientHello Handshake OR DTLS encrypted packet from x.x.x.x:61687)since DTLS session is not established
Finally resolved after deleting the "flash:/mesh*" , "fash:/config" a few times n reloading...
have no idea why is it so and there is no command on CLI to change the AP mode to local