cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
284
Views
0
Helpful
1
Replies

7960G SCCP Firmware Upgrade Strange Fail

patrickherborn
Level 1
Level 1

I have two 7960G IP Phones. One has upgraded to SCCP firmware 8.1(2)_SR2 successfully, the other won't upgrade the application to the same version. The one which will not upgrade will accept SCCP firmware 8.0(4), but nothing newer (ie it will reject 8.0(5)). When the XMLDefault or SEP<MAC> file indicates a newer load, the phone will download and update the loader (.sbn), reboot with the new loader, try to fetch the application (.sb2) file, say it is verifying, sit there for a while, then fetch the .sb2 file again, then it boots the application in flash (ie 8.0(4)) without reporting any errors (but it is still the old application image running, not the new one). When trying to go from (say) a 5.X release to (say) 8.0(5) it will reject the image with an Auth error - it will accept 8.0(4) though.

 

Interestingly the phone will accept SIP firmware 8.12(0), and when going back to SCCP version 8.0(4) it will install the loader (.sbn) and the application (.sb2) and it will not fetch the .sb2 file twice - it updates the flash after the first fetch. Furthemore, it is fussy about which earlier SCCP image it will accept - even back to version 5 it refuses to accept some of the images. I am discounting image corruption because a) they were directly downloaded from Cisco and b) the other phone is NOT rejecting them.

 

Tried different DHCP options (66 only, 66 and 150 etc), tried different TFTP servers (default in.tftpd, aftpd running standalone and also tftp server on a Cisco 7200 VXR), the behaviour is always the same - fetches the .sb2 file twice and then gives up and boots the image in flash - indeed if trying to go from SIP image 8.12 to SCCP 8.0(5) it will update the loader, then it will boot the (still resident) SIP application!

 

Tried numerous factory resets on the phone, with different images in flash and nothing seems to be able to get anything newer than 8.0(4) into the flash. Running out of ideas now on what to try next... at this rate the flash write endurance may start becoming an issue! This leaves three question marks - a) is it possible that something in (or not in) the XMLDefault or SEP<MAC> file could cause certain image upgrades to fail (for one phone and not another) ? b) is it possible that there is something in flash already that is preventing is (previous CTL or something like that ?) and if so, is it possible to wipe the flash and get the boot ROM to fetch the loader and application to populate a clean flash (349167258 style reset does not work, but IIRC that's for a 79x1 not 79x0) ? and c) is it possible that there is an incompatibility between the boot ROM code or DSP and the image (these differ between the two phones).

 

Any ideas much appreciated.... right now it looks like this phone is going to be SIP only (or stuck at SCCP 8.0(4)).

 

Regards,


Pat.

1 Reply 1

patrickherborn
Level 1
Level 1

A little more info....

 

A console cable connected to the RS232 shed some light on this. Interesting messages from the Little-App and Big-App are :


First, the Little-App :

Old App: P00308000400  New App: P00308010100.sb2

*** check App image: P00308010100.sb2
TFTP: Request file:P00308010100.sb2 from: <172.16.68.10>
TFTP: File received successfully!
parseHdr: start of pad ('T' 0x0d) at TLV 14
parseHdr: WARN!: got hdr version <1.1>, expected <1.2>
parseHdr): skipping 3 trailing bytes of padding and/or unknown TLVs
verifySignedFile(): RSA decr of sig failed
validate_file_envelope: Error: File sign verify FAILED
parseHdr: start of pad ('T' 0x0d) at TLV 14
parseHdr: WARN!: got hdr version <1.1>, expected <1.2>
parseHdr): skipping 3 trailing bytes of padding and/or unknown TLVs
verifySignedFile(): file hash doesn't match hash in sig
validate_file_envelope: Error: File sign verify FAILED
Waiting to retry fetch of BA image file
TFTP: Request file:P00308010100.sb2 from: <172.16.68.10>
TFTP: File received successfully!
parseHdr: start of pad ('T' 0x0d) at TLV 14
parseHdr: WARN!: got hdr version <1.1>, expected <1.2>
parseHdr): skipping 3 trailing bytes of padding and/or unknown TLVs
verifySignedFile(): RSA decr of sig failed
validate_file_envelope: Error: File sign verify FAILED
parseHdr: start of pad ('T' 0x0d) at TLV 14
parseHdr: WARN!: got hdr version <1.1>, expected <1.2>
parseHdr): skipping 3 trailing bytes of padding and/or unknown TLVs
verifySignedFile(): file hash doesn't match hash in sig
validate_file_envelope: Error: File sign verify FAILED

 

And then in the Big-App :

 

09:04:10.630 addSignedBlock: invalid signed block or size
09:04:10.660 The MIC region in Manufacturing sector is corrupt!

 

Looks like this unit may have issues. What's not so obvious is why some of the signed images (like 8.0(4)) will flash OK whereas others (including things back to 6.x) don't. Guess this unit is going to be stuck with 8.0(4) or it will have to run SIP.

 

Regards,


Pat.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: