7936 "Cannot contact TFTP server"

Unanswered Question
Mar 29th, 2009

I have a 7936 conference phone that just won't play. It gets an IP address then keeps saying it can't contact the TFTP server. Any ideas?

More info:

It's on the same switch and VLAN as a bunch of 7940s, a 7985, and a 7937. None of those are having any problems.

It gets an IP address from the DHCP server just fine. It knows about the right TFTP servers, it shows their IP addresses as "Contacting..." immediately before the "Cannot contact TFTP server" messages.

I can get onto the web interface on the 7936 no problem, so it has network connectivity. If I set "Use alternate TFTP server" to "Yes" and give it an IP of an appropriate TFTP server, it still doesn't work. If I use the ping diagnostic via the phone's web interface, it can ping all three available TFTP servers just fine.

I've tried setting the phone back to factory defaults. No change.

I've tried restarting the TFTP services on the call managers (even if no other phones were having trouble it had to be worth a shot) - no change.

The troubleshooting info I can find on the Cisco site or via google only suggests basic stuff that I've already tried. Is there some magic incantation required to make a 7936 behave? :)

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
redesfusionet Mon, 03/30/2009 - 19:41

Hello,

What version of CallManager you are using? Under Device Defaults, have you checked if the 7936 is a valid options?

This is a common issue when you don't have the correct load to support this type of phone. If this is the case, upgrade to the latest Service Pack or install the Device Pack to support this version.

Depending on the version, you could see on the TFTP server, if the .cnf.xml file got created.

If this is not the issue, I recommend you to setup a sniffer trace on the port, and check for the tftp request to the CCM and see if you get any response.

Also try to ping the IP Phones from the server to check connectivity.

Hope this gives you a light!!

mcreilly Tue, 03/31/2009 - 01:33

Thanks for the ideas. I was trying to get it working against CCM 6.1.3, I have about forty 7936s already working on that cluster already so definitely a valid option. I tried using a TFTP server on my laptop and pointing the phone to that just to see if it was making requests - and it was. It seems the error message "Cannot contact TFTP server" doesn't necessarily mean what it says, it may also mean that the TFTP server didn't have the file the phone was looking for? I tried configuring a profile for this phone on my old 3.3 cluster and pointing it to the appropriate TFTP servers for that - and it started up without complaint. Changed the TFTP servers back to point at the 6.1.3 cluster again, without making ANY change at all to it's profile on that cluster, and... bingo. It came up working. Curious behaviour!

wrightmp Wed, 04/22/2009 - 02:20

I am having the same issue - upgraded to 6.13 and 5 out of the 20 are not working - did you get a resolution?

mcreilly Wed, 04/22/2009 - 02:26

No "proper" resolution unfortunately, but I found pointing the phone back at the old cluster temporarily caused it to reload it's firmware (older code), then pointing it to the new cluster again it worked second time round. If you still have the old version running somewhere that might be worth trying?

Brian Carscadden Thu, 09/10/2009 - 12:15

News on an old post...

I had the same problem with a 7935.

I was able to find a CM4.1(3) cluster in our lab and homed the 7935 to it successfully. It upgraded the software (to 3.2(17)), and now it's taking the upgraded load from our 6.x cluster. Looks like we're back in business with this phone, now on 3.2(19.00.0007).

pjweppner Thu, 10/01/2009 - 07:06

I just experience this problem from a 3.3 cluster to 7.12. The 3.2(17) firmware resolved the issue. Thank god the old cluster servers weren't decommissioned.

ccie4297 Sun, 08/07/2011 - 22:44

Brian,

Thanks a bunch - now I dont have a paperweight! 

Every other post I could find told me the 7935 would have to be RMAd... I was lucky enough to have an old ghost image of a 4.1 CM and I just turned on autoreg and she fixed the firmware.... then pointed the 7935 to the new 7.0 cluster and voila - my 7935 is back.

Just an FYI for others... my 7935 was happy and registered to my 7.0 cluster - but showed some 10.x CMs on boot... so I thought I would "factory reset" to get rid of some old garbage CM entries somehow stuck in the phone and the thing got stuck like others in this thread mentioned... so careful with the factory reset!

      Cheers,

        Ken

http://www.packetbrain.com

Cisco's most innovative learning partner

Brian Carscadden Wed, 08/10/2011 - 18:26

i've had plenty of times where I see old threads go unresolved. Glad I could help.

Brian

pmvillarama Sun, 08/07/2011 - 23:05

Hi all,

though the right fixed for this hasn't been cleared, i still find your post very helpful. +5 for you .

Regards,

paul

Leroy Plock Tue, 09/04/2012 - 14:22

If you don't have an old CM to use, this worked for me:

* Configure the phone in your production Call Manager

* Set up a temp tftp server.

* Get the XMLdefault.cnf.xml and SEP.cnf.xml for this phone from your production call manager, put them on your temp tftp server.

* Get the oldest firmware available for the 7936 from Cisco. I used cmterm_7936.3-3-10-0.bin. Put it on the temp tftp server.

* Edit the SEP.cnf.xml file on the temp tftp server. Remove everything except the first callmanager and the loadinformation, leaving the and lines intact. (See below.Not sure that the CallManager section needed to be there.)

* Change the loadInformation section to match the firmware you got from Cisco.

* Set the Alt TFTP server on the phone to point to your temp tftp server.

* Reboot the phone, it should upgrade or downgrade to the firmware on your temp tftp server. (Mine registered but still wasn't functional.)

* Once the firmware has been changed and the phone has booted up, turn off the alt TFTP.

* Reboot the phone. It should download the latest firmware from your Call Manager, read the original unaltered .cnf.xml file, register, and work.

Apparently upgrading to the latest firmware doesn't work from certain earlier versions. Installing the intermediate firmware allows it to correctly upgrade to the latest. Maybe you could just put the intermediate firmware on the production Call Manager and specify it in the Phone Load Name. But, I wasn't comfortable adding files to the CM tftp directory, wasn't sure what repercussions there might be.

+--- Edited .cnf.xml file ----+





YOUR_CALL_MANAGER_IP_ADDRESS_HERE
YOUR_DESCRIPTION

2000
5060
5061

2427
2428


YOUR_CALL_MANAGER_IP_ADDRESS_HERE


cmterm_7936.3-3-10-0

Actions

This Discussion