Phone firmware upgrade /TFTP issues 255.255.255.255

[d.marsh]

Hi anyone seen this?

I have a phone firmware upgrade to do and I done a test for 10, all ok, then I done 100, and 18 failed I looked at the devices and found that the TFTP address was set to 255.255.255.255 on the devices for both TFTP 1 and TFTP 2. ahhah I pointed atthe DHCP guy and said its your fault. We checked out the DHCP and all was well, we got a new phone plugged it in and all was well with that. We reset, restarted, unplugged, deleted from DHCP, nothing worked unless we go into the phone menu and release the DHCP manually from there, and then it got the right TFTP address and upgraded ok.

So I am 110 phones into a firmware upgrade of 4000 and 15% have failed, any ideas of how to get this to work without touching each phone? open to any ideas crazier the better at this point. It has mainly been 7941 phones so far but the customer has a mixture and it has been seen on a 7911 also.

[csabavirag]

Hi,

The reason of becoming a TFTP address invalid on the phone is not known (based on TAC's answer) , however there are 2 workaround I could recommend:

1. If you have access to a computer on the same LAN where the affected phones are, install a TFTP server (eg. tftpd32) on a PC and put the xmldefault.cnf.xml file and the appropriate firmware on it to let the phones download the new firmware. Or configure the nearest router as a TFTP server and copy these file onto that. The router or a local TFTP server will answer on 255.255.255.255 TFTP requests.
   
2. You need to do a factory reset with pressing the Erase button under Settings menu. This can be done remotely with a small application, which looks the actual IP address of a defected phone (or phones) in RIS, based on their devicename, and use the /CGI/Execute web interface of the phone to send key sequences of pressing 'Settings' button then the 'Erase'. The application can be a bit more complex, if you use 'Local Phone Unlock Password' in the Common Phone Profile, as in this case you need to "unlock" the settings (**#) and send the password key sequence too. Pressing 'Erase' button will clear all the network settings including the TFTP address, and will request these parameters again during the next DHCP query.
   
   You can easily verify all your phone's TFTP address with fetching their webserver's Network Setup page then search for the TFTP server values. You can find examples how to parse a Cisco IP Phone's webserver information and get the necessary data. So you can have the list of device names should be reseted.

I hope this can turn your fantasy on .

[dmclean]

OOOH I like that second one I can get the device names from CUCM fiarly easliy based on the phones that don't have the default load after an upgrade.

But what application do you refer to that will do this for mutiple phones at a time? Any links to it supported or not would be great.

[d.marsh]

Ahh don worls with me, but we would be interested to know what if any application you have used to do this on bulk phones in the past.

Cheers

dave

[csabavirag]

Sorry, I was miles away from computer last week...

Unfortunately that time I did not find any app for this purpose on the market, so decided to write my own. The main request was to make it available for multiple users from different locations (we controll the access through CUCM roles), therefore I used php to implement the functionality.

If you need, I can provide some pseudo code on how I achieved.

[d.marsh]

Hi

I found another way out of this situation. If you change the IP helper address on the Voice VLAN to that of the TFTP after the phones have an IP address then reset the phones from the CUCM and the affected phones do then contact the TFTP server via the broadcast message the send out and upgrade (if you have already upgraded the firmware load on CUCM correctly). When they upgrade past 8.4.2S then this issues clears. In fact 8.4.2S is the only version I have tried and I only had faulty 7911's and 7941's.

the only advise I can give on this is that you need to remove all of the IP helper address configured first (or I did in my case) and if using a HSRP pair of routers/layer 3 switches then in our tests the active one should be changed, but anyone that knows about HSRP will suggest that this is wrong as both routers will forward the broadcast request and they do (I have tested with a sniffer ) but for some reason in my system it when it was added to the standby it didn't work when I moved to the active it did, I dunno I recon it should have worked on both but I'm no expert on HSRP.

[kenta_watai]

You sir, are brilliant. You have saved me a long drive across the nation.  I owe you a beer. Let me know when you are in Canada.

Kenta Watai

[bvanbenschoten]

I just ran into this issue. The changing of the IP helper (we actually just added an additional IP helper) pointing to the CUCM server worked great for me.  We had 50+ remote sites with a handful of phones at each having this issue.  Great tip !