Phone in perpetual reboot mode

tboynton · ‎09-10-2001

I have a 7960 phone that keeps rebooting. I'm seeing it connect to the tftp server. I don't have eyes at this branch to assist me with troubleshooting. Here is a tftp trace:

9/10/2001 12:03:13.235 Cisco Tftp|-->CTFTPConnect::IsReq() |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.235 Cisco Tftp|[opcode = 1] [Mode = 65295565]|<CLID::CM-O-UNET-Cluster><NID::130.111.39.121><CT::169.244.83.200:52756><IP::169.244.83.200><DEV::OS79XX.TXT>

09/10/2001 12:03:13.235 Cisco Tftp|<--CTFTPConnect::IsReq() |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.235 Cisco Tftp|<--TFTPServer::recvMessage() |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.235 Cisco Tftp|-->TFTPServer::recvMessage() |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.235 Cisco Tftp|-->TFTPServer::ServerConnectionThread[169.244.83.200:52756] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.235 Cisco Tftp|-->TFTPServer::tftp[169.244.83.200:52756] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.235 Cisco Tftp|-->CTftpConnect::GetName[169.244.83.200:52756] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.235 Cisco Tftp|<--CTftpConnect::GetName[169.244.83.200:52756] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.235 Cisco Tftp|-->TFTPServer::validateAccess[169.244.83.200:52756] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.235 Cisco Tftp|file handle=2013509360|<CLID::CM-O-UNET-Cluster><NID::130.111.39.121><CT::169.244.83.200:52756><IP::169.244.83.200><DEV::OS79XX.TXT>

09/10/2001 12:03:13.235 Cisco Tftp|<--TFTPServer::validateAccess[169.244.83.200:52756] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.235 Cisco Tftp|-->TFTPServer::sendFile[169.244.83.200:52756] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|-->CTFTPConnect::IsReq() |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|[opcode = 1] [Mode = 65273638]|<CLID::CM-O-UNET-Cluster><NID::130.111.39.121><CT::169.244.83.200:52757><IP::169.244.83.200><DEV::SEP0003E3A5282E.cnf>

09/10/2001 12:03:13.250 Cisco Tftp|<--CTFTPConnect::IsReq() |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|<--TFTPServer::recvMessage() |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|-->TFTPServer::recvMessage() |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|block #1 ACK recieved,size=0|<CLID::CM-O-UNET-Cluster><NID::130.111.39.121><CT::169.244.83.200:52756><IP::169.244.83.200><DEV::OS79XX.TXT>

09/10/2001 12:03:13.250 Cisco Tftp|-->TFTPServer::ServerConnectionThread[169.244.83.200:52757] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|-->TFTPServer::tftp[169.244.83.200:52757] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|-->CTftpConnect::GetName[169.244.83.200:52757] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|<--CTftpConnect::GetName[169.244.83.200:52757] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|-->TFTPServer::validateAccess[169.244.83.200:52757] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|file handle=2013509392|<CLID::CM-O-UNET-Cluster><NID::130.111.39.121><CT::169.244.83.200:52757><IP::169.244.83.200><DEV::SEP0003E3A5282E.cnf>

09/10/2001 12:03:13.250 Cisco Tftp|<--TFTPServer::validateAccess[169.244.83.200:52757] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|-->TFTPServer::sendFile[169.244.83.200:52757] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|<--TFTPServer::sendFile[169.244.83.200:52756] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|<--TFTPServer::tftp[169.244.83.200:52756] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|<--TFTPServer::ServerConnectionThread[169.244.83.200:52756] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|block #1 ACK recieved,size=170|<CLID::CM-O-UNET-Cluster><NID::130.111.39.121><CT::169.244.83.200:52757><IP::169.244.83.200><DEV::SEP0003E3A5282E.cnf>

09/10/2001 12:03:13.250 Cisco Tftp|<--TFTPServer::sendFile[169.244.83.200:52757] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|<--TFTPServer::tftp[169.244.83.200:52757] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:13.250 Cisco Tftp|<--TFTPServer::ServerConnectionThread[169.244.83.200:52757] |<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:34.532 Cisco Tftp| CServiceModule::TimerThread(000016E8) signal reRead config[1499]|<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

09/10/2001 12:03:34.532 Cisco Tftp| CServiceModule::ConfigThread(000014B8) Recieved timeout event|<CLID::CM-O-UNET-Cluster><NID::130.111.39.121>

Any advice.

Thanks.

tboynton · ‎09-10-2001

The forum seems to be truncating the longer lines. Sorry.

tvanblon · ‎09-13-2001

I am seeing the same problem arise with 3.1(1) deployments. The problem is remedied by unplugging power and network from the phone, and re-applying (cold boot).

tboynton · ‎09-13-2001

No, actually that has been tried several times. But thanks for responding.

davidgipe · ‎09-18-2001

I had an identical problem with CM 3.09 and two 7940's. A PC could connect to the network fine using both data jacks, but any 7940 would continually reboot. It ended up being a cabling issue at the patch panel on the first and a cabling issue at both ends on the second.

Does the problem follow the phone or does it stay with the connection?

For what it's worth, I remember back when I assisted with a migration from a AS/400 CISC box to a RISC box, some of our existing cabling suddenly wasn't good enough any more . . . the RISC box amplified our problem runs (of which we weren't aware of up to that point).

paul.stephens · ‎09-18-2001

I've seen a problem like this with 3.0.9

What we did was to restore the factory defaults on the phone has it was booting.

It turned out to be because we had changed the ringlist file and the phone was trying to get a ringtone that didn't exist anymore.

Lars.Karow · ‎09-19-2001

In our testlab we had also some phones that were booting non-stop. The solution: the bandwidth to the phones was very limited (32 kbit/s) and the download of the new phone-image was terminated too soon. Using a better link (64 kbit/s) solved the problem.

tboynton · ‎09-19-2001

The site in question has the phone plugged directly into a 10/100 port on a catalyst. Several cables have been tried. The site has a 43megabit circuit, although only 8 or less is reserved for data.