beevik / ntp Goto Github PK

Any plan on KoD support?

In NTPv4 and SNTPv4, packets of this kind are called Kiss-o'-Death (KoD) packets, and the ASCII messages they convey are called kiss codes. The KoD packets got their name because an early use was to tell clients to stop sending packets that violate server access controls.

The following is the output of a program querying the ntp servers 0.centos.pool.ntp.org and 1.centos.pool.ntp.org while sleeping for a few seconds between queries.

I've run into two kinds of errors

1. Failed to reach NTP server: 1.centos.pool.ntp.org error: read udp 10.4.67.150:37627->171.66.97.126:123: i/o timeout. I've tried increasing the timeout to 10 seconds from the default of 5 but that hasn't helped. Please share any suggestions you might have.

2. And the other is for invalid values Reached NTP server: 1.centos.pool.ntp.org offset: 3754691965.127657. Where the 3754691965.127657 is way higher than the expected offset.

I've been using the 0.3 release but have experienced the same errors in the 0.2 release.

Reached NTP server: 0.centos.pool.ntp.org offset: 19.631600
Failed to reach NTP server: 1.centos.pool.ntp.org error: read udp 10.4.67.150:57557->104.155.144.4:123: i/o timeout
Reached NTP server: 0.centos.pool.ntp.org offset: 19.626120
Reached NTP server: 1.centos.pool.ntp.org offset: 19.636507
Reached NTP server: 0.centos.pool.ntp.org offset: 19.631544
Failed to reach NTP server: 1.centos.pool.ntp.org error: read udp 10.4.67.150:38249->104.155.144.4:123: i/o timeout
Reached NTP server: 0.centos.pool.ntp.org offset: 19.626148
Failed to reach NTP server: 1.centos.pool.ntp.org error: read udp 10.4.67.150:34181->162.248.241.94:123: i/o timeout
Reached NTP server: 0.centos.pool.ntp.org offset: 19.631553
Reached NTP server: 1.centos.pool.ntp.org offset: 19.636571
Reached NTP server: 0.centos.pool.ntp.org offset: 19.633790
Reached NTP server: 1.centos.pool.ntp.org offset: 3754691965.127657
Reached NTP server: 0.centos.pool.ntp.org offset: 19.635017
Reached NTP server: 1.centos.pool.ntp.org offset: 19.626531
Reached NTP server: 0.centos.pool.ntp.org offset: 19.626131
Reached NTP server: 1.centos.pool.ntp.org offset: 19.634028
Reached NTP server: 0.centos.pool.ntp.org offset: 19.631843
Failure count: 6 bogus values: 4

I'll raise a PR if you are happy to accept it

I used your library to write a tiny diagnostic tool, thanks!

I noticed that Wireshark's dissector can tell me if the NTP version in the response was 3 or 4, it might be nice to have this in this library as well.

Running the test cases during package build on Ubuntu fail [1]:

   dh_auto_test -O--builddirectory=_build -O--buildsystem=golang
	cd _build && go test -vet=off -v -p 4 github.com/beevik/ntp
=== RUN   TestTime
    ntp_test.go:34: [0.beevik-ntp.pool.ntp.org] Query failed: lookup 0.beevik-ntp.pool.ntp.org: no such host
--- FAIL: TestTime (0.02s)
=== RUN   TestTimeFailure
--- PASS: TestTimeFailure (5.01s)
=== RUN   TestQuery
    ntp_test.go:77: [0.beevik-ntp.pool.ntp.org] ----------------------
    ntp_test.go:78: [0.beevik-ntp.pool.ntp.org] NTP protocol version 4
    ntp_test.go:34: [0.beevik-ntp.pool.ntp.org] Query failed: lookup 0.beevik-ntp.pool.ntp.org: no such host
--- FAIL: TestQuery (0.00s)
=== RUN   TestValidate
--- PASS: TestValidate (0.00s)
=== RUN   TestBadServerPort
--- PASS: TestBadServerPort (0.00s)
=== RUN   TestTTL
--- PASS: TestTTL (0.00s)
=== RUN   TestQueryTimeout
--- PASS: TestQueryTimeout (0.00s)
=== RUN   TestShortConversion
--- PASS: TestShortConversion (0.00s)
=== RUN   TestLongConversion
--- PASS: TestLongConversion (0.00s)
=== RUN   TestOffsetCalculation
--- PASS: TestOffsetCalculation (0.00s)
=== RUN   TestOffsetCalculationNegative
--- PASS: TestOffsetCalculationNegative (0.00s)
=== RUN   TestMinError
--- PASS: TestMinError (0.01s)
=== RUN   TestTimeConversions
--- PASS: TestTimeConversions (0.00s)
=== RUN   TestKissCode
--- PASS: TestKissCode (0.00s)
FAIL
FAIL	github.com/beevik/ntp	5.091s
FAIL

This is caused by the package build host having no Internet access. Please change the test cases to not require Internet access. The positive side effect will be that the test cases can't break by changes to the NTP host 0.beevik-ntp.pool.ntp.org.

[1] Full log: https://launchpadlibrarian.net/575776629/buildlog_ubuntu-jammy-amd64.golang-github-beevik-ntp_0.3.0-2_BUILDING.txt.gz

There is a rounding problem between fixed-point and nanoseconds conversions.

I have a need to filter server responses that are v3, since some of my devices only accept a v4 server, I'm halfway through checking the header flag myself in an extension, but was wondering if this might be a valid feature request? Would adding Version to the response struct make sense to anyone else?

Any chance for you to add the reverse function of (t ntpTimeShort) Duration() time.Duration?

like a toNtpTime(t time.Duration) NtpTime function?

I can't figure the formula myself.

Or can you provide any link where I can find the formula? Sorry but I can't contact you privately

It'd be nice if the main branch was renamed to main instead of the legacy / old term.

(Also, thank you for this package -- the NTP Pool is using it to do hundreds of millions of monitoring probes every month!)

Hi,

nice package. I saw in the code that you use IPv4 connection. Is there a reason for that?

Can this implementation support both v4 & v6?

Hi,

I wanted to use this package to monitor stratum 1 servers.
There doesn't seem to be support for querying some fields useful for plotting the oscillator stability.
I'm looking for in particular these fields reported by ntpq -c rv

• time constant
• frequency error
• system jitter
• clock jitter
• clock wander

Would you consider adding support for that?

When calling Query with an empty string as an address, the code panics.

Maybe add a check for the empty string.

I'll raise a PR if you are happy to accept it

I think that the commit a393ae8 broke RPi4 support.

The only diff related to NTP is v1.3.1...v1.4.2 which suggest the commit above as the possible culprit.

It doesn't have an RTC on-board, and this is somewhat related to siderolabs/talos#8828

Hi,

I am packaging dependencies for prometheus.io for Debian, and since they use your package I need to package it too. The problem is that without an explicit license attached to the code it is not legal for Debian to include the package.

Could you add that?

Hi,

I have machines that have only IPv6 connectivity. Using net.ResolveUDPAddr with udp will always* return IPv4 if the DNS name has an IPv4 configured, regardless if the system can route it.

Consider either giving the user a possibility of specifying "udp6" for IPv6, or better yet try with "udp" first, then "udp4" and then "udp6".

Thanks!
* See https://golang.org/src/net/ipsock.go line 85.

It's confusing that stratum=0 gets changed to 16.

I understand that implementations are suggested to do this, but I think it's "later" than "when processing packets". For my application I want to know what the server said.

The RFC also says to process the referenceID separately if the stratum is 0, right now that's impossible to do correctly with the Go client because you can't know if the server said 16 or if it said 0 and it was changed.

In 1.2.0 the API for querying an IPv6 IP by IP address got a little awkward.

I used to just pass the IP (because that was the API, I think). In 1.2.0 I get a "missing port" address.

For an API that takes an optional IP usually sending the IP in brackets like [fe80::1] would work, but getTime() use net.JoinHostPort which messes that up a returns an error that [[fe80::1]] is missing a port number. (see https://go.dev/play/p/Wi0YDXQ0gUH )

Passing a string with the port number works [fe80::1]:123, but that seems to defeat the intention of having the Port number in the opts. Maybe the awkwardness comes from trying to support the port number in the address AND in the opts; currently making the opts version not actually work for IPv6 IPs.

Example of errors from SplitHostPort that might be helpful in figuring out how to fix it: https://go.dev/play/p/mJR_MD9PDUn

It would be nice to cut a new release to include #30