[cisco-voip] 79xx and Firmware 9-2-1

Wed Jan 4 23:57:36 EST 2012

Would that be CSCtr27100?  (That's the version I'm on 8.5.1.11900-21)

I see references to ITL files:
Specifically this from Wes and Jason (Burns) which is where that
bug originated from.
https://puck.nether.net/pipermail/cisco-voip/2011-June/022700.html

I pulled my TVS logs and found this:

22:14:50.148 |   debug ERROR:loadFile () - Unable to open file -
/usr/local/cm/tftp/CTLFile.tlv for reading (errno - 2)
22:14:50.148 |   debug ERROR:Unable to open file
/usr/local/cm/tftp/CTLFile.tlv, errno 2

That the timestamp from when the device pack was added.  However, I don't
see any of the "Writing" errors that Wes specifically mentions.  (This
might be one of the red herrings he DID mention)

I think it's time for a TAC case

On Wed, Jan 4, 2012 at 10:28 PM, Matthew Berry <matthew.berry at cdw.com>wrote:

>   Aside from a factory reset, you could try deleting the ITL file off the
> phone.  Yes, it is still a manual process, but it isn't as time consuming
> as a factory reset (process below).
>
>  I spoke with a TAC engineer last month about this.  It has been
> identified as a bug and will be resolved in a future release.
> Unfortunately, I can't locate the bug ID for it.  I will email him and see
> if I can get a response.
>
>  Steps to delete ITL file:
> 1. Select Settings
> 2. Select Security Configuration (4)
> 3. Select Trust List (5)
> 4. Press * * # (Padlock in upper righthand corner will unlock)
> 5. Select ITL File (2)
> 6. Select More
> 7. Select Erase
> 8. Phone will display "Erasing CTL and ITL files" and reset
> 9. Phone will optionally upgrade firmware
>
>
>   Thanks,
>
>  Matthew Berry, CCIE #26721 (Voice)
> Sr. Unified Communications Engineer, CDW
> +1.763.592.5987  |  protocol.by/matthewberry
>
>   From: Mike King <me at mpking.com>
> Date: Wed, 4 Jan 2012 22:06:24 -0500
>
> To: Cisco VoIPoE List <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] 79xx and Firmware 9-2-1
>
>  Ok.
>
>  Any idea's on how this happened?  I'm very interested in not repeating
> this experience.
>
>  We added the latest devicepack, the Cius 9-2-3.cop file, and then
> rebooted all servers in our cluster.
>
>  Since the latest devicepack included 9-2-1 for our phones, all our
> phones updated.    At this point, I have no idea how many phones are
> affected, but I have reports from nearly all of my sites, so it must be a
> significant number.
>
>  No settings where changed on the PUB/SUB's other than the addition of
> the the two .cop files.   I find it very disheartening/disturbing that
> such a minor *normal* maintenance item is going to cost me the amount of
> hours it's going to take to fix this.
>
>  Other than buying 3rd party software (Thanks Steve!), Cisco needs to put
> some serious thought in a way to fix this.  I'm not the first sad story
> involving this *Feature*.  I know I won't be the last.  Touching every
> single phone in my environment (Because how else can you verify if it's
> failing or not) is not really a solution.  We have sites in other states,
> and most of our operation is remote support.
>
>  Is factory default the only Cisco answer?
>
>
> On Wed, Jan 4, 2012 at 6:24 PM, Mike King <me at mpking.com> wrote:
>
>> I have one of those sinking feelings in my stomache...........
>>
>>
>>  (Clip of the phone web interface)
>>
>>  1856: NOT 18:01:32.717962 SECD: tvsReqAuthenticateCertificate: Received
>> the response from TVS proxy, status: 1
>> 1857: ERR 18:01:32.719531 SECD: Authentication failed for the HTTPS conn
>> via TVS
>> 1858: NOT 18:01:32.720438 SECD: srvr_cert_vfy:  ** srvr cert verify
>> FAILED ** <10.1.1.1>
>> 1859: ERR 18:01:32.721527 SECD: EROR:clpState: SSL3 alert
>> write:fatal:handshake failure:<10.1.1.1>
>> 1860: ERR 18:01:32.722625 SECD: EROR:clpSetupSsl: ** SSL handshake
>> failed, <10.1.1.1> c:9 s:11
>> 1861: ERR 18:01:32.723402 SECD: EROR:clpSetupSsl: SSL/TLS handshake
>> failed, <10.1.1.1> c:9 s:11
>> 1862: ERR 18:01:32.724086 SECD: EROR:clpSetupSsl: SSL/TLS setup failed,
>> <10.1.1.1> c:9 s:11
>> 1863: ERR 18:01:32.724720 SECD: EROR:clpSndStatus: SSL CLNT ERR,
>> srvr<10.1.1.1>
>> 1864: ERR 18:01:32.725353 SECD: EROR:secErr_errStr:  *** bad err table ***
>> 1865: ERR 18:01:32.726020 SECD: EROR:secErr_errStr: ** SEC-ERR:
>> code:3(N/A) subcode:9(UNKNOWN_CERT)
>> 1866: ERR 18:01:32.726704 SECD: EROR:clpSndStatus: ** SEC-ERR: desc
>> <HTTPS cert failed auth via TVS>
>> 1867: ERR 18:01:32.727436 SECD: EROR:clpWriteToClntSock: write() err,
>> clnt closed ?!, errno 32, <10.1.1.1> c:9 s:11
>> 1868: ERR 18:01:32.728124 SECD: EROR:clpSndStatus: failed to send SSL/TLS
>> conn status, <10.1.1.1> c:9 s:11
>> 1869: NOT 18:01:32.730813 SECD: clpDelClnt: closing conn to
>> <10.201.27.5>, c:14, s:-1
>> 1870: NOT 18:01:32.731684 SECD: clpDelClnt: Closing the local socket now
>>
>>  1871: NOT 18:01:32.740853 SECD: clpDelClnt: closing conn to <10.1.1.1>,
>> c:9, s:11
>> 1872: NOT 18:01:32.742630 SECD: clpDelClnt: Closing the local socket now
>>
>>
>>
>>
>>
>> On Wed, Jan 4, 2012 at 6:17 PM, Mike King <me at mpking.com> wrote:
>>
>>> I've seen mention of TVs failure on the logs. What impact would that be?
>>>  On Jan 4, 2012 6:08 PM, "Dennis Heim" <Dennis.Heim at cdw.com> wrote:
>>>
>>>>  I know I have seen that where there were issues with SBD/TVS
>>>> certificate issues in the past.****
>>>>
>>>> ** **
>>>>
>>>> Dennis Heim
>>>> Senior Engineer (Unified Communications)
>>>> CDW  Advanced Technology Services
>>>> 10610 9th Place
>>>> Bellevue, WA 98004
>>>>
>>>> 425.310.5299 Single Number Reach (WA)****
>>>>
>>>> 317.569.4255 Single Number Reach (IN)
>>>> 317.569.4201 Fax
>>>> dennis.heim at cdw.com*
>>>> *cdw.com/content/solutions/unified-communications/<http://www.cdw.com/content/solutions/unified-communications/>
>>>> ****
>>>>
>>>> ** **
>>>>
>>>> *From:* cisco-voip-bounces at puck.nether.net [mailto:
>>>> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Mike King
>>>> *Sent:* Wednesday, January 04, 2012 3:04 PM
>>>> *To:* Cisco VoIPoE List
>>>> *Subject:* [cisco-voip] 79xx and Firmware 9-2-1****
>>>>
>>>> ** **
>>>>
>>>> I'm having a weird problem with our 7900's (7941/7945 7961/7965)****
>>>>
>>>> The Corporate Directory won't work on some of the phones.   (We've
>>>> eliminated everything but the phone's themselves, I actually have two
>>>> phones, on the same subnet, one exhibits behavior, one doesn't)****
>>>>
>>>> ** **
>>>>
>>>> It says "requesting...." then eventually says Host does not respond.***
>>>> *
>>>>
>>>> ** **
>>>>
>>>> We finally decided to try downgrading the phone back to 9.1.1 SR1s.  **
>>>> **
>>>>
>>>> ** **
>>>>
>>>> The phones that don't display the corporate directory, they also don't
>>>> downgrade.****
>>>>
>>>> ** **
>>>>
>>>> I've Reset/Restarted from CM****
>>>>
>>>> I've done the **#** from the keypad****
>>>>
>>>> I've unplugged the phone, and plugged it back in.****
>>>>
>>>> I've unplugged the phone, waited 5 minutes, and plugged it back in.
>>>> Doesn't downgrade.****
>>>>
>>>> ** **
>>>>
>>>> I tried a factory reset, (# key, then 123456789*0#) and the phone will
>>>> then download the correct version.  (I guess it has to at this point)**
>>>> **
>>>>
>>>> ** **
>>>>
>>>> (And the corporate directory started working again.)****
>>>>
>>>> ** **
>>>>
>>>> Idea's besides visiting every phone?****
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>
>>
>  _______________________________________________ cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120104/ecb7e389/attachment.html>