Cisco 9971 not accepting NTP settings?

[lukebenfey]

Heya guys... We've got some Cisco 9971s that I've been trying to configure to work with our SIP Server... I've got them making/receiving calls fine, which is great, but I'm seeing a weird problem that LOOKS like it is on the phone side.  Specifically, NTP settings made in the .cnf.xml file do not seem to be registering.  The result is that the phone always thinks it is 16:00 on 12/31/81 whenever it boots. 

The relevant section of my SEP(mac).cnf.xml is:

    <dateTimeSetting>

      <dateTemplate>M/D/Y</dateTemplate>

      <timeZone>Pacific Standard/Daylight Time</timeZone>

      <ntps>

        <ntp>

          <name>192.168.168.10</name>

          <ntpMode>Unicast</ntpMode>

        </ntp>

      </ntps>

    </dateTimeSetting>

When I watch all the traffic to/from this port with Wireshark I don't see any attempts to talk to the IP of the NTP server at all.  

Anyone have any ideas?

Thanks!

[chrisax212]

@ Joseph Martini

You said it worked with a newer load, can you tell us which version you used?

Maybe we just need a differnt configuration in the SEP file.

With 9.0.4 this works for me:

            D.M.Y

            W. Europe Standard/Daylight Time

                    192.53.103.108

                    unicast

Could you post your config?

[lukebenfey]

Sure thing, the setting that I ended up using is:

      M/D/Y

      Pacific Standard/Daylight Time

          10.1.10.42

          Unicast

----

But, I tried a lot of other things before realizing that I needed to stick with 9.0.4 in order to get it to work.  I don't really remember the specifics, however, as this was over two years ago.

[Till Steinbach]

The interesting question is: what do we have in common what other users don't have:

      D.M.Y

      W. Europe Standard/Daylight Time

             10.11.2.254

             unicast

Most interesting would be to see a config of a user who has a running setup!

[Joseph Martini]

I used 9.3(4).

{9ec4850a-7748-11d3-bdf0-00108302ead1}">
CMLocal
M/D/Y
Greenwich Standard Time
Etc/GMT


172.18.108.15
Anycast

[Till Steinbach]

I just copied the part you posted and changed the IP to my server. No changes in the behaviour. Are you shure that your 99xx Phone is using the NTP-Server and not the time provided by the register response?

[Till Steinbach]

Ahhh, here is another suspicious line:

4171 ERR 01:01:21.740800  NTP: -Missing or invalid argument on line 1

[chrisax212]

@Luke

Sorry the questions wasn't for you, it was an question/answer for Joseph.

It's a bit hard to see in this forum, so I edited my post.

@Till

try instead of

I think this resolved the error with the missing argument, but not the whole ntp problem.

[Till Steinbach]

No I don't think that argument is allowed:

3805 WRN 00:01:18.331728  CVM-xml.LogWarning: [thread=configmgr MQThread][class=cip.xml.ad][line=13] XML Parser Warning: Unknown attribute 'priority' in element '/device/devicePool/dateTimeSetting/ntps/ntp/name'

I think the error message is independent of the argument, but have not confirmed that yet

[Joseph Martini]

Follow up from my last post.  My test wasn't completed enough.  I setup an NTP reference with a date of Jan 1, 2035 and pointed my phone to it.  The phone while on firmware 9.0(4) showed the correct Jan 1, 2035 time on the phone and not the time from my server which is today's date and time.  Upgrading the phone to 9.4(1) which is the newest available, and changing nothing else in my environment, I saw the CUCM's time not the NTP reference time on the phone.  This confirms that this is indeed broken.  I've brought this up to the phone developers and filed a defect for it, CSCul33490 (should be visible in the bug toolkit in about 24 hours).

Thanks for finding this and pointing it out!  I wouldn't have noticed since the time on CUCM is almost never wrong since NTP is required to expose this.

[chrisax212]

Thanks,

at least now we know for sure, that it is a bug and I can stop testing different NTP settings

Hopefully they will resolve this with the next version.

[Till Steinbach]

The ticket was closed without a resolution. I don't know why.

[Till Steinbach]

Is the bug id correct? It's still not visible.

Best regards

Till

[Joseph Martini]

Thanks for the follow up Till.  I just checked on the bug again and it should be visible shortly.

[Alexander Shestov]

in case its useful for someone. Its not a bug - ntp is intentionally turned off >91(1).

https://tools.cisco.com/bugsearch/bug/CSCul33490

[AlexRyan10043]

Your post was very useful.

Thank you very much.

I stumbled upon the same problem while trying to set the time on a 9971 connected to Fritz!Box.

...and after looking here I found a solution on a German page. Simply search for "sip-date.pl cisco-8961-9951-9971" and let Google translate the page.

I had to alter the code for the sip-date.pl a bit. This is the diff I had to apply to make it run under Ubuntu 18.04:

--- sip-date.pl.org     2019-05-03 21:13:58.168648698 +0200
+++ sip-date.pl     2019-05-03 21:19:03.048169800 +0200
@@ -38,9 +38,8 @@

 sub cb()
 {
-    my ($dummy,$payload) = @_;
+    my ($payload) = @_;
     print "Perl callback called!\n";
-    print "dummy is $dummy\n" if $dummy;
     if ($payload) {
         print "len: " . $payload->get_length() . "\n";

@@ -114,10 +113,6 @@
 $q = new nfqueue::queue();


-print "open\n";
-$q->open();
-print "bind\n";
-$q->bind(AF_INET);


 $SIG{INT} = "cleanup";
@@ -132,7 +127,7 @@


 print "creating queue\n";
-$q->create_queue(0);
+$q->fast_open(0, AF_INET);


 print "trying to run\n";

The time display now looks like this:

Good luck.