[cisco-voip] 7945 phone has wrong time and can't verify config

Wed Nov 6 01:15:35 EST 2013

Well, the rest of the phones are liking the config now since correcting the
issue with Enterprise Phone configuration.

Strange....

On Tue, Nov 5, 2013 at 3:40 PM, Stephen Welsh
<stephen.welsh at unifiedfx.com>wrote:

>  Strange, so it looks like an DB inconsistency was generating duff config
> files?
>
>  Sorry to hear you have to delete those dam ITL files, I know a product
> that will help you to remotely delete them, unfortunately it’s not free (we
> all have to make a living ;)
>
>  Stephen
>
>  On 5 Nov 2013, at 21:32, Erick B. <erickbee at gmail.com> wrote:
>
>  I think I fixed this... on the System -> enterprise phone configuration
> page it was initially throwing an error message on both servers.
>
>  Status
> Error Message Unmapped Exception The content of elements must consist of
> well-formed character data or markup.
>
>  It had a save button.  I hit save and it then displayed the settings and
> such as normal. I then saved again and went to another page and back and it
> was still displaying fine. I then reset 2 phones and they updated fine and
> no verify error. Looks like I need to go around and delete the ITLs and
> trust lists on phones we did not test with since those say trust list
> update failed.
>
>  Weird one, thanks for the pointers guys.
>
>
>
>
>
> On Tue, Nov 5, 2013 at 3:02 PM, Erick B. <erickbee at gmail.com> wrote:
>
>> Yep, deleted the phone and re-added it as correct type. The phones are
>> setup and registered and working as correct model. Just not verifying
>> configuration and phones on older firmwares not updating. Some show wrong
>> time depending on firmware version.  I did make a new datetime group but
>> phone did not take condfig due to this underlying verification issue.
>>
>>  If I go under System -> Enterprise Phone configuration it errors on
>> that page. Doesn't display anything but error message.
>>
>>  Status
>> Error Message Unmapped Exception The content of elements must consist of
>> well-formed character data or markup.
>>
>>  Tried to restart tomcat, same thing. The servers were rebooted last
>> week.
>>
>>
>>
>> On Tue, Nov 5, 2013 at 2:39 PM, Wes Sisk (wsisk) <wsisk at cisco.com> wrote:
>>
>>> Possibilities:
>>> CSCts83522    Unsupported phone service category prevents device
>>> registration
>>>
>>>
>>>  Is 192.168.5.10 the correct TFTP server?
>>>
>>>  Found at least one instance of this where devices were provisioned as
>>> wrong type in CUCM.
>>>
>>>  Try deleting the phone to clear all features and letting it
>>> re-register. Or just change the MAC address to save the existing
>>> configuration and re-add the phone as a new phone with no or minimal
>>> configuration.
>>>
>>>  Errors parsing the dateTimeSetting are also related to old phone loads
>>> (pre-olson implementation) configured with olson timezones.
>>>
>>>
>>>  "Parser Exception: name expected "
>>>
>>>  This makes me suspect the XML file integrity like transfer may be
>>> incomplete or corrupted in transit.
>>>
>>>  -Wes
>>>
>>>  On Nov 5, 2013, at 3:04 PM, Erick B. <erickbee at gmail.com>
>>>  wrote:
>>>
>>> The phone is registered and working.
>>>
>>>  Just wrong time, and not updating to current firmware on server and
>>> probably not taking phone changes.
>>>
>>>  Stephen's cisco link was in right direction, but the XML parse is
>>> throwing errors on device pool section. We've made a new device pool with
>>> new settings, new date/time group and it still is having issues with
>>> parsing device pool settings.
>>>
>>>  It is downloading the cfg file file, authenticating it fine (success
>>> for that) but having issue parsing the cfg once downloaded.
>>>
>>>  This is a 7945 with SCCP45.9-2-3S, the default load
>>> is SCCP45.9-3-1SR2-1S. Most of the phones have error verifying config -
>>> multiple models. There is one 7945  with 7945.default load to not updating.
>>>
>>>  9791: NOT 13:48:21.430429 TFTP: [14]:Requesting
>>> SEP001D705EB9DA.cnf.xml.sgn from 192.168.5.10 with size limit of 550001
>>> 9792: NOT 13:48:21.450165 TFTP: [14]:Finished --> rcvd 9501 bytes
>>> 9793: NOT 13:48:21.462040 SECD: verifyFile: sgn-verify
>>> </usr/ram/SEP001D705EB9DA.cnf.xml>, 'name'[SEP001D705EB9DA.cnf.xml.sgn]
>>> 9794: NOT 13:48:21.464543 SECD: parseHdr(): start of pad ('T' 0x0d) at
>>> TLV 15
>>> 9795: NOT 13:48:21.465226 SECD: parseHdr(): skipping 1 trail bytes (pad
>>> and/or unknown TLVs)
>>> 9796: NOT 13:48:21.467750 SECD: parseHdr(): start of pad ('T' 0x0d) at
>>> TLV 15
>>> 9797: NOT 13:48:21.468668 SECD: parseHdr(): skipping 1 trail bytes (pad
>>> and/or unknown TLVs)
>>> 9798: NOT 13:48:21.518135 SECD: file sgn verify SUCCESS, hdr 336 byte,
>>> </usr/ram/SEP001D705EB9DA.cnf.xml>
>>> 9799: NOT 13:48:21.518969 SECD: verifyFile: file sgn verified
>>> </usr/ram/SEP001D705EB9DA.cnf.xml>, hdrlen 336
>>> 9800: NOT 13:48:21.519982 SECD: verifyFile: hdr ver [2.0], and file not
>>> encr, </usr/ram/SEP001D705EB9DA.cnf.xml>
>>> 9801: NOT 13:48:21.532024 SECD: verifyFile: 9165 byte after hdr strip,
>>> </usr/ram/SEP001D705EB9DA.cnf.xml>
>>> 9802: NOT 13:48:21.532752 SECD: verifyFile: verify SUCCESS
>>> </usr/ram/SEP001D705EB9DA.cnf.xml>
>>> 9803: NOT 13:48:21.551304 tftpClient: authorize file = 12, isEncr = 0
>>> 9804: NOT 13:48:21.558846 SECD: lookupCTL: TFTP SRVR secure
>>> 9805: NOT 13:48:22.429740 JVM: Startup Module Loader|cip.cfg.t:? -
>>> Config handleTftpResponse, status=0 for file=ram/SEP001D705EB9DA.cnf.xml
>>> 9806: NOT 13:48:22.434950 INETD: Set IP mode 1
>>> 9807: WRN 13:48:22.466548 JVM: Startup Module Loader|cip.xml.ap:parse -
>>> Encoding Updated to UTF-8
>>> 9808: WRN 13:48:22.468227 JVM: Startup Module Loader|cip.xml.ap:  - XML
>>> Parser Warning: Unknown element 'name' in element '/device/devicePool'
>>> (line=16)
>>> 9809: WRN 13:48:22.469870 JVM: Startup Module Loader|cip.xml.ap:  - XML
>>> Parser Warning: Unknown element 'name' in element
>>> '/device/devicePool/dateTimeSetting' (line=18)
>>> 9810: WRN 13:48:22.472332 JVM: Startup Module Loader|cip.xml.ap:  - XML
>>> Parser Warning: Unknown element 'name' in element
>>> '/device/devicePool/callManagerGroup' (line=38)
>>> 9811: WRN 13:48:22.474019 JVM: Startup Module Loader|cip.xml.ap:  - XML
>>> Parser Warning: Unknown element 'tftpDefault' in element
>>> '/device/devicePool/callManagerGroup' (line=39)
>>> 9812: WRN 13:48:22.475703 JVM: Startup Module Loader|cip.xml.ap:  - XML
>>> Parser Warning: Unknown element 'mgcpPorts' in element
>>> '/device/devicePool/callManagerGroup/members/member/callManager/ports'
>>> (line=49)
>>> 9813: WRN 13:48:22.477512 JVM: Startup Module Loader|cip.xml.ap:  - XML
>>> Parser Warning: Unknown element 'mgcpPorts' in element
>>> '/device/devicePool/callManagerGroup/members/member/callManager/ports'
>>> (line=65)
>>> 9814: WRN 13:48:22.479195 JVM: Startup Module Loader|cip.xml.ap:  - XML
>>> Parser Warning: Unknown element 'name' in element
>>> '/device/devicePool/srstInfo' (line=76)
>>> 9815: WRN 13:48:22.480925 JVM: Startup Module Loader|cip.xml.ap:  - XML
>>> Parser Warning: Unknown element 'userModifiable' in element
>>> '/device/devicePool/srstInfo' (line=78)
>>> 9816: WRN 13:48:22.482619 JVM: Startup Module Loader|cip.xml.ap:  - XML
>>> Parser Warning: Unknown element 'mlppDomainId' in element
>>> '/device/devicePool' (line=93)
>>> 9817: WRN 13:48:22.484214 JVM: Startup Module Loader|cip.xml.ap:  - XML
>>> Parser Warning: Unknown element 'mlppIndicationStatus' in element
>>> '/device/devicePool' (line=94)
>>> 9818: WRN 13:48:22.485860 JVM: Startup Module Loader|cip.xml.ap:  - XML
>>> Parser Warning: Unknown element 'preemption' in element
>>> '/device/devicePool' (line=95)
>>> 9819: ERR 13:48:22.487534 JVM: Startup Module Loader|cip.xml.ap:  - XML
>>> Parser Exception: name expected (position:START_TAG <null>@122:2 in
>>> java.io.InputStreamReader at 30ed62)  (line=122)
>>> 9820: ERR 13:48:22.489157 JVM: Startup Module Loader|cip.cfg.t:? - ERROR
>>> PARSING CONFIG file:ram/SEP001D705EB9DA.cnf.xml
>>>
>>>
>>>
>>>
>>> On Tue, Nov 5, 2013 at 1:50 PM, Andy Carse <andy.carse at gmail.com> wrote:
>>>
>>>> Only because I ran into this the other day, but with a 7942.
>>>> Is it that it doesn't register?
>>>> Mine was to do with the firmware on the handset requiring 9.3.1sr1
>>>> minimum. Shown in the console logs.
>>>>   On 5 Nov 2013 17:43, "Erick B." <erickbee at gmail.com> wrote:
>>>>
>>>>>  Anyone have any ideas on this? I've become pretty good at figuring
>>>>> out SBD issues but this one is throwing me for a loop.
>>>>>
>>>>>  I've followed the SBD document and verified the ITL values and
>>>>> regenerated TVS, TFTP, Tomcat and restarted those services but can't get
>>>>> the 7945 to verify the config file.
>>>>>
>>>>>  The phone has ITL value of 8d50d44a707119a37dc5f66bd7149041 and the
>>>>> publisher server where TFTP is running also has same ITL value (show itl)
>>>>> command.
>>>>>
>>>>>  The subscriber server has a different ITL value.
>>>>>
>>>>>  The phones use the primary/publisher server for TFTP.
>>>>> CUCM version is 8.6.2a SU2.  The trust lists, etc have been deleted
>>>>> from phones and factory reset also.
>>>>>
>>>>>
>>>>>  Thanks, Erick
>>>>>
>>>>>  _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>  _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>  _______________________________________________
> 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/20131106/8ea7197e/attachment.html>