[ntp:questions] NTP multicast client appears to work in unicast...

Tim Tanguy.ropitault at gmail.com
Wed Apr 5 12:49:25 UTC 2006


Hi, here is my problem. (I use NTP 4..2.0 version on both machines)
I have an NTP server wich use the multicast mode... here is the
ntp.conf for this machine:

server 0.europe.pool.ntp.org iburst
server 1.europe.pool.ntp.org iburst
server 2.europe.pool.ntp.org iburst
broadcast 224.0.1.1 key 1 ttl 1
driftfile /etc/ntp.drift
keys /etc/ntp.keys
trustedkey 1
trustedkey 2
trustedkey 3
enable auth
controlkey 1
requestkey 1

So I set a client machine in multicastclient mode. Here is its ntp.conf
keys /etc/ntp.keys
trustedkey 1
multicastclient 224.0.1.1
#broadcastclient
driftfile /etc/ntp.drift
statistics loopstats
statsdir /var/log/ntp/
filegen peerstats file peers type day link enable
filegen loopstats file loops type day link enable

The content of ntp.keys file are the same. It's MD5 keys... so here is
the problem. I start my server, ntpq -p shows:
[root at linux2400 tar]# ntpq -p
     remote           refid      st t when poll reach   delay   offset
jitter
==============================================================================
+discovery.jonep 80.239.2.130     3 u   30   32  377  121.375    0.541
10.825
*80-28-46-78.ads 150.214.94.5     2 u   31   32  376  133.226    1.820
 5.949
+skylar.fbagroup 193.62.22.98     2 u   29   32  377   68.968   -0.755
 5.616
 NTP.MCAST.NET   .MCST.          16 u    -   64    0    0.000    0.000
4000.00
wich is quite normal.
Now, when I start the client, ntpq -p gives:
ntpq -p
No association ID's returned
So I think It's normal, the 8 packets exchange must be done in order to
enter in the multicast mode but the problem is the result giver with
ntpq -p after. It shows:
 ntpq -p
     remote           refid      st t when poll reach   delay   offset
jitter
==============================================================================
*192.168.1.20    80.28.46.78      3 u   39 1024   77    0.349   15.870
 0.246
So my client is running exactly as If it was in client server mode wich
is not normal... when I use ethereal for monitoring what's going on, It
confirms what I think... First, the server send a multicast packet, the
client receives it but don't answer to the server... in fact, the
client waits 64 second to send a packet to the server as if it was in
client-server... and the, when four packets has been sent to the
server, its run exactly like in the client server mode... the client
polls the server depends on its poll intervall, and it's not the
purpopse of multicast client wich should only send packet to server at
the beginning for estimating parameters, and the only listening...
anyone has idea?




More information about the questions mailing list