ntp broadcast not working with IPv6

[rakesh v]

Hi,
Iam facing issues with ntp broadcast <ip address> in case of IPv6.
Iam using the latest ntp 4.26p3 package.
Can I have a use case scenario for ntp broadcast in IPv6?
As I see in the documentation, we can have only multicast addresses in IPv6.

Here are my configurations:
Client side:

*# Created by IMI. /etc/ntp.conf*
*authenticate yes*
*
*
*# Broadcastclient mode. *
*disable auth *
*#broadcastclient*
*
*
*multicastclient ff02::101*
*
*
*# Drift file*
*driftfile /etc/ntp/drift*
*
*
*# Keys file. *
*keys /etc/ntp/keys*
*#trustedkey 100*


Server Side:

*# Created by IMI. /etc/ntp.conf*
*server 127.127.1.0 #Local clock*
*fudge 127.127.1.0 stratum 2 #Not disciplined*
*
*
*broadcast ff02::101 iburst*
*#authenticate yes*
*
*
*# Drift file*
*driftfile /etc/ntp/drift*
*
*
*# Keys file. *
*keys /etc/ntp/keys*
*#trustedkey 100*

Iam able to see the broadcast packets being received in the client but time
synchronization does not happen in the client.
I have even enabled the authentication on both the sides also. But no use.
Can somebody help me out from this?


--
Thanks & Regs,
Rakesh V

[Danny Mayer]

On 11/30/2011 3:50 AM, rakesh v wrote:
> Hi,
> Iam facing issues with ntp broadcast <ip address> in case of IPv6.
> Iam using the latest ntp 4.26p3 package.
> Can I have a use case scenario for ntp broadcast in IPv6?
> As I see in the documentation, we can have only multicast addresses in IPv6.

Where did you see that? It's not true, multicast also works with IPv4.

>
> Here are my configurations:
> Client side:
>
> *# Created by IMI. /etc/ntp.conf*
> *authenticate yes*
> *

What is this? I don't recall such an option.

> *
> *# Broadcastclient mode. *
> *disable auth *
> *#broadcastclient*
> *
> *
> *multicastclient ff02::101*
> *
> *
> *# Drift file*
> *driftfile /etc/ntp/drift*
> *
> *
> *# Keys file. *
> *keys /etc/ntp/keys*
> *#trustedkey 100*
>
>
> Server Side:
>
> *# Created by IMI. /etc/ntp.conf*
> *server 127.127.1.0 #Local clock*
> *fudge 127.127.1.0 stratum 2 #Not disciplined*
> *
> *
> *broadcast ff02::101 iburst*

iburst is invalid.

> *#authenticate yes*
> *
> *
> *# Drift file*
> *driftfile /etc/ntp/drift*
> *
> *
> *# Keys file. *
> *keys /etc/ntp/keys*
> *#trustedkey 100*
>
> Iam able to see the broadcast packets being received in the client but time
> synchronization does not happen in the client.
> I have even enabled the authentication on both the sides also. But no use.
> Can somebody help me out from this?

run ntpd -D2 and see what the output looks like.

Danny

[rakesh v]

Hi Danny,
Thanks for your valuable reply. Please see my comments/observations inlined

On Wed, Dec 7, 2011 at 8:54 AM, Danny Mayer <ma...@ntp.org> wrote:

> On 11/30/2011 3:50 AM, rakesh v wrote:
> > Hi,
> > Iam facing issues with ntp broadcast <ip address> in case of IPv6.
> > Iam using the latest ntp 4.26p3 package.
> > Can I have a use case scenario for ntp broadcast in IPv6?
> > As I see in the documentation, we can have only multicast addresses in
> IPv6.
>
> Where did you see that? It's not true, multicast also works with IPv4.
>

*RV: Iam not saying multicast does not work with IPv4. I was saying for
IPv6, we can give only multicast addresses as part of broadcast command. *

> >
> > Here are my configurations:
> > Client side:
> >
> > *# Created by IMI. /etc/ntp.conf*
> > *authenticate yes*
> > *
>
> What is this? I don't recall such an option.
>

*RV: This is to enable authentication.* *However in my case, I was trying
without authentication. *

>
> > *
> > *# Broadcastclient mode. *
> > *disable auth *
> > *#broadcastclient*
> > *
> > *
> > *multicastclient ff02::101*
> > *
> > *
> > *# Drift file*
> > *driftfile /etc/ntp/drift*
> > *
> > *
> > *# Keys file. *
> > *keys /etc/ntp/keys*
> > *#trustedkey 100*
> >
> >
> > Server Side:
> >
> > *# Created by IMI. /etc/ntp.conf*
> > *server 127.127.1.0 #Local clock*
> > *fudge 127.127.1.0 stratum 2 #Not disciplined*
> > *
> > *
> > *broadcast ff02::101 iburst*
>
> iburst is invalid.
>

*RV: Yes, It is invalid, because it doesn't send burst of packets in case
of broadcast. It was a misconfiguration.*

>
> > *#authenticate yes*
> > *
> > *
> > *# Drift file*
> > *driftfile /etc/ntp/drift*
> > *
> > *
> > *# Keys file. *
> > *keys /etc/ntp/keys*
> > *#trustedkey 100*
> >
> > Iam able to see the broadcast packets being received in the client but
> time
> > synchronization does not happen in the client.
> > I have even enabled the authentication on both the sides also. But no
> use.
> > Can somebody help me out from this?
>
> run ntpd -D2 and see what the output looks like.
>

*RV: I couldn't run the ntpd with -D2 option as it is not available.*
*These are the options available for ntpd (alphabetically)*

*-b no bcastsync Allow us to sync to broadcast servers*
*-c Str configfile configuration file name*
*-f Str driftfile frequency drift file name*

*Are you mentioning about -b option here? How to give that option?*


> Danny
> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>



--
Regs,
Rakesh Vanam
+91 9900 024 002

[David Woolley]

rakesh v wrote:

> *RV: I couldn't run the ntpd with -D2 option as it is not available.*
> *These are the options available for ntpd (alphabetically)*
>
> *-b no bcastsync Allow us to sync to broadcast servers*
> *-c Str configfile configuration file name*
> *-f Str driftfile frequency drift file name*

From a fairly old man page:

SYNOPSIS
ntpd [ -46aAbdDgLnNqx ] [ -c conffile ] [ -f driftfile ] [ -i
jaildir ]
[ -k keyfile ] [ -l logfile ] [ -p pidfile ] [ -P priority ]
[ -r
broadcastdelay ] [ -s statsdir ] [ -t key ] [ -u user[:group]
] [ -v
variable ] [ -V variable ]


Are you possibly using openntp? There is very little knowledge of that
here and, at least at one time, this was actually an SNTP
implementation, not a full NTP one.

[rakesh v]

Hi David,
Iam using the ntp package that is available for Debian 64.
http://packages.debian.org/stable/ntp
http://packages.debian.org/squeeze/amd64/ntp/download

Not sure whether this is Openntp?
One query though it is not intended to discuss here:
So, if the option(-D2) is not present can't we run ntp multicast client in
Openntp/SNTP? Is there any alternative?

> ______________________________**_________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/**questions<http://lists.ntp.org/listinfo/questions>
>



--
Regs,
Rakesh

[rakesh v]

Hi Danny,
Actually I ran the ntpd with Debug option before with a downloaded source
code (ntp-4.26p4).


These are the logs Iam seeing on the client side...

*6 Dec 06:11:52 ntpd[2884]: set_process_priority: Leave priority alone:
priority_done is <2>*
* 6 Dec 06:11:52 ntpd[2884]: proto: precision = 0.208 usec*
* 6 Dec 06:11:52 ntpd[2884]: ntp_io: estimated max descriptors: 1024,
initial socket boundary: 16*
* 6 Dec 06:11:52 ntpd[2884]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
*
* 6 Dec 06:11:52 ntpd[2884]: Listen and drop on 1 v6wildcard :: UDP 123*
* 6 Dec 06:11:52 ntpd[2884]: Listen normally on 2 lo 127.0.0.1 UDP 123*
* 6 Dec 06:11:52 ntpd[2884]: Listen normally on 3 eth1 10.16.34.6 UDP 123*
* 6 Dec 06:11:52 ntpd[2884]: Listen normally on 4 lo ::1 UDP 123*
* 6 Dec 06:11:52 ntpd[2884]: Listen normally on 5 eth2 2000::2 UDP 123*
* 6 Dec 06:11:52 ntpd[2884]: Listen normally on 6 eth1
fe80::a00:27ff:fe68:7b4c UDP 123*
* 6 Dec 06:11:52 ntpd[2884]: Listen normally on 7 eth2
fe80::a00:27ff:fe38:605 UDP 123*
* 6 Dec 06:11:52 ntpd[2884]: peers refreshed*
* 6 Dec 06:11:52 ntpd[2884]: Listening on routing socket on fd #24 for
interface updates*
* 6 Dec 06:11:52 ntpd[2884]: bind(25) AF_INET6 ff02::101#123 (multicast)
flags 0x0 failed: Invalid argument*
* 6 Dec 06:11:52 ntpd[2884]: multicast address ff02::101 using wildcard
interface #1 v6wildcard*
* 6 Dec 06:11:52 ntpd[2884]: Joined :: socket to multicast group ff02::101*
*
*
Actually Iam able to see only one Broadcast packet being received on client
side in wireshark. Packets are not received.
Here Iam not sure why the socket bind is failing for ntpd? Any inputs on
this?


Regs,
RV.

On Wed, Dec 7, 2011 at 8:54 AM, Danny Mayer <ma...@ntp.org> wrote:

> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>



--

[Danny Mayer]

On 12/7/2011 4:53 AM, rakesh v wrote:
> Hi Danny,
> Actually I ran the ntpd with Debug option before with a downloaded
> source code (ntp-4.26p4).
>
>
> These are the logs Iam seeing on the client side...
>

> /6 Dec 06:11:52 ntpd[2884]: set_process_priority: Leave priority alone:
> priority_done is <2>/
> / 6 Dec 06:11:52 ntpd[2884]: proto: precision = 0.208 usec/
> / 6 Dec 06:11:52 ntpd[2884]: ntp_io: estimated max descriptors: 1024,
> initial socket boundary: 16/
> / 6 Dec 06:11:52 ntpd[2884]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP
> 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen and drop on 1 v6wildcard :: UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 2 lo 127.0.0.1 UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 3 eth1 10.16.34.6 UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 4 lo ::1 UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 5 eth2 2000::2 UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 6 eth1
> fe80::a00:27ff:fe68:7b4c UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 7 eth2
> fe80::a00:27ff:fe38:605 UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: peers refreshed/
> / 6 Dec 06:11:52 ntpd[2884]: Listening on routing socket on fd #24 for
> interface updates/
> / *6 Dec 06:11:52 ntpd[2884]: bind(25) AF_INET6 ff02::101#123
> (multicast) flags 0x0 failed: Invalid argument*/
> / 6 Dec 06:11:52 ntpd[2884]: multicast address ff02::101 using wildcard
> interface #1 v6wildcard/
> / 6 Dec 06:11:52 ntpd[2884]: Joined :: socket to multicast group ff02::101/
> /
> /

> Actually Iam able to see only one Broadcast packet being received on
> client side in wireshark. Packets are not received.
> Here Iam not sure why the socket bind is failing for ntpd? Any inputs on
> this?

That sounds like a bug. I haven't looked at that area of the code
recently but being unable to bind to the socket would prevent it
receiving packets. Dave Hart has touched this area recently may will
likely know more. I do remember some issues with multicast but I don't
remember this one.

Danny

[Steve Kostecke]

On 2011-12-07, rakesh v <rakes...@gmail.com> wrote:

> Iam using the ntp package that is available for Debian 64.
> http://packages.debian.org/stable/ntp
> http://packages.debian.org/squeeze/amd64/ntp/download

The Debian NTP packages are built without debugging.

Rebuilding the package with debugging enabled is not too
difficult. A rough overview of the process is described at
http://www.debian-administration.org/articles/20. Once you perform
the set-up steps and have the source unpacked you will need to edit
./debian/rules in the source tree and change --disable-debugging to
--enable-debugging. Please contact me off-list it you need help.

> Not sure whether this is Openntp?

It's the NTP Reference Implementation from www.ntp.org

--
Steve Kostecke <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/

[rakesh v]

Thanks for your inputs Danny.

Hi Dave,
Can you give your inputs on this below issue?
Is the socket bind failing due to the reuse of the udp port 123. But I
assume for ntp multicast client also we use the same port for listening. Or
Is it due to some other issue?

[Danny Mayer]

On 12/7/2011 11:15 PM, rakesh v wrote:
> Thanks for your inputs Danny.
>
> Hi Dave,
> Can you give your inputs on this below issue?
> Is the socket bind failing due to the reuse of the udp port 123. But I
> assume for ntp multicast client also we use the same port for listening.
> Or Is it due to some other issue?
>

I think it is trying to bind to the incorrect address but I'd have to
look carefully at the code to figure out exactly what is going on.

Danny

[rakesh v]

Hi Danny,
Have you got a chance to go through the code for this?
Here though the socket bind is failing the multicast registration is
happening successfully (which are shown by the debug traces here.)
Does that have anything to infer here?

> --

>
>
>
>
> --
> Regs,
> Rakesh Vanam
> +91 9900 024 002
>
>
>
>

> --
>



--
Regs,
Rakesh V

[Danny Mayer]

On 12/8/2011 11:18 PM, rakesh v wrote:
> Hi Danny,

> Have you got a chance to go through the code for this?
> Here though the socket bind is failing the multicast registration is
> happening successfully (which are shown by the debug traces here.)
> Does that have anything to infer here?
>

Sorry, no. I've been at a conference almost all week and I've only been
dealing with work related issues outside of the conference.

Danny

[Dave Hart]

On Wed, Dec 7, 2011 at 09:53, rakesh v <rakes...@gmail.com> wrote:
> Hi Danny,
> Actually I ran the ntpd with Debug option before with a downloaded source
> code (ntp-4.26p4).
>
> These are the logs Iam seeing on the client side...
>

> * 6 Dec 06:11:52 ntpd[2884]: bind(25) AF_INET6 ff02::101#123 (multicast)
> flags 0x0 failed: Invalid argument*

This is unexpected. ntpd expects non-Windows systems to listen for
multicast by binding a socket to each multicast group address.

> * 6 Dec 06:11:52 ntpd[2884]: multicast address ff02::101 using wildcard
> interface #1 v6wildcard*
> * 6 Dec 06:11:52 ntpd[2884]: Joined :: socket to multicast group ff02::101*

As you can see, there's fallback code to attempt to use the wildcard
interface, but I doubt that will work out for you, even if you add
"interface listen ::" to override the default behavior of dropping all
traffic received via the wildcard interface. This is because ntpd
typically depends on determining the destination address based on the
socket on which the packet was received.

I note the following paragraph in "man ipv6" on a Debian stable system:

Linux 2.4 will break binary compatibility for the sockaddr_in6 for
64-bit hosts by changing the alignment of in6_addr and adding an addi-
tional sin6_scope_id field. The kernel interfaces stay compatible, but
a program including sockaddr_in6 or in6_addr into other structures may
not be. This is not a problem for 32-bit hosts like i386.

Since you saw the problem even when building ntpd from source, this
seems unlikely to be the cause of your problem, but it seemed worth
mentioning. I'd suggest trying to determine what is causing the
bind() to ff02::101 to fail on your system.

Cheers,
Dave Hart

[Danny Mayer]

On 12/6/2011 11:58 PM, rakesh v wrote:
> Hi Danny,
> Thanks for your valuable reply. Please see my comments/observations inlined
>
>
> On Wed, Dec 7, 2011 at 8:54 AM, Danny Mayer <ma...@ntp.org
> <mailto:ma...@ntp.org>> wrote:
>
> On 11/30/2011 3:50 AM, rakesh v wrote:
> > Hi,
> > Iam facing issues with ntp broadcast <ip address> in case of IPv6.
> > Iam using the latest ntp 4.26p3 package.
> > Can I have a use case scenario for ntp broadcast in IPv6?
> > As I see in the documentation, we can have only multicast
> addresses in IPv6.
>
> Where did you see that? It's not true, multicast also works with IPv4.
>
>

> */RV: Iam not saying multicast does not work with IPv4. I was saying for
> IPv6, we can give only multicast addresses as part of broadcast command. /*

That is correct. There is no such thing as broadcast in IPv6.

>
> >
> > Here are my configurations:
> > Client side:
> >
> > *# Created by IMI. /etc/ntp.conf*
> > *authenticate yes*
> > *
>
> What is this? I don't recall such an option.
>

> */RV: This is to enable authentication./* */However in my case, I was
> trying without authentication. /*
>

You don't enable or disable authentication with such an option as it
doesn't exist. The corect option is "enable/disable auth"

>
> > *
> > *# Broadcastclient mode. *
> > *disable auth *
> > *#broadcastclient*
> > *
> > *
> > *multicastclient ff02::101*
> > *
> > *
> > *# Drift file*
> > *driftfile /etc/ntp/drift*
> > *
> > *
> > *# Keys file. *
> > *keys /etc/ntp/keys*
> > *#trustedkey 100*
> >
> >
> > Server Side:
> >
> > *# Created by IMI. /etc/ntp.conf*
> > *server 127.127.1.0 #Local clock*
> > *fudge 127.127.1.0 stratum 2 #Not disciplined*
> > *
> > *
> > *broadcast ff02::101 iburst*
>
> iburst is invalid.
>

> */RV: Yes, It is invalid, because it doesn't send burst of packets in
> case of broadcast. It was a misconfiguration./*

>
>
> > *#authenticate yes*
> > *
> > *
> > *# Drift file*
> > *driftfile /etc/ntp/drift*
> > *
> > *
> > *# Keys file. *
> > *keys /etc/ntp/keys*
> > *#trustedkey 100*
> >
> > Iam able to see the broadcast packets being received in the client
> but time
> > synchronization does not happen in the client.
> > I have even enabled the authentication on both the sides also. But
> no use.
> > Can somebody help me out from this?
>
> run ntpd -D2 and see what the output looks like.
>
>

> */RV: I couldn't run the ntpd with -D2 option as it is not available./*
> */These are the options available for ntpd (alphabetically)/*
>
> /-b no bcastsync Allow us to sync to broadcast servers/
> /-c Str configfile configuration file name/
> /-f Str driftfile frequency drift file name/
>

I don't know where you are getting these options. That's a very small
subset of the options. If you do not have debug enabled when compiling
you won't get the -D or -d options.

Danny

Danny
> */Are you mentioning about -b option here? How to give that option?/*

>
>
> Danny
> _______________________________________________
> questions mailing list

> ques...@lists.ntp.org <mailto:ques...@lists.ntp.org>

[E-Mail Sent to this address will be added to the BlackLists]

Danny Mayer wrote:

> rakesh v wrote:
>> */RV: Iam not saying multicast does not work with IPv4.
>> I was saying for IPv6, we can give only multicast
>> addresses as part of broadcast command. /*
>
> That is correct. There is no such thing as broadcast in IPv6.

Can it use the all hosts on local links multicast address ff02::1 ?
{I haven't looked at the docs for this at all (yet).}

--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.

[Danny Mayer]

On 12/19/2011 1:37 PM, E-Mail Sent to this address will be added to the

BlackLists wrote:
> Danny Mayer wrote:
>> rakesh v wrote:
>>> */RV: Iam not saying multicast does not work with IPv4.
>>> I was saying for IPv6, we can give only multicast
>>> addresses as part of broadcast command. /*
>>
>> That is correct. There is no such thing as broadcast in IPv6.
>
> Can it use the all hosts on local links multicast address ff02::1 ?
> {I haven't looked at the docs for this at all (yet).}

Any multicast address is valid for NTP usage but whether or not it
should be used is a separate question.

Danny

[ngr...@gmail.com]

On Thursday, December 8, 2011 at 1:28:23 AM UTC-3, Danny Mayer wrote:
>
> I think it is trying to bind to the incorrect address but I'd have to
> look carefully at the code to figure out exactly what is going on.
>

Sorry to refloat this old thread, but this bug is still present on 4.2.6p5 and I think I discovered the cause:

Ntpd is trying to bind() to the link-local multicast address ff02::101 *WITHOUT* specifying the scope id of the link local interface. The bind() strace is:

bind(24, {sa_family=AF_INET6, sin6_port=htons(123), inet_pton(AF_INET6, "ff02::101", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)

Note sin6_scope_id=0.

Defining "multicastclient [ff02::101]%2" or "multicastclient [ff02::101]%eth0" or "multicastclient ff02::101" in ntp.conf also results in sin6_scope_id=0 and the same error.

If you call bind() specifying sin6_scope_id=2 (the scope id of my link-local interface), the bind() call works. (I'm trying this on Ubuntu 16.10).

[יובל פלד‎]

ב-יום חמישי, 9 בפברואר 2017 בשעה 00:16:32 UTC+2, ngr...@gmail.com כתב/ה:

hi,

on the new ntpd, there is option to configure sin6_scope_id=2 from the ntp.conf file?
can we also configure one of mreq6.ipv6mr_interface or iface->ifindex on the ntp.conf?

thanks ,
Yuval Peled