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!
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.
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...
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...
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.
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.
Other phones in the same IP segment register successfully to your CME?
How is your network set up?
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...
Try doing the method explained by Paolo, but instead of performing the 123456789*0# sequence, perform the following: 3491672850*#
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.
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...
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.
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...
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...
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".
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?
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.
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.
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.
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.