Ray,

>>> In article , "Ray" writes:

Ray> I am running stratum-1 servers with NTP version 4.1.0. There are no
Ray> restrictions in the NTP configuration and no restrictions in the
Ray> firewall. Yet, when I receive NTP request, from version3, and with an
Ray> IP address starting with 69, the daemon does not reply to it. The
Ray> server will reply to NTP packets with version4. The server appears to
Ray> respond properly to all other subnets. Does anyone have any ideas why
Ray> this happens?

Got any debug output from ntpd that shows it receiving/replying v4 but
receiving/not replying to v3?

--
Harlan Stenn
http://ntpforum.isc.org - be a member!

Harlan,

Here are sample of the debug output, which include IP addresses that start
with 69.
This first sample gave no reply. I assume it is version 3.
----------------------------------------------------------------------------
-------
MCAST *****sendpkt(fd=6 dst=192.70.172.132, src=132.246.168.2, ttl=0,
len=48)
transmit: at 37 132.246.168.2->192.70.172.132 mode 4
input_handler: if=2 fd=6 length 48 from d1cd2803 209.205.40.3
receive: at 38 132.246.168.2<-209.205.40.3 restrict 00
receive: at 38 132.246.168.2<-209.205.40.3 mode 3 code 2
MCAST *****sendpkt(fd=6 dst=209.205.40.3, src=132.246.168.2, ttl=0, len=48)
transmit: at 38 132.246.168.2->209.205.40.3 mode 4
input_handler: if=2 fd=6 length 48 from 453fdb02 69.63.219.2
receive: at 38 132.246.168.2<-69.63.219.2 restrict 00
input_handler: if=2 fd=6 length 48 from d06f2383 208.111.35.131
receive: at 38 132.246.168.2<-208.111.35.131 restrict 00
receive: at 38 132.246.168.2<-208.111.35.131 mode 3 code 2
MCAST *****sendpkt(fd=6 dst=208.111.35.131, src=132.246.168.2, ttl=0,
len=48)
transmit: at 38 132.246.168.2->208.111.35.131 mode 4
----------------------------------------------------------------------------
-

This sample did reply in mode 4.
-------------------------------------------------
receive: at 182 132.246.168.2<-72.139.76.245 mode 3 code 2
MCAST *****sendpkt(fd=6 dst=72.139.76.245, src=132.246.168.2, ttl=0,
len=48)
transmit: at 182 132.246.168.2->72.139.76.245 mode 4
input_handler: if=2 fd=6 length 48 from 459c69c0 69.156.105.192
receive: at 182 132.246.168.2<-69.156.105.192 restrict 00
receive: at 182 132.246.168.2<-69.156.105.192 mode 3 code 2
MCAST *****sendpkt(fd=6 dst=69.156.105.192, src=132.246.168.2, ttl=0,
len=48)
transmit: at 182 132.246.168.2->69.156.105.192 mode 4
input_handler: if=2 fd=6 length 48 from 0426649b 4.38.100.155
receive: at 183 132.246.168.2<-4.38.100.155 restrict 00
----------------------------------------------------------------------------
----

Does this make any sense to you?

Thanks for your help,
Ray
========================================

"Harlan Stenn" wrote in message
news:ywn9r6du8xop.fsf@ntp1.isc.org...
> Ray,
>
> >>> In article , "Ray"
writes:
>
> Ray> I am running stratum-1 servers with NTP version 4.1.0. There are no
> Ray> restrictions in the NTP configuration and no restrictions in the
> Ray> firewall. Yet, when I receive NTP request, from version3, and with
an
> Ray> IP address starting with 69, the daemon does not reply to it. The
> Ray> server will reply to NTP packets with version4. The server appears to
> Ray> respond properly to all other subnets. Does anyone have any ideas
why
> Ray> this happens?
>
> Got any debug output from ntpd that shows it receiving/replying v4 but
> receiving/not replying to v3?
>
> --
> Harlan Stenn
> http://ntpforum.isc.org - be a member!

Ray,

I don't know if Danny has any ideas, but I think we may need a higher level
of debugging.
--
Harlan Stenn
http://ntpforum.isc.org - be a member!

How do you know that the problem is specific to systems that have
addresses that begin with 69? If you take the failing system in this
debug and change nothing else but it's IP address, does it work okay?
Do you have more than one system that is having this problem and they
are all on the 69.*.*.* network? If so, do they have anything else in
common? Different? What version of NTP is running on the clients that
fail? On the ones that succeed?

Brian Utterback

On Tue, 1 Apr 2008 12:44:17 -0400, "Ray" wrote:

> input_handler: if=2 fd=6 length 48 from 453fdb02 69.63.219.2
> receive: at 38 132.246.168.2<-69.63.219.2 restrict 00

> receive: at 182 132.246.168.2<-69.156.105.192 restrict 00
> receive: at 182 132.246.168.2<-69.156.105.192 mode 3 code 2
> MCAST *****sendpkt(fd=6 dst=69.156.105.192, src=132.246.168.2, ttl=0,
> len=48)
> transmit: at 182 132.246.168.2->69.156.105.192 mode 4


> > Ray> I am running stratum-1 servers with NTP version 4.1.0.

Compare the above two client addresses in the output of
"ntpdc -nc monlist 132.246.168.2" :

remote address port local address count m ver drop last first

69.63.219.2 353 132.246.168.2 99 3 3 0 18 6354

69.156.105.192 2605 132.246.168.2 11 3 4 0 294 6309


Then examine this piece of code in ntp-4.1.0/ntpd/ntp_proto.c receive() :

if (!(SRCPORT(&rbufp->recv_srcadr) == NTP_PORT ||
SRCPORT(&rbufp->recv_srcadr) >= IPPORT_RESERVED)) {
sys_badlength++;
return; /* invalid port */
}

QED. Time to upgrade to a later version ...

--
Ronan Flood

Guys,

I was afraid this might happen. There is no such port check in the
development branch, so somebody broke my rules not to change ntp_proto.c
withhout my permission. The result not only breaks the specification, it
disables symmetric active/active modes. Any check like this has to be
mode dependent, so whoever made the change eithher doesn't believe the
specification or doesn't understand symmetric modes or both.

This is the main reason I object to changing the files I specifically
reserve for my own paws, including ntp_proto.c, ntp_crypto.c,
ntp_loopfilter.c and ntp-keygen.c, between development merges and I'm
rather pissed off.

Dave

Ronan Flood wrote:
> On Tue, 1 Apr 2008 12:44:17 -0400, "Ray" wrote:
>
>
>>input_handler: if=2 fd=6 length 48 from 453fdb02 69.63.219.2
>>receive: at 38 132.246.168.2<-69.63.219.2 restrict 00
>
>
>>receive: at 182 132.246.168.2<-69.156.105.192 restrict 00
>>receive: at 182 132.246.168.2<-69.156.105.192 mode 3 code 2
>> MCAST *****sendpkt(fd=6 dst=69.156.105.192, src=132.246.168.2, ttl=0,
>>len=48)
>>transmit: at 182 132.246.168.2->69.156.105.192 mode 4
>
>
>
>>>Ray> I am running stratum-1 servers with NTP version 4.1.0.
>
>
> Compare the above two client addresses in the output of
> "ntpdc -nc monlist 132.246.168.2" :
>
> remote address port local address count m ver drop last first
>
> 69.63.219.2 353 132.246.168.2 99 3 3 0 18 6354
>
> 69.156.105.192 2605 132.246.168.2 11 3 4 0 294 6309
>
>
> Then examine this piece of code in ntp-4.1.0/ntpd/ntp_proto.c receive() :
>
> if (!(SRCPORT(&rbufp->recv_srcadr) == NTP_PORT ||
> SRCPORT(&rbufp->recv_srcadr) >= IPPORT_RESERVED)) {
> sys_badlength++;
> return; /* invalid port */
> }
>
> QED. Time to upgrade to a later version ...
>

"David L. Mills" wrote:

> I was afraid this might happen. There is no such port check in the
> development branch

Relax, Dave: the original poster is running old code, version 4.1.0.
This port check was removed in 2002.

--
Ronan Flood

On 2008-04-02, David L. Mills wrote:

> I was afraid this might happen. There is no such port check in the
> development branch, so somebody broke my rules not to change ntp_proto.c
> withhout my permission. The result not only breaks the specification, it
> disables symmetric active/active modes. Any check like this has to be
> mode dependent, so whoever made the change eithher doesn't believe the
> specification or doesn't understand symmetric modes or both.
>
> This is the main reason I object to changing the files I specifically
> reserve for my own paws, including ntp_proto.c, ntp_crypto.c,
> ntp_loopfilter.c and ntp-keygen.c, between development merges and I'm
> rather pissed off.

I don't see 'NTP_PORT' in ntp_proto.c in the current stable release:

steve@stasis:/tmp/ntp-4.2.4p4/ntpd$ grep NTP_PORT ntp_proto.c
steve@stasis:/tmp/ntp-4.2.4p4/ntpd$

--
Steve Kostecke
NTP Public Services Project - http://support.ntp.org/

Dave,

4.1.0 was a long time ago in a galaxy far, far away. We don't care about
that version any more. Anyone who wants help needs to upgrade to a more
recent version.

Danny

David L. Mills wrote:
> Guys,
>
> I was afraid this might happen. There is no such port check in the
> development branch, so somebody broke my rules not to change ntp_proto.c
> withhout my permission. The result not only breaks the specification, it
> disables symmetric active/active modes. Any check like this has to be
> mode dependent, so whoever made the change eithher doesn't believe the
> specification or doesn't understand symmetric modes or both.
>
> This is the main reason I object to changing the files I specifically
> reserve for my own paws, including ntp_proto.c, ntp_crypto.c,
> ntp_loopfilter.c and ntp-keygen.c, between development merges and I'm
> rather pissed off.
>
> Dave
>
> Ronan Flood wrote:
>> On Tue, 1 Apr 2008 12:44:17 -0400, "Ray" wrote:
>>
>>
>>> input_handler: if=2 fd=6 length 48 from 453fdb02 69.63.219.2
>>> receive: at 38 132.246.168.2<-69.63.219.2 restrict 00
>>
>>> receive: at 182 132.246.168.2<-69.156.105.192 restrict 00
>>> receive: at 182 132.246.168.2<-69.156.105.192 mode 3 code 2
>>> MCAST *****sendpkt(fd=6 dst=69.156.105.192, src=132.246.168.2, ttl=0,
>>> len=48)
>>> transmit: at 182 132.246.168.2->69.156.105.192 mode 4
>>
>>
>>>> Ray> I am running stratum-1 servers with NTP version 4.1.0.
>>
>> Compare the above two client addresses in the output of
>> "ntpdc -nc monlist 132.246.168.2" :
>>
>> remote address port local address count m ver drop last first
>>
>> 69.63.219.2 353 132.246.168.2 99 3 3 0 18 6354
>>
>> 69.156.105.192 2605 132.246.168.2 11 3 4 0 294 6309
>>
>>
>> Then examine this piece of code in ntp-4.1.0/ntpd/ntp_proto.c receive() :
>>
>> if (!(SRCPORT(&rbufp->recv_srcadr) == NTP_PORT ||
>> SRCPORT(&rbufp->recv_srcadr) >= IPPORT_RESERVED)) {
>> sys_badlength++;
>> return; /* invalid port */
>> }
>>
>> QED. Time to upgrade to a later version ...
>>
>
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
>

mayer@ntp.isc.org (Danny Mayer) wrote:

> 4.1.0 was a long time ago in a galaxy far, far away.

"The code is out there."

--
Ronan Flood

mayer@ntp.isc.org (Danny Mayer) writes:

>Dave,

>4.1.0 was a long time ago in a galaxy far, far away. We don't care about
>that version any more. Anyone who wants help needs to upgrade to a more
>recent version.

IF you knoww that this was a bug in a particular old version and that the
new versions fix it, then this is good advice. Otherwise it looks like "Go
away-- i will set you a sufficient number of useless tasks that you stop
posting here."

If someone knows that 4.1.0 screwed up all IPs with 69 at the start then
this is a reasonable bit of advice. Or if it is the port that is being
used, and not the "69" then pointing out that that is a bug in 4.1.0 which
is now fixed is useful.



>Danny

>David L. Mills wrote:
>> Guys,
>>
>> I was afraid this might happen. There is no such port check in the
>> development branch, so somebody broke my rules not to change ntp_proto.c
>> withhout my permission. The result not only breaks the specification, it
>> disables symmetric active/active modes. Any check like this has to be
>> mode dependent, so whoever made the change eithher doesn't believe the
>> specification or doesn't understand symmetric modes or both.
>>
>> This is the main reason I object to changing the files I specifically
>> reserve for my own paws, including ntp_proto.c, ntp_crypto.c,
>> ntp_loopfilter.c and ntp-keygen.c, between development merges and I'm
>> rather pissed off.
>>
>> Dave
>>
>> Ronan Flood wrote:
>>> On Tue, 1 Apr 2008 12:44:17 -0400, "Ray" wrote:
>>>
>>>
>>>> input_handler: if=2 fd=6 length 48 from 453fdb02 69.63.219.2
>>>> receive: at 38 132.246.168.2<-69.63.219.2 restrict 00
>>>
>>>> receive: at 182 132.246.168.2<-69.156.105.192 restrict 00
>>>> receive: at 182 132.246.168.2<-69.156.105.192 mode 3 code 2
>>>> MCAST *****sendpkt(fd=6 dst=69.156.105.192, src=132.246.168.2, ttl=0,
>>>> len=48)
>>>> transmit: at 182 132.246.168.2->69.156.105.192 mode 4
>>>
>>>
>>>>> Ray> I am running stratum-1 servers with NTP version 4.1.0.
>>>
>>> Compare the above two client addresses in the output of
>>> "ntpdc -nc monlist 132.246.168.2" :
>>>
>>> remote address port local address count m ver drop last first
>>>
>>> 69.63.219.2 353 132.246.168.2 99 3 3 0 18 6354
>>>
>>> 69.156.105.192 2605 132.246.168.2 11 3 4 0 294 6309
>>>
>>>
>>> Then examine this piece of code in ntp-4.1.0/ntpd/ntp_proto.c receive() :
>>>
>>> if (!(SRCPORT(&rbufp->recv_srcadr) == NTP_PORT ||
>>> SRCPORT(&rbufp->recv_srcadr) >= IPPORT_RESERVED)) {
>>> sys_badlength++;
>>> return; /* invalid port */
>>> }
>>>
>>> QED. Time to upgrade to a later version ...
>>>
>>
>> _______________________________________________
>> questions mailing list
>> questions@lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/questions
>>

On 2008-04-02, Ronan Flood wrote:

> mayer@ntp.isc.org (Danny Mayer) wrote:
>
>> 4.1.0 was a long time ago in a galaxy far, far away.
>
> "The code is out there."

That NTP_PORT test appears to be present in ntp-4.1.0 but not in
ntp-4.1.1. So it was obviously removed after it was discovered.

A useful response to the OP's problem report would have been something
along the lines of: "The NTP_PORT check should not be present in
../ntpd/ntp_proto.c. Please comment the check out and recompile ntpd."

--
Steve Kostecke
NTP Public Services Project - http://support.ntp.org/

Ronan,

You are right. The oldest version I have here is 4.1.2 circa July 2003
and the port check had been removed. Also, my warning to not change
ntp_proto.c without my permission was not in that version. So, nobody
did anything wrong, just misguided. I just don't want somthing to leave
here not in spec, and that port check has been illegal since 1992.

The current NTPv4 ntent is that source port 123 is required only for
symmetric modes. Previously it was required for all modes.

Dave

Ronan Flood wrote:
> "David L. Mills" wrote:
>
>
>>I was afraid this might happen. There is no such port check in the
>>development branch
>
>
> Relax, Dave: the original poster is running old code, version 4.1.0.
> This port check was removed in 2002.
>

Thanks to everyone who replied.
I now know I have to update. So what is the last stable version?

I just wanted to know how the daemon could be so selective to deny IP
69.x.x.x

Ray
--------------------------------------
"Ray" wrote in message
news:fstop5$jo$1@nrc-news.nrc.ca...
> Harlan,
>
> Here are sample of the debug output, which include IP addresses that start
> with 69.
> This first sample gave no reply. I assume it is version 3.
> --------------------------------------------------------------------------
--
> -------
> MCAST *****sendpkt(fd=6 dst=192.70.172.132, src=132.246.168.2, ttl=0,
> len=48)
> transmit: at 37 132.246.168.2->192.70.172.132 mode 4
> input_handler: if=2 fd=6 length 48 from d1cd2803 209.205.40.3
> receive: at 38 132.246.168.2<-209.205.40.3 restrict 00
> receive: at 38 132.246.168.2<-209.205.40.3 mode 3 code 2
> MCAST *****sendpkt(fd=6 dst=209.205.40.3, src=132.246.168.2, ttl=0,
len=48)
> transmit: at 38 132.246.168.2->209.205.40.3 mode 4
> input_handler: if=2 fd=6 length 48 from 453fdb02 69.63.219.2
> receive: at 38 132.246.168.2<-69.63.219.2 restrict 00
> input_handler: if=2 fd=6 length 48 from d06f2383 208.111.35.131
> receive: at 38 132.246.168.2<-208.111.35.131 restrict 00
> receive: at 38 132.246.168.2<-208.111.35.131 mode 3 code 2
> MCAST *****sendpkt(fd=6 dst=208.111.35.131, src=132.246.168.2, ttl=0,
> len=48)
> transmit: at 38 132.246.168.2->208.111.35.131 mode 4
> --------------------------------------------------------------------------
--
> -
>
> This sample did reply in mode 4.
> -------------------------------------------------
> receive: at 182 132.246.168.2<-72.139.76.245 mode 3 code 2
> MCAST *****sendpkt(fd=6 dst=72.139.76.245, src=132.246.168.2, ttl=0,
> len=48)
> transmit: at 182 132.246.168.2->72.139.76.245 mode 4
> input_handler: if=2 fd=6 length 48 from 459c69c0 69.156.105.192
> receive: at 182 132.246.168.2<-69.156.105.192 restrict 00
> receive: at 182 132.246.168.2<-69.156.105.192 mode 3 code 2
> MCAST *****sendpkt(fd=6 dst=69.156.105.192, src=132.246.168.2, ttl=0,
> len=48)
> transmit: at 182 132.246.168.2->69.156.105.192 mode 4
> input_handler: if=2 fd=6 length 48 from 0426649b 4.38.100.155
> receive: at 183 132.246.168.2<-4.38.100.155 restrict 00
> --------------------------------------------------------------------------
--
> ----
>
> Does this make any sense to you?
>
> Thanks for your help,
> Ray
> ========================================
>
> "Harlan Stenn" wrote in message
> news:ywn9r6du8xop.fsf@ntp1.isc.org...
> > Ray,
> >
> > >>> In article , "Ray"

> writes:
> >
> > Ray> I am running stratum-1 servers with NTP version 4.1.0. There are no
> > Ray> restrictions in the NTP configuration and no restrictions in the
> > Ray> firewall. Yet, when I receive NTP request, from version3, and with
> an
> > Ray> IP address starting with 69, the daemon does not reply to it. The
> > Ray> server will reply to NTP packets with version4. The server appears
to
> > Ray> respond properly to all other subnets. Does anyone have any ideas
> why
> > Ray> this happens?
> >
> > Got any debug output from ntpd that shows it receiving/replying v4 but
> > receiving/not replying to v3?
> >
> > --
> > Harlan Stenn
> > http://ntpforum.isc.org - be a member!
>
>

On 2008-04-03, Ray wrote:

> I now know I have to update. So what is the last stable version?

The current stable release is 4.2.4p4 2007/09/10

Current version information is published at:

http://www.ntp.org/
http://support.ntp.org/
http://support.ntp.org/rss/releases.xml (as an RSS feed)

The download pages are:

http://www.ntp.org/downloads.html
http://support.ntp.org/download

Current version information is available for inclusion on other
web-pages in the following formats:

HTML table: http://support.ntp.org/bin/view/Main...ble?skin=plain
Unordered list: http://support.ntp.org/bin/view/Main...ist?skin=plain

Please visit http://support.ntp.org/bin/view/Main...eNotifications
for more information about NTP Release Notifications

--
Steve Kostecke
NTP Public Services Project - http://support.ntp.org/

Ray wrote:
> Thanks to everyone who replied.
> I now know I have to update. So what is the last stable version?
>
> I just wanted to know how the daemon could be so selective to deny IP
> 69.x.x.x
>
> Ray

It depends on what's in your config file. You may be restricting 69/8
addresses.

Danny

Ronan Flood wrote:
> mayer@ntp.isc.org (Danny Mayer) wrote:
>
>> 4.1.0 was a long time ago in a galaxy far, far away.
>
> "The code is out there."
>

That doesn't matter. We only support the current current unless there's
a paid contract to maintain some other version. Dave was concerned about
something that he wants to ensure control of but that's in the recent
versions.

Danny

Danny,

Danny Mayer wrote:
> Ronan Flood wrote:
>> mayer@ntp.isc.org (Danny Mayer) wrote:
>>
>>> 4.1.0 was a long time ago in a galaxy far, far away.
>>
>> "The code is out there."
>>
>
> That doesn't matter. We only support the current current unless there's
> a paid contract to maintain some other version. Dave was concerned about
> something that he wants to ensure control of but that's in the recent
> versions.

I don't think I've read a request where this should be fixed in an older
version.

The problem in this NG seems to be that some insiders seem to assume all
users are running a very recent version of NTP, and I'm pretty sure this is
not the case.

I think most users run the version which comes with their OS or
distribution, and stuck with it unless they stumble across a bug or
limitation, in which case it's normally sufficient to point them to the
latest version.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
[]
> I don't think I've read a request where this should be fixed in an
> older version.
>
> The problem in this NG seems to be that some insiders seem to assume
> all users are running a very recent version of NTP, and I'm pretty
> sure this is not the case.
>
> I think most users run the version which comes with their OS or
> distribution, and stuck with it unless they stumble across a bug or
> limitation, in which case it's normally sufficient to point them to
> the latest version.
>
> Martin

On the general principle "If it works, leave it", I agree with their
approach!

David