Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory.

There are only two fields, but ;)

Summary

Explain the motivation for making this change. What existing problem does the pull request solve?

Chrony puts some source information into the "SourceData" reply, which the library already handles, and some additional information into the "SourceStats" reply, which this PR adds. I needed the stats to keep track of how far off 1Hz various PPS sources are (the "ResidFreqPPM" element).

Test Plan

Demonstrate the code is solid. Example: The exact commands you ran and their output, copy text from console etc.

I was hoping there would be some test infrastructure in the repo to properly test new messages, but the current state is that most messages aren't tested. I could be persuaded to take some packet captures and check that they unmarshal into the right fields. Or I could just submit this and it could be someone else's problem in the future.

In terms of manually testing, we can compare the output of this codepath with chronyc sourcestats on two machines:

Machine A

chronyc (chrony) version 4.0 (+READLINE +SECHASH +IPV6 -DEBUG)

chronyd (chrony) version 4.0 (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)

This code (+ https://github.com/jrockway/beaglebone-gps-clock to produce the output):

Name/IP Address              NP  NR           Span  Frequency  Freq Skew        Offset       Std Dev
====================================================================================================
PHC0                         46  26           6m0s    +22.704      0.004  1.741635322s         788ns
45.15.168.198                 9   6       2h17m48s     +0.126      0.334   -1.177994ms      492.01µs
216.229.0.50                 10   6       2h35m11s     +0.484      0.657    4.741208ms    1.306933ms
12.167.151.1                 12   7        3h9m24s     +0.383      0.836       26.66µs    2.176271ms
162.159.200.1                12   8        3h9m15s     +0.125      0.725    -2.80691ms    2.154848ms
192.168.1.62                 64  30           1m4s     +0.004      0.740            0s      32.452µs

chronyc sourcestats (the samples were taken a few seconds apart, so the numbers don't match perfectly, but it does feel like the right field is going to the right place):

Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
PHC0                       47  26   368    +22.694      0.004  +1742ms   780ns
45.15.168.198               9   6  137m     +0.116      0.334  -1179us   492us
nu.binary.net              10   6  155m     +0.474      0.657  +4742us  1307us
12.167.151.1               12   7  189m     +0.372      0.836    +27us  2176us
time.cloudflare.com        12   8  189m     +0.114      0.725  -2808us  2155us
192.168.1.62               49  25    49     +0.029      1.110     +9ns    31us

Machine B

chronyc (chrony) version 3.4 (+READLINE +SECHASH +IPV6 -DEBUG)

chronyd (chrony) version 3.4 (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)

This code:

Name/IP Address              NP  NR           Span  Frequency  Freq Skew        Offset       Std Dev
====================================================================================================
GPS                          31  16           8m2s    +20.126     14.265   12.809642ms    3.673112ms
PPS                          16   9           4m0s     +0.000      0.016            0s       1.113µs
RTC                          10   8          2m22s     -0.036      0.011     385.133µs         304ns
180.77.60.117                50  32      14h21m50s     +0.230      0.099    4.737684ms    3.096571ms
101.187.24.205               26  14       7h10m38s     +0.257      0.304   -5.456276ms     2.95475ms
38.229.52.9                  51  24       14h40m5s     +0.190      0.085   -9.521911ms    2.579329ms
162.159.200.1                30  14       8h18m54s     +0.236      0.201   -3.028984ms    2.633467ms

chronyc sourcestats:

Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
GPS                        31  16   482    +20.126     14.265    +13ms  3673us
PPS                        16   9   240     +0.000      0.016     +0ns  1113ns
RTC                        10   8   142     -0.036      0.011   +385us   304ns
2602:fe90:300:1a2::a093:>  50  32   14h     +0.230      0.099  +4738us  3097us
2605:6400:d814::ad18       26  14  430m     +0.257      0.304  -5456us  2955us
38.229.52.9                51  24   14h     +0.190      0.085  -9522us  2579us
time.cloudflare.com        30  14  498m     +0.236      0.201  -3029us  2633us

These are pretty much identical, modulo my inability to write out the proper IPv6 address from the refid ;)

Summary

Add an initial config to get RPM builds per-commit and per-PR via PackIt. This will make it easier to spot issues like #100 down the road.

Test Plan

CI

Summary

Zone info database now uses version 2 of file format to store leap seconds info. That's why it's good to have parser for both versions. Current generator of leap seconds prints them to stdout, but for testing purpose it's great to write it to file.

The changes are:

• add parameter to printleap command to specify the file to read and show
• add command addfakesecond to add fake leap second to source file and store it in output file
• add version 2 leap seconds file parser

Test Plan

Some tests are added to cover new code

Add a "cert" package which will do some validation of the supplied PEM file for the "calnex cert" command.

Validates:

• The PEM file parses
• We have a private key
• We have a cert
• One of the cert CNs matches the supplied hostname
• The cert validity date before and ends after the supplied time.

Summary

This change provides a basic level of validation of any new certificate being uploaded to the Calnex to try and prevent common errors that might result in unavailability of the remote API.

Test Plan

$ go test ./...
ok  	github.com/facebook/time/calnex/api	0.080s
ok  	github.com/facebook/time/calnex/cert	0.007s
ok  	github.com/facebook/time/calnex/cmd	0.006s
ok  	github.com/facebook/time/calnex/config	0.016s
ok  	github.com/facebook/time/calnex/export	0.014s
ok  	github.com/facebook/time/calnex/firmware	0.014s

$ touch ~/empty.pem
$ go run github.com/facebook/time/cmd/calnex cert --target my.host.here --file ~/empty.pem
FATA[0000] bundle has no private key                    
exit status 1

$ echo "this is rubbish" > ~/corrupt.pem
$ go run github.com/facebook/time/cmd/calnex cert --target my.host.here --file ~/corrupt.pem 
FATA[0000] failed to parse certificate PEM              
exit status 1

$ openssl req -x509 -nodes -newkey rsa:2048 -keyout ~/privkey.pem -out ~/cert.pem -sha256 -days 365 -subj '/CN=my.host.here' -reqexts SAN -extensions SAN -config <(printf '[req]\ndistinguished_name = dn\n[dn]\nCN=my.host.here\n[SAN]\nsubjectAltName=DNS:my.host.here')
…
$ go run github.com/facebook/time/cmd/calnex cert --target my.host.here --file ~/privkey.pem 
FATA[0000] bundle has no certificates                   
exit status 1

$ go run github.com/facebook/time/cmd/calnex cert --target my.host.here --file ~/cert.pem 
FATA[0000] bundle has no private key                    
exit status 1

$ cat ~/cert.pem ~/privkey.pem > ~/bundle.pem

$ go run github.com/facebook/time/cmd/calnex cert --target not.my.host.here --file ~/bundle.pem 
FATA[0000] bundle has no certificate for supplied host  
exit status 1

$ go run github.com/facebook/time/cmd/calnex cert --target my.host.here --file ~/bundle.pem 
FATA[0000] dial tcp: lookup my.host.here: no such host  
exit status 1

$ go run github.com/facebook/time/cmd/calnex cert --target my.real.host --file ~/device.pem
FATA[0000] new certificate matches existing certificate 
exit status 1

Summary

This PR adds support for the activity command to the chrony package.

chrony docs:

activity This command reports the number of servers and peers that are online and offline. If the auto_offline option is used in specifying some of the servers or peers, the activity command can be useful for detecting when all of them have entered the offline state after the network link has been disconnected.

We use tracking and activity commands for chrony monitoring. I'd like to get this PR merged so we can use this library.

Test Plan

• The changes are pretty straightforward:

  • RPY_ACTIVITY code is 12.
  • REQ_ACTIVITY code is 44.
  • RPY_Activity structure.

• test binary that queries activity

$ ./main
&{ReplyHead:{Version:6 PKTType:reply Res1:0 Res2:0 Command:44 Reply:12 Status:SUCCESS Pad1:0 Pad2:0 Pad3:0 Sequence:1 Pad4:0 Pad5:0} Activity:{Online:4 Offline:0 BurstOnline:0 BurstOffline:0 Unresolved:0}}

Updated README.md and .gitignore with the following features:

• Add project status badges to READE.md
• Refactor README.md format
• Add tests output files to .gitignore

Summary

Exposing pre existing correction field to diag results

Warning Threshold: 1 minute Error Threshold: 10 minutes

Test Plan

./ntp/ntpcheck/ntpcheck/ntpcheck/ntpcheck diag

NOTE: I ran 3 times and manually adjusted correction to get different cases

[ OK ] Leap indicator is set to 'none'
[ OK ] Sys Peer offset is 0.007ms, we expect it to be within 1.0ms
[ OK ] Sys Peer jitter is 0.000ms, we expect it to be within 1.0ms
[ OK ] Current correction is 0.003ms, we expect it to be within 60000.0ms
[ OK ] All 18 peers are OK (have 'flash' indicator set to 0)
[ OK ] All 18 peers were reachable 8/8 last sync attempts

[ OK ] Leap indicator is set to 'none'
[ OK ] Sys Peer offset is 0.007ms, we expect it to be within 1.0ms
[ OK ] Sys Peer jitter is 0.000ms, we expect it to be within 1.0ms
[WARN] Current correction is 70000.003ms, we expect it to be within 60000.0ms. Correction is the difference between system time and chronyd’s estimate of the current true time.
[ OK ] All 18 peers are OK (have 'flash' indicator set to 0)
[ OK ] All 18 peers were reachable 8/8 last sync attempts

[ OK ] Leap indicator is set to 'none'
[ OK ] Sys Peer offset is 0.007ms, we expect it to be within 1.0ms
[ OK ] Sys Peer jitter is 0.000ms, we expect it to be within 1.0ms
[FAIL] Current correction is 610000.003ms, we expect it to be within 60000.0ms. Correction is the difference between system time and chronyd’s estimate of the current true time.
[ OK ] All 18 peers are OK (have 'flash' indicator set to 0)
[ OK ] All 18 peers were reachable 8/8 last sync attempts

Chrony has a leapsectz directive to get the next leap second info from the system tz database.

I am adding a leapsectz package to get visibility of the information in there.

Example run:

ntpchkng utils printleap
1972-07-01 00:00:00 +0000 UTC
1973-01-01 00:00:00 +0000 UTC
1974-01-01 00:00:00 +0000 UTC
1975-01-01 00:00:00 +0000 UTC
1976-01-01 00:00:00 +0000 UTC
1977-01-01 00:00:00 +0000 UTC
1978-01-01 00:00:00 +0000 UTC
1979-01-01 00:00:00 +0000 UTC
1980-01-01 00:00:00 +0000 UTC
1981-07-01 00:00:00 +0000 UTC
1982-07-01 00:00:00 +0000 UTC
1983-07-01 00:00:00 +0000 UTC
1985-07-01 00:00:00 +0000 UTC
1988-01-01 00:00:00 +0000 UTC
1990-01-01 00:00:00 +0000 UTC
1991-01-01 00:00:00 +0000 UTC
1992-07-01 00:00:00 +0000 UTC
1993-07-01 00:00:00 +0000 UTC
1994-07-01 00:00:00 +0000 UTC
1996-01-01 00:00:00 +0000 UTC
1997-07-01 00:00:00 +0000 UTC
1999-01-01 00:00:00 +0000 UTC
2006-01-01 00:00:00 +0000 UTC
2009-01-01 00:00:00 +0000 UTC
2012-07-01 00:00:00 +0000 UTC
2015-07-01 00:00:00 +0000 UTC
2017-01-01 00:00:00 +0000 UTC

Related code snippets:

• https://gist.github.com/zed/92df922103ac9deb1a05
• https://stackoverflow.com/questions/19332902/extract-historic-leap-seconds-from-tzdata

Go does not currently parse this data:

• https://golang.org/src/time/zoneinfo_read.go
• https://github.com/golang/go/issues/15247

Since we found that we don't allow using Travis-CI anymore.

Also, forgot to add tests.sh from the previous PR

Signed-off-by: Andrea Barberio [email protected]

Summary

Currently server directly responds to the signaling messages (grants). However, we already have powerful mechanism of sending messages (sync/fwup/announce/delayResp) via workers. This change will leverage workers to send grants, completely removing send logic from the server. This will unblock cancellation messages being generated within the subscription on cancel.

Test Plan

Tcpdump/Wireshard

Works in prod

Unittests

Lint issue is unrelated

Description:

Cover new monitoring values

Test plan:

1. Socket sends this json:

{ "Action requested": "None", "disciplining": { "status": "LOCK_HIGH_RESOLUTION", "current_phase_convergence_count": -1, "valid_phase_convergence_threshold": -1, "convergence_progress": 0.0, "tracking_only": "false", "ready_for_holdover": "false" }, "clock": { "class": "Lock", "offset": 2 }, "oscillator": { "model": "sa5x", "fine_ctrl": -625, "coarse_ctrl": 10000, "lock": true, "temperature": 46.935000000000002 }, "gnss": { "fix": 3, "fixOk": true, "antenna_power": 1, "antenna_status": 2, "lsChange": 0, "leap_seconds": 18, "satellites_count": 27, "survey_in_position_error": 8 } }

2. ptpcheck shows:

Oscillator:
	model: sa5x
	fine_ctrl: -625
	coarse_ctrl: 10000
	lock: true
	temperature: 46.94C
GNSS:
	fix: Time (3)
	fixOk: true
	antenna_power: ON (1)
	antenna_status: OK (2)
	leap_second_change: NO WARNING (0)
	leap_seconds: 18
	satellites_count: 27
	survey_in_position_error: 8
Clock:
	class: Lock (6)
	offset: 2

Using the chrony library forces users into using the logrus logging library. It's not a terrible choice, but it makes it such that you're stuck with it, even if you have other logging.

It would be nice if you could register a logger, similar to how we do this in gosnmp.

Right now, this code is using SO_TIMESTAMPNS/SO_TIMESTAMP, which use kernel level RX timestamps. The documentation and code comment state "hardware timestamps", which is misleading. These timestamps come from https://elixir.bootlin.com/linux/latest/C/ident/net_timestamp_check while "hardware timestamps" would come from 1588 timer hardware in the NIC itself.

https://www.kernel.org/doc/Documentation/networking/timestamping.txt has documentation on the SO_TIMESTAMPING flag, which accepts SOF_TIMESTAMPING_RX_HARDWARE. NIC 1588 hardware timers are usually not synchronized to system time, so your software would need to do that as well. chrony has an example of all of this.

This is just the RX timestamps. TX timestamps could be enabled in NTP interleaved mode, but that would mean keeping state per client. I'm assuming keeping state per client would conflict with the other goals of this project.