[ntp:questions] Manycast server stops answering after the client has synchronized

Jussi Nieminen j.nieminen at aerospy.at
Mon Oct 8 12:32:20 UTC 2012


Hi all,

I'm trying to set up a simple synchronization test scenario with two computers, the other synchronizing over the internet and acting as a manycast server while the other is a manycast client. The initial connection is created without problems and the machines start trading messages but once the client is synchronized (and sends a message with a stratum value other than "unspecified or invalid" 0), the server stops answering. The server claims to be a stratum 3 machine and the client (correctly, afaik) then becomes stratum 4.

The server machine stays connected to its own servers all the time and ntpq -p return the following table:

---8<---
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.          12 l  91m   64    0    0.000    0.000   0.000
+ntp1.sil.at     131.130.251.107  2 u   25   64  377   22.807   41.149   7.845
-vz00.holub.co.a 26.91.187.18     2 u   22   64  377   23.842   29.585   8.219
*svn.mediainvent 193.171.23.163   2 u   22   64  377   10.310   35.211   8.168
+nntpcache01.opt 195.58.160.5     3 u   45   64  377   34.511   32.236   6.326
+ntp2.exa-networ 157.44.176.4     2 u   32   64  377   44.992   33.462   6.107
---8<---

The peer info for the client looks correct (I don't paste it here because I doubt it's not going to help). The server appears on the list at first, gets the asterisk in front of it (so synchronization happens) and then, when there's no more responses, the reach starts showing missed requests until the server disappears from the list.

The config file for the server is following:

---8<---
keys "C:\Program Files\NTP\etc\ntp.keys"
trustedkey 1
driftfile "C:\Program Files\NTP\etc\ntp.drift"
tos minclock 1 minsane 1
manycastserver 224.0.1.2
server 127.127.1.0
fudge 127.127.1.0 stratum 12
server 0.at.pool.ntp.org iburst
server 1.at.pool.ntp.org iburst
server 2.at.pool.ntp.org iburst
server 1.de.pool.ntp.org iburst
server 2.uk.pool.ntp.org iburst
logfile "C:\workdir\tmp\ntp_stats\ntpd.log"
---8<---

And the client config:

---8<---
keys "C:\Program Files\NTP\etc\ntp.keys"
trustedkey 1
driftfile "C:\Program Files\NTP\etc\ntp.drift"
tos minclock 1 minsane 1
manycastclient 224.0.1.2 iburst key 1
logfile "C:\workdir\tmp\ntp_stats\ntpd.log"
---8<---

I'm pretty confused about this. The server has a lower stratum than the client (and by default should also reply to clients with an equal stratum) and it is constantly synchronized itself, so there shouldn't be any reason for it not to reply. Every time I restart the client ntp service, the connection is once again successfully made and only breaks once the client starts sending packets with the stratum 4. Could there be something else in the packet that causes this? Just in case, here's a packet before and after the initial synchronization (from Wireshark):

---8<---
# before:
Network Time Protocol
    Flags: 0xe3
    Peer Clock Stratum: unspecified or invalid (0)
    Peer Polling Interval: 6 (64 sec)
    Peer Clock Precision: 0,000977 sec
    Root Delay:    0,0000 sec
    Root Dispersion:    0,0011 sec
    Reference ID: (Initialization)
    Reference Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Origin Timestamp: Oct  8, 2012 11:35:43.133811000 UTC
    Receive Timestamp: Oct  8, 2012 11:35:43.152932000 UTC
    Transmit Timestamp: Oct  8, 2012 11:35:45.151497000 UTC
    Key ID: 00000001
    Message Authentication Code: 38fa9a6.....

# after:
Network Time Protocol
    Flags: 0x23
    Peer Clock Stratum: secondary reference (4)
    Peer Polling Interval: 6 (64 sec)
    Peer Clock Precision: 0,000977 sec
    Root Delay:    0,0113 sec
    Root Dispersion:    1,0377 sec
    Reference ID: 192.168.1.92
    Reference Timestamp: Oct  8, 2012 11:35:45.152503000 UTC
    Origin Timestamp: Oct  8, 2012 11:35:45.133783000 UTC
    Receive Timestamp: Oct  8, 2012 11:35:45.152503000 UTC
    Transmit Timestamp: Oct  8, 2012 11:35:47.151741000 UTC
    Key ID: 00000001
    Message Authentication Code: b79bbf6.....
---8<---

I think that's all the info I can provide. Any help is greatly appreciated!

Cheers,
Jussi Nieminen


More information about the questions mailing list