Bricked 7941g
Submitted by vprea on Sat, 05/10/2008 - 1:25pm.
Hi, I have a 7941g, and trying to upgrade, it got stuck. The phone request its address via DHCP, but then it don't request new firmware via TFTP. I've also tryed factory reset but nothing special happens....
I have a serial console cable, I connected to the AUX port of the phone via Hyperterminal 9600 8N1.
If I look at the init process, I can see this line:
WRN 04:51:18.209781 image: Invalid default load name -> 'FCH1101963K'(255)@pos=0
It seems that trying to upgrade it, boot image got corrupted.
Here is the DCHP log, who seems to be right:
NOT 04:51:27.181249 DHCP: DHCP enabled...
NOT 04:51:28.180140 DHCP: Sending Discover...
NOT 04:51:28.927988 DHCP: Sending Request...
NOT 04:51:32.213124 DHCP: ACK received
NOT 04:51:32.213972 DHCP: Succeeded
NOT 04:51:32.234221 DHCP: IP Address -- 192.168.1.210
NOT 04:51:32.235023 DHCP: Subnet Mask - 255.255.255.0
NOT 04:51:32.235773 DHCP: Default Gwy - 192.168.1.1
INF 04:51:33.232453 DLoad: TFTP Svr set by opt150
INF 04:51:33.233255 DLoad: TFTP Svr0 --> 192.168.1.101
Any help please?!! Is there any way to upload a boot image via serial console?
none..... The %%$$# phone is
Sun, 05/11/2008 - 12:38am
none..... The %%$$# phone is not requesting any file...
The atftp.log is empty...... the last logs are from those old days (few days ago really) when the phone used to work fine!!.
atftpd is forking right, I've tested with a win32 client and all files in /tftpboot are viewable.
yes, that's what I did. In
Sun, 05/11/2008 - 4:50pm
yes, that's what I did. In fact, te log lines are from the boot process of the phone, read by the serial cable.
But, when the phone finishes it's boot process, the only application I can run is "setipcfg", in wich I can can configure IP addresses, TFT, alternate TFT, but no sucess, the phone doesn't show any sign of trying to contact the TFT server. I cheked it with Etherreal, no packets.
---------
setipcfg> getcfg
getcfg
status - 0x12310000
ip - 192.168.1.210
subnet - 255.255.255.0
default gateway - 192.168.1.1
alternate tftp server - 192.168.1.101
setipcfg>
-------------
I can also SSH to the phone, but as it can't read SEPxxx.xml, I can not asign a root password to log in with SSH.
I've read that there is a security issue with this phones, that would let me SSH with a default user and password (hard coded), but Cisco didn't published those information.
It would be nice to know how to upload the firmware via serial cable!
A long long time ago we
Sun, 05/11/2008 - 4:59pm
A long long time ago we bricked a phone. This is trickly from memory but I am almost sure you can reload the base code using xmodem protocol over the serial link.
Since it was a 7970 that got bricked, and they used to cost a fortune, I spent a better part of a day on it and got it back running.
I am sure half that time was trolling through useless links from Internet and Mailing List searches.
Sometimes I have very good luck finding stuff on Usenet.
Scott
--
Scott
aka "Skyking"
Thanks for your help
Fri, 05/16/2008 - 3:58pm
Thanks for your help Scott.
I've been the entire week looking for Xmodem, and it seems that this is the way to reload the firmware on a dead phone, but the information I found was from Cisco routers.
I've been looking for documentation on how to do it with IP Phones (they run CNU operating system), but I can't find anything.
If you remember the way you do it or remember where to look for that information please let me know!.
Thanks,
Victor
use build in trixbox dhcp
Fri, 05/16/2008 - 9:07pm
Well my memory was very bad
Fri, 05/16/2008 - 9:14pm
Well my memory was very bad that week, and I apologize for my mistake. Xmodem is for the ROMMON on the routers.
In fact that same 7970 came back and bit my because it is still bricked! I tried to use a serial cable per the Cisco documentation. I must be doing something wrong because I can't even get console output on a good phone.
I used a standard Cisco 9 pin serial adapter and used a rolled RJ11 cable with all four conductors in the jacket.
This is exactly what is in the Cisco documentation. I tried both Hypererminal and Putty 9600/8/N/1 no handshaking. I get nothing.
Please let me know what you did to get the serial cable going. I will be glad to share what I figure out.
Do you get anything on your display or are the line appearance keys flashing in order?
Scott
--
Scott
aka "Skyking"
Cisco 7941g serial console pinout
Sun, 06/01/2008 - 5:56pm
Hi, sorry for takin too long to answer, I was with some final exams.
Here is a picture of the 7941g AUX pinout:
http://img222.imageshack.us/img222/6124/imagen002wp1.jpg
It's very easy to build your cable, just get half of an RJ-11 cable and solder to a DB-9 RS-232 connector like this:
Cisco's Tx pin ---------------- RS-232 Pin 2
Cisco's Rx pin ---------------- RS-232 Pin 3
Cisco's Signal GND pin ------ RS-232 Pin 5
That's all, run Hyperterminal with 9600,8,N,1, no flow control and you should see the phone boot process and configure IP via serial console. Try it and post the serial log here so we can compare!, maybe we can make our Cisco phones back to life!!!.
On my 7941's display I get the initial CISCO screen, then I get a screen wich says the phone IP address and the Upgrading... legend. Then, it stays there forever...
I will make a connector like
Sun, 06/01/2008 - 7:47pm
OK, A slight OT, but along these lines.
Thu, 06/05/2008 - 9:31pm
I am trying to recover a bricked 7970 that is trying to TFTP firmware and does get some, but is failing while loading TFTP apps70.1-1-3-31.sbn and says the file is too large.
Here's the complete text from Hyperterm:
CNU version 2.5 (43.17); Built Nov 18 2003 17:31:02
sysboot: loading core applications.
INIT: Checking filesystem /dev/flash0...
INIT: Mounting filesystem...
INIT: Mount succeeded.
INIT: Displaying /bin/ciscostart.png
INIT: Starting applications from /usr/tmp/init.tab
INIT: State load_apps --> startup_apps
INIT: Starting /bin/strace
INIT: Starting /sbin/inetd
INIT: State startup_apps --> foregnd_app
INETD: pid = 6
INETD: /etc/inetd/inetd.conf does not exist
CDP: pid = 7
CDP: PHY 0 --> 100 MB LINK IS UP
CDP: PHY 1 --> LINK IS DOWN
DHCP: pid = 8
DHCP: COLDBOOT - wait 8 seconds...
CDP: VVLAN acquired --> VLAN = 4096, VVLAN = 4095
INIT: State foregnd_app --> startup_apps
INIT: Starting /sbin/tftpClient
INIT: Starting /sbin/imgauthd
INETD: SIGINFO received
INETD: SIGCONT received
DHCP: SIGINFO received
/sbin/imgauthd: version: 1.0(1.1): 7970 RELEASE, current key only
/sbin/imgauthd: raised CPU time limit to 20 sec
/sbin/imgauthd: ready
DHCP: state = INIT_REBOOT
DHCP: DHCP enabled, status = 0x12300000
DHCP: Sending Request...
DHCP: ACK received
DHCP: Succeeded
INIT: State startup_apps --> apps_up
INETD: SIGIPCFG received
DNS: pid = 15
INIT: Requesting load file /usr/tmp/term70.default.loads
tftpClient: tftp request rcv'd from /usr/tmp/initTftp, srcFile = term70.default.
loads, dstFile = /usr/tmp/term70.default.loads
TFTP: pid = 16
TFTP: Requesting term70.default.loads from 192.168.x.x
TFTP: Finished --> rcvd 641 bytes
INIT: Authenticating loaded file /usr/tmp/term70.default.loads
handle_verify_req: verifying with current 7970 RELEASE key
parseHdr(): skipping 3 trailing bytes of padding and/or unknown TLVs
verifySignedFile(): WARN! has future timestamp <1172546725>, current <1075140048
>
handle_verify_req: verififed with current 7970 RELEASE key
handle_verify_req: verification SUCCESS
INIT: Requesting archive image /usr/tmp/jar70sip.8-0-3-33.sbn
tftpClient: tftp request rcv'd from /usr/tmp/initTftp, srcFile = jar70sip.8-0-3-
33.sbn, dstFile = /usr/tmp/jar70sip.8-0-3-33.sbn
TFTP: pid = 17
TFTP: Requesting jar70sip.8-0-3-33.sbn from 192.168.x.x
TFTP: Finished --> rcvd 445891 bytes
INIT: Authenticating loaded file /usr/tmp/jar70sip.8-0-3-33.sbn
handle_verify_req: verifying with current 7970 RELEASE key
parseHdr(): skipping 2 trailing bytes of padding and/or unknown TLVs
verifySignedFile(): WARN! has future timestamp <1172546733>, current <1075140050
>
handle_verify_req: verififed with current 7970 RELEASE key
handle_verify_req: verification SUCCESS
INIT: Requesting archive image /usr/tmp/cnu70.3-1-3-31.sbn
tftpClient: tftp request rcv'd from /usr/tmp/initTftp, srcFile = cnu70.3-1-3-31.
sbn, dstFile = /usr/tmp/cnu70.3-1-3-31.sbn
TFTP: pid = 18
TFTP: Requesting cnu70.3-1-3-31.sbn from 192.168.x.x
TFTP: Finished --> rcvd 418055 bytes
INIT: Authenticating loaded file /usr/tmp/cnu70.3-1-3-31.sbn
handle_verify_req: verifying with current 7970 RELEASE key
parseHdr(): skipping 1 trailing bytes of padding and/or unknown TLVs
verifySignedFile(): WARN! has future timestamp <1172546728>, current <1075140053
>
handle_verify_req: verififed with current 7970 RELEASE key
handle_verify_req: verification SUCCESS
INIT: Requesting archive image /usr/tmp/apps70.1-1-3-31.sbn
tftpClient: tftp request rcv'd from /usr/tmp/initTftp, srcFile = apps70.1-1-3-31
.sbn, dstFile = /usr/tmp/apps70.1-1-3-31.sbn
TFTP: pid = 19
TFTP: Requesting apps70.1-1-3-31.sbn from 192.168.x.x
TFTP: 512000 bytes received
TFTP: 1024000 bytes received
TFTP: 1536000 bytes received
TFTP: 2048000 bytes received
TFTP: write failed : File too large
INIT: State apps_up --> update_done
INIT: State update_done --> kill_apps
INIT: Sending termination signals to apps for cause 3.
INIT: Killing non-child pid 15
DNS: SIGTERM received...DNS is exiting
INIT: Killing child /sbin/imgauthd, pid 10
/sbin/imgauthd: sig_handler: exiting on signal 23
INIT: Killing child /sbin/tftpClient, pid 9
INIT: Killing non-child pid 8
DHCP: SIGTERM received...DHCP is exiting
INIT: Killing non-child pid 7
CDP: SIGTERM received...CDP is exiting
INIT: Killing child /sbin/inetd, pid 6
INETD: SIGTERM received...inet daemon is exiting
INIT: State kill_apps --> load_apps
INIT: State load_apps --> reboot
INIT: Reboot in 60 seconds, cause 1
Now I'll admit that I have been awake for the last 18 hours and most of that has been spent working. As such I may be looking right at the problem and missing it through the caffeine haze.
Any ideas?
Are you working with SIP or
Fri, 06/06/2008 - 7:52am
Are you working with SIP or SCCP?
Try to find a newer firmware here: http://ftp.itl.ua/pub/cisco/ip-7900ser/
For example, SCCP or SIP release 8.0.2SR1
D O N O T F O L L O W V
Fri, 06/06/2008 - 8:14am
D O N O T F O L L O W V P R E A's L I N K
Not only is this a link to stolen software it is of dubious origin. This software has a high risk of truly bricking your phone.
The are only two safe, legitimate ways to obtain Cisco Firmware. Some is available for free at ftp.cisco.com or purchase a Smartnet contract for the phone for $10 from CDW.
Scott
--
Scott
aka "Skyking"
At this point, I don't care if it's SIP or SCCP.
Fri, 06/06/2008 - 8:26am
This phone is BRICKED. The screen won't come up (dark), and I get nothing more than flashing lights. The line/speed dial buttons flash in sequence until I pull the plug and the headphone button lights up steadily. If I can get ANY firmware loaded I can bring it back from the dead. I've tried a couple of different builds but the phone keeps looking for apps70.1-1-3-31.sbn.
I'll throw together a different TFTP server this weekend and see what happens then.
Quote:
I didn't know it was
Fri, 06/06/2008 - 10:45am
Quote:
I didn't know it was an stolen firmware page.
I don't know if it is stolen. It certainly is being distributed outside the UELA. Since we don't know where the code came from and can't verify the signature it should not be loaded.
Quote:
I'm sure they have to publish firmware for free.
Not hardly, this is about as far from free as you can get. There are two ways to purchase a new Cisco phone from a reseller. One is with a Cisco Unified Call Manager license and the other is as a service spare. A service spare has an equals sign at the end of a part number.
If you look at Voip Supply you will see two different part numbers one as a global spare and one with a license.
Without a valid license you are not entitled to use the Cisco firmware. You must hold a license per device to use the firmware.
The software on the ftp site is for EOL (End of Life) devices. I can only assume this is some sore of tacit exception the EULA. From a strict construction of the EULA the distribution of the software the public FTP site, does not void the entire license agreement.
The bottom line, a few phones at your house I would bet Cisco does not care about. If the phones are used in a commercial deployment or worse sold to and end user without licensing, the users/dealers are fully exposed.
With regard to the console port, thanks for asking, I have not had a chance to try again. Will keep you posted.
Scott
--
Scott
aka "Skyking"
HAW-LAY-LOU-YAA!
Sat, 06/07/2008 - 10:39am
Like I said, the answer was right in front of me...
I copied an old SCCP image to the TFTP server and edited the SEPmac.cnf.xml file but when the phone booted it tried to load the newer SIP image. I looked at File Manager and saw that there was a TERM70.DEFAULT.loads right above the term70.default.loads file. I renames the lowercase version and then renamed the UPPERCASE to lowercase and power cycled the phone.
The phone then proceded to fully load the SCCP firmware and IT WAS ALIVE!!!!
I have since renamed the files again and my bricked 7970 is now a fully functional SIP phone on my trixboxCE test box!
WOO HOO! (and I don't even bank at Washington Mutual...)
Do you think you could talk
Tue, 07/08/2008 - 4:44pm
Do you think you could talk me through doing that?
I've got a bricked 7941 which got to the dreaded 'upgrading' firmware screen, and never budged, and now doesn't even 'boot up', and when I run a 'reset' procedure, I can get the alternate line button flashing lights (holding down #)...
Can you remember what you did, and how - I'm a total newb at this and I have no idea how to setup a conf. file for SCCP, since I bought this phone SIPped...
I believe I have an SCCP image for this phone a few firmware generations old, as well as having the SIP firmware I want to run.
You probably don't need to downgrade...
Wed, 07/09/2008 - 8:31am
The 7970 I fixed was WAY bricked, not just stuck in an upgrade loop. The screen would never show anything but black and the line apperance buttons would flash in sequence. It was mostly a writeoff.
It sounds like you just need to have a good copy (ONLY ONE! *grin*) of a recent SIP firmware on your trixbox, create an extension in endpoint manager using the bricked phones MAC address, and have both Option 66 and Option 150 set correctly in your DHCP server. (I use a Linksys WRT300N with DD-WRT installed, but just about any good DHCP server should work. (Heck, turn it on in the trixbox and use that one...)
If you are in the SoCal area I would be happy to help but unfortunately, there can be several problems with the firmware/server/DHCP/etc that can be causing your problem. It's difficult to "walk you through" fixing them without seeing your setup.
Member Since:
2007-09-18