Unable to factory default a 7960 Phone with old code?

Unanswered Question
Mar 19th, 2008

Hi,

I am trying to get a couple of old 7960 phones to work with my CME demo kit. The phones were originally working with CCM4.0 or 4.1.

When I boot them up on a port with DHCP, option 150, etc, they never get an IP address and reboot continually. They also reboot as soon as I attempt to enter the network configuration menu - as soon as I use the up/down button to navigate the menu.

Any ideas whay is going on?

Thanks in advance!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Paolo Bevilacqua Wed, 03/19/2008 - 07:14

Depower phone. Press and hold #. Apply power, release # when display show "reset sequence detected". Enter 123456789*0#. enter 2 to confirm delete network setting. Phone should reflash. Note, it may have problems in upgrading straight to latest.

Note most 7940-60 load a bugs with cme, there is a specific "T23" image that you can obtain from XC7 zipfile I think.

If all this seems too crazy to you, be patient, phones requires lot attention to details.

tmoffett Wed, 03/19/2008 - 07:19

Thanks for your reply... I believe I tried that a while ago - with no success (never got the "reset sequesce detected"). I will try that again and see what happens...

Thanks!

Tim

Adrian Saavedra Wed, 03/19/2008 - 07:31

Hi,

What do you see 'wiresharking' the port where is plugged the ip phone?

Regards,

-- adrián.

tmoffett Wed, 03/19/2008 - 07:27

Does the phone need to detect the LAN for this to work? I plugged a power brick in while holding the # key and got the same thing as not pressing the # key. Doesn't ever indicate "configuring IP, Configuring VLAN", etc...

Paolo Bevilacqua Wed, 03/19/2008 - 07:54

As indicated by above, when phones do not react to the reset sequence, you need to connect wireshark and see which tftp server the phone sis trying to access, then "spoof" it with a PC and the necessary files. Kind of tricky but the alternative is to bin the phones.

tmoffett Wed, 03/19/2008 - 08:15

I will give that a try and reply with the details....

Thanks!

tmoffett Wed, 03/19/2008 - 10:08

All I see is an ARP request coming from the phone - looking for the MAC address of 10.1.1.1.

I configured the CME router with this IP address and it doesn't appear to respond and the phone reboots.

Adrian Saavedra Wed, 03/19/2008 - 10:52

Hi,

Other phones in the same IP segment register successfully to your CME?

How is your network set up?

Regards.

tmoffett Wed, 03/19/2008 - 10:57

The other phones are newer and have only ever been registered to CME. They all work fine.

The two phones that don't seem to work are older 1st generation 7960s that were used with CCM 3.3 and 4.0...

The ports are set up as trunk ports (dot1q)and the voice vlan is set and native vlan as default (1).

Interestingly, a PC works through the phone as expected when it's not rebooting...

Adrian Saavedra Wed, 03/19/2008 - 11:02

Hi,

Try doing the method explained by Paolo, but instead of performing the 123456789*0# sequence, perform the following: 3491672850*#

Regards.

Paolo Bevilacqua Wed, 03/19/2008 - 10:59

You can continue trying with the router, but a pc w/ tftpd32.exe can be more effective.

Configure it w/ ip 10.1.1.1, option 150 in the dhcp server, observe which tftp files are being requested (tftp server tab), should be os79xx.txt, write back once you're there.

tmoffett Fri, 03/21/2008 - 06:36

The phone doesn't respond to holding down the # key at all - when powering up.

The only traffic from the phone, aside from CDP is from the source address of 255.255.255.255- arping for 10.1.1.1.

It doesn't appear to have an IP address and I am not sure why it is ARPing for 10.1.1.1...

Paolo Bevilacqua Fri, 03/21/2008 - 16:20

The bcast source it's strange, but likely it's arping because it wants tftp to 10.1.1.1

Is there an unicast ip source within arp ?

Anyway, connect PC with thta address and tftpd32 as described above.

You should be able to see the tftp request coming once arp is replied. Things should be a little easier after that.

tmoffett Sun, 03/23/2008 - 06:13

I had already set up my PC to be the 10.1.1.1 endpoint. It doesn't seem to reply to the phone with its MAC address...

tmoffett Sun, 03/23/2008 - 09:39

Sure. I changed the config around a bit just to satisfy my curiousity. I put the phone and my PC in VLAN1 and addressed that SVI for 10.1.1.10 and gave my PC 10.1.1.1. The router did a gratuitous ARP reply to the phone and it then sent out a TFTP GET to 10.1.1.1 with a source address of 255.255.255.255. The sniffer showed it as a malformed tftp packet. The string was 377\377\377\377...

Attachment: 
Paolo Bevilacqua Sun, 03/23/2008 - 11:15

Hi, the phone for sure is very confused but I still think it can be recovered. Although malformed the tftp request is there,try with PC or router to supply the file

OS79XX.TXT simply contain the .loads filename ( without .loads extension). To be sure, try specifying some old image like 5.x perhaps.

This because one step you have to solve too, is to ge the ephone to upgrade to "universal boot loader".

tmoffett Sun, 03/23/2008 - 12:53

I don't even see a request hitting the TFTP server application - running on 10.1.1.1. Could there be a different app that might work better than the 3CServer?

Paolo Bevilacqua Sun, 03/23/2008 - 15:22

Hi, as mentioned before, I recommend using either a router, or tftpd32.exe (free download). Both have debug capabilities, the latter is actually better in that, only I don't know how it will react to request coming from broadcast address.

tmoffett Tue, 03/25/2008 - 05:59

Not a single one of the tftp apps that I have tried have even reported seeing a tftp request from the phone. Probably because it is coming from a broadcast address?

I am trying to find information on how to connect to the phone over the RS232 port, but it seems as if Cisco has removed ever single document that contains this information.

WTF?

Paolo Bevilacqua Tue, 03/25/2008 - 06:49

Yes the problem can be due to the broadcast address in source, that doesn't make much sense.

Are you sure there are no packets send immediately after turning on, before the capture you sent ?

The serial port cannot be use to control the phone, there is no login console or anything like that, much less when the phone is not running full firmware.

Paolo Bevilacqua Tue, 03/25/2008 - 07:23

Alos, I see that at least on CLI level, IOS can nat between bcast address inside and one unicast outside. So you would put the phone on inside (any network), outside 10.1.1/244, TFTP server at 10.1.1.1, request will be natted to unicast and tftp server will reply then.

Actions

This Discussion