Re: Hack for monitoring NTP servers
Yo Richard! On Fri, 12 Apr 2024 14:12:41 -0500 Richard Laager via devel wrote: > On 2024-04-11 14:39, Hal Murray via devel wrote: > > If somebody feels like hacking, something like this should be fun. > > > > The idea is to setup a ntpd server watching the servers you want to > > monitor. (noselect on the server line does that) > > > > The new code is a program that watches that server to see if the > > servers to be monitored are responding correctly and sends you > > email if they aren't. > > I think you're looking for this (plus some monitoring program like > Nagios, Icinga, etc.): > https://nagios-plugins.org/doc/man/check_ntp_peer.html I used to use Nagios, but I moved on to Zabbix. Both will do this job. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpdut3q4BWI7.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Any Coverity wizards?
Yo Hal! On Tue, 05 Dec 2023 20:40:46 -0800 Hal Murray via devel wrote: > I expect the comment on the previous line to tell Coverity to not > complain about this case. > > Is there a typo or such that I'm missing? > > 149/* coverity[checked_return] */ > CID 462307 (#1 of 1): Unchecked return value (CHECKED_RETURN) > 15. check_return: Calling CMAC_Update without checking return value > (as is done elsewhere 5 out of 6 times). > 150CMAC_Update(cmac_ctx, data, (unsigned int)datalen); AFAIK, that override should work, but does not. Maybe "checked_return" should be in CAPS? The suggestions of adding (void) should work. Ir actually check the return. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpuJNAL0TXtf.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release
Yo Hal! On Sun, 03 Dec 2023 17:44:45 -0800 Hal Murray via devel wrote: > Gary said: > > DO you have an account on: https://scan.coverity.com/ > > If so, I think I can add you to the project. > > How does their stuff work? How often do they check NTPsec? > Or what should I be asking? Every time a commit is made to NTPSec on GitLab, the CI asks Coverity to do a review. > How much mail should I expect? ... One email every few commits. > Should I push the fix? That will require more testing. Or you could do an MR that we can test first. All depends on how good you feel about the commit. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp6xI3zyLWm5.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release
Yo Hal! On Sun, 03 Dec 2023 15:07:18 -0800 Hal Murray via devel wrote: > > Gary said: > > > Uh, not quite. Check the Coverity stuff. > > > > How do I do that? > > DO you have an account on: https://scan.coverity.com/ On further checking,halmurray...@sonic.net is an admin on the NTPSec Coverity account. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpaBnZEYZfQa.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release
Yo Hal! On Sun, 03 Dec 2023 15:07:18 -0800 Hal Murray via devel wrote: > Gary said: > > Uh, not quite. Check the Coverity stuff. > > How do I do that? DO you have an account on: https://scan.coverity.com/ If so, I think I can add you to the project. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpYVmJogELej.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release
Yo James! On Sat, 2 Dec 2023 21:12:04 -0800 (PST) James Browning via devel wrote: > 4. The buildbots are not reporting any unplanned regressions; there > are always issues to be addressed. Uh, not quite. Check the Coverity stuff. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpkG88t_v7LS.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: What's magic about /tmp/? ntpd can't find UNIX socket
Yo Hal! On Thu, 19 Oct 2023 17:45:43 -0700 Hal Murray via devel wrote: > Found it. systemd sets up separate /tmp for some services. Yeah, systemd(umb) is your problem... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpq91HcZnrx9.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: What's magic about /tmp/? ntpd can't find UNIX socket
Yo Hal! On Thu, 19 Oct 2023 14:27:56 -0700 Hal Murray wrote: > Gary said: > > Notice the "nodev"? > > From "man chmod": > >nodev > >Do not interpret character or block special devices on > > the filesystem. > > It works fine from my test program. What's different about ntpd? Does your test program change user and group the way ntpd does? > Is a UNIX socket (fifo?) a special device? Seems "special" to me. > When I see "device", I think of the stuff in /dev/ That too. Easy way to check, just turn nodev off: ~ # mount -o remount,dev /tmp RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp7lZaBWX8eX.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: What's magic about /tmp/? ntpd can't find UNIX socket
Yo Hal! On Thu, 19 Oct 2023 13:42:08 -0700 Hal Murray wrote: > devel@ntpsec.org said: > > Can you provide: > > ~ $ ls -ld /tmp drwxrwxrwt 12 root root 580 Oct 19 11:00 /tmp > > Changing the owner to ntp didn't make any difference. Nor would I expect it to. > > And: > > ~ $ mount | fgrep /tmp tmpfs on /tmp type tmpfs > > (rw,nosuid,relatime,size=3D20 97152k) > > tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576,inode64) Notice the "nodev"? From "man chmod": nodev Do not interpret character or block special devices on the filesystem. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpZU8ptSS2Mp.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: What's magic about /tmp/? ntpd can't find UNIX socket
Yo Hal! On Wed, 18 Oct 2023 21:37:06 -0700 Hal Murray via devel wrote: > What's magic about ntpd and /tmp/? Many things. Can you provide: ~ $ ls -ld /tmp drwxrwxrwt 12 root root 580 Oct 19 11:00 /tmp And: ~ $ mount | fgrep /tmp tmpfs on /tmp type tmpfs (rw,nosuid,relatime,size=2097152k) Notice my /tmp has the "sticky bit" (see man chmod), and is nosuid. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpLqoxuy8UXF.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Go GC
Yo Hal! On Tue, 12 Sep 2023 18:49:35 -0700 Hal Murray via devel wrote: > I think it's worth some effort to investigate this area. I'm > prepared to give up if we find a fatal problem. Again, I'm assuming > that we split ntpd into client and server parts so all we have to > work on is the server half. I look forward to your results. I found working with Go was nice. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpHZrLIVFtSe.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Go GC
Yo Hal! On Tue, 12 Sep 2023 16:55:12 -0700 Hal Murray via devel wrote: > Gary said: > >James Browning via devel wrote: > >> It would appear there is a way to turn off GC under runtime/, > > How? Link? > > https://pkg.go.dev/runtime/debug#SetGCPercent > > It's not clear to me how to take advantage of that. You still have > to turn it on occasionally or your world will fill up with garbage. Assuming you create garbage. Avoiding creating garbage is hard. > I poked around a bit. I'm pretty sure that we can write a server > that doesn't generate any garbage when processing a normal client > request. The problem is not when you generate garbage, but when the garbage collector wakes up. > Occasinally, there is something in the 60-70 microseconds range. > They are rare enough that it's easy to miss one in a million sample > pairs of reading the clock. Which is why NTP slowly adjusts PLL's instead of jumping around. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpkyZe9wWCRx.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Is python2 dead?
Yo Hal! On Tue, 12 Sep 2023 00:00:47 -0700 Hal Murray via devel wrote: > Gary said: > > Please, no. Go is a garbage collected language. Just what NTPsec > > does not need, random, unpredictable delays. > > I was thinking of the Python code in ntpclients/ and pylib/ > Is there anything in there that is time sensitive? That could work. I wrote a Go client for gpsd from scratch. Not hard. > There are lots of ways to inject timing bumps before we get to > garbage collecting. cache, scheduler, interrupts, CPU speed, ... Any that work? > Do you have any data on Go GC times? Just what is in the doc: https://go.dev/doc/gc-guide The programmer has very little control over the GC. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp4XtybeBuJP.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Is python2 dead?
Yo James! On Tue, 12 Sep 2023 06:46:38 -0700 (PDT) James Browning via devel wrote: > > On 09/12/2023 12:00 AM PDT Hal Murray via devel > > wrote: > > > > > > Gary said: > > > Please, no. Go is a garbage collected language. Just what > > > NTPsec does not need, random, unpredictable delays. > > It would appear there is a way to turn off GC under runtime/, How? Link? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpdclVCKifCv.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Is python2 dead?
Yo Hal! On Mon, 11 Sep 2023 22:03:45 -0700 Hal Murray via devel wrote: > Maybe it's time to switch to Go? Please, no. Go is a garbage collected language. Just what NTPsec does not need, random, unpredictable delays. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpVpLWWqTcTy.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Is python2 dead?
Yo Richard! On Mon, 4 Sep 2023 19:24:22 -0500 Richard Laager via devel wrote: > Dropping support for Python 2 should allow for dropping most of the > poly infrastructure. That code (pylib/poly.py) involves some > contortions (see also [1]) to make it possible to run on both Python > 2 and Python 3. And it also makes Python 3 code way easier to write. Even when I don't care about Python 2, I use the poly stuff. > If we dropped support for Python 2, that should come in a couple > phases. Phase 1 would be removing anything relating to Python 2 > itself. It should probably also include any changes relating to > Python detection with waf. Phase 2 would be /carefully/ removing > usage of the poly infrastructure, converting to idiomatic Python 3 > approaches. Once that is done, then we'd be rid of the 2 -> 3 > conversion baggage. These phases need not be separate releases, but > should (IMHO) certainly be separate commits and likely be separate > PRs. A fair plan, and a lot of work, for little added value. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpobBjBIjEeO.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Is python2 dead?
Yo Matthew! On Mon, 4 Sep 2023 21:46:50 + Matthew Selsky wrote: > Is the implication that we can safely drop python2 support after June > 2024? Maybe. RHEL, and friends, are the last to drop things. Worse, people that use RHEL, and friends, seem to never update their systems... > Are there any other distributions that ship python2 that we > want to maintain support for? Dunno, RHEL, and friends, seem to be where the whiners come from. I think there are a few "embedded" distros that still need Python 2. I found this online: Debian – v10 (Buster) is the last release to include Python 2.7, which will continue to be supported through June of 2024. Redhat – RHEL 8 was the last version to include support for Python 2, which will be retired in June 2024. CentOS – v8 was the last version to include support for Python 2.7, which will be EOL in May 2024. Also Ubuntu Extended Security Maintenance (ESM) plan still supports Python 2. > How much does it cost us to maintain python2 support in our own code? Except for the CI, benign neglect seems to be working. The problem is at the other end, where coders want to use new, unstable, Python 3 features. Getting rid of Python 2 does not make them stable. For example: type hints. Even Luke Skywalker can't keep his eyes on that moving target. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpwxTAElWcSk.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Is python2 dead?
Yo James! On Mon, 04 Sep 2023 15:38:26 -0700 James Browning via devel wrote: > > By dropping 2.7 we could probably assume secrets which simplifies > > ntpkeygen, simplify ntp.poly, be able to drop the now oldoldstable? > > runner testing for asciidoc on python 2 support, and also have the > > option of adding type hinting. Type hinting is still unstable in Python. Gonna be years before we can use that. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpvQLlNcKHhK.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Is python2 dead?
Yo Hal! On Mon, 04 Sep 2023 15:46:45 -0700 Hal Murray via devel wrote: > > Rumours of its death are greatly exagerated. > > Thanks. > > Let me try again with maybe closer to what I should have asked? > > Are there any distros that we currently run on that don't support > python 3? RHEL. > I can imagine some places are running really really old software. > If it ain't broke, don't fix it. > But would they be running ntpsec? They are running gpsd, people keep trying to kill Python 2 support in gpsd, and the complaints are pretty quick to arrive. Let's try again in a year. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgphJjkfI_ONs.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Is python2 dead?
Yo Hal! On Mon, 04 Sep 2023 14:15:26 -0700 Hal Murray via devel wrote: > Really really dead? Or maybe just hiding in some dark corner? Rumours of its death are greatly exagerated. > Should we drop support for python2 as part of the next release? > Or announce in the next release that we will drop it as part of the > following release? From RHEL: "The RHEL 8 AppStream Lifecycle Page puts the end date of RHEL 8's Python 2.7 package at June 2024." https://access.redhat.com/solutions/4455511 RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpmVz_jXODnQ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Old email on gitlab
Yo Hal! On Sun, 23 Jul 2023 18:13:36 -0700 Hal Murray via devel wrote: > Author: Hal Murray [...] > I haven't used that email in ages. My profile has been updated. It is in you local git config. > Where is the other address stored and how do I fix it? Here is how I change it: git config --global user.name "Gary E. Miller" git config --global user.email g...@rellim.com Look in the "FILE"s section in "man git-config" for all the places it might be stored. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp0nPzdXqzSJ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Warnings from unity
Yo Hal! On Tue, 20 Jun 2023 12:57:40 -0700 Hal Murray via devel wrote: > Is anybdy familiar with this area? > Is this something I did? Or are others seeing the same problem? > (I might have turned on some more-warnings flag, but I don't think > so.) > > ../../tests/unity/unity.c:984:5: warning: enumeration value > \u2018UNITY_FLOAT_INVALID_TRAIT\u2019 not handled in switch > [-Wswitch-enum] ../../tests/unity/unity.c:1124:5: warning: > enumeration value \u2018UNITY_FLOAT_INVALID_TRAIT\u2019 not handled > in switch [-Wswitch-enum] That usually means there is no "default:" case in a switch. > > > Speaking of warnings, some versions of OpenSSL and/or some compilers > generate this: > > /usr/local/ssl/include/openssl/ssl.h:1491:53: warning: cast discards > "const" qualifier from pointer target type [-Wcast-qual] Simple, just a bad cast. But since it is in a system header, not easy to fix. > I've looked into it a bit and don't understand what's going on. I > think our code is OK. This is passing a string literal through a > maze of macros. I've decided not to spend much time on this since it > doesn't happen with newer OpenSSL and/or compilers. A string literal is (const char *), but you are passing that as a (char *). Just be real sure that string is not modified by the called function. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpVFcNe_S1_e.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: UnicodeDecodeError from tty.readline(), u-Blox 8
Yo Hal!
On Sat, 03 Jun 2023 21:53:34 -0700
Hal Murray via devel wrote:
> Gary said:
> > To open to read binary:
> > tty = open("/dev/ttyACM0", "rb")
> > The line will be binary. Getting just the NMEA out will be fun.
>
> Thanks. That's what I needed.
Good.
> There is no problem getting just the NMEA. I'm using isASCII to
> detect the garbage cases.
Cool.
> I get things like:
> ### Not ASCII 2023 Jun 3, 22:46:41 UTC
> ###
> "$GLG\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\x
> cd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\
> xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd
> \xcd\xcd\xcd$GLGSV,3,3,11,87,43,333,,88,01,306,,90,13,029,*5A"
>
> I get several bogus lines each day. I haven't seen anything other
> then 0xcd in the non-ASCII part.
Weird... Since ttyACM0 is USB, maybe a driver thing.
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpNWqbZhyEPG.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: UnicodeDecodeError from tty.readline(), u-Blox 8
Yo Hal!
On Mon, 29 May 2023 15:22:43 -0700
Hal Murray via devel wrote:
> Can somebody give me a lesson on this area?
>
> The code is:
> tty = open("/dev/ttyACM0")
> forever:
> line = tty.readline()
> a) How do I read mostly ASCII without crashing when there is
> non-ASCII?
To open to read binary:
tty = open("/dev/ttyACM0", "rb")
The line will be binary. Getting just the NMEA out will be fun.
> b) Why is a u-Blox LEA-M8T sending me non-ASCII crap?
Becasue it wants to. Becasue UBX is better than NMEA.
> This is coming from the USB port. It's running in NMEA mode.
> I don't think I have sent it any commands.
From u-blox8-M8_ReceiverDescrProtSpec_UBX-13003221.pdf:
"By default all ports are configured for UBX and NMEA protocols."
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgphJpZk9Bk6j.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
Yo James! On Tue, 07 Feb 2023 22:54:30 -0800 James Browning via devel wrote: > > Can you poke it by hand? > > > Not as such, no. But it is easy for an authorized user to trigger a > scheduled run at GitLab. It's under ci > schedules on the left > sidebar. The coverity scans are not part of the GitLab CI. They run off the GitHub mirror. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpEBDyWEgT7e.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
Yo Hal! On Tue, 07 Feb 2023 18:23:17 -0800 Hal Murray via devel wrote: > Yes, it's reasonably obvious, but only after you find the right URL. Consider it like a game of Adventure. > > I approved your account. > > Thanks. I didn't get any you-were-approved mail. > > Do I have to explicitly sign up for mail about reports? Dunno, go to the Dashboard for you options. > > No. We run the Coverity CI job weekly via a schedule, ... > > I'll work on running Coverity post-merge. > > I agree that running it every merge is overkill. > > A button that says run-now would be nice if we are working on fixing > Coverity problems. Can't object to free... > How does Coverity fit into the release procedure? It does not. > Should we schedule releases after a Coverity run? Probably. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp44FLoIDo0T.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
Yo Hal! On Tue, 07 Feb 2023 14:03:50 -0800 Hal Murray via devel wrote: > I took a look at the Coverity reports for ntpsec. > There are 10 of them. 10 is a small number. We should be able to > fix them all. Good. > The Coverity report that started this thread was actually a bug. My experience is that most of them are worth a good think. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpGmKK7xrYCy.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
Yo Hal! On Tue, 07 Feb 2023 13:20:38 -0800 Hal Murray via devel wrote: > >> OK, I propose to turn on -Wswitch-enum and fix all the warnings I > >> find. Then I/we fix whatever Coverity complains about. If that is > >> too painful, we can back out of -Wswitch-enum. > > Seems good to me. > > OK, I'll start working on it when I get time. No rush, they've been there a while. > > There are so many Coverity warnings about ntpd to worry about theat > > no one will notice a few more or less. > > Any chance we can fix/annotate them all? gpsd eventually crushed them all. Once you get on a roll they are mostly quick fixes. > Is there a web page that describes the /* coverity(mumble) */ stuff? No need, the "mumble" is the error you are blocking. It will be in your face when you look at that one issue. > Can I add a comment in there too, like: > /* coverity(mumble) we handle all the cases */ > Something like that might help somebody understand what's going on. The coverity descriptions are good. Use them. Too many to study,just look at the ones we trip. The decriptions will pretty much match clang. > >> > I'm waiting for somebody to approve me. > > Where? How would I see it? > > > The request was stuck in my spam folder. Looks like someone beat > > me to approving you. > > Thanks. No mail yet. I guess I'll have to go poke around. Don't expect Coverity to nag you. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpzxwWc4Ima1.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
Yo Hal! On Mon, 06 Feb 2023 22:51:02 -0800 Hal Murray wrote: > > I'm waiting for somebody to approve me. > > Where? How would I see it? The request was stuck in my spam folder. Looks like someone beat me to approving you. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp658xvgo4v0.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
Yo Hal! On Mon, 06 Feb 2023 22:51:02 -0800 Hal Murray wrote: > Thanks. > > > Do you have a coverity account? > > https://scan.coverity.com/ > > Then go to "My Dashboard" and "Add project". > > Should we document that? Where? The procedure changes more often than we add cverity users. > It looks like Coverity is running over on github. > Is our copy-to-github stuff documented? Dunno how it works. It just does. > I'm waiting for somebody to approve me. Where? How would I see it? > >> Date: Thu, 02 Feb 2023 05:48:37 + (Wed 21:48 PST) > > It was detected on Feb 5. > > So the turn around is days rather than hours. Yeah. > > So we tell Coverity to ignore the extra defaults. > > OK, I propose to turn on -Wswitch-enum and fix all the warnings I > find. Then I/we fix whatever Coverity complains about. If that is > too painful, we can back out of -Wswitch-enum. Seems good to me. > It may take a few iterations to make Coverity happy and we won't have > great turn-around, but it's not on the critical path. What coverity does is mostly run the code with high warning levels. So if you bump up your warnings you'll see what they see. There are so many Coverity warnings about ntpd to worry about theat no one will notice a few more or less. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpO1BdIxMLRQ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
Yo Hal! On Mon, 06 Feb 2023 20:08:21 -0800 Hal Murray wrote: > >> But then Coverity will barf (DEADCODE) at all the defaults. > > What purpose do they still have? > > None. But we have -Wswitch-default so it will barf if we remove them. > > They would be useful if an illegal value was passed in. At least in > the case that started this thread, the values are coming out of > compile time data and I'm reasonably sure I have the type checking > set up right so I'm not really worried about bogus values. I'd > rather leave the default in with an error message and tell Coverity > it's OK. So we tell Coverity to ignore the extra defaults. > >> I think I'm willing to fix them. Is there any way to run Coverity > >> without waiting for it to get around to scanning our code? > > I think coverity grabs every commit, and does not wait long. > > I don't get the Coverity mail. How do I fix that? The bottom of the > mail you forwarded has a link for you to "manage Coverity Scan email > notifications" so I assume there is some recipe to sign up. I poked > around a bit but didn't find it. Do you remember how you signed up? Do you have a coverity account? https://scan.coverity.com/ Then go to "My Dashboard" and "Add project". > Can you check to see how long it was between when I pushed that > commit and when the mail arrived? Here is the pipeline mail from > that push. Subject: ntpsec | Successful pipeline for master | bd596fa3 > From: GitLab > Date: Thu, 02 Feb 2023 05:48:37 + (Wed 21:48 PST) It was detected on Feb 5. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpLXtIqyE_BS.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
Yo Hal! On Sun, 05 Feb 2023 20:01:13 -0800 Hal Murray wrote: > > Sadly some compilers will always complain if there is no default. > > So I always add a default. > > We turn on -Wswitch-default I like it. > I'd like to turn on -Wswitch-enum > That generates a handful of warnings that I'm willing to fix. I like it. > But then Coverity will barf (DEADCODE) at all the defaults. What purpose do they still have? > I think I'm willing to fix them. Is there any way to run Coverity > without waiting for it to get around to scanning our code? I think coverity grabs every commit, and does not wait long. I think there is a way to force it too. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp_zsybVrQSa.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
Yo Hal!
On Sun, 05 Feb 2023 17:38:49 -0800
Hal Murray via devel wrote:
> 1439 default: {
> 1440 /* There should be a way for the compiler to
> check this. */ 1441 bool once =3D false;
> >>> CID 435753: Possible Control flow issues (DEADCODE)
> >>> Execution cannot reach this statement: "return;". =20
> 1442 if (once) return;/* Avoid log
> file DDoS */
>
> That's some of my new code.
I figured, since a new coverity issue.
> In this case, I'm switching on a enum and have handled all the cases
> so the default "can't happen".
Sadly some compilers will always complain if there is no default. So
I always add a default.
> How do I get the compiler to tell me if I missed an option on a
> switch statement?
From "man gcc":
-Wswitch
Warn whenever a "switch" statement has an index of enumerated type
and lacks a "case" for one or more of the named codes of that
enumeration.
Or the similar -Wswitch-enum
> Of course, the data might get mashed, so the other question is:
> How do I get coverty to not complain about this code?
// coverity[var_deref_model]
That will ignore a var_deref_model message on the net line.
Grep the ntpsec sources, it is used a lot. Maybe over used.
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpMWHqnxVBoL.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: New SHM
Yo Hal! On Fri, 20 Jan 2023 12:20:09 -0800 Hal Murray wrote: > Your current code has 2 1/2 memory barriers. That's the same as my 2 > counter proposal. I rather not take responsibility for the current code. Not mine. And gpsd only has 2 threads, while ntpd has just one. The next solution needs to be multi0thread and multi-reader freindly. > As long as we are mucking in this area, should we take the > opportunity and do a big jump and convert to a new way of doing > things? We have to do both. Maintain back compatibility, and go forward. > Support old and new SHM until we can drop old. How about no new SHM? It is a mess from many angles. The current SHM does not come close to being POSIX compliant. There is no way to fix it the old way. No need for a new solution. A well tested solution already exists. https://xkcd.com/927/ The chrony socket protocol has been doing everything we need here, and more. It is well established, debugged and documented. It needs no locking It supports 32-bit and 64-bit time_t It already has a MAGIC value (sorta like a version. It has much better access control. It supports single writer multiple reader. It avoids all the issues we know, and hate, about SHM. Long past time for ntpd to support chrony sockets. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpztb2qmcm3m.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Mutex and Atomic (was 64 bit time_t on 32 bit systems)
Yo Hal! On Thu, 19 Jan 2023 21:43:08 -0800 Hal Murray wrote: > g...@rellim.com said: > > Sadly, that no longer works on modern CPUs with out of order > > execution. Unless wrapped in a mutex, or atomic, and that is now a > > no-no. > > Do you have a good reference for that? Many ariticle on lwn.net. > I'd like something like a nice blog article that explains things. Sadly work in this area has been slow and disjoint. Following lwn.net is the onely way I know to keep up with it. > What is the new/wonderful way? Even if you do something like a > kernel call with a file handle, deep inside there I'd expect a mutex > to make sure the right thing happens if 2 threads try to do the same > operation at the same time. Many techniques, RCU, Red/Black trees, etc. > Is there a blog type page describing the TIME_BITS stuff? Yes, the gpsd issue: https://gitlab.com/gpsd/gpsd/-/issues/152 Which has links to other sources. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp1WsNprkFo5.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New SHM layout from gpsd
Yo Hal! On Fri, 20 Jan 2023 02:11:29 -0800 Hal Murray wrote: > The 31 bit idea seems strange/ugly to me. How did you decide to do > it that way? For back compatibility. > Why is it better than 32 unsigned bits? Is there some case that > works with 31 bits that breaks with 32? Yeah, 2038. > I think there is a case that works for 32 unsigned that doesn't work > for 31. Consider code that gets updated to use 64 bit time_t but they > forget to update the SHM interface. That will pick up the 32nd bit > and do the right think for another 68 years. No, it will go negative. > An alternative would be to make the new high-bit slots into 64 bits > and make the rule use-them, ignore the old slot. That would eat 2 > more dummy words. Which then breaks 64-bit compatibility. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgppkjYVZiu3F.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: I am bidding for power and have yet more branches for consideration.
Yo James! How about you respond to my pending reviews dirst? On Thu, 19 Jan 2023 13:27:54 -0800 (PST) James Browning via devel wrote: > If I were a maintainer of the NTPsec group, I could merge the > following branches on my own. If only a developer, I could still > approve other people's merge requests. > > > https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1304 > !1304 - Enable debugging symbols by default, with an option to > !disable them. > > > https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1305 > !1305 - Update the NEWS.adoc file with things that should be in > !it that have not made it there. > > > https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1272 > !1272 - Adds a preempt option for clocks, making them act as if > !the pool option added them. > > > https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1299 > !1299 - Change the shared memory refclock to be compatible with > !the latest gpsd. > > > https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1290 > !1290 - Use the ntp.poly module, check it, and fix polychr() > !when it does not behave correctly. > ___ > devel mailing list > devel@ntpsec.org > https://lists.ntpsec.org/mailman/listinfo/devel RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpFLK47fhrGm.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Greg! On Sun, 15 Jan 2023 09:42:06 -0500 Greg Troxel wrote: > > You can always build bad .o. But good practice is to build all .o > > in a program or binary with the same setting. Otherwise a huge > > number of ways to fail. That is why all gpsd c files start with: > > > > #include "../include/gpsd_config.h" // must be before all includes > > > > I was asking about an installed library built one way, and a program > built another. It seems like they will have DT_NEEDED on two > different libc versions, which will end up somewhere between erroring > at start and UB. Um, lost me. The new _TIME_SIZE_BITS means only one libc is needed. You keep thinking it needs two. > How are you going to manage building gpsd to match the time_t size > choice made in dbus and libusb? Don't need to. dbus can use whatever time_t it wants, different from the one gpsd uses, as long as time_t is not passed as a binary between the two. gpsd does not pass binary time_t to either one. Unless you can point out somewhere I miised a bianry call? gpsd passes dbus time as a double: DBUS_TYPE_DOUBLE, , gpsd only uses libusb for the Garmin 18usb which only speaks native usd. But the protocol is Garmin Binary. No time_t anywhere. > How is anyone else going to manage > this in the world of individual compilation unit choice? Linux has been doing this a long time. Not my first choice, but rare that glibc or Linus takes what I say seriously. If you are sure they are wrong, I'd love to watch you convince them the error of their ways. I'll get popcorn. > The only > paths I can see are > > a distribution choosing a setting for all programs Like all the BSDs. Except, they don't always. > setting up two hierarchies of lib/bin for building each way And yet, the folks at glibc disagree, at least as far as time_t. For other things, yes, my Gentoo has many separate /usr/lib depending on all sorts of things. All installed at the same time, and it just works. Close to a dozen on one of my hosts. Could be much more. So it can be done, is very frequently done, but is irrelevant to the gpsd issue at hand. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp9lTGoV2_Ge.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Greg! On Sat, 14 Jan 2023 09:00:58 -0500 Greg Troxel wrote: > "Gary E. Miller" writes: > > >> > 1: 64-bit time_t with 64-bit ints: > >> > All known 64-bit distros (?) > >> > Works after 2038 > >> > No change required. > >> > >> Do you mean "int64_t"? > > > > No, I meant, should have said, LP64: 32-bit ints, 64 bit pointers, > > as in x86_64. > > The size of int isn't really the question. Thus my correction above. > It's the size of the type > used for time_t, which is an implementation choice. POSIX requires > only "time_t shall be an integer type.". Yes. > However, my memory was fuzzy. Historically, time_t was "long". On > the PDP-11, int was 16 bits and long was 32 bits. It remained long > on most 32-bit machines (ILP32) Uh, no. time_t has been in t on Linux for decades. But, I don't care how we got here. I just care where we are and how to move forward. We already agreed we categorized all the common current cases, and the way to move forward that breaks nothing is already in git head. > >> have only seen "int" be 64 bit on Alpha. > > > > And now Intel. > > I meant in the standard, normal, ABI that is generally in use. I thought we were enumerating all likely cases, not just the "normal". But, the recent gpsd patches handle that too, so no worries. > > That is, the case where default time_t is int (int32_t), and > > overridden time_t is int64_t. > > That needs a prior ifdef linux and/or if defined(_TIME_SIZE_BITS). Which is exactly what the new code in git head does. Except it cannot ifdef linux since glibc runs on more than linux. > My > point is that this whole thing is a workaround for the unusual feature > of a dual API where it is normal for different programs to make > different choices Which is nack to exactly where this started: https://gitlab.com/gpsd/gpsd/-/issues/152 And now completed. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgppTklN9rWYM.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Greg! On Sat, 14 Jan 2023 09:26:45 -0500 Greg Troxel wrote: > >> Do the same thing that BSDs did: change time_t to in64_t and > >> change the syscall codepoints. (Except you have to define > >> something.) > > > > No, not change time_t. Add an incompatible alias to time_t. > > When you compile with -D _TIME_SIZE_BITS=64, doesn't it cause time_t > to be a different type for that compilation? Yes, This is discussed in the issue: https://gitlab.com/gpsd/gpsd/-/issues/152 #ifdef __USE_TIME_BITS64 typedef __time64_t time_t; #else typedef __time_t time_t; #endif > > >> Unlike the BSD approach, also support -- even on post-change > >> systems -- compiling code that uses int for time_t, and using the > >> old codepoints. > > > > Uh, lost me? I thought BSD had a flag day and just changed all > > time_t to int64_t and broke all back compat? > > Not quite. > > time_t was changed to int64_t > > all syscalls that have time_t in the ABI got a new number > > compat syscalls were added that use the old ABI, using the old > numbers. > > Thus: > > newly built programs see time_t as int64_t and use the new syscalls > > binaries from Before, which have code to use time_t as 32 bits, use > the compat syscalls and thus continue to work (until 2038). For > example you can boot a NetBSD 6 kernel on a system with 5 userland > and packages built under 5 and it all works fine. > > nothing was done about ABIs like the gpsd/ntpd/chrony ones. So you > need all of those programs consistently from before or after. > > Aside from programs that have these inter-program ABI with time_t, > everything is ok, even with a mix of old and new binaries. Uh, no. You can not mix SHM used by programs built before and after the switch. Beacuse the size and layout differes. Thus, a flag day, thus breakage. > > Sadly, Linux did not do that. I doubt they twill change course > > now. > > But we can choose to always define _TIME_SIZE_BITS=64 when building on > Linux. That's what I meant by ignore the ability to compile in the > old way: just don't. And thus break all existing binaries. Nope, not gonna happen. BSD hates its users, not Linux. > >> If all of > >> gpsd/chronyd/ntpsec: > >> > >> By default (on Linux only) check if the flag to get "time_t is > >> int64_t" is available and use it > > > > Which means old and new can't mix. Not an option. > > I think it's a perfectly reasonable option. Packaging systems > (distributions) are going to have to deal with this in general. Like they have with python 2.7, openssl 3. ffmpeg? No, this is not a solved problem. Don't pretend it is. > > NetBSD just blew off binary compatibility. Linux does not do that. > > > > Not at all, see above. Wrong, see above. > Binary compat is excellent in this case. Except the case we care about SHM and chrony socket. > > Everything is so simple in BSD land, where you can tell your users > > to do as you say. > > That's unfair, and this discussion has crossed into no longer useful. I agree. The change is already made. > I have no memory of pain from the transition. Short memory. > People basically > upgraded packages from ones built for 5 to ones built for 6, just as > they typically do when upgrading and went from all old to all new, Sadly Gentoo, and some other Linux do not have versions. And even the ones that do still are trying to handle python 2.7, openssl 3, ffmpeg, etc. > The problem here is because various distributions will change to the > new kernel at various times but there is an idea that there is a > single Linux ABI. Corrext. Things change randomly, and there is no single Linux ABI. That is my world, I'm stuck with it. > Still, if the syscalls that programs see when > building with _TIME_SIZE_BITS=64 have new codepoints: > > old and new binaries should run on new kernels > > only old binaries will run on old kernels > > programs with non-syscall ABIs with time_t need to either > > be consistently old or new > > do something kludgy Which totally ignores the problem at hand: the size of SHM and chronyd structs. > I don't see it as a problem to expect 3 programs to be all old or all > new. For you, in BSD land, but for us in the real world... > But as long as the accomodations for this are all #idef linux, I don't > really care. Amazing enough, not required. And already done. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp80w5aOK3wN.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Greg! On Sat, 14 Jan 2023 09:32:03 -0500 Greg Troxel wrote: > "Gary E. Miller" writes: > > >> Which magically changes references to syscalls that use time_t, in > >> the entire binary, to the new ones? > > > > Uh, once again, no. No "versioning". No syscalls are changed. > > > > Every existing syscall that uses 32-bit time_t now has a 64_bit > > twin. > > And the new ones have new codepoints? Yes. > New names that are user-facing? No. > Does one have to ifdef _TIME_SIZE_BITS in source code and call > gettimeofday64? No. > Or in a program with _TIME_SIZE_BITS there is some #define so that > gettimeofday in the sources maps to the int64_t version? Yes. From /usr/include/sys/time.h: #ifndef __USE_TIME_BITS64 extern int gettimeofday (struct timeval *__restrict __tv, void *__restrict __tz) __THROW __nonnull ((1)); #else # ifdef __REDIRECT_NTH extern int __REDIRECT_NTH (gettimeofday, (struct timeval *__restrict __tv, void *__restrict __tz), __gettimeofday64) __nonnull ((1)); # else # define gettimeofday __gettimeofday64 # endif #endif > This is what has been unclear Maybe to BSD people... > > So old and new binaries just work. > > That has to mean that the old syscall number leads to a syscall with > the old behavior and the new syscall has a new number. That's what I > meant by versioned. That is not how I use "versioned". In Linux land "versioned" applis to the version number on shared libraries. > >> What happens if a library defines D_TIME_BITS 64 and makes > >> syscalls, and a program which is unaware of this defines 32 and > >> also makes sycalls? Or is the syscall switch per .o because the > >> names are #defined? > > > > That can never happen. > > I don't see how different .o files are prohibited from having > different _TIME_SIZE_BITS, unless it leads to a link failure. You can always build bad .o. But good practice is to build all .o in a program or binary with the same setting. Otherwise a huge number of ways to fail. That is why all gpsd c files start with: #include "../include/gpsd_config.h" // must be before all includes > Are there then new and old libc? Of course. glibs versions change with the days of the week. When a program is linked, it is matched to one and only one glibc version. libc proliferate like bunnies. Thus the need for them to be versioned. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpqLRsDz09x0.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Hal! On Sat, 14 Jan 2023 08:30:08 -0800 Hal Murray wrote: > Does this problem go away (for another 68 years) if on 32 bit systems, >we change the time_t in SHM to uint32_t? No. Some ILP32 already moved to int64_t for time_t. Like all the BSDs. > The SHM layout stays the same so all combinations of old/new will > continue to work today. No. Some ILP32 already moved to int64_t for time_t. > When the top bit turns on in 2038, recent builds will fill with 0s > rather than sign extend when converting to a 64 bit time_t which is > what we want. And breaking a lot of existing stuff. BSD's like to break stuff, but not Linux. > Old code using SHM and 32 bit time_t will do whatever in 2038. I > hope any interesting code will be recompiled by then. Did you see the FAA NOTAM system that broke is running on Solaaris? Care to guess the last update to that system? > (Will we still > be running Intel instruction sets? ARM?)If there is enough code > that hasn't been updated, it wouldn't surprise me if somebody added a > hack that said something like dates older than 1950 are really next > era sp add 0x1 seconds when converting to text. I'm still running and "maintaining" Pentiums from the '90s that have not updated is a long time. > There is a potential problem. If a 32 bit OS/Distro has already > converted to 64 bit time_t then we will break things if we convert to > uint32_t. So the decision to switch from time_t to uint32_t is more > complicated that are we running on a 32 bit system. I already pushed to gpsd git head a soltution that works in all cases. And breaks nothing. Unless you have a solution that breaks nothing, and improves something, we are already done. > How many 32 bit OSes do we run on? Your guess ignores a lot of OS that gpsd runs on. But off topic. The CPU arch is not relavant. Only the size of time_t is. And if a system supports 2 sizes of time_t at the same time. > In case nobody noticed, I hacked a sizeof(time_t) into NTPsec's > configuration stuff a while ago. So you can get the answer by > looking in a handy config.h Not good enough. You need to set these for ILP32 glibc 2.34 and up: #define _TIME_BITS 64 #define _FILE_OFFSET_BITS 64 See the gpsd issue for more details that you missed: https://gitlab.com/gpsd/gpsd/-/issues/152 As far as I am concerned, the gpsd side of this is done. Nothing existing is broken (more), everything works going forward. Nothing to improve (?). RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpRP9MXF0O0W.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Greg! On Fri, 13 Jan 2023 19:46:15 -0500 Greg Troxel wrote: > "Gary E. Miller" writes: > > >> Does Linux version syscalls? In NetBSD, we change the codepoints > >> when the ABI changes, and there is kernel code to implement the old > >> codepoint (but no header support) so old binaries still work. I > >> think Solaris does this too. > > > > For some definition of "version". There is one set of syscalls for > > 32-bit time, including time in file system metadata. And another > > for 64 bit time. And only since late 2021. > > > >> I don't really follow "compile time option". The size of time_t is > >> part of the kernel ABI. > > > > Yes. BOTH sizes of time_t are part of the 32-bit linux kernel ABI. > > > > Wow. So people have to, specially for Linux, version all interfaces > that use time_t. That's not just gpsd, but all sorts of things. > > >> Or does the kernel use sys/types.h? > > > > Not relevant. > > But it has codepoints for syscalls with each flavor. > > >> The headers in sys are semantically part of the kernel, regardless > >> of how they are sliced up in packaging/maintenance. > > > > Sort of. sys/tyoes.h is part of musl or glibc. > > Yes, but it has to match the kernel. That's why I said semantically > part of. > > >> shmTime is simply using time_t, so it inherits the definition of > >> time_t from the compilation environment. POSIX says that > >> is required to define time_t: > >> > >> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_time.h.html > >> > > > > Yes. And it does. Selected by D_TIME_BITS 64 > > Which magically changes references to syscalls that use time_t, in the > entire binary, to the new ones? Uh, once again, no. No "versioning". No syscalls are changed. Every existing syscall that uses 32-bit time_t now has a 64_bit twin. So old and new binaries just work. I'm not gonna defend, that is what glibc and Linus negotitated. > What happens if a library defines D_TIME_BITS 64 and makes syscalls, > and a program which is unaware of this defines 32 and also makes > sycalls? Or is the syscall switch per .o because the names are > #defined? That can never happen. > >> > How does ntpd know what size time_t to use? And thus know the > >> > size of shmTime? How do we know portably, preserving backwards > >> > and forwards compatibility? > >> > >> It builds against the installed headers and just uses time_t. > > > > Yes, but which one? The 32-bit one, or the 64-bit one? > > I see. Well, I see several sane paths: > > Make a new api in json to work around the Linux approach. Only use > it on Linux, with it just serializing the struct. I really don't > like this. We will need a new API for chronyd. For now, I'm trying to save existing binaries. When we get a new chinryd API, I'd like gpsd, ntpd and chonryd to support it, but that only works going forward, which will take close to a decade to all migrate. I need a solution this week. My shmTime change gets there right away. At least for ntpshmmon, ntpd, etc. > The entire time community agrees that code will be built 64 if > that's supported on the build system. Yeah, and how to get there, while being back compatible with binaries. My shmTime idead does that. This week. > But then the "linux is one > ABI" is falling apart and it's going to be a mess as there will be > old code. No. You misunderstand the Linux ABI. Nothing is falling apart. Execpt the gpsd to chronyd interace. > So you have a rule that gpsd/ntpd/chronyd need to all be > new or all be old. And now you know why people hate *BSD. Liniux does not have "flag days" that piss everyone off. > On Linux, redefine the struct to be int64_t instead of time_t. add > options to gpsd/ntpd/chrony to move to the new way. After a bit > take out the option and int64_t is the answer. After time_t is > int64_t on all linux systems rename it back to time_t. And break back compatibility. Only as a last resort. Nad last resort is not required. > I think the third option is the way to go. That way each program can > use 32/64 as it is available but start using the new ABI now. It will > interop and as each program is built for 64 it becomes 2038-safe. Richard liked my idea, you did not discuss it. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpPJFeq0xfcu.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Richard! On Fri, 13 Jan 2023 19:08:10 -0600 Richard Laager via devel wrote: > > So, looking only at option 4. The one that we can improve. > > I think you have captured the options correctly. Plus the corrections from Greg. > > That maintains compatibility with existing SHM users. > > That works with existing SHM users until 2038. > > That works with modified SHM users until the end of 64 bit time. > > I like it! In broad strokes, this seems like the right solution. Way > better than my ideas about trying to use a magic and detect where it > is. Good. > There is another time_t field in the struct. Does that also have to > change? Yeah. Missed that. time_t clockTimeStampSec; And: time_t receiveTimeStampSec; > Should top_time_t be unsigned? Either way. The top bit is never set. I would like to follow the existing as much as possible (time_t is int). > The original 64-bit time_t will be > signed, but you know that it is always positive. You put the lower 31 > bits in the original field (which makes sense, as you don't want the > 32nd bit to go in the sign bit spot of the original field). That > leaves 64 - 31 = 33 bits to save. One of those is the sign bit. Since > we know it is positive, we can drop that. So top_time_t should be > unsigned to make that clear. I'll see what is easist to avoid compiler warnings with. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpyXBXpAxi4I.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Greg! On Fri, 13 Jan 2023 20:20:48 -0500 Greg Troxel wrote: > Greg Troxel writes: > > I just had a realization. What Linux is doing is more or less: > > Do the same thing that BSDs did: change time_t to in64_t and change > the syscall codepoints. (Except you have to define something.) No, not change time_t. Add an incompatible alias to time_t. > Unlike the BSD approach, also support -- even on post-change systems > -- compiling code that uses int for time_t, and using the old > codepoints. Uh, lost me? I thought BSD had a flag day and just changed all time_t to int64_t and broke all back compat? > We could just treat the Linux approach like the BSD one and try ignore > the ability to compile in "time_t is int" mode. Sadly, Linux did not do that. I doubt they twill change course now. > If all of > gpsd/chronyd/ntpsec: > > By default (on Linux only) check if the flag to get "time_t is > int64_t" is available and use it Which means old and new can't mix. Not an option. > Have, for now, a --without to say "don't look for and use the define > to make time_t is int64_t". No need with my proposed shmTime idea. > Each distribution/packaging system uses the without until all > programs have an update with the above, and then flips them all off > at once. Yeah, which is why we still don't have puthon 3, openssl 3, or IPv6. Bad idea. My shmTime idea is forward and backward compatible. No flag day, not rebuild the world day. > We do know all this code works fine when > built in a "time_t is int64_t" environemnt from the last 9 years of > use on NetBSD. NetBSD just blew off binary compatibility. Linux does not do that. > then way, we end up just using the time_t is int64_t, with no options > and no grossness, after some number of years. Everything is so simple in BSD land, where you can tell your users to do as you say. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpTZFRXAXMHO.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Greg! On Fri, 13 Jan 2023 19:55:47 -0500 Greg Troxel wrote: Sorry, you correctly point out I was sloppy and mistakes in nomenclature. See below for more. > "Gary E. Miller" writes: > > > 1: 64-bit time_t with 64-bit ints: > > All known 64-bit distros (?) > > Works after 2038 > > No change required. > > Do you mean "int64_t"? No, I meant, should have said, LP64: 32-bit ints, 64 bit pointers, as in x86_64. > Are there really Linux systems where "int" is 64 bits?, on x86_64? Intel supports ILP64: https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-guide-linux/top/compiling-and-linking/ilp64-support.html gcc also supports ILP64. But let's ignore that for now. Until someone complains... > have only seen "int" be 64 bit on Alpha. And now Intel. > > 2: 64-bit time_t with 32-bit ints: > > All *BSD (?) > > Works after 2038 > > No change required. > > I suspect most BSD. Certainly NetBSD has "int64_t" as time_t, on all > CPU types, i386, x86_64, alpha (as the three representatives). My suspicion as well. I don't care to nail it down exactly, the header files "do the right thing". > > 3: 32-bit time_t with 32-bit ints, No #define to get 64-bit time_t > > glibc version 2.33 and before > > Fails in 2038 > > No change possible > > > > 4: Optional 64-bit time_t with 32-bit ints. #define to get 64-bit > > time_t glibc version 2.34 and later > > Works after 2038 > > Incompatible with unmodified chrinyd, ntpd, htpshmmon, etc. > > Fix possible. > > Sure, but isn't this pretty much all Linux computers, except on Alpha? I meant, should have said, ILP32, as in x86. Thus all 32-bit linux distros that use glibc prior to 2.34. > int is not guaranteed to be 32 bits. It is 64 bits on Alpha. I don't care. We need to match existing shmTime structure to the byte. As in case 3, time_t is an int, so we need to be an int, whatever an int is. > So this is guarded on "time_t is the same type as int32_t"? And also > "time_t is int64_t, but it's Linux with a define"? No. Guarded by #ifdef _TIME_SIZE_BITS == 64 That is, the case where default time_t is int (int32_t), and overridden time_t is int64_t. > And NOT for "the system time_t type is int64_t, with no funny > business?" Yes. > I lean to favoring a non-icky post-transition state. I all ears. Then we have to solve chrony sockets. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpetr3T38N8D.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Greg! On Fri, 13 Jan 2023 19:33:35 -0500 Greg Troxel wrote: > [dropping ntpsec because they bounced my mail] > > "Gary E. Miller" writes: > > >> but int is ok in > >> practice, on ILP32. On IP16L32, it's not, but we aren't building > >> for PDP-11 any more :-) > > > > What is ILP32? Or IP16L32? > > ILP32 means int, long and pointer are all 32 bits. Like the vax, and > i386. > > LP64 means long/* are 64, and by implication int is 32. Like x86_64, > sparc64, aarch74 > > ILP64 means int is also 64. Like alpha. > > IP16L32 I just made up; 16-bit ints and pointers, 32 longs. That's > the UNIX ABI on PDP-11. Interesting. I see the glibc headers files use that notation. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpdVLZzeHg0k.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo All!
Looks like there are four cases to support with shmTime:
1: 64-bit time_t with 64-bit ints:
All known 64-bit distros (?)
Works after 2038
No change required.
2: 64-bit time_t with 32-bit ints:
All *BSD (?)
Works after 2038
No change required.
3: 32-bit time_t with 32-bit ints, No #define to get 64-bit time_t
glibc version 2.33 and before
Fails in 2038
No change possible
4: Optional 64-bit time_t with 32-bit ints. #define to get 64-bit time_t
glibc version 2.34 and later
Works after 2038
Incompatible with unmodified chrinyd, ntpd, htpshmmon, etc.
Fix possible.
So, looking only at option 4. The one that we can improve.
I had over looked the "int dummy[8]" in shmTime that Richard pointed out.
CUrrently gpsd has set those fields to 0.
In that case, and only that case, change shmTime as follows:
From:
struct shmTime
{
[...]
time_t receiveTimeStampSec;
[...]
int dummy[8];
};
To:
struct shmTime
{
[...]
// because we use 64-bit time_t, but ntpd expects 32-bits
// ignore the sign bit
int receiveTimeStampSec;// lower 31-bits of 64-bit time_t
[...]
// use the first dummy, previously zero
int top_time_t; // upper bits of 64-bit time_t
int dummy[7];
};
Before 2038, top_time_t will always be zero.
After 2038, until 2106, top_time_t will be always one.
That maintains compatibility with existing SHM users.
That works with existing SHM users until 2038.
That works with modified SHM users until the end of 64 bit time.
Thoughts?
No ideas about chronyd sockets yet.
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpwMJMDm7uud.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Hal! On Fri, 13 Jan 2023 13:50:23 -0800 Hal Murray wrote: > I'm missing the big picture. I've been assuming that gpsd and ntpsec > and everybody else will use time_t from the system header files. > (without tweaking anything) A valid assumption, until now. glibc on 32-bit, now tells us wwe MUST "tweak" to be 2038 compliant. > I've been assuming the problem will just go away as distros that > support 32 bit systems will update their (default) time_t to 64 bits. Bad assumption. Linus is very insistent on backward ABI compatibility, so glbic decided the way forward if dual track. > If 2038 rolls around and a distro is still using 32 bit time_t, gpsd > is not going to be one of their major problems. The distros using glibc 2.34 and up, are 2038 compliant, it is gpsd that is not. Until we "twak". > [Context was read-only SHM] > > Sadly, that no longer works on modern CPUs with out of order > > execution. Unless wrapped in a mutex, or atomic, and that is now a > > no-no. > > I was assuming appropriate memory barriers. As I said, those are now a no-no. > What's no-no about atomics? I causes cache flushes. A 96 core CPU has a huge number of caches to flush. > Mutexes seem complicated when shared by 2 programs. Yes. Locking is a bitch. Thuse the need to go to multi-reader, which probably means chronyd had it (almost) right. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp5gzUopynPe.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo James! On Fri, 13 Jan 2023 13:43:38 -0800 (PST) James Browning wrote: > > On 01/13/2023 1:06 PM PST Hal Murray wrote: > > > > > > If we make any changes to SHM, we should switch to a setup where > > the memory is read only. The idea is to allow multiple readers. > > > > The trick to implementing that is to have 2 counters. > > X and Y are initialized to the same value. > > The writer bumps X, updates the data, then bumps Y. > > The reader grabs Y, grabs the data, then grabs X. > > If X and Y are the same the data is valid. If not, try again. > > I've heard you mention this before, and I specced it > by calling them bookends instead and sticking them at > opposite ends of a 4KiB page-sized struct. How do you force 4kB page size? Or 4kB alignment? Maybe the kernel is using hug pages? On a modern CPU, you have no way to force what gets written first. You used to me able to depend on the write order of memcpy(), but not true for a while. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpSuMZt5dje5.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Hal! On Thu, 12 Jan 2023 23:15:25 -0800 Hal Murray wrote: > g...@rellim.com said: > > Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit > > time_t on 32-bit Linux without much work. > > What does "without much work" mean? See commit 19d76e95312b03028752d57e76098d56adac63d9 #define _TIME_BITS 64 #define _FILE_OFFSET_BITS 64 That's not much work. > How does gcc/clang/whatever decide if it is using 32 or 64 bits for > time_t? gcc and clang do not care, what matters is sys/time.h. That file decides based on the presence, or abscense, of: #define _TIME_BITS 64 #define _FILE_OFFSET_BITS 64 > What do I do if I want to use the one the distro didn't pick? You do nothing that you did not already always do: use time.h RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpJcBbbx8JFQ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Hal! On Fri, 13 Jan 2023 13:06:28 -0800 Hal Murray wrote: > If we make any changes to SHM, we should switch to a setup where the > memory is read only. The idea is to allow multiple readers. And how do we do that? Without mutexes or atomics? The "new normal" is to avoid those because they turn a 96 core system into a 1 core system. The chrony socket is multiple readers. I think. I really wish ntpd supported chrony sockets, but those need fixing too for time_64_t. > The trick to implementing that is to have 2 counters. > X and Y are initialized to the same value. > The writer bumps X, updates the data, then bumps Y. > The reader grabs Y, grabs the data, then grabs X. > If X and Y are the same the data is valid. If not, try again. Sadly, that no longer works on modern CPUs with out of order execution. Unless wrapped in a mutex, or atomic, and that is now a no-no. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpy_fWwKPxU1.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Greg! On Fri, 13 Jan 2023 07:11:49 -0500 Greg Troxel wrote: > "Gary E. Miller" writes: > > > Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit > > time_t on 32-bit Linux without much work. > > Interesting to hear; I had assumed time_t on Linux was changed long > ago to int64_t. Nope, not yet. > Does Linux version syscalls? In NetBSD, we change the codepoints when > the ABI changes, and there is kernel code to implement the old > codepoint (but no header support) so old binaries still work. I > think Solaris does this too. For some definition of "version". There is one set of syscalls for 32-bit time, including time in file system metadata. And another for 64 bit time. And only since late 2021. > > This is no problem for newer musl on 32-bits. An int is 32-bits and > > time_t is 64. Assuming all clients use the same version musl. > > > > This is a problem for glibc on 32 bits. And int is 32-bits, but > > time_t is a compile time option (32 or 64 bits). > > I don't really follow "compile time option". The size of time_t is > part of the kernel ABI. Yes. BOTH sizes of time_t are part of the 32-bit linux kernel ABI. > Is it specified separately in the kernel sources No, kernel sources support 32-bit and 64-bit time syscalls at the same time. > and in whatever > sources lead to sys/types.h? No. time_t is in syst/time.h, selected by D_TIME_BITS 64 > Or does the kernel use sys/types.h? Not relevant. > The headers in sys are semantically part of the kernel, regardless of > how they are sliced up in packaging/maintenance. Sort of. sys/tyoes.h is part of musl or glibc. > shmTime is simply using time_t, so it inherits the definition of > time_t from the compilation environment. POSIX says that > is required to define time_t: > > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_time.h.html Yes. And it does. Selected by D_TIME_BITS 64 > so I think gpsd has to just assume that's true, It is true, but has two incompatible truths. > and if there's a > system where the kernel size for time_t doesn't match the installed > header, that just needs to be fixed. It is handles by using 2 distinct syscall type. One for 32-bit and one for 64-bit. > > How does ntpd know what size time_t to use? And thus know the size > > of shmTime? How do we know portably, preserving backwards and > > forwards compatibility? > > It builds against the installed headers and just uses time_t. Yes, but which one? The 32-bit one, or the 64-bit one? > Of course binaries are not portable across systems with different > choices for time_t. Those are different ABIs. Bout our problem is incompativble SHM and sock on the same ABI. > > In hindsight, maybe shmTime should have started with a 1 char > > version field,or magic field. But, no such luck. > > Probably time_t should have just been changed to int64_t, no option, > and syscalls should have been versioned so old binaries work :-) For some reason Linus does not take out sugggestions... > > Options (for 32-bit only): > > > > 1. Do nothing, stick with 32-bit time_t. Fail in 2038. > > How do you "stick with it" if sys/time.h changes on systems configured > for int64_t? Bad conclusion, based on incorrect assumption. The same sys/time.h can lead to either 32-bit or 64-bit time_t. > > 2. Allow 64-bit time_t and let incompatible ntpd fail. > > How do you "allow"? By setting -D_TIME_BITS=64 > > 3. Add run time options to gpsd and ntpd to specify time_t size. > > That's crazy. Sometimes you gotta accept crazy. But I hope not to. > > 4. gpsd and ntpd always use 64-bit time_t going forward. Admin > > needs to mix and match. > > How can you use a type different from what the kernel is using? Easy, when the kernel uses both types at the same time. > > 5. 1st process to open SHM(0) wins, the other process checks the > > size to know the contents. > > That seems messy. Yup. > > 6. Create a new way to pass time from gpsd to ntpd and chronyd. Which may have other benefits. > Indeed, the int in ntpshm should be suseconds_t, I'm pretty sure this predates suseconds_t. but int is ok in > practice, on ILP32. On IP16L32, it's not, but we aren't building for > PDP-11 any more :-) What is ILP32? Or IP16L32? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpbmhQEs6pDt.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Fw: ✘64-bit time_t on glibc 2.34 and up
Yo All!
Greg is not on devel@ntpsec, and asked me to cross post this for him.
See below.
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
Begin forwarded message:
Date: Fri, 13 Jan 2023 07:11:49 -0500
From: Greg Troxel
To: "Gary E. Miller"
Cc: gpsd dev ,
Subject: Re: ✘64-bit time_t on glibc 2.34 and up
"Gary E. Miller" writes:
> Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit
> time_t on 32-bit Linux without much work.
Interesting to hear; I had assumed time_t on Linux was changed long ago
to int64_t.
> Extracted from include/ntpshm.h:
>
> struct shmTime
> {
> int mode;
> volatile int count;
> time_t clockTimeStampSec;
> int clockTimeStampUSec;
> time_t receiveTimeStampSec;
> int receiveTimeStampUSec;
> int leap; // not leapsecond offset, a
> notification code int precision; // log(2) of source
> jitter int nsamples; // not used
> volatile int valid;
> unsignedclockTimeStampNSec; // Unsigned ns timestamps
> unsignedreceiveTimeStampNSec; // Unsigned ns timestamps
> int dummy[8];
> };
>
> Note the struct size depends on the size of an int, and the size of
> time_t.
Does Linux version syscalls? In NetBSD, we change the codepoints when
the ABI changes, and there is kernel code to implement the old codepoint
(but no header support) so old binaries still work. I think Solaris
does this too.
> This is no problem for newer musl on 32-bits. An int is 32-bits and
> time_t is 64. Assuming all clients use the same version musl.
>
> This is a problem for glibc on 32 bits. And int is 32-bits, but time_t
> is a compile time option (32 or 64 bits).
I don't really follow "compile time option". The size of time_t is part
of the kernel ABI.
Is it specified separately in the kernel sources and in whatever sources
lead to sys/types.h? Or does the kernel use sys/types.h? The headers
in sys are semantically part of the kernel, regardless of how they are
sliced up in packaging/maintenance.
shmTime is simply using time_t, so it inherits the definition of time_t
from the compilation environment. POSIX says that is
required to define time_t:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_time.h.html
so I think gpsd has to just assume that's true, and if there's a system
where the kernel size for time_t doesn't match the installed header,
that just needs to be fixed.
> How does ntpd know what size time_t to use? And thus know the size of
> shmTime? How do we know portably, preserving backwards and forwards
> compatibility?
It builds against the installed headers and just uses time_t.
Of course binaries are not portable across systems with different
choices for time_t. Those are different ABIs.
> In hindsight, maybe shmTime should have started with a 1 char version
> field,or magic field. But, no such luck.
Probably time_t should have just been changed to int64_t, no option, and
syscalls should have been versioned so old binaries work :-)
It is true that e.g. on NetBSD a gpsd and an ntpd that were compiled on
opposite sides of the time_t type change (2012) will not interoperate.
> Options (for 32-bit only):
>
> 1. Do nothing, stick with 32-bit time_t. Fail in 2038.
How do you "stick with it" if sys/time.h changes on systems configured
for int64_t?
> 2. Allow 64-bit time_t and let incompatible ntpd fail.
How do you "allow"?
> 3. Add run time options to gpsd and ntpd to specify time_t size.
That's crazy.
> 4. gpsd and ntpd always use 64-bit time_t going forward. Admin needs
> to mix and match.
How can you use a type different from what the kernel is using?
> 5. 1st process to open SHM(0) wins, the other process checks the size
> to know the contents.
That seems messy.
> 6. Create a new way to pass time from gpsd to ntpd and chronyd.
> Also note, chrony sockets have a similar problem:
>
> #define SOCK_MAGIC 0x534f434b
> struct sock_sample {
> struct timeval tv;
> double offset;
> int pulse;
> int leap; // notify that a leap second is upcoming
> int _pad;
> int magic; // must be SOCK_MAGIC
> };
>
> Where timeval is:
>
> struct timeval {
> time_t tv_sec;
> suseconds_t tv_usec;
> };
> ```
Indeed, the int in ntpshm should be suseconds_t, but int is ok in
practice, on ILP32. On IP16L32, it's not, but we aren't building for
PDP-11 any more :-)
To reduce spam only list members may post to this list. If you think
that your messages are being rejected in error please contact
devel-ow...@ntpsec.org.
--- Begin Message ---
"Gary E. Miller" writes:
> Recent glibc (2.34 and up)
Re: My ignorance was Re: ✘64-bit time_t on glibc 2.34 and up
Yo James! On Fri, 13 Jan 2023 08:49:34 -0800 (PST) James Browning wrote: > > This makes my head hurt... > > IIRC there are a few users of those interfaces; linuxptp, gpsd, > classic NTP, NTPsec, and chrony. Multiplied by the number of distros that carry each, and update on their own schedules. Did you hear the FAA NOTAM system that crashed yesterday runs on Sun Solaris? > I would jokingly suggest > something like the following as a replacement. We can't really replace, it would have to be in parallel, and hope the old one dies out before 2038. I prefer Richard's idea. > Purely based on > the misassumption that SHM internally works on page-sized blocks Wrong assumption. Can we stick to nown facts? > and probably via POSIX shared memory which would allow names. If we add a 3rd time transfer method, I'd rather go with sockets, like gpsd now talks to chronyd. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgphM4TA2XDOH.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
Yo Richard! On Fri, 13 Jan 2023 13:43:06 -0600 Richard Laager wrote: > On 1/12/23 19:10, Gary E. Miller via devel wrote: > > How does ntpd know what size time_t to use? And thus know the size > > of shmTime? How do we know portably, preserving backwards and > > forwards compatibility? > > > > In hindsight, maybe shmTime should have started with a 1 char > > version field,or magic field. But, no such luck. > > Here are some thoughts on various options. > > I don't know what valid values of "mode" are. I snipped that part from include/timehint.h: int mode; /* 0 - if valid set * use values, * clear valid * 1 - if valid set * if count before and after read of values is equal, * use values * clear valid */ Clear as mud... Looks like gpsd only ever sets it to a 1. NTPsec ntpd/refclock_shm.c (un)helpfully says: * To add new modes: Extend or union the shmTime-struct. Do not * extend/shrink size, because otherwise existing implementations * will specify wrong size of shared memory-segment Maybe set mode = 2, and use two of the dummy from shmTime: int dummy[8]; > Could that be used, > possibly by setting some high bit(s) to indicate a 64-bit time_t and > a 32-bit int? That would break backwards compatibility, though, as > old readers would see modes they do not expect. NTPsec would reject a mode of 2: default: shm_stat->status = BAD_MODE; break; Maybe keep mode of 1, and dummy[0] could be the top bits of time64_t? Then old and new clients work until 2038. And new clients after that. > Do you know if, _in practice_, providers of shmTime are providing > zeros for the dummy[8] padding? All I care about is gpsd, and it does zero the padding. Once. If so, then (subject to agreement > from the various projects), part of that could be defined as a magic. > Of course, the problem there is that you need to find dummy[x], which > can be in different positions depending on the struct size (which is > the issue at hand). That is fixable. Just force the existing time_t to be time32_t on 32-bit systems that support 2 types of time_t. The other fields are "int" and "unsigned". > One possible solution would be Too complicated. If dumm[0] is non-zero, take that as the top 32 bits of time64_t. But only on 32-bit dual time_t systems. Along the way, pull the duplicate shmTime definitions from NTPsec and gpsd and put them in one system header file. > > 4. gpsd and ntpd always use 64-bit time_t going forward. Admin > > needs to mix and match. > > I think ntpd (and probably gpsd too) should enable whatever option to > use 64-bit time_t if the platform supports it. But do we need to > still support existing 32-bit platforms where time_t is only 32-bit? > Probably? Certainly. At least until 2038. chrony sockets are still a problem... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpayEnXFDuFq.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
✘64-bit time_t on glibc 2.34 and up
Yo All!
Cross-posted to gpsd-dev and devel@ntpsec.org
Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit
time_t on 32-bit Linux without much work.
But...
How to get that 2038 compatible time to ntpd and chronyd? That is a
much bigger problem.
Extracted from include/ntpshm.h:
struct shmTime
{
int mode;
volatile int count;
time_t clockTimeStampSec;
int clockTimeStampUSec;
time_t receiveTimeStampSec;
int receiveTimeStampUSec;
int leap; // not leapsecond offset, a notification code
int precision; // log(2) of source jitter
int nsamples; // not used
volatile int valid;
unsignedclockTimeStampNSec; // Unsigned ns timestamps
unsignedreceiveTimeStampNSec; // Unsigned ns timestamps
int dummy[8];
};
Note the struct size depends on the size of an int, and the size of time_t.
This is no problem for newer musl on 32-bits. An int is 32-bits and
time_t is 64. Assuming all clients use the same version musl.
This is a problem for glibc on 32 bits. And int is 32-bits, but time_t
is a compile time option (32 or 64 bits).
How does ntpd know what size time_t to use? And thus know the size of
shmTime? How do we know portably, preserving backwards and forwards
compatibility?
In hindsight, maybe shmTime should have started with a 1 char version
field,or magic field. But, no such luck.
Options (for 32-bit only):
1. Do nothing, stick with 32-bit time_t. Fail in 2038.
2. Allow 64-bit time_t and let incompatible ntpd fail.
3. Add run time options to gpsd and ntpd to specify time_t size.
4. gpsd and ntpd always use 64-bit time_t going forward. Admin needs
to mix and match.
5. 1st process to open SHM(0) wins, the other process checks the size
to know the contents.
6. Create a new way to pass time from gpsd to ntpd and chronyd.
Also note, chrony sockets have a similar problem:
#define SOCK_MAGIC 0x534f434b
struct sock_sample {
struct timeval tv;
double offset;
int pulse;
int leap; // notify that a leap second is upcoming
int _pad;
int magic; // must be SOCK_MAGIC
};
Where timeval is:
struct timeval {
time_t tv_sec;
suseconds_t tv_usec;
};
```
Since the sample has a magic value, maybe that can be used to detect versions.
This makes my head hurt...
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpAUyyMQ2wlc.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: proposal for sntp program: include 'delay' in json output
Yo folkert! On Tue, 3 Jan 2023 08:58:40 +0100 folkert wrote: > Can I please send the patch via e-mail? I've been struggeling with > gitlab for an hour and whatever I do it keeps complaining that I'm not > allowed to push to the project (my own clone, in a branch). I think you already sent the patch by email. Twice. Since you are not a developer you can not push to the project, but you can create a Merge Request or Issue. I just created an issue for this: https://gitlab.com/NTPsec/ntpsec/-/issues/758 RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpPDCvEAmX75.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: proposal for sntp program: include 'delay' in json output
Yo folkert!
> Lost me. What about sntp do you want to put on gitlab?
Oh, reading these in reverse order. I think you are offering to
add this as a Merge Request on GitLab? Yes, that would be good.
>
> On Mon, 2 Jan 2023 15:10:06 +0100
> folkert via devel wrote:
>
> > Just noticed https://ntpsec.org/contributor.html
> > If you people want to include it, I'll put it in gitlab.
> >
> > > Hello,
> > >
> > > I would like to suggest the following small tweak for the sntp
> > > program:
> > >
> > > --- sorg 2023-01-02 14:45:52.975926908 +0100
> > > +++ /usr/bin/sntp 2023-01-02 14:44:13.322691440 +0100
> > > @@ -216,12 +216,12 @@
> > >
> > > if json:
> > > say('{"time":"%sT%s%s","offset":%f,"precision":%f,"host":"%s",'
> > > -'"ip":"%s","stratum":%s,"leap":"%s","adjusted":%s}\n'
> > > +
> > > '"ip":"%s","stratum":%s,"leap":"%s","adjusted":%s,"delay":%f}\n' %
> > > (date, tod, tz, packet.adjust(), packet.synchd(),
> > > packet.hostname, packet.resolved or
> > > packet.hostname, packet.stratum, packet.leap(),
> > > - "true" if adjusted else "false"))
> > > + "true" if adjusted else "false", packet.delta()))
> > > else:
> > > say("%s %s (%s) %+f +/- %f %s"
> > > % (date, tod, tz,
> > >
> > > It makes it include the delay in the json output.
> > ___
> > devel mailing list
> > devel@ntpsec.org
> > https://lists.ntpsec.org/mailman/listinfo/devel
>
>
>
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com Tel:+1 541 382 8588
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can't measure it, you can't improve it." - Lord Kelvin
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpPcXLk6SwyX.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: proposal for sntp program: include 'delay' in json output
Yo folkert!
Lost me. What about sntp do you want to put on gitlab?
On Mon, 2 Jan 2023 15:10:06 +0100
folkert via devel wrote:
> Just noticed https://ntpsec.org/contributor.html
> If you people want to include it, I'll put it in gitlab.
>
> > Hello,
> >
> > I would like to suggest the following small tweak for the sntp
> > program:
> >
> > --- sorg2023-01-02 14:45:52.975926908 +0100
> > +++ /usr/bin/sntp 2023-01-02 14:44:13.322691440 +0100
> > @@ -216,12 +216,12 @@
> >
> > if json:
> > say('{"time":"%sT%s%s","offset":%f,"precision":%f,"host":"%s",'
> > -'"ip":"%s","stratum":%s,"leap":"%s","adjusted":%s}\n'
> > +
> > '"ip":"%s","stratum":%s,"leap":"%s","adjusted":%s,"delay":%f}\n' %
> > (date, tod, tz, packet.adjust(), packet.synchd(),
> > packet.hostname, packet.resolved or packet.hostname,
> > packet.stratum, packet.leap(),
> > - "true" if adjusted else "false"))
> > + "true" if adjusted else "false", packet.delta()))
> > else:
> > say("%s %s (%s) %+f +/- %f %s"
> > % (date, tod, tz,
> >
> > It makes it include the delay in the json output.
> ___
> devel mailing list
> devel@ntpsec.org
> https://lists.ntpsec.org/mailman/listinfo/devel
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpr14yf7gh3Z.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: We need to test leap smearing :)
Yo Fred! On Thu, 22 Dec 2022 17:00:37 -0800 (PST) Fred Wright via devel wrote: > On Wed, 21 Dec 2022, Hal Murray via devel wrote: > > > Google says: > > https://developers.google.com/time/smear > > We encourage anyone smearing leap seconds to use a 24-hour linear > > smear from noon to noon UTC. > > > > There were earlier versions which did sine rather than linear. > > Hmm. I don't recall any nonlinear version (and I presume you meant > raised cosine rather than sine), but I do recall that Google's smear > interval was originally 20 hours, not 24. If you make it 24 hours, > there's the question of whether that means 86400 seconds or 86401. :-) There are many strange smearing schemees. From a few hours to 48 hours. Google: On Feb 15 Google said they smear linear, over 20 hours, centered on the leap second. Previously Google said this: https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html lie(t) = (1.0 - cos(pi * t / w)) / 2.0 AWS smears linear for the 24 hours preceeding the leap second. Some versions of NTP and chronyd, can ignore the leap second, then slew the system clock to catch up: https://developers.redhat.com/blog/2015/06/01/five-different-ways-handle-leap-seconds-ntp#options_with_ntpd And of course: https://xkcd.com/2266/ The madness goes on, the only way to win the game is not to play. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpzxXjdrZoQD.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: We need to test leap smearing :)
Yo Fred! On Wed, 21 Dec 2022 18:21:39 -0800 (PST) Fred Wright via devel wrote: > On Wed, 21 Dec 2022, Hal Murray via devel wrote: > > > Does anybody use it? > > Do any distros build with it enabled? > > Should we add an "#warn untested" to the code? > > If some systems need leap-smeared time to get around bugs in their > code, they should be free to implement an *internal* leap-smeared > timescale. But leap smearing on the wire is an abomination that ought > to be expressly prohibited. +10 RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpMt7p0vX_aN.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘Testing
Yo Paul! On Mon, 21 Nov 2022 19:27:12 -0800 Paul Theodoropoulos wrote: > Yeah, I would be curious what the full infrastructure is with paths, > but as you mentioned, Thanksgiving lingers near. No one still with NTPsec likes it, but inertia is strong. > I've used DJB's dnscache for, well I guess it would be decades now, > for near-line lookup caching, it is really a wonderful thing, but it > "requires" many patches, and has no IPv6 support out of the box > (another patch). Sadly, I still find bind the best. All it seriously lacks is DNS over HTTP. > > On 11/21/2022 16:16 PM, Gary E. Miller via devel wrote: > > Yo Paul! > > > > On Mon, 21 Nov 2022 16:14:33 -0800 > > Paul Theodoropoulos wrote: > > > >> Seven seconds round-trip. I'd say the issues are formally > >> mitigated. > > Maybe because DNS is recently cached? Something else to look at. > > > >> On 11/21/2022 16:13 PM, Paul Theodoropoulos via devel wrote: > >>> And this reply took about one minute thirty seconds round-trip. > >>> > >>> Screws up the line, but in a good way. > >>> > >>> On 11/21/2022 16:10 PM, Paul Theodoropoulos via devel wrote: > >>>> Inserted into stream: > >>>> Mon, 21 Nov 2022 15:09:32 -0800 > >>>> > >>>> Received here: > >>>> > >>>> Mon, 21 Nov 2022 15:46:32 -0800 > >>>> So, about 3 hours, down to about 90 minutes, down to about 37 > >>>> minutes. > >>>> > >>>> Pretty smooth line. > >>>> Return-path: > >>>> Envelope-to:p...@anastrophe.com > >>>> Delivery-date: Mon, 21 Nov 2022 15:46:32 -0800 > >>>> Received: from mx.ntpsec.org ([140.211.9.57]:20808) > >>>> by relay.anastrophe.com with esmtps (TLS1.3) tls > >>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) > >>>> (envelope-from) > >>>> id 1oxGUc-006XpM-2D > >>>> forp...@anastrophe.com; > >>>> Mon, 21 Nov 2022 15:46:32 -0800 > >>>> Received: from lists.ntpsec.org (lists.int.ntpsec.org > >>>> [192.168.9.59]) by mx.ntpsec.org (Postfix) with ESMTP id > >>>> AD6252869D8; Mon, 21 Nov 2022 23:42:40 + (UTC) > >>>> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ntpsec.org; > >>>> s=dkim; t=1669074385; > >>>> bh=cqB08lDH4HOppOt+A7Z5bG0T/wmUZyy7Hsxj2M8Whb4=; > >>>> h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: > >>>> List-Help:List-Subscribe:From:Reply-To; > >>>> z=Date:=20Mon,=2021=20Nov=202022=2015:09:32=20-0800|To:=20 >>>> psec.org>|Subject:=20=3D?UTF-8?B?4pyYVGVzdGluZw=3D=3D?=3D|List-Id: > >>>> =20Developer=20discussion=20|List-Unsubscribe:=2 > >>>> 0<https://lists.ntpsec.org/mailman/options/devel>,=0D=0A=20 >>>> :devel-requ...@ntpsec.org?subject=3Dunsubscribe>|List-Archive:=20< > >>>> https://lists.ntpsec.org/pipermail/devel/>|List-Post:=20<mailto:de > >>>> v...@ntpsec.org>|List-Help:=20<mailto:devel-requ...@ntpsec.org?subj > >>>> ect=3Dhelp>|List-Subscribe:=20<https://lists.ntpsec.org/mailman/li > >>>> stinfo/devel>,=0D=0A=20<mailto:devel-requ...@ntpsec.org?subject=3D > >>>> subscribe>|From:=20"Gary=20E.=20Miller=20via=20devel"=20 >>>> subscribe> sec.org>|Reply-To:=20"Gary=20E.=20Miller"=20; > >>>> subscribe> > >>>> subscribe>b=zmRXPOh8RKpIrX09TcKunPhOBphrgVmqzmsJxK+ai7T825o/+xrEuHIb6fIwu+epd > >>>> subscribe>PQR3Uh7Fo5AYQI0RD3ufw/uRocNE9Ln/PiBdKRgi+wEVV9JxXI0nYHlSFxK+pcj8do > >>>> subscribe>9frqrzOI/2Lb0571NT1HL2SyDKrr1wCDdkN3YYBc= Received: > >>>> subscribe>from lists.ntpsec.org (unknown [192.168.9.59]) by > >>>> subscribe>lists.ntpsec.org (Postfix) with ESMTP id EE1A03C0CF7; > >>>> subscribe>Mon, 21 Nov 2022 23:09:43 + (UTC) Received: from > >>>> subscribe>mx.ntpsec.org (unknown [192.168.9.57]) > >>>>by lists.ntpsec.org (Postfix) with ESMTP id E7C043C0285 > >>>>for; Mon, 21 Nov 2022 23:09:42 + (UTC) > >>>> Received: from rellim.com (rellim.com [204.17.205.19]) > >>>>(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 > >>>> bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) > >>>> server-digest SHA256) (No client certificate requested) > >>>
Re: ✘Testing
Yo Paul! Email gets into mailman, and archives, quickly. Then mailman, on lists.ntpsec.org, was talking directly mx.ntpsec.org, sending one email every 75 seconds. Now I have mailman sending email to the postfix on lists.ntpsec.org, and that sends many emails in parallele to mx.ntpsec.org, that take time sending them. The next step may be to have lists.ntpsec.org stop forwaiding email to mx.ntpsec.org and instead try to deliver directly. I'm sure that will also break something. With Turkey Day coming, my testing will have to slow down. On Mon, 21 Nov 2022 16:10:12 -0800 Paul Theodoropoulos wrote: > Inserted into stream: > > Mon, 21 Nov 2022 15:09:32 -0800 > > Received here: > > Mon, 21 Nov 2022 15:46:32 -0800 > > So, about 3 hours, down to about 90 minutes, down to about 37 minutes. > > Pretty smooth line. > > Return-path: > Envelope-to:p...@anastrophe.com > Delivery-date: Mon, 21 Nov 2022 15:46:32 -0800 > Received: from mx.ntpsec.org ([140.211.9.57]:20808) > by relay.anastrophe.com with esmtps (TLS1.3) tls > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) > (envelope-from) > id 1oxGUc-006XpM-2D > forp...@anastrophe.com; > Mon, 21 Nov 2022 15:46:32 -0800 > Received: from lists.ntpsec.org (lists.int.ntpsec.org [192.168.9.59]) > by mx.ntpsec.org (Postfix) with ESMTP id AD6252869D8; > Mon, 21 Nov 2022 23:42:40 + (UTC) > DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ntpsec.org; > s=dkim; t=1669074385; bh=cqB08lDH4HOppOt+A7Z5bG0T/wmUZyy7Hsxj2M8Whb4=; > h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: >List-Help:List-Subscribe:From:Reply-To; > z=Date:=20Mon,=2021=20Nov=202022=2015:09:32=20-0800|To:=20 psec.org>|Subject:=20=3D?UTF-8?B?4pyYVGVzdGluZw=3D=3D?=3D|List-Id: > =20Developer=20discussion=20|List-Unsubscribe:=2 > 0<https://lists.ntpsec.org/mailman/options/devel>,=0D=0A=20 :devel-requ...@ntpsec.org?subject=3Dunsubscribe>|List-Archive:=20< > https://lists.ntpsec.org/pipermail/devel/>|List-Post:=20<mailto:de > v...@ntpsec.org>|List-Help:=20<mailto:devel-requ...@ntpsec.org?subj > ect=3Dhelp>|List-Subscribe:=20<https://lists.ntpsec.org/mailman/li > stinfo/devel>,=0D=0A=20<mailto:devel-requ...@ntpsec.org?subject=3D > subscribe>|From:=20"Gary=20E.=20Miller=20via=20devel"=20 subscribe>sec.org>|Reply-To:=20"Gary=20E.=20Miller"=20; > subscribe>b=zmRXPOh8RKpIrX09TcKunPhOBphrgVmqzmsJxK+ai7T825o/+xrEuHIb6fIwu+epd > subscribe>PQR3Uh7Fo5AYQI0RD3ufw/uRocNE9Ln/PiBdKRgi+wEVV9JxXI0nYHlSFxK+pcj8do > subscribe>9frqrzOI/2Lb0571NT1HL2SyDKrr1wCDdkN3YYBc= Received: from > subscribe>lists.ntpsec.org (unknown [192.168.9.59]) by > subscribe>lists.ntpsec.org (Postfix) with ESMTP id EE1A03C0CF7; Mon, > subscribe>21 Nov 2022 23:09:43 + (UTC) > Received: from mx.ntpsec.org (unknown [192.168.9.57]) > by lists.ntpsec.org (Postfix) with ESMTP id E7C043C0285 > for; Mon, 21 Nov 2022 23:09:42 + (UTC) > Received: from rellim.com (rellim.com [204.17.205.19]) > (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) > key-exchange X25519 server-signature RSA-PSS (2048 bits) > server-digest SHA256) (No client certificate requested) > by mx.ntpsec.org (Postfix) with ESMTPS id EF960286BBA > for; Mon, 21 Nov 2022 23:09:39 + (UTC) > Received: from spidey.rellim.com (rellim.com [IPv6:2001:470:e815::19]) > by rellim.com (Postfix) with ESMTPSA id 9D42120001F > for; Mon, 21 Nov 2022 15:09:39 -0800 (PST) > Date: Mon, 21 Nov 2022 15:09:32 -0800 > To: > Subject: =?UTF-8?B?4pyYVGVzdGluZw==?= > Message-ID:<20221121150932.5ed30...@spidey.rellim.com> > Organization: Rellim > X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-pc-linux-gnu) > MIME-Version: 1.0 > X-BeenThere:devel@ntpsec.org > X-Mailman-Version: 2.1.39 > Precedence: list > List-Id: Developer discussion > List-Unsubscribe:<https://lists.ntpsec.org/mailman/options/devel>, > <mailto:devel-requ...@ntpsec.org?subject=unsubscribe> > List-Archive:<https://lists.ntpsec.org/pipermail/devel/> > List-Post:<mailto:devel@ntpsec.org> > List-Help:<mailto:devel-requ...@ntpsec.org?subject=help> > List-Subscribe:<https://lists.ntpsec.org/mailman/listinfo/devel>, > <mailto:devel-requ...@ntpsec.org?subject=subscribe> > From: "Gary E. Miller via devel" > Reply-To: "Gary E. Miller" > Content-Type: multipart/mixed; > boundary="===3697578452347589219==" > Errors-To:devel-boun...@ntpsec.org Sender: > "devel" X-Rspamd-Queue-Id: AD6252869D8 > X-Spamd-Result: default: False [-2.31 / 15.00]; > SIGNED_PGP(-2.00)[]; > MIME_GOOD(
Re: ✘Testing
Yo Paul! On Mon, 21 Nov 2022 16:14:33 -0800 Paul Theodoropoulos wrote: > Seven seconds round-trip. I'd say the issues are formally mitigated. Maybe because DNS is recently cached? Something else to look at. > > On 11/21/2022 16:13 PM, Paul Theodoropoulos via devel wrote: > > And this reply took about one minute thirty seconds round-trip. > > > > Screws up the line, but in a good way. > > > > On 11/21/2022 16:10 PM, Paul Theodoropoulos via devel wrote: > >> Inserted into stream: > >> Mon, 21 Nov 2022 15:09:32 -0800 > >> > >> Received here: > >> > >> Mon, 21 Nov 2022 15:46:32 -0800 > >> So, about 3 hours, down to about 90 minutes, down to about 37 > >> minutes. > >> > >> Pretty smooth line. > >> Return-path: > >> Envelope-to:p...@anastrophe.com > >> Delivery-date: Mon, 21 Nov 2022 15:46:32 -0800 > >> Received: from mx.ntpsec.org ([140.211.9.57]:20808) > >>by relay.anastrophe.com with esmtps (TLS1.3) tls > >> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) > >>(envelope-from) > >>id 1oxGUc-006XpM-2D > >>forp...@anastrophe.com; > >>Mon, 21 Nov 2022 15:46:32 -0800 > >> Received: from lists.ntpsec.org (lists.int.ntpsec.org > >> [192.168.9.59]) by mx.ntpsec.org (Postfix) with ESMTP id > >> AD6252869D8; Mon, 21 Nov 2022 23:42:40 + (UTC) > >> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ntpsec.org; > >> s=dkim; t=1669074385; > >> bh=cqB08lDH4HOppOt+A7Z5bG0T/wmUZyy7Hsxj2M8Whb4=; > >> h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: > >> List-Help:List-Subscribe:From:Reply-To; > >> z=Date:=20Mon,=2021=20Nov=202022=2015:09:32=20-0800|To:=20 >> psec.org>|Subject:=20=3D?UTF-8?B?4pyYVGVzdGluZw=3D=3D?=3D|List-Id: > >> =20Developer=20discussion=20|List-Unsubscribe:=2 > >> 0<https://lists.ntpsec.org/mailman/options/devel>,=0D=0A=20 >> :devel-requ...@ntpsec.org?subject=3Dunsubscribe>|List-Archive:=20< > >> https://lists.ntpsec.org/pipermail/devel/>|List-Post:=20<mailto:de > >> v...@ntpsec.org>|List-Help:=20<mailto:devel-requ...@ntpsec.org?subj > >> ect=3Dhelp>|List-Subscribe:=20<https://lists.ntpsec.org/mailman/li > >> stinfo/devel>,=0D=0A=20<mailto:devel-requ...@ntpsec.org?subject=3D > >> subscribe>|From:=20"Gary=20E.=20Miller=20via=20devel"=20 >> subscribe>sec.org>|Reply-To:=20"Gary=20E.=20Miller"=20; > >> subscribe>b=zmRXPOh8RKpIrX09TcKunPhOBphrgVmqzmsJxK+ai7T825o/+xrEuHIb6fIwu+epd > >> subscribe>PQR3Uh7Fo5AYQI0RD3ufw/uRocNE9Ln/PiBdKRgi+wEVV9JxXI0nYHlSFxK+pcj8do > >> subscribe>9frqrzOI/2Lb0571NT1HL2SyDKrr1wCDdkN3YYBc= Received: from > >> subscribe>lists.ntpsec.org (unknown [192.168.9.59]) by > >> subscribe>lists.ntpsec.org (Postfix) with ESMTP id EE1A03C0CF7; > >> subscribe>Mon, 21 Nov 2022 23:09:43 + (UTC) Received: from > >> subscribe>mx.ntpsec.org (unknown [192.168.9.57]) > >> by lists.ntpsec.org (Postfix) with ESMTP id E7C043C0285 > >> for; Mon, 21 Nov 2022 23:09:42 + (UTC) > >> Received: from rellim.com (rellim.com [204.17.205.19]) > >> (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) > >> key-exchange X25519 server-signature RSA-PSS (2048 bits) > >> server-digest SHA256) (No client certificate requested) > >> by mx.ntpsec.org (Postfix) with ESMTPS id EF960286BBA > >> for; Mon, 21 Nov 2022 23:09:39 + (UTC) > >> Received: from spidey.rellim.com (rellim.com > >> [IPv6:2001:470:e815::19]) by rellim.com (Postfix) with ESMTPSA id > >> 9D42120001F for; Mon, 21 Nov 2022 15:09:39 -0800 > >> (PST) Date: Mon, 21 Nov 2022 15:09:32 -0800 > >> To: > >> Subject: =?UTF-8?B?4pyYVGVzdGluZw==?= > >> Message-ID:<20221121150932.5ed30...@spidey.rellim.com> > >> Organization: Rellim > >> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-pc-linux-gnu) > >> MIME-Version: 1.0 > >> X-BeenThere:devel@ntpsec.org > >> X-Mailman-Version: 2.1.39 > >> Precedence: list > >> List-Id: Developer discussion > >> List-Unsubscribe:<https://lists.ntpsec.org/mailman/options/devel>, > >> <mailto:devel-requ...@ntpsec.org?subject=unsubscribe> > >> List-Archive:<https://lists.ntpsec.org/pipermail/devel/> > >> List-Post:<mailto:devel@ntpsec.org> > >> List-Help:<mailto:devel-requ...@ntpsec.org?subject=help> > >> List-Subscribe:<https://lists.ntpsec.or
✘Testing
Yo All! Testing 7-8-9 RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpMpLx2bQg3O.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
✘Testing
Yo All! Test 4-5-6 RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp8kDP5Yh13E.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘Testing
Yo Paul! There were 500k messages backed up on the mailman queue. I just deleted them all. With the queue empty, mailman is sending one email every 75 seconds. No idea why, still looking at it. On Sun, 20 Nov 2022 16:03:17 -0800 Paul Theodoropoulos wrote: > Apparently submitted at: > > Sunday, 20 Nov 2022 12:00:06 -0800 > > Received here (also on US West coast): > > Sunday, 20 Nov 2022 15:09:33 -0800 > > Three hours is certainly dramatically better than the three months we > were seeing. > > Full header if it helps analysis: > > Return-path: > Envelope-to:p...@anastrophe.com > Delivery-date: Sun, 20 Nov 2022 15:09:33 -0800 > Received: from mx.ntpsec.org ([140.211.9.57]:62969) > by relay.anastrophe.com with esmtps (TLS1.3) tls > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) > (envelope-from) > id 1owtQY-006Sg3-1W > forp...@anastrophe.com; > Sun, 20 Nov 2022 15:09:33 -0800 > Received: from lists.ntpsec.org (lists.int.ntpsec.org [192.168.9.59]) > by mx.ntpsec.org (Postfix) with ESMTP id 7BDF42869E2; > Sun, 20 Nov 2022 23:07:26 + (UTC) > DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ntpsec.org; > s=dkim; t=1668985721; bh=ClEMCgssYGQwC1NR/F0ovAHiM45u53KAHPu4NuiBE1U=; > h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: >List-Help:List-Subscribe:From:Reply-To; > z=Date:=20Sun,=2020=20Nov=202022=2012:00:06=20-0800|To:=20 psec.org>|Subject:=20=3D?UTF-8?B?4pyYVGVzdGluZw=3D=3D?=3D|List-Id: > =20Developer=20discussion=20|List-Unsubscribe:=2 > 0<https://lists.ntpsec.org/mailman/options/devel>,=0D=0A=20 :devel-requ...@ntpsec.org?subject=3Dunsubscribe>|List-Archive:=20< > https://lists.ntpsec.org/pipermail/devel/>|List-Post:=20<mailto:de > v...@ntpsec.org>|List-Help:=20<mailto:devel-requ...@ntpsec.org?subj > ect=3Dhelp>|List-Subscribe:=20<https://lists.ntpsec.org/mailman/li > stinfo/devel>,=0D=0A=20<mailto:devel-requ...@ntpsec.org?subject=3D > subscribe>|From:=20"Gary=20E.=20Miller=20via=20devel"=20 subscribe>sec.org>|Reply-To:=20"Gary=20E.=20Miller"=20; > subscribe>b=DVgl6+7AO38WXtrAoix89o7WRNk+E7X9TY0a4FR/vHEC0ktruSGOs7QpsCCrtODgs > subscribe>BFgUQD+7AVraHll1AZtyC3qDQVPPcTy+u4K8I7KD+staoAyXEmDur3h9kg2UeSTS37 > subscribe>xkY8kUG/Y5lRvrqZIQOZTqavUYtoVIbEoNsRFFCo= Received: from > subscribe>mx.ntpsec.org (unknown [192.168.9.57]) by lists.ntpsec.org > subscribe>(Postfix) with ESMTP id C10153C01E3 for; > subscribe>Sun, 20 Nov 2022 20:00:14 + (UTC) > Received-SPF: pass (rellim.com: 204.17.205.19 is authorized to use > 'g...@rellim.com' in 'mfrom' identity (mechanism > 'ip4:204.17.205.0/24' matched)) receiver=mx.ntpsec.org; > identity=mailfrom; envelope-from="g...@rellim.com"; helo=rellim.com; > client-ip=204.17.205.19 Received: from rellim.com (rellim.com > [204.17.205.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 > (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 > bits) server-digest SHA256) (No client certificate requested) > by mx.ntpsec.org (Postfix) with ESMTPS id E59532869DD > for; Sun, 20 Nov 2022 20:00:12 + (UTC) > Received: from spidey.rellim.com (unknown [IPv6:2001:470:e815::19]) > by rellim.com (Postfix) with ESMTPSA id 51ABB20732C > for; Sun, 20 Nov 2022 12:00:12 -0800 (PST) > Date: Sun, 20 Nov 2022 12:00:06 -0800 > To: > Subject: =?UTF-8?B?4pyYVGVzdGluZw==?= > Message-ID:<20221120120006.200ca...@spidey.rellim.com> > Organization: Rellim > X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-pc-linux-gnu) > MIME-Version: 1.0 > X-BeenThere:devel@ntpsec.org > X-Mailman-Version: 2.1.38 > Precedence: list > List-Id: Developer discussion > List-Unsubscribe:<https://lists.ntpsec.org/mailman/options/devel>, > <mailto:devel-requ...@ntpsec.org?subject=unsubscribe> > List-Archive:<https://lists.ntpsec.org/pipermail/devel/> > List-Post:<mailto:devel@ntpsec.org> > List-Help:<mailto:devel-requ...@ntpsec.org?subject=help> > List-Subscribe:<https://lists.ntpsec.org/mailman/listinfo/devel>, > <mailto:devel-requ...@ntpsec.org?subject=subscribe> > From: "Gary E. Miller via devel" > Reply-To: "Gary E. Miller" > Content-Type: multipart/mixed; > boundary="===8167145145813447727==" > Errors-To:devel-boun...@ntpsec.org Sender: > "devel" X-Rspamd-Queue-Id: 7BDF42869E2 > X-Spamd-Result: default: False [-2.31 / 15.00]; > SIGNED_PGP(-2.00)[]; > MIME_GOOD(-0.20)[multipart/mixed,multipart/signed,text/plain]; > MAILLIST(-0.20)[mailman]; > RCVD_NO_TLS_LAST(0.10)[]; > HAS_LIST_UNSUB(-0.01)[]; > TO_DN_N
✘Testing
Yo All! Testing 1-2-3... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp3GWVhyIbcf.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Adafruit Pi GPS HAT -- serial port stuck
Yo Hal! On Thu, 16 Jun 2022 19:33:07 -0700 Hal Murray via devel wrote: > Has anybody seen the serial port get stuck? Not me, but I have heard reports. Usually a voltage mismatch. > It's software/kernel. I can see the bits with a scope. You can't just cat/minicom the serial port? And stty shows the proper speed/framing? > It works as expected until it runs out of satellites. Then, > sometimes it doesn't recover. Why would it run out of satellites? Forget to charge them up? > Restarting ntpd doesn't fix it. Rebooting does. Wierd. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpuJNaPKeLHH.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | solve #714, #737 by removing ill-conceived test. (!1270)
Yo All! mes showed me how to duplicate this bug. Obviously a clang 13 optimier bug. Fix pushed to git head. Please test. Users should prolly avoid clang 13 until the bug is fixed in clang. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpghcoXzx4fF.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | solve #714, #737 by removing ill-conceived test. (!1270)
Yo jamesb...@jamesb192.com! On Sat, 14 May 2022 22:27:13 -0400 (EDT) "jamesb...@jamesb192.com jamesb192--- via devel" wrote: > > On 05/14/2022 8:53 PM Gary E. Miller via devel > > wrote: > > > > > > Yo Hal! > > > > On Sat, 14 May 2022 17:42:59 -0700 > > Hal Murray via devel wrote: > > > > > I'm cc-ing devel so this doesn't get lost on gitlab. Let's move > > > the discussion real email.. > > > > > > > > > > include/ntp_fp.h:58 defines l_fp as a uint64_4, I can find no > > > > current contrary definitions. > > > > > > We need to make a cleanup pass in this area. > > > > > > On the wire, it's unsigned. As soon as the code gets 2 of them, > > > it does a subtract so we need a signed version. We need to check > > > for underflow on the initial subtract. > > > > > > There is also u_fp, a 32 bit version. The comment says there is a > > > s_fp, but I can't find it. > > > > > > --- > > > > > > I think we should comment out this test until we get the release > > > out. Please include references to both issues and this > > > message/thread. > > > > I'm OK with commenting it out, just the two lines, until we figure > > out what clang is doing. But I'd rather figure it out... > > I figured it out a while back and apparently failed to post my work > to bug 714. It has to do with whether l_fp_abs is inlined and/or > optimized IIRC. I had a (partial) disasembly, but I threw it away. You threw away a fix? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgps716sjsUEF.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | solve #714, #737 by removing ill-conceived test. (!1270)
Yo Hal! On Sat, 14 May 2022 17:42:59 -0700 Hal Murray via devel wrote: > I'm cc-ing devel so this doesn't get lost on gitlab. Let's move the > discussion real email.. Not yet in the delvel emailarchives: What distro is broken by this? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp3tEzU6RnSo.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | solve #714, #737 by removing ill-conceived test. (!1270)
Yo Hal! On Sat, 14 May 2022 17:42:59 -0700 Hal Murray via devel wrote: > I'm cc-ing devel so this doesn't get lost on gitlab. Let's move the > discussion real email.. > > > > include/ntp_fp.h:58 defines l_fp as a uint64_4, I can find no > > current contrary definitions. > > We need to make a cleanup pass in this area. > > On the wire, it's unsigned. As soon as the code gets 2 of them, it > does a subtract so we need a signed version. We need to check for > underflow on the initial subtract. > > There is also u_fp, a 32 bit version. The comment says there is a > s_fp, but I can't find it. > > --- > > I think we should comment out this test until we get the release out. > Please include references to both issues and this message/thread. I'm OK with commenting it out, just the two lines, until we figure out what clang is doing. But I'd rather figure it out... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp0fL5IJ_Vty.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Raspberry Pi startup: certificate is not yet valid
Yo Hal! On Wed, 11 May 2022 01:53:30 -0700 Hal Murray wrote: > > I like you suggestion of ntpd using "-g" to get the system time > > close, before checking any certificates. > > It was Richard's suggestion, not mine. The idea was to only skip the > date checks and do the rest of the certificate checking. You can see how well I'm paying attention > The main reason is that it's a hole in securty. I don't want to > clutter up security discussions and documentation with that very > unlikely case. It could be a non-default option, coupled with serious warnings. > The second reason is that OpenSSL isn't setup to skip only the date > check. We could easily implement your version of no-check, but that > would make the tiny security hole a big hole. I find that convincing. If OpenSSL does not have the knob, game over. > I think the alternative is to get the clock reasonably close before > running ntpd. And the traditional solution(s). > What is swclock? What distros does it run on? swlock is part of OpenRC. Which is in any OS that runs OpenRC, like Gentoo. On startup it resets the system time to the time of the last shutdown (usually). https://github.com/openrc/openrc/ > I think the Linux kernel sets the clock to the build time or > something similar. Nope. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpOJGMK60W31.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Raspberry Pi startup: certificate is not yet valid
Yo Hal! On Tue, 10 May 2022 10:26:08 -0700 Hal Murray wrote: > Gary said: > >> Should we do something like set the time to the time stamp of the > >> drift file? (if it is significantly newer than the current time) > > > Nope. Don't get in a fight with the OS. > > Could you please say more. Be careful whjat you ask for. > The whole purpose of ntpsec is to keep good time. Yes, but so many other tasks also may think that is their job. When two fight, bad things happen. It is the job of the OS, using it RC method (OpenRC, systemd(umb), launchd, etc.) to pick the right programs, in the right order, to keep time on that host. > If we know the > clock is way off, what's wrong with taking a big step to get a lot > closer so certificate checking has a better chance of working? Nothing at all, once the system RC has tol ntpsec that system time is its job, then ntpsec needs to do the best job it can. I like you suggestion of ntpd using "-g" to get the system time close, before checking any certificates. The problem I see a lot is that a lot of Pi's are started with no network connection, and a bad time, so swclock is commonly used before starting ntpd. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpedRM2Q6rfa.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Raspberry Pi startup: certificate is not yet valid
Yo Hal! On Mon, 09 May 2022 00:38:34 -0700 Hal Murray via devel wrote: > Does anybody know how the initial time gets set on a Raspberry Pi -- > before ntpd gets called? It depends. Some use swclock, some use ntpclient, some use an RTC, some use a GNSS time. > I have a recently setup system that gets initialized to 2022-04-01 > and is trying to use a certificate that was created after that. :) Fun. > Should we do something like set the time to the time stamp of the > drift file? (if it is significantly newer than the current time) Nope. Don't get in a fight with the OS. > Do we have a document that collects interesting things about NTS and > certificates? Nope. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpsrXzIZzJIE.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Fw: [LEAPSECS] podcast from Orolia
Yo All! From [time-nuts]: predictions of a negative leap second in 2027! See below, and attached. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin > From: John Sauter via LEAPSECS > On Thu, 2022-05-05 at 20:05 +0100, Tony Finch wrote: > > John Sauter via LEAPSECS wrote: > > My guesstimate for the negative leap second is now end of 2027, and > > likely to get closer if things continue like this! > To illustrate Tony's point, here is a plot of the slope of the IERS's > estimates of UT2-UTC since 2005. Values greater than zero predict a > negative leap second. UT2 is UT1 with seasonal fluctuations removed. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin UT2_slope.pdf Description: Adobe PDF document ___ LEAPSECS mailing list leaps...@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs pgphWjaARyCv8.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
New release & OpenSSL 3
Yo All! openssl 3.0.0 is becoming an issue. See: https://gitlab.com/NTPsec/ntpsec/-/issues/734 We have been stolling towards a release, what do we need to get one out with openssl 3.0? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin Title: GitLab Sam James created an issue: #734 Thanks all for your work on ntpsec. Would you consider a new release for the OpenSSL 3 fixes (but also seccomp filter updates for newer versions of glibc)? I ask because it makes it a lot easier downstream (speaking for Gentoo here) to get the fixes in, and we're trying to figure out which packages still really need OpenSSL 3. Cheers! — Reply to this email directly or view it on GitLab. You're receiving this email because of your account on gitlab.com. If you'd like to receive fewer emails, you can unsubscribe from this thread or adjust your notification settings. pgpeijnvA057o.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
Yo Hal! On Wed, 16 Mar 2022 18:44:29 -0700 Hal Murray wrote: > > You should be able to login here: > > https://scan.coverity.com/dashboard > > I get to a page where it wants me to Authorize Coverity Scan. > > What's that all about? You are authorizing them to scna NTPsec directly from the GitLab repo. It is already authorized, so they jut want to get your login for it too. If you have a coverity account, I can just add you to the NTPsec account. I just added JamesB192 to the account. > > Push the fix, and wait for Coverity to run the checks again. > > I'm missing a key step. > > Coverity is on GitHub. I normally push changes to GitLab. Yes, but that is mostly for auth porposes, they pull NTPsec from GitlAb. > Do they magicly get from GitLab over to GitHub or do I have to push > them to GitHub? Yup. > How long will I have to wait? Dunno, hours to days, depends. Just have them send you an email. I just pushed some fixes to gpsd, and the coverity report took maybe 30 minutes. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpgCEwx1UPiu.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
Yo Hal! On Wed, 16 Mar 2022 16:01:17 -0700 Hal Murray wrote: > I don't know my way around coverty. You should be able to login here: https://scan.coverity.com/dashboard > Does this have a meaning? > > ** CID 349664: Uninitialized variables (UNINIT) 349664 is the serial number of the defect. UNINIT just means used before set. > Can I poke that number into a web form or something like that? https://scan.coverity.com/dashboard > I think I have a fix. How do I test it? Push the fix, and wait for Coverity to run the checks again. Once you login, you can have them send you update emails on the defects. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpVo7AMWlhuC.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Fw: New Defects reported by Coverity Scan for gpsd-gitlab
Yo All!
Another coverity found defect. See below.
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
Begin forwarded message:
Please find the latest report on new defect(s) introduced to
gpsd-gitlab found with Coverity Scan.
1 new defect(s) introduced to gpsd-gitlab found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 349687:(PW.PRINTF_ARG_MISMATCH)
/gpsd-3.23.2~dev/gpsd/gpsd.c: 619 in ()
/gpsd-3.23.2~dev/gpsd/gpsd.c: 627 in ()
*** CID 349687:(PW.PRINTF_ARG_MISMATCH)
/gpsd-3.23.2~dev/gpsd/gpsd.c: 619 in ()
613const size_t len)
614 {
615 ssize_t status;
616
617 if (LOG_CLIENT <= context.errout.debug) {
618 if (isprint((unsigned char) buf[0])) {
>>> CID 349687:(PW.PRINTF_ARG_MISMATCH)
>>> argument is incompatible with corresponding format string
>>> conversion
619 GPSD_LOG(LOG_CLIENT, ,
620 "=> client(%d) len %d: %s\n",
sub_index(sub), len, buf); 621 } else {
622 char *cp, buf2[MAX_PACKET_LENGTH * 3];
623 buf2[0] = '\0';
624 for (cp = buf; cp < buf + len; cp++)
/gpsd-3.23.2~dev/gpsd/gpsd.c: 627 in ()
621 } else {
622 char *cp, buf2[MAX_PACKET_LENGTH * 3];
623 buf2[0] = '\0';
624 for (cp = buf; cp < buf + len; cp++)
625 str_appendf(buf2, sizeof(buf2),
626"%02x", (unsigned int)(*cp &
0xff));
>>> CID 349687:(PW.PRINTF_ARG_MISMATCH)
>>> argument is incompatible with corresponding format string
>>> conversion
627 GPSD_LOG(LOG_CLIENT, ,
628 "=> client(%d) len %d: =%s\n",
sub_index(sub), len, buf2); 629 }
630 }
631
632 gpsd_acquire_reporting_lock();
To view the defects in Coverity Scan visit,
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yqNJDICWpx21HRhfIOfqp5jVIanDcsgKId5TQLLVy3HWNFDyIwNJawxMM3-2BO59tiRg-3DMyYq_V4vXdTh-2BxT-2BxCKbyFfrSoP7IYJKibTqYyKHgATb-2BpYbnITUgveY1WKmGRsYE8gafeSwWnnXlKe2i04VpFDDzYqCW3hlHlWntHSDDejFExKJ3t3LOgen0VNlO1EfPGxkK8ffkBOMQKC3r-2FpNjAOLKQX4AkYahg3jxH2O3-2FTzwgd0q3zti3rPdnAQhPYTJP2hLBREoajSDn6HNGvvg5hM8rg-3D-3D
To manage Coverity Scan email notifications for "g...@rellim.com",
click
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXx7Tfqjjbls0cEjccfNLTtXEyJGZ4VdMsA5BAyVQQG3-2BhiayktbDtQ9xydmCGCqXM-2FiCfaecVOZTo8suXWaB1cwto7f0wTnlZytc1QYkzBIo8-3Dqhn5_V4vXdTh-2BxT-2BxCKbyFfrSoP7IYJKibTqYyKHgATb-2BpYbnITUgveY1WKmGRsYE8gafuxBrFQwxxPdHVmWElGyEVAvTWP8dw0uXVX3XDdxmKM2TaEQwKXf22nE8zmP8zGCb3UonhuS-2BW7t7zJy4Pjqw0d99ob39Xc60khmVRqZv-2FO-2BhXn4sAvEXyR1lxJZAP6PfolubCQEOh2cp1QOTzol8AA-3D-3D
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpulu1OqhAaV.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Fw: New Defects reported by Coverity Scan for ntpsec
Yo All! New coverity found defect in NTPsec. See below. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin Begin forwarded message: Please find the latest report on new defect(s) introduced to ntpsec found with Coverity Scan. 1 new defect(s) introduced to ntpsec found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 349664: Uninitialized variables (UNINIT) *** CID 349664: Uninitialized variables (UNINIT) /tests/ntpd/nts_client.c: 122 in TEST_nts_client_nts_client_process_response_core_() 116 0x80, nts_new_cookie, 0, 8, 1, 2, 3, 4, 5, 6, 7, 8, 117 /* server_negotiation skipped due to getaddrinfo() containment breach */ 118 0x80, nts_port_negotiation, 0, 2, 0, 3, 119 0x80, nts_end_of_message, 0, 0 120}; 121 /* run */ >>> CID 349664: Uninitialized variables (UNINIT) >>> Using uninitialized value "peer.srcadr" when calling >>> "nts_client_process_response_core". 122 success = nts_client_process_response_core(buf0, sizeof(buf0), ); 123 /* check */ 124 TEST_ASSERT_EQUAL(true, success); 125 TEST_ASSERT_EQUAL_INT16(AEAD_AES_SIV_CMAC_256, peer.nts_state.aead); 126 TEST_ASSERT_EQUAL_INT32(8, peer.nts_state.cookielen); 127 TEST_ASSERT_EQUAL_INT8(1, peer.nts_state.cookies[0][0]); To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yp8Ldxo61EGGRiTZ6U-2Bjg3sA07-2BBpfNSmUdAWFIW4-2FfVHYSy8cV7mYfZsABp8TO5F4-3DjMwg_V4vXdTh-2BxT-2BxCKbyFfrSoP7IYJKibTqYyKHgATb-2BpYZS-2FWAmCwblwmm8OcEIl6rwptgxCXQw8DeLi3jMzJ0Ec2uQGrvTHiyT6WJjvJ8OvJIHuVm4WHhe-2BcrRqlFkHWXlMqEgTM-2BeF7kt9bKBa-2FIvADI1y13fvqPKbRdFIZSeVcua8J3HFm7RKgR-2FfDsa3H-2FOV5xPhCsZTT6emXTwZ-2B5jog-3D-3D To manage Coverity Scan email notifications for "g...@rellim.com", click https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXx7Tfqjjbls0cEjccfNLTtXEyJGZ4VdMsA5BAyVQQG3-2BhiayktbDtQ9xydmCGCqXM-2FiCfaecVOZTo8suXWaB1cwto7f0wTnlZytc1QYkzBIo8-3DjF1g_V4vXdTh-2BxT-2BxCKbyFfrSoP7IYJKibTqYyKHgATb-2BpYZS-2FWAmCwblwmm8OcEIl6rwXXxfomDL5d4K9aapJ8FcOsqqb5zd2yMSNgtK221QuiXgR7tmqseRzvquUgRSaY3Qb17dEjt-2F8P1VYncR0LVXUkkvoGxsL5JZuNZOkz-2BPwjB46Boo1leo3ugTdcZUwzKANXYyje31ZbO0eRLHnHYJSg-3D-3D RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp395n1jIaaZ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Wildcards on NTS certificates -- security
Yo Hal! On Tue, 22 Feb 2022 14:39:21 -0800 Hal Murray via devel wrote: > They don't work. See https://gitlab.com/NTPsec/ntpsec/-/issues/729 > > There is a single line of code that disables them. > > They are less secure. But is that "less" practical or theoretical? > > They are deprecated in RFC 6125 > https://datatracker.ietf.org/doc/html/rfc6125#section-7.2 > > Should we: > remove or comment out that line of code > add an option to the server line to allow wildcards > reject the bug report > ... I'd go with making it optional, not the default. > Anybody have any opinions? How strong? Not strong, but I see how some people woule need them. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpNKFhHn7aqq.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Udo! On Sat, 12 Feb 2022 12:35:43 +0100 Udo van den Heuvel wrote: > On 12-02-2022 07:36, Gary E. Miller via devel wrote: > > A capture of the raw NMEA would be helpful. > > The other gps18x does not show the wrong date. > So would a reset of the 'wrong date' gps18x work? > Powerdown/up? You need to ask just to power cycle? My guess is, no. What firmware versions are your two devices? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp1yasiQZpzx.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Udo! A capture of the raw NMEA would be helpful. On Sat, 12 Feb 2022 06:52:47 +0100 Udo van den Heuvel via devel wrote: > On 12-02-2022 06:45, Hal Murray wrote: > > > > devel@ntpsec.org said: > >> Is this an effect? I get loads of these: > >> Feb 6 00:00:28 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date > >> advanced by 0 weeks, WNRO > > > > That's a bug. Looks like it's alternating between 0 and 1024. > > > > Which sentence(s) are you using? What's your server line? (the > > mode part) I'm guessing you don't have one. Try adding "mode 1" > > > > > > Thanks for the report. > > ##NMEA zonder PPS > refclock nmea unit 0 mode 7 flag3 1 flag2 0 flag1 0 time1 0.0006 > time2 0.260 baud 4800 > # > ## PPS van dezelfde NMEA GPS > refclock pps unit 0 flag2 0 > > # vuurmuur > server 192.168.10.98 minpoll 4 iburst > > > Udo > ___ > devel mailing list > devel@ntpsec.org > https://lists.ntpsec.org/mailman/listinfo/devel RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgplrFIIqFXwM.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: TrimbleMime-Version: 1.0
Yo Hal! On Tue, 08 Feb 2022 02:55:10 -0800 Hal Murray wrote: > Have you got it working yet? I'm not sure which you are talking about. The broken RES360, or the RES720? I have a firmware update that is supposed to fix my RES 360, but I'm woorkong on the very different RES 720 right now. I'll fuss with tthe new firmware later. The RES720 is comong along. Most of the TPV stuff works, but the SKY stuff is WIP. > Gary said: > > Yesterday I fire up my Trimble RES360. And it is 2019 all over > > again. I peeked at the TSIP binary, and it is sending a negative > > GPS Time OF Week (TOW), and an extended GPS week of 2048. For > > reference this week is GPS week 2195. Transmitted as week 147 > > (2195 modulo 1024). > > Is this a production model or did they slip you an engineering > version so you would find things like this for them? The RES360 has firmware from 2006, so not new at all. It did sit on a stocking shelf for 10 years before I got it. There have been several firmware updates for major problems since 2006. > Is the negative week -147? In which case, you can just add an abs() > and go back to work. Nope. Week is stuck at 2048. It is the TOW that is negative. > Did they forget a byte swap? Nope. It actually computes the lat/lon/alt and SKY view perfectly. Since it could not increment the week, it went backwards in TOW. Thus coming to a working time solution. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpoXIGZiw2iP.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
✘Trimble and GPS Week Roll Over.
Yo All! Another twist on GPS Week Roll Over mess. Yesterday I fire up my Trimble RES360. And it is 2019 all over again. I peeked at the TSIP binary, and it is sending a negative GPS Time OF Week (TOW), and an extended GPS week of 2048. For reference this week is GPS week 2195. Transmitted as week 147 (2195 modulo 1024). There is no pivot point to work with, just pegged at 2048! Lat/Lon/Alt are correct. I looked for Trimble Firmware updates, but they seem to no longer be on the Trimble web site... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpjje6WOFXP9.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp_calendar, struct calendar
Yo Hal! On Fri, 28 Jan 2022 15:59:03 -0800 Hal Murray via devel wrote: > I think I've figured out part of what is going on. There is code > that I think is trying to do the right thing with dates past 32 bits > on systems with a 32 bit time_t. > > I'm assuming that is not an interesting case. > > I'm going to remove that code and pull the string to see how much > other code I can remove. Good for 64 bit time_t. Maybe wait a teensy bit longer for 64 bit time_t to be everywhere. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpMdwcnMGGKG.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Bogus results from NMEA/WNRO tangle
Yo Hal!
On Fri, 28 Jan 2022 22:19:15 -0800
Hal Murray wrote:
> > I handle the regressions in gpsd so no need to fix them up. They
> > have always had a line:
>
> Good. But that doesn't get the refclock drivers in ntpd. I've been
> discussing refclock_nmea.
>
> > So that is two roll overs, so far..
>
> Right. But only one pivot date.
gpsd does not use a pivot date, Why does anyone need a pivot date?
gpsd just checks if the date fro mthe receiver is less than the
build data and if so, adds 1024 until it is not.
> >> Things like WNRO fixup can be done by adding 1024*7*86400.
> >> There is no need for any calendar conversions.
> > That is not a calendar conversion?
>
> There is no year/month/day. The code I fixed was using struct
> calendar from ntp_calendar.h
Yet another calendar struct? Why not use the standard one?
Sre looke like a year/month/day:
struct calendar {
uint16_t year; /* year (A.D.) */
uint16_t yearday; /* day of year, 1 = January 1 */
uint8_t month; /* month, 1 = January */
uint8_t monthday; /* day of month */
uint8_t hour; /* hour of day, midnight = 0 */
uint8_t minute;/* minute of hour */
uint8_t second;/* second of minute */
uint8_t weekday; /* 0..7, 0=Sunday */
};
> >> The refclocks need to convert things like -MM-DD to seconds.
> >> POSIX should provide that, but doesn't. See next chunk.
> > POSIX mktime() does that.
>
> mktime uses the local time zone. We need UTC.
So use tzset() to change mktime() to use UTC.
> > Lost me. Isn't that why gpsd does everything in time_t? Doesn't
> > ntpd do the same?
>
> The context is converting GPS HH-MM-SS without -MM-DD to a time_t.
Which is what mktime() does.
> So we assume the system time is close to right, get the time_t for
> the start of today and add on the seconds-this-day from GPS.
Bad assumption. On nstatup a RasPi thinks it is 1969, again.
> The case that needs a 1 day fixup is when system time is 23:00:00 and
> GPS says 01:00:00. The time_t for start-of-today from the system
> clock needs to be bumped forward by a day.
Only if you make the bad assumption above about system time.
> Each of the refclocks is slightly different. The final result is
> that they need the offset between the refclock sample and the system
> time. Some of the code uses struct calendar and code in
> ntp_calendar. I'm trying to eliminate that.
Please do. That prolly predates the POSIX struct tm.
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpeyqJ8ksuJY.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: Bogus results from NMEA/WNRO tangle
Yo Hal! On Wed, 26 Jan 2022 19:05:17 -0800 Hal Murray wrote: > Thanks. > > Gary said: > >> We need 2 pivot dates, one for the 2 digit year fixup, another for > >> the WNRO fixup. > > > More than 2, as WKRO happens every 1024 weeks. > > I don't understand how you are counting. I see one pivot date for > WNRO. The fixup may have to take multiple steps but there is only > one date to compare against. The first roll over of the GPS broadcast week counter was: August 2, 1999. The second roll over of the GPS broadcast week counter was: August 7, 2019. Or, another way to look at it, today is GPS week 2194. Modulo 1024 that is 146, with two roll overs. So that is two roll overs, so far.. > Note that the dates we see may not pivot at a GPS pivot date. The > firmware in the GPS unit may have its own fixup code pivoting around > its own release date. Yup. Many examples in the gpsd regression data. > >> We need to add a pivot date to the release recipe -- something to > >> replace the build-date that we removed to make builds predictable. > >> > > > Maybe use the latest release data? Then we still get predictable > > builds. > > I'm setting things up so there is a header file that gets updated > with a manual edit. It needs to be done a bit before the actual > release rather than when editing VERSION. The catch is that the > testing stuff has some tests that may need fixing if the pivot date > changes. I think the release announcement is a good time. Anytime > between releases is also OK. I handle the regressions in gpsd so no need to fix them up. They have always had a line: # Date: -mm-dd gpsd uses that to override the built-in roller. > >> I'm a bit surprised that Eric's early code removal effords didn't > >> spot the calendar code. > > > Few GPS had rolled over then, so not a well understood issue. > > No, that's not the problem. There is just a lot of code doing > calendar conversions when Unix/POSIX already does almost what we > need. It's the sort of thing that Eric likes to clean up. When some of that was written, POSIX functions was not always available. Better now. > Things like WNRO fixup can be done by adding 1024*7*86400. There is > no need for any calendar conversions. That is not a calendar conversion? > The refclocks need to convert things like -MM-DD to seconds. > POSIX should provide that, but doesn't. See next chunk. POSIX mktime() does that. > >> One problem with my current code is that Posix doesn't provide a > >> UTC version of mktime. > > Garbage typo of mine. That should have been: > > One problem with my current code is that POSIX doesn't provide a > reverse of gmtime. localtime is the reverse of mktime but they both > use the local time zone. gmtime uses UTC, but there is no reverse. Why is UTC not good enough? What GPS does not use UTC? > timegm is in Linux and BSDs. If we want to run on a system without > it, we can grab a copy form the web. I don't understand why not mktime()? > >> It needs to handle the case where the GPS time and system time > >> cross day boundaries. That is unlikely to get tested. > > > Just once a day... > > Maybe. But if the system time is close to correct and the GPS > sentence comes in at a significant offset from the second tick, then > they will both be in the same second and hence same day. Lost me. Isn't that why gpsd does everything in time_t? Doesn't ntpd do the same? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgplDfBdE9j_R.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Bogus results from NMEA/WNRO tangle
Yo Hal! Sorry for the dealy, my inbox got full. On Mon, 17 Jan 2022 22:41:36 -0800 Hal Murray via devel wrote: > I think I've figured out what was going on. There are 2 stages of > fixup. One is for the 2 digit year. The other is for the WNRO. The > trick is that the year fixup has to let through known-bad years so > the WNRO has the correct data to work with. Interesting. > If the GPS unit puts out xx20 for the year, and the pivot date is > 2021, that shouldn't be bumped up to 2120. Yup. > We need 2 pivot dates, one for the 2 digit year fixup, another for > the WNRO fixup. More than 2, as WKRO happens every 1024 weeks. > We need to add a pivot date to the release recipe -- something to > replace the build-date that we removed to make builds predictable. Maybe use the latest release data? Then we still get predictable builds. > I think I have refclcok_nema working without using any of the > calendar stuff. It needs more testing. Never enough testing. > I'm a bit surprised that Eric's early code removal effords didn't > spot the calendar code. Few GPS had rolled over then, so not a well understood issue. > One problem with my current code is that Posix doesn't provide a UTC > version of mktime. Linux and BSDs have timegm. I propose we treat > this the same way we handle the BSD string routines -- provide an > implementation if the environment doesn't. According to the Linux mktime() man page: CONFORMING TO POSIX.1-2001. C89 and C99 specify asctime(), ctime(), gmtime(), local‐ time(), and mktime(). > There is code to use the current date for the NMEA sentences that > provide time without any date. That's GPGGA and GPGLL. Is there a > good reason to support that? Yes. A lot of receivers on output GPGGA, or GPGLL, and nothing else. > Is there any GPS unit that doesn't > support a sentence with the date or any reason not to use it? "support" is not the issue, "default" is. ntpd does repgrogram the receiver to what it needs. > It's not a big deal, just some minor clutter with a few lines of > slightly trickly code. It needs to handle the case where the GPS > time and system time cross day boundaries. That is unlikely to get > tested. Just once a day... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpc52XZ_WKG2.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Hal! On Wed, 29 Dec 2021 13:31:44 -0800 Hal Murray via devel wrote: > Gary said: > >> The code I was expecting doesn't know anything about leaps. > >> It would be close to: > >> while (t < PIVOT) t += 1024*7*86400 > > > Which will break after 1024 weeks. Which sounds like a lot, but > > there are a lot of GPS that are more than 1024 weeks old since > > their firmware was cut. > > Your code has similar problems. Right? Only a few of the problematic drivers have the problem. As lone as the NMEA reports the correct year, all is good. > That's 1024 weeks after ntpsec is released. I'm willing to assume > that ntpsec gets updated more often than that. Not 100%, but close. > We could add a config option to sepcify the pivot date but that > doesn't seem worth the effort. Maybe for testing, but anyone using a 1024 week old ntpd will not have read the man page in a long time. > Do we have any place to collect documentation for quirks like this? Prolly best in the NMEA doc. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpjTiSu9ahyZ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Hal! On Wed, 29 Dec 2021 03:02:00 -0800 Hal Murray via devel wrote: > Gary said: > > Basically, if the GPS reports more the 17 leap seconds, then the > > time has to be aster 1 Jan 2017. > > Thanks. > > I assume the leap second tangle is so avoid breaking some very old > test cases by bumping them into the current epoch. Only the not so very old test cases. The very old test cases needed a different fix. For those, the "# Date:" header in the regression test is used. > The code I was expecting doesn't know anything about leaps. > > It would be close to: > while (t < PIVOT) t += 1024*7*86400 Which will break after 1024 weeks. Which sounds like a lot, but there are a lot of GPS that are more than 1024 weeks old since their firmware was cut. > Are there any GPS units old enough to need to get bumped twice? Yes. A few. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpYlrAk3qCi3.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Hal!
On Tue, 28 Dec 2021 13:35:33 -0800
Hal Murray wrote:
> > That is the important part. gpsd handles that just fine:
>
> Is there anything tricky about the fixup code?
Nope. gpsd/timebase.c, line 322.
Here is the meat:
/* sanity check unix time against leap second.
* Does not work well with regressions because the leap_sconds
* could be from the receiver, or from BUILD_LEAPSECONDS.
* Leap second 18 at 1 Jan 2017: 1483228800
* (long long) for 32-bit systems */
if (17 < session->context->leap_seconds &&
1483228800LL > t.tv_sec) {
long long old_tv_sec = t.tv_sec;
t.tv_sec += 619315200LL;// fast forward 1024 weeks
Basically, if the GPS reports more the 17 leap seconds, then the time
has to be aster 1 Jan 2017.
The regression tests are dealt with elsewhjere.
> I was expecting a few lines of code. The existing code is much much
> more complicated than that.
I assume you are talking about the NTPsec code. THat does look excessive.
> Is there any magic not-before date in the ntpsec environment?
gpsd has BUILD_LEAPSECONDS, and BUILD_CEDNTURY.
> I think we used to have the build date in the version string but that
> was removed to make builds reproducable. I thought we added
> something in a #define someplace with the idea that it would get
> updated with each release, but I can't find it.
Ditto for gpsd.
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpA3gsgPVUNr.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: "default send string"
Yo Hal! On Sat, 25 Dec 2021 17:22:23 -0800 Hal Murray via devel wrote: > I'm looking at the cruft a pool server receives. > > I see UDP packets where the body is ASCII text of "default send > string". > > I'm pretty sure I've seen UDP code with that string. I can't find it > in our code. Does anybody know where it comes from? Port scanner. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpW6OLY_oIt5.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Hal!
On Fri, 24 Dec 2021 12:01:50 -0800
Hal Murray wrote:
> >> I have a NMEA unit that's off by 1024 weeks. Somebody
> >> is fixing it twice.
> > How do you know that?
>
> The time on that system got set to Nov 4 2023
>
> The "twice" part was sloppy, but something strange was going on.
>
> The log message says -4096 weeks which just adds to my confusion.
> 20 Dec 12:22:32 ntpd[40363]: NMEA(1) Changed GPS epoch warp to -4096
> weeks
Odd. Plus, or minus, 4096 sems way off.
Today, 24 Dec 2021, is GPS Week 2189 day 358.
From: https://www.ngs.noaa.gov/CORS/Gpscal.shtml
> The code is in ntpd/ntp_wrapdate.c
>
> refclock_nmea calls it in at least 2 places:
>
> case NMEA_GPRMC:
> rc_date = parse_date(, , 9, DATE_1_DDMMYY)
> && unfold_century(,
> lfpuint(rd_timestamp));
You are seeing $GPRMC.
> case NMEA_PGRMF:
> rc_date = rc_date
> && gpsfix_century(, ,
> >century_cache);
Garmin private, so you can ignore that.
> rd_reftime = eval_gps_time(refclock_name(peer), , ,
>(peer->cfg.mode &
> NMEA_DATETRUST_MASK), >epoch_warp, _timestamp);
That looks nothing like gpsd does...
> > Can you send this list a few seconds of your NMEA?
>
> $GPRMC,195031.000,A,3726.0713,N,12212.2560,W,0.00,344.40,100502,,,A*74
That is the important part. gpsd handles that just fine:
{"class":"TPV","device":"stdin","mode":3,"time":"2021-12-24T19:50:31.000Z"...
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpSj2MC59z5o.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Hal! On Mon, 20 Dec 2021 12:51:53 -0800 Hal Murray via devel wrote: > I have a NMEA unit that's off by 1024 weeks. Somebody is fixing it > twice. How do you know that? > Anybody know where that fixup code is located? I took a quick scan > in the NMEA driver but didn't find it. I don't think ntpd adjusts NMEA years. gpsd does, by looking at the leap second. Can you send this list a few seconds of your NMEA? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpBJE0o7Nx3j.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
✘Testing 1-2-3...
Yo Al;! Testing 1-2-3... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp_QTtbM1Lor.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: What does "Pipeline has been fixed" mean?
Yo Hal! On Tue, 16 Nov 2021 23:16:26 -0800 Hal Murray via devel wrote: > Subject: ntpsec | Fixed pipeline for master | fa3d3486 > From: GitLab > Date: Wed, 17 Nov 2021 06:57:06 + (Tue 22:57 PST) > > Pipeline has been fixed and #410451161 has passed! It means the CI job had failed. Someone pushed something to git head, then the CI job passed. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgp2iCzndypb8.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
