7925 phones won't register when using WLANDefault.xml

[Mark VandeVere]

We recently moved to new controllers and 3600 series CAPWAPs. As part of that we wanted to move our 345 - 7925 phones over to a new SSID using EAP-FAST and CCKM. We used the Bulk Deployment Utility to create the WLANDefault.xml file, which was loaded onto both tftp servers in our cluster. The process seemed flawless in terms of moving the phones onto the new wireless network profile. Within 24 hours, almost every phone was on the new SSID.

What wasn't flawless was that in 24 hours we also started seeing phones move to the new SSID and then essentially stop working. They were stuck in a loop of "locating network" and "configuring IP" - they wouldn't pull down firmware, and wouldn't register to CUCM (8.0.3).

We engaged TAC, who suggested we had a "database mismatch" and recommended rebooting our cluster. We took that step after hours, and saw a few phones immediately start dowloading firmware, so results were encouraging. Over the weekend (the two following days) what happened was that about half the phones (including ones we'd seen download firmware right after the cluster reboot), simply lost registration to CUCM and stayed in the "locating network" loop.

Since the phones were visible on the network (we could ping to them and browse to them), but not registered to CUCM, it was obviously not a network issue. We removed the only thing that had changed on the CUCM side - the WLANDefault.xml file - from both tftp servers, stopped and started services, and voila!! We immediately saw phones that were stuck cycling for the network pull updated firmware and register. We found every phone we could that was not powered up, and with no exceptions they all came up, pulled firmware and registered. In the 48 hours since, we've had not one issue.

Has ANYONE ever seen this, and does anyone have any idea what would be going on with this? We'd like to use that process for the same purpose at another site with 500 - 7925 phones, but I can't afford to have half of them quit working for 24-48 hours while we move phones to the new SSID.

PS: Thus far TAC has zero response to what would have caused this behavior.

[migilles · Accepted solution]

Hi Mark.

If you are getting "Locating Network Service" then it is wouldn't be related to CUCM per se, but more of a WLAN issue.

But if you are seeing phones getting into a loop, then it sounds like you may be running 7925 firmware prior to 1.3(4), which could have this type of issue as versions prior where not tuned to handle BDU templates.

Is that correct?

We only support the BDU with firmware version 1.3(4) and later as outlined in the BDU readme.

See the Introduction section on page 3.

http://www.cisco.com/web/software/282074239/14006/792xBD.1-0-Readme.pdf

Let me know what 7925 firmware version you are using.

Thanks.

[Mark VandeVere]

You win the prize, and have made my life much easier now.

I never found (even tried again this morning) a readme for BDU. All the phones were on 1.3.3 firmware. They were obviously able to get the network profile and use it. Our other sites this should not be an issue, as we're already on newer firmware.

[migilles]

Well, I better know as I am a tech lead for the 792x products and also wrote the BDU readme.

Glad we have quickly identified the issue.

I don't suggest to use 1.3(4) at this time, but rather use 1.4.4.3, which is our current firmware release and has optimized scanning and roaming.

[Mark VandeVere]

I'm relieved for moving forward as all our phones are on 1.4.4.3 already.

Can you satisfy my curiousity and provide an explanation of what is happening when these phones try to come up and fail? This is one of the more intriguing issues I've ever seen and I'd appreciate a deeper understanding.

[migilles · Accepted solution]

You are referring to why the 1.3(3) phones get in a loop when the WLANDefault.xml file is on the TFTP server?

Yes, basically there is no logic to check version stamp info of the file, so it gets into this loop.

Or the vague response is, 1.3(3) is not supported with the BDU.

[Mark VandeVere]

Perfect all the way around. Thanks so much for the original response, and the clarification on the trailing end as well. This is all good to know and deliverable to management for a post-mortem and future steps document.