Re: [questions] Regarding NTP interleaved mode
Thank you very much for your reply and time. Thanks Srihari On Fri, Feb 23, 2024 at 2:52 AM Dave Hart wrote: > On Thu, 22 Feb 2024 at 10:47, Srihari Raghavan > wrote: > >> What is the base NTP.org ntp SW version that started supporting >> interleaved mode in the code base? >> >> I see in the latest code base, that process_packet in ntp_proto.c has >> interleaved mode handling, but is there some documentation on the nature >> and extent of the interleaved support and what is needed, if any, to enable >> the same etc., >> > > Dr. Mills added interleaved support sometime in the NTP 4 timeframe, but > I'm not sure exactly when. It has been around for at least 15 years, if > that helps. > > Cheers, > Dave Hart >
[questions] Regarding NTP interleaved mode
Hi all What is the base NTP.org ntp SW version that started supporting interleaved mode in the code base? I see in the latest code base, that process_packet in ntp_proto.c has interleaved mode handling, but is there some documentation on the nature and extent of the interleaved support and what is needed, if any, to enable the same etc., Thanks Srihari https://datatracker.ietf.org/doc/html/draft-ietf-ntp-interleaved-modes
Re: [questions] Regarding NTS...
Thank you much for the reply. /Srihari On Thu, Oct 26, 2023 at 5:27 PM Dru Lavigne wrote: > Hello Srihari, > > We recently published updates on two major milestones needed for NTS > support as well as the funding effort to provide the resources to finish > this feature. Please refer to: > >- >https://www.nwtime.org/news/refactor-upgrade-ntpd-extension-field-handling/ >- https://www.nwtime.org/news/ntf-awarded-2023-arin-community-grant/ >- https://www.nwtime.org/news/join-endrun-spearheading-nts-funding/ > > NTS will be in 4.4 which is targeted for release in mid 2024 to give > adequate time for comprehensive testing. > > Cheers, > > Dru Lavigne > > On Mon, Oct 23, 2023 at 11:09 PM Srihari Raghavan < > srihari.ragha...@gmail.com> wrote: > >> Are there plans to support RFC 8915 - NTS in mainline ntp.org releases? >> If so, what is the targeted release and rough timelines? >> >> Thanks >> Srihari >> >
[questions] Regarding NTS...
Are there plans to support RFC 8915 - NTS in mainline ntp.org releases? If so, what is the targeted release and rough timelines? Thanks Srihari
Re: [ntp:questions] Regarding SHA1 authentication and Key_id 0 and no MAC sent in packets from server
Hi all Just an update to close this thread. I just saw that keyid of all 0 as MAC is the crypto-nak and so will pursue that line of investigation. Thanks Srihari On Tue, May 18, 2021, 3:41 PM Srihari Raghavan wrote: > Hi all > > I was trying to get SHA1 based symmetric key authentication and MAC work > with a standard Linux NTP server. > > I have root access to the Linux NTP server but the NTP server there is > ALWAYS sending back replies with 'key id: ' with no MAC in reply to > an NTP client sending valid packets. > >1. Linux test_ntp 3.10.0-957.27.2.el7.x86_64 #1 SMP Tue Jul 9 16:53:14 >UTC 2019 x86_64 x86_64 x86_64 GNU/Linux >2. ntpd 4.2.6p5 in Red Hat Enterprise Linux Server release 7.6 (Maipo) >3. I have the following /etc/ntp/keys file as generated by 'ntpkeygen >-M' > 1. # idtypekey > 21 SHA1 bfe521e1c452d12885dd25ce889 # > > 4. openssl is supported - OpenSSL 1.0.2k-fips 26 Jan 2017 >5. As seen in the attached images, the NTP client sends a key ID: 21 >with a MAC, while the server ALWAYS replies with key ID:0 and no MAC. >6. Between the same server and client, MD5 configuration and MAC works >perfectly fine. > > I also saw that the RHEL version that I have, has the fixes for the > following issue. > https://bugzilla.redhat.com/show_bug.cgi?id=641800 > > Thoughts? > > Thanks > Srihari > > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Regarding step_systime call
Hello there: Thanks so much for your time. 1. This is Linux on a x86. If you want more details, I can get that as well. 2. Sorry. I meant 1000 seconds. 3. I have verified that there are no background processes affecting system clock. I did not see any traces of someone manually changing clock by date etc., 4. Is there a way to track or log all the calls to clock_settime or any better ways to track all abrupt system clock changes? Thanks SR On Mon, Jan 27, 2020 at 6:58 PM Charles Elliott wrote: > Hello: > It is very difficult to help you if > you don't specify the platform being used, > i.e., O/S (publisher, version and updates) > and CPU if at all unusual. > > What does this mean: "more than 1000s > clock change done erroneously at the > head-end"? Does 1000s mean 1000 seconds or > is it an abbreviation for the word > "thousands"? It is common and natural (i.e., > planned that way) for NTPD to step the time > on initial startup. > > If the O/S is Windows, what does the > Event Log say? Normally, there will be a > message in the Event Log for every NTPD time > step change. > > Is there another clock program in the > system (such as Windows Time) that is also > trying to control the time, so that NTPD and > the other program are fighting? > > Have you tried a packet sniffer (such > as Wireshark) to see if an external program > is somehow affecting the time? > > Charles Elliott > > -Original Message- > From: questions > [mailto:questions-bounces+elliott.ch=comcast. > n...@lists.ntp.org] On Behalf Of Srihari > Raghavan > Sent: Tuesday, January 21, 2020 1:03 AM > To: questions@lists.ntp.org > Subject: [ntp:questions] Regarding > step_systime call > > Hi all > > In one of our research network lab devices, > that use an implementation based off of > ntp.org 4.2.8p12 in NTP client mode - I see a > spurious "stepped" system clock change under > certain conditions (more than 1000s clock > change done erroneously at the head-end) > BEFORE the actual NTP triggered clock change > via known NTP log message around > "step_systime" call > - and am trying to track down the spurious > clock change that happened first. There > could be other actors that could have changed > the system clock via 'date' etc., but I am > trying to rule out the obvious. > > I have added logs around step_systime call in > the code ntp_loopfilter.c and also in > ntp_timer.c and also via ntpd_time_stepped > and I don't see any of them being being > triggered for the 'spurious' case. > > Are there any other calls/paths/APIs in > NTP.org code, besides step_systime > way, that can potentially step the system > clock? Scoured the NTP.org code > (ntpdate is not being used) for the same > without success and hence my request and > email. > > Thanks in advance for any help. > > Regards > SR > _ > __ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Regarding step_systime call
Hi all In one of our research network lab devices, that use an implementation based off of ntp.org 4.2.8p12 in NTP client mode - I see a spurious "stepped" system clock change under certain conditions (more than 1000s clock change done erroneously at the head-end) BEFORE the actual NTP triggered clock change via known NTP log message around "step_systime" call - and am trying to track down the spurious clock change that happened first. There could be other actors that could have changed the system clock via 'date' etc., but I am trying to rule out the obvious. I have added logs around step_systime call in the code ntp_loopfilter.c and also in ntp_timer.c and also via ntpd_time_stepped and I don't see any of them being being triggered for the 'spurious' case. Are there any other calls/paths/APIs in NTP.org code, besides step_systime way, that can potentially step the system clock? Scoured the NTP.org code (ntpdate is not being used) for the same without success and hence my request and email. Thanks in advance for any help. Regards SR ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
