Hi,

what i have to do to configure an ntpd als multicast server and
another als client?

1. is there realy an option "multicastserver" for the daemon?

2. When i try to configure an Server with "broadcast" to an
multicast address, -- what i have to do on the client side?
When i put an multicastclient $address i see that ntpd -d
is getting packets. "received" - but i cant see it with
ntpq -p, i think i should, or?? i too saw that the multicast
group was entered and so on, it should work but with what
options i can test it?

3. Or are there any spezial config things i dont know,
can anyone pls post an typical mcast client setup?


Versions on the server are 4.1 and client 4.2.

mfg Wilhelm

I see that the multicast client and server configuration information
at https://ntp.isc.org/bin/view/Support/ConfiguringNTP needs more content...

H

Hi,
* Harlan Stenn <stenn@ntp.isc.org> schrieb:
>  I see that the multicast client and server configuration information
>  at https://ntp.isc.org/bin/view/Support/ConfiguringNTP needs more content...

;)

But can anyone help please to find out what the Problem is?

Here i have some debugging output from ntpd:

receive: at 388 224.2.2.1<-10.1.1.1 mode 5 code 5
receive: at 388 0.0.0.0<-10.112.223.116 mode 5 code 5
auth_agekeys: at 420 keys 1 expired 0

Netstat -g and tcpdump also say that ntpd is joined
the multicast group, but i dont see any clock with
ntpq -p.

mfg Wilhelm

Wilhelm Greiner wrote:
> Hi,
> 
> what i have to do to configure an ntpd als multicast server and
> another als client?
> 
> 1. is there realy an option "multicastserver" for the daemon?
> 

The multicast server is set up by using the "broadcast" line with a
multicast address like this:

broadcast FF05::101 autokey ttl 2
broadcast 224.0.1.1 autokey ttl 2

for IPv6 and IPv4 respectively. Autokey is used to allow clients to
authenticate the multicast server. If this is for a local lan and you
don't think that it's necessary to authenticate then you can ignore it.
However clients then have to disable authentication on their side. It's
on by default. ttl 2 indicates the number of hops to propogate the
multicast packets through. I believe the default for that is 1.
If you are going to use autokey you should generate the keys on the
server and follow the instructions on where to put them and how to
distribute them to the clients that need them.

On the client side you need to add the following lines with the
multicast IP address matching the server like this:

multicastclient FF05::101
multicastclient 224.0.1.1

again using the same addresses. If you don't want authentication of the
multicast packets you should add the line
disable auth
to the client's configuration file.

Note that you can have more than one multicast server running and the
clients will see these as independent providers of NTP packets and
utilize them in the same kind of way as if you had specified more than
one server.


> 2. When i try to configure an Server with "broadcast" to an
> multicast address, -- what i have to do on the client side?
> When i put an multicastclient $address i see that ntpd -d
> is getting packets. "received" - but i cant see it with
> ntpq -p, i think i should, or?? i too saw that the multicast
> group was entered and so on, it should work but with what
> options i can test it?
> 
You must authenticate the multicast server first before the client
accepts the packet. Authentication is on by default for multicast and
broadcast.

> 3. Or are there any spezial config things i dont know,
> can anyone pls post an typical mcast client setup?
> 

See above.
> 
> Versions on the server are 4.1 and client 4.2.
> 

Get the latest version of the ntp-dev tarball and build that. I've fixed
a great number of problems with multicasting over the past year and it
should be functioning for almost all platforms.

Danny

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Hi,
* Danny Mayer <mayer@ntp.isc.org> schrieb:

>  again using the same addresses. If you don't want authentication of the
>  multicast packets you should add the line
>  disable auth
>  to the client's configuration file.
 
That was the Problem, thank you realy for your help.

> > Versions on the server are 4.1 and client 4.2.
>  Get the latest version of the ntp-dev tarball and build that. I've fixed
>  a great number of problems with multicasting over the past year and it
>  should be functioning for almost all platforms.
 
OK, thanks for your hint.

mfg Wilhelm

Hi,
* Danny Mayer <mayer@ntp.isc.org> schrieb:
> > what i have to do to configure an ntpd als multicast server and
> > another als client?
>  The multicast server is set up by using the "broadcast" line with a
>  multicastclient 224.0.1.1

It is working now, but with stability problems.

Since the time source is an internet ntp host, the service is working only
sometimes. On the client side i always see the Multicast NTP Server,
also the reach goes up to 377.

But when i type "ntpq -p" is only sometimes see the "*" before the servers
IP.

Also it also doesnt work if the multicast Server has an "Local" (Local(0))
Entry.

It is an low latency link, ping are round about 800 - 1000 ms.

Can this delay be the problem?

mfg Wilhelm

* Wilhelm Greiner <wilhelm.greiner@web.de> schrieb:

forgot to say:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.1.1 192.168.1.2   2 -    6   16  377    0.000    0.000 4000.00

This ntpq -p output looks strange, not? the delay and offset are 0 and
the jitter 4000, can this be an hint to find out the Problem?

mfg Wilhelm

also, the problem only exists if both ntpd (server and client) would not
startet at the same time.

If i start the ntpd client and server new around at the same time, it works
without any problems. Then i have my "*" :>

What can that be?

mfg Wilhelm

Wilhelm Greiner wrote:
> Hi,
> * Danny Mayer <mayer@ntp.isc.org> schrieb:
> 
>>>what i have to do to configure an ntpd als multicast server and
>>>another als client?
>>
>> The multicast server is set up by using the "broadcast" line with a
>> multicastclient 224.0.1.1
> 
> 
> It is working now, but with stability problems.
> 
> Since the time source is an internet ntp host, the service is working only
> sometimes. On the client side i always see the Multicast NTP Server,
> also the reach goes up to 377.
> 
> But when i type "ntpq -p" is only sometimes see the "*" before the servers
> IP.
> 
> Also it also doesnt work if the multicast Server has an "Local" (Local(0))
> Entry.
> 
> It is an low latency link, ping are round about 800 - 1000 ms.
> 
> Can this delay be the problem?
> 

What version of ntp are you using. There have been many bug fixes in the
area of multicasting. I can't see how Local would have anything to do
with it since it should always receive the multicast packets no matter
what is configured.

Danny

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Wilhelm Greiner wrote:
> * Wilhelm Greiner <wilhelm.greiner@web.de> schrieb:
> 
> forgot to say:
> 
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  192.168.1.1 192.168.1.2   2 -    6   16  377    0.000    0.000 4000.00
> 
> This ntpq -p output looks strange, not? the delay and offset are 0 and
> the jitter 4000, can this be an hint to find out the Problem?
> 

I've seen this kind of thing immediately after the system gets 
synchronized, but then you start to see it look normal again. Does it 
change or is it stuck in this state?

Danny

> mfg Wilhelm
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Hi,
* Danny Mayer <mayer@ntp.isc.org> schrieb:
>  Wilhelm Greiner wrote:
> >      remote           refid      st t when poll reach   delay   offset  jitter
> > ==============================================================================
> >  192.168.1.1 192.168.1.2   2 -    6   16  377    0.000    0.000 4000.00
> > 
> > This ntpq -p output looks strange, not? the delay and offset are 0 and
> > the jitter 4000, can this be an hint to find out the Problem?

>  I've seen this kind of thing immediately after the system gets 
>  synchronized, but then you start to see it look normal again. Does it 
>  change or is it stuck in this state?
 
It stuck in this state, if i plug out the cable reach goes down and up after
pluggin in.

mfg Wilhelm

Wilhelm Greiner <wilhelm.greiner@web.de> wrote:

>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  192.168.1.1 192.168.1.2   2 -    6   16  377    0.000    0.000 4000.00
> 
> This ntpq -p output looks strange, not? the delay and offset are 0 and
> the jitter 4000, can this be an hint to find out the Problem?

You need more detailed info -- try, um, ntpq -p -c "rv &1"

-- 
                      Ronan Flood <R.Flood@noc.ulcc.ac.uk>
                        working for but not speaking for
             Network Services, University of London Computer Centre
     (which means: don't bother ULCC if I've said something you don't like)

Hi,
* Danny Mayer <mayer@gis.net> schrieb:
> > * Danny Mayer <mayer@ntp.isc.org> schrieb:
> >> The multicast server is set up by using the "broadcast" line with a
> >> multicastclient 224.0.1.1

>  What version of ntp are you using. There have been many bug fixes in the
>  area of multicasting. I can't see how Local would have anything to do
>  with it since it should always receive the multicast packets no matter
>  what is configured.
 
If the local statement is in the config, it doesnt send multicast packets.
Since i found that i dont use it anymore now.

The configs are trivial configs.

Server side is only
server ntphost
broadcast address key 1 ttl 1 iburst minpoll 4
keys keyfile

Client side
multicastclient address
broadcastdelay delay
trustedkey 1

But i now tried different versions and now i see new things.

Server Version is 4.1.1
Client Version 4.2

That does not working, but i compiled in an temp directory the version
4.1.2 for the client and it does working now.

It will not be easy to change the Version on client side, so i tried to use
4.2 as server version this also does not work.

On client side also ntp-dev-4.2.0b-20050926 and 4.2 stable doesnt work.

I dont see on the affected Versions in the -d (Debug Output) the string/
message "clock_filter".

For example:
---
clock_filter: n 1 off 0.000000 del 0.000015 dsp 7.937624 jit 0.000015, age 0
---

Thats the only thing i see what differs.

All these is on Fedora Core 3.

I will try to test any versions (and other OS too) <-> and post working
combinations.

Also i see when ntpd with debugging runs that it transmits any packets
to find out is the way back reachable.

Can i turn off this initial trials??

>  Danny

mfg Wilhelm

Wilhelm Greiner wrote:
> also, the problem only exists if both ntpd (server and client) would not
> startet at the same time.
> 

What exactly do you mean by "the same time"?

Danny
> If i start the ntpd client and server new around at the same time, it works
> without any problems. Then i have my "*" :>
> 
> What can that be?
> 
> mfg Wilhelm
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Wilhelm Greiner wrote:
>  
> If the local statement is in the config, it doesnt send multicast packets.
> Since i found that i dont use it anymore now.
> 
Please file a bug report on this. I don't understand why this would be a 
  problem but someone should look at it.

> The configs are trivial configs.
> 
> Server side is only
> server ntphost
> broadcast address key 1 ttl 1 iburst minpoll 4
> keys keyfile
> 
Remove iburst and minpoll from broadcast. It makes no sense on a 
broadcast server. Also what is the IP address being used by the 
broadcast line? Please don't munge addresses, it doesn't help and 
doesn't protect you.

> Client side
> multicastclient address
> broadcastdelay delay
> trustedkey 1
> 
> But i now tried different versions and now i see new things.
> 
> Server Version is 4.1.1
> Client Version 4.2
> 
> That does not working, but i compiled in an temp directory the version
> 4.1.2 for the client and it does working now.
> 
> It will not be easy to change the Version on client side, so i tried to use
> 4.2 as server version this also does not work.
> 
> On client side also ntp-dev-4.2.0b-20050926 and 4.2 stable doesnt work.
> 

There is some sort of problem still with multicast on Linux that I have 
still not tracked down, though there is a hint of a solution in a recent 
bug report.

> I dont see on the affected Versions in the -d (Debug Output) the string/
> message "clock_filter".
> 
> For example:
> ---
> clock_filter: n 1 off 0.000000 del 0.000015 dsp 7.937624 jit 0.000015, age 0
> ---
> 
That has nothing to do with multicasting. The multicasting information 
is in the send and receive debug lines.

> Thats the only thing i see what differs.
> 
> All these is on Fedora Core 3.
> 
> I will try to test any versions (and other OS too) <-> and post working
> combinations.
> 
> Also i see when ntpd with debugging runs that it transmits any packets
> to find out is the way back reachable.
> 

I don't understand what you mean here. Can you explain?

> Can i turn off this initial trials??
> 
I also don't understand this question.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

In article <433E0D98.6070004@gis.net>, mayer@gis.net (Danny Mayer) wrote:

> Wilhelm Greiner wrote:
> > 
> > Also i see when ntpd with debugging runs that it transmits any packets
> > to find out is the way back reachable.
> > 
> 
> I don't understand what you mean here. Can you explain?
> 
> > Can i turn off this initial trials??
> > 
> I also don't understand this question.

When a broadcast client is starting it makes a normal access to the
server to calibrate the round trip delay and therefore estimate the
downstream delay.  It will fall back to the configured delay if this
fails.

Also, I believe that if you enable authentication, and that is strongly
encouraged for broadcast, this exchange is mandatory to negotiate keys.
(I vaguely remember that authentication is defaulted on for broadcast.)

I believe this is what the person wants disables, although he hasn't 
explained why.

David Woolley wrote:
> In article <433E0D98.6070004@gis.net>, mayer@gis.net (Danny Mayer) wrote:
> 
> 
>>Wilhelm Greiner wrote:
>>
>>>Also i see when ntpd with debugging runs that it transmits any packets
>>>to find out is the way back reachable.
>>>
>>
>>I don't understand what you mean here. Can you explain?
>>
>>
>>>Can i turn off this initial trials??
>>>
>>
>>I also don't understand this question.
> 
> 
> When a broadcast client is starting it makes a normal access to the
> server to calibrate the round trip delay and therefore estimate the
> downstream delay.  It will fall back to the configured delay if this
> fails.
> 

I'm not sure that it does send a packet if authentication is not 
enabled, but I'd have to check.

> Also, I believe that if you enable authentication, and that is strongly
> encouraged for broadcast, this exchange is mandatory to negotiate keys.
> (I vaguely remember that authentication is defaulted on for broadcast.)
> 

Authentication is enabled by default for both broadcast and multicast. 
Turning it off means that you have accepted the risks of doing so.

When you authenticate that means that you are exchanging a bunch of NTP 
packets between broadcast/multicast client and server. It's described as 
the "key dance" in the documentation. I don't remember how many packets 
are exchanged, but it's more than two.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny,

I really like it when folks send in plain, unformatted ASCII. It's much 
easier to read and better resists spam filtering.

By default, to mobilize a broadcast client requires authentication using 
either symmetric or public key cryptography. Ordinarily, eight packets 
are exchanged with the server at two-second intervals. This is 
sufficient to both accurately calibrate the propagation delay and run 
the authentication protocol. This can be disabled with the novolley 
option in the broadcastclient command. If so or if the server does not 
respond, a default delay is assumed and life goes on.

Dave

Dave

Danny Mayer wrote:

> David Woolley wrote:
> 
>> In article <433E0D98.6070004@gis.net>, mayer@gis.net (Danny Mayer) wrote:
>>
>>
>>> Wilhelm Greiner wrote:
>>>
>>>> Also i see when ntpd with debugging runs that it transmits any packets
>>>> to find out is the way back reachable.
>>>>
>>>
>>> I don't understand what you mean here. Can you explain?
>>>
>>>
>>>> Can i turn off this initial trials??
>>>>
>>>
>>> I also don't understand this question.
>>
>>
>>
>> When a broadcast client is starting it makes a normal access to the
>> server to calibrate the round trip delay and therefore estimate the
>> downstream delay.  It will fall back to the configured delay if this
>> fails.
>>
> 
> I'm not sure that it does send a packet if authentication is not 
> enabled, but I'd have to check.
> 
>> Also, I believe that if you enable authentication, and that is strongly
>> encouraged for broadcast, this exchange is mandatory to negotiate keys.
>> (I vaguely remember that authentication is defaulted on for broadcast.)
>>
> 
> Authentication is enabled by default for both broadcast and multicast. 
> Turning it off means that you have accepted the risks of doing so.
> 
> When you authenticate that means that you are exchanging a bunch of NTP 
> packets between broadcast/multicast client and server. It's described as 
> the "key dance" in the documentation. I don't remember how many packets 
> are exchanged, but it's more than two.
> 
> Danny
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 

Hi,
* Danny Mayer <mayer@gis.net> schrieb:
> > also, the problem only exists if both ntpd (server and client) would not
> > startet at the same time.
 
>  What exactly do you mean by "the same time"?

Should mean, if the server and the client is started in a
10 second window frame or so, it works.

Otherwise it does not work.

Also it does not work if the client is restarted.
In the time up to the restart the client works without any
problems.

That occoured with ntpd client 4.2.x.


mfg Wilhelm

Hi
* David L. Mills <mills@udel.edu> schrieb:
>  Danny Mayer wrote:
> > David Woolley wrote:
> >>>> Also i see when ntpd with debugging runs that it transmits any packets
> >>>> to find out is the way back reachable.
> >>> I don't understand what you mean here. Can you explain?

> >> When a broadcast client is starting it makes a normal access to the
> >> server to calibrate the round trip delay and therefore estimate the
> >> downstream delay.  It will fall back to the configured delay if this
> >> fails.

> > I'm not sure that it does send a packet if authentication is not 
> > enabled, but I'd have to check.

> >> Also, I believe that if you enable authentication, and that is strongly
> >> encouraged for broadcast, this exchange is mandatory to negotiate keys.
> >> (I vaguely remember that authentication is defaulted on for broadcast.)

> > When you authenticate that means that you are exchanging a bunch of NTP 
> > packets between broadcast/multicast client and server. It's described as 
> > the "key dance" in the documentation. I don't remember how many packets 
> > are exchanged, but it's more than two.

>  By default, to mobilize a broadcast client requires authentication using 
>  either symmetric or public key cryptography. Ordinarily, eight packets 
>  are exchanged with the server at two-second intervals. This is 
>  sufficient to both accurately calibrate the propagation delay and run 
>  the authentication protocol. This can be disabled with the novolley 
>  option in the broadcastclient command. If so or if the server does not 
>  respond, a default delay is assumed and life goes on.

Could not find this option in the man page.

when i try "multicastclient 224.6.2.1 novolley" or
"multicastclient novolley 224.6.2.1" in the config
it too transmit packets.
See the output.

The reason is that there can be a way back, but with other delay,
that falsified the resulting time.
Also this can trigger an unwanted dial in.

[root@ntpserver ntpd-4.1.2_build_20051004]# ./ntpd -d | grep transmit
transmit: at 10 0.0.0.0->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 25 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 26 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 30 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 34 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 35 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 36 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 37 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 110 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 128 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 130 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 132 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 135 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 139 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 142 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 144 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20


>  Dave

mfg Wilhelm

Hi,
* David Woolley <david@djwhome.demon.co.uk> schrieb:
>  In article <433E0D98.6070004@gis.net>, mayer@gis.net (Danny Mayer) wrote:
> > Wilhelm Greiner wrote:
> > > Also i see when ntpd with debugging runs that it transmits any packets
> > > to find out is the way back reachable.

>  Also, I believe that if you enable authentication, and that is strongly
>  encouraged for broadcast, this exchange is mandatory to negotiate keys.
>  (I vaguely remember that authentication is defaulted on for broadcast.)
 
Yes i have the recommended authentication enabled via trustedkey etc.
(see config example above) - only the minimal standard options are in
use.

"mandatory" seems like it is a "must", but the host is not reachable,
a ntpdate -d multicastserver says "no server suitable for synchronization found"

But it works fine as daemon.

>  I believe this is what the person wants disables, although he hasn't 
>  explained why.

The way back to the multicastserver can have a false delay, that
would falsify the time, also this can trigger an unwanted dial in.

In the most cases the way back is not reachable.

mfg Wilhelm

Wilhelm Greiner wrote:
> Hi
> 
> Could not find this option in the man page.
> 
NTP doesn't ship man pages. Those are created by your O/S vendor.
You need to look in the HTML pages. You can start here:
http://www.eecis.udel.edu/~mills/ntp/html/index.html

> when i try "multicastclient 224.6.2.1 novolley" or
> "multicastclient novolley 224.6.2.1" in the config
> it too transmit packets.
> See the output.
> 
> The reason is that there can be a way back, but with other delay,
> that falsified the resulting time.
> Also this can trigger an unwanted dial in.
> 
> [root@ntpserver ntpd-4.1.2_build_20051004]# ./ntpd -d | grep transmit

Upgrade that version is very old. novolley may have been added in 4.2.0.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny & Co.,

The multicastclient command does not parse the novolley argument, since 
the arguments are group addresses. As we know, the configuration 
function needs to be overhauled.

Dave

Danny Mayer wrote:
> Wilhelm Greiner wrote:
> 
>> Hi
>>
>> Could not find this option in the man page.
>>
> NTP doesn't ship man pages. Those are created by your O/S vendor.
> You need to look in the HTML pages. You can start here:
> http://www.eecis.udel.edu/~mills/ntp/html/index.html
> 
>> when i try "multicastclient 224.6.2.1 novolley" or
>> "multicastclient novolley 224.6.2.1" in the config
>> it too transmit packets.
>> See the output.
>>
>> The reason is that there can be a way back, but with other delay,
>> that falsified the resulting time.
>> Also this can trigger an unwanted dial in.
>>
>> [root@ntpserver ntpd-4.1.2_build_20051004]# ./ntpd -d | grep transmit
> 
> 
> Upgrade that version is very old. novolley may have been added in 4.2.0.
> 
> Danny
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 

Hi,
* Danny Mayer <mayer@ntp.isc.org> schrieb:
> > Could not find this option in the man page.
>  NTP doesn't ship man pages. Those are created by your O/S vendor.
>  You need to look in the HTML pages. You can start here:
>  http://www.eecis.udel.edu/~mills/ntp/html/index.html
> 
> > when i try "multicastclient 224.6.2.1 novolley" or
> > "multicastclient novolley 224.6.2.1" in the config
> > it too transmit packets.
> > See the output.
> > 
> > The reason is that there can be a way back, but with other delay,
> > that falsified the resulting time.
> > Also this can trigger an unwanted dial in.
> > 
> > [root@ntpserver ntpd-4.1.2_build_20051004]# ./ntpd -d | grep transmit
> 
>  Upgrade that version is very old. novolley may have been added in 4.2.0.

I cant run 4.2.x, it doesnt run as multicast client here
see above postings.

mfg Wilhelm

David L. Mills wrote:
> Danny & Co.,
> 
> The multicastclient command does not parse the novolley argument, since 
> the arguments are group addresses. As we know, the configuration 
> function needs to be overhauled.
> 
Yes, I agree. It just checks to see if it has an argument, doesn't check 
what the argument is and set a value to 2 if present. I definitely is 
not the right thing to do.

Danny

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Wilhelm Greiner wrote:
> Hi,
> * Danny Mayer <mayer@ntp.isc.org> schrieb:
> 
>>>Could not find this option in the man page.
>>
>> NTP doesn't ship man pages. Those are created by your O/S vendor.
>> You need to look in the HTML pages. You can start here:
>> http://www.eecis.udel.edu/~mills/ntp/html/index.html
>>
>>
>>>when i try "multicastclient 224.6.2.1 novolley" or
>>>"multicastclient novolley 224.6.2.1" in the config
>>>it too transmit packets.
>>>See the output.
>>>
>>>The reason is that there can be a way back, but with other delay,
>>>that falsified the resulting time.
>>>Also this can trigger an unwanted dial in.
>>>
>>>[root@ntpserver ntpd-4.1.2_build_20051004]# ./ntpd -d | grep transmit
>>
>> Upgrade that version is very old. novolley may have been added in 4.2.0.
> 
> 
> I cant run 4.2.x, it doesnt run as multicast client here
> see above postings.
> 

Ah. I have a fix in process at the moment that should make multicast 
client work on linux. I expect to be able to make it available in the 
next few days.

Danny
Danny
> mfg Wilhelm
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny,

With all due respect, I'm not prepared to "fix" this unless and until a 
serious effort is under way to properly fix the broken configuration 
code. The novolley flag is a bandaid. The syntax is broken.

Dave,

Danny Mayer wrote:

> David L. Mills wrote:
> 
>> Danny & Co.,
>>
>> The multicastclient command does not parse the novolley argument, 
>> since the arguments are group addresses. As we know, the configuration 
>> function needs to be overhauled.
>>
> Yes, I agree. It just checks to see if it has an argument, doesn't check 
> what the argument is and set a value to 2 if present. I definitely is 
> not the right thing to do.
> 
> Danny
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 

David L. Mills wrote:
> Danny,
> 
> With all due respect, I'm not prepared to "fix" this unless and until a 
> serious effort is under way to properly fix the broken configuration 
> code. The novolley flag is a bandaid. The syntax is broken.
> 

Dave,

Harlan has been working on some replacement code.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions