> Is there some plan to have more than one NTS protocol??
ALPN also lets you negotiate different versions of the same protocol.
I doubt there are any near-term plans for a new version but we will want the
extra loop (or equivalent) if/when we ever implement a new version of NTS.
I'm happy to
> But, it will break existing NTPsec NTS. So upgrade to git head now if you
> use NTS.
What's the nature of the breakage?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
> I was not sure if broadcast as a server was dropped for similar reasons.
The text for broadcast and multicast are not in the keyword generating file.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
>> I was looking for more information. Why can't we secure it?
> Daniel explained it to me once, but I've forgotten the details. Perhaps he'll
> speak up.
The delay/replay problem is fatal, at least with a simple public key system
like I proposed.
There is probably something like a FAQ
>> What's wrong with using a public/private key to sign each broadcast packet?
> However, there is not reasonable protection against delayed or replayed
> packets.
Thanks. That's what I was looking for.
--
These are my opinions. I hate spam.
e...@thyrsus.com said:
> That's covered. In the page on NTPsec changes:
> * Broadcast- and multicast modes, which are impossible to
> secure, have been removed.
I was looking for more information. Why can't we secure it?
What's wrong with using a public/private key to sign each broadcast
e...@thyrsus.com said:
> Go ahead. Whatever broadcast code was left is pretty much a vermiform
> appendix, anyway.
The only leftovers that I know about are packet types. They may be used by
ntpq.
I remember a comment about there being no way to do broadcast securely. It
would be good to
Anybody seen this yet? (I assume not, or it would have been fixed.)
Has the new ntp_wrapdate.c been tested? Should the warp be positive or
negative?
This is on a 32 bit system. The GPS chip is a MTK-3301
ntpq -p shows:
xNMEA(0) .GPS.0 l 29 64 377 0.
--- Forwarded Message
From: Michael Cardell Widerkrantz
To: n...@ietf.org
Date: Thu, 25 Jul 2019 11:45:52 +0200
Message-ID: <877e86qwfj@tp1.hack.org>
Subject: [Ntp] NTS in Go
Martin Samuelsson, Daniel Lublin and I participated remotely during the
recent IETF hackathon. Our friend omni
Sorry for the delay. I got distracted on other things.
While I think of it, did TESTFRAME dump floating point numbers in ASCII or
hex? If ASCII, there are likely to be round off errors when you read them
back in. Were there any floating point numbers that were read back in? (as
compared
tenterl...@gmail.com said:
> I come from a scientific background, where we compare results somewhat as
> analog values. If the test result is off the expected by 1000%, that's bad.
> If it's off 1%, better. If the error is .1%, probably within achievable
> accuracy.
There is a difference
Mark's comment about lots of data reminded me that I meant to send this a
month ago. I guess it fell through the cracks.
Most of the talk is about open systems, not much about Jupyter itself.
Nothing NTP related. The first 30 minutes is Guido then Fernando describing
history and culture.
> Can you get them to specify exactly what they want?
One thing to add to the list if you are going to collect NTP data...
If you know that the clocks at both ends are accurate, rawstats will give you
the transit times in each direction.
NTP assumes the transit times in each direction are
> It's...hm...maybe a good way to put it is that the structure of the NTPsec
> state space and sync algorithms is extremely hostile to testing.
I still don't have a good understanding of why TESTFRAME didn't work. I can't
explain it to somebody.
We've got
code mutations
hidden variables
> Especially the idea of verifying key parts of the state space, even if we
> can't verify it all. And especially if there was a way to usefully log the
> relative timing of various important state transitions. (That is something
> on the wishlist of the AWS NTP Kronos team.)
What are they
e...@thyrsus.com said:
> A lot of configuration options - even things like minsane - effectively
> change the FSM.
Right. But as you said, that's a configuration option.
> Sure, you can think of the config as part of the input state - this isn't a
> code mutation. But it also means you can
e...@thyrsus.com said:
> https://blog.ntpsec.org/2017/02/22/testframe-the-epic-failure.html
> Read that and think about it for a while. This is a very hard problem. I
> hit it and bounced.
Thanks.
>From the blog page:
> In effect, the entire logic of the sync algorithms is a gigantic free
>
(Context is that I went to edit a config file to test something and I ran into
some cruft leftover from testing something else.)
Handwave...
There are a zillion corner cases that I'd like to be able to test. A typical
example is something like: with configuration X, Y should happen. You can
Description : flatpak is a system for building, distributing and running
: sandboxed desktop applications on Linux. See
: https://wiki.gnome.org/Projects/SandboxedApps for more
: information.
I'm guessing it's targeted at things more complicated than
Is there a reason that warnings don't default to on?
When configured with --enable-warnings, I get this on an old gcc.
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
../../ntpd/ntp_wrapdate.c: In function 'eval_gps_time':
../../ntpd/ntp_wrapdate.c:226: warning: declaration of 'refclock_name'
Has anybody tried building ntpsec on Windows? Cigwin? I'm just curious. How
close are we?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Consider something like the collection of samples from a PPS. Assume ntpd is
not running so the system clock is not bouncing around.
There is some noise with each sample. If you collect several samples, you can
average them to get a better number. You probably want 2 numbers rather than
Introducing time.cloudflare.com
https://blog.cloudflare.com/secure-time/amp/
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
I made an update pass. More eyeballs would be good.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
NTS has been working for a while without any serious problems. We may have to
tweak a few details when the actual RFC gets published but it seems unlikely
there will be any major changes.
Is there any reason not to do a release now/soon?
If not, I'll tweak the NTS documentation to be
> Which means it's time for a serious on-list conversation about what our next
> major objective beyond wrapping up NTS is.
Other ideas to consider...
Randomize client side ports. (big messy discussion on IEFT list)
We may want/need servers supporting NTS to support non standard port number,
> Yeah, but I'm not sure it would be efficient to pull the trigger on anything
> like this until we figure out how many months out the Go port is.
We could also use the "simple" client/server NTS-KE samples as warm ups on the
Go port. I think the client side is pretty simple - OpenSSL does
>> Does ntpdig know about NTS? Seems like it should be able to ue NTS.
> That would be pretty tricky, actually. We'd have to expose the NTS crypto
> and key-exchange primitived as a C extension to Python.
Another possibility...
On my back burner, is a pair of NTS-KE programs, one for server
> I'm inclined to ignore TLS 1.3 until the openssl 1.1.1 bugs are worked out.
I've forgotten that stuff. What is/was the problem? OpenSSL is up to 1.1.1c
I have a vague memory of 1.1.1a fixing something we were interested in.
--
These are my opinions. I hate spam.
> I think the other end is on TLS 1.3 only, but my end only supports TLS 1.2
Well, if that's the setup, it's not going to work. It should be possible to
setup a test case.
We might be able to produce a better error message. What was the surrounding
log info?
(That stuff has fallen out of my
> I'm not going to look at that stuff on YouTube⦠any link to oldfashioned
> non-multimedia?
Here is a Usenix paper that covers the same ground:
https://www.usenix.org/system/files/conference/nsdi18/nsdi18-geng.pdf
The interesting graphs are on page 7 (86).
--
These are my opinions. I
https://www.youtube.com/watch?v=Opf9CBwP5R8
Several ideas.
One is the use the PTP style time-stamping available on many modern Ethernet
interfaces. Does anybody know how that works? API? I assume there is a
counter in the Ethernet hardware. How does that counter get converted into a
> You should be able to plug it into a Pi without a hat. It takes 3 wires:
> ground, power, and signal.
I screwed up. It's 2 signal wires.
I got one when they were announced, but it fell through the cracks. Time to
clean up my desk.
--
These are my opinions. I hate spam.
> An eBay search for "EverSet ES100 WWVB BPSK Phase Modulation Receiver Kit"
> should prove fruitful. I have one - but I haven't had time to tinker with
> it yet.
>
> The kit comes with the double-antenna setup that appears to be key to the
> improved reception. In the clocks, the antennas are at
Ian said:
> In trying to write tests for nts_client.c I have run into a problem I do not
> know how to solve, as it involved much of the structure of the codebase as
> well as the build system.
> Some of the code in nts_client.c calls the dns_take* series of functions.
> These functions are
> No, that description only holds for what are called "coarse" clocks.
Do you understand this area?
I think the term I've been missing is "dither". I don't understand that area
well enough to explain it to anybody. Interesting timing. I was at a talk a
few weeks ago that covered dithering.
> Also the PLL goes up and offsets rise. (just like before)
Another way to maybe learn something.
Can you grab a copy of
http://users.megapathdsl.net/~hmurray/time-nuts/60Hz/60Hz.py
It's a hack to measure line frequency using the PPS capture logic. The idea
is to turn that inside out and
> HPET is a travel out to ACPI system registers mapped into memory, this should
> never be never cached.
Yes. But there is still the cache for code and data.
This sort of code is amazingly delicate. Minor changes can make interesting
changes in the results.
For example:
for (i = 0; i <
devel@ntpsec.org said:
> That's a fantastically wierd distribution. Here's what my old single core
> Athlon64 does:
Your sample is what I would expect from a system that isn't doing much. If
there is other activity going on, the clean bell curve gets spread out due to
cache reloads and
udo...@xs4all.nl said:
> ntpsec 1.1.3's ntpd from ftp://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz
> gives me after startup:
> Apr 13 15:53:50 bla ntpd[12382]: CLOCK: ts_prev 1555163630 s + 594156272 ns,
> ts_min 1555163630 s + 594155713 ns
...
Thanks.
So now we know it wasn't a recent
> I know about bisect but it is quite a task.
HPET works for me.
So far, you have the only test case.
Plese give it a quick try to see if ntpsec is the problem. How about just
trying the 1.1.3 release?
--
These are my opinions. I hate spam.
> clocksource is fixed at hpet since the previous situations where clock sync
> was weird/gone/etc.
> I never ever saw these before.
Something changed. All we have to do is figure out what/when.
Was the switch to using HPET recent?
Did you do a recent git pull? Do you know how to drive git
Here is a typical batch of the confusing CLOCK printout:
Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts_prev 1555072655 s +
712154322 ns, ts_min 1555072655 s + 712153764 ns
Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts 1555072655 s + 712154322 ns
Apr 12 14:37:35 box.local ntpd[2109]: CLOCK:
Gary said:
>> Somebody on 2600:1700:6731:6c0:f2de:f1ff:fe20:1bbe is sending you
>> packets that don't make sense. Same for 68.75.8.147.
> Those two hit my hackathon server as well. But the connection is a normal
> NTPv4 exchange on UDP.
Depends on what you mean by "normal". How much did you
The "JUNK" stuff is for debugging NTS. The most important part is the length
at the end. It's rate limited so there shouldn't be any serious problems with
clutter in the log file - just minor potential confusion like this.
Somebody on 2600:1700:6731:6c0:f2de:f1ff:fe20:1bbe is sending you
> I just realised something: LetsEncrypt certs are max 90 days. When I renew
> them, will I need to restart NTPd?
Interesting timing. Richard's recent message reminded be of that issue.
Currently, you have to restart NTPD.
There is already code for doing things like that on SIGHUP. We
I'm close to finishing cleaning up all the FIXMEs I had left behind.
What's next?
There are 2 major items on my list:
More and/or alternate certificate checking.
There are lots of possibilities in this area. I haven't found one that
looks clean and simple. We can afford modest amounts of
Gary (on users) said:
> Sure feels like a droproot permission problem.
It's a feature, not a bug. ;(
If gpsd runs first, it needs to set things up so user ntpd can write to the
SHM it creates. ntpd would have the same problem if gpsd had an
early-droproot.
Can we fix this by putting users
I just updated the NTS code to include a Copyright, copied from another module.
If this isn't appropriate, please tell me what it should be.
/*
* nts_cookie.c - Network Time Security (NTS) cookie processing
* Copyright 2019 by the NTPsec project contributors
* SPDX-License-Identifier:
> It's one of the few times I've gone on an expedition like that and completely
> failed. Whatever it is, it's not going to be obvius.
Here is an interesting possibility. How about the code is working as designed
but the parameters are set wrong. Maybe not "wrong". How about "not
g...@rellim.com said:
> I would go further and say that order matters not at all. What matters is to
> start both as root. Depending on whether I am working on gpsd of ntpd I will
> just keep restarting the one I am working on. Never an issue.
How do you configure ntpsec?
I think the order
Thanks.
There is another quirk that seems related to retransmissions. I forget the
details. I'm pretty sure there is bug report on it.
> I do remember that there was a very old issue with flaky behavior of ntpq
> over WiFi that we thought might be due to a bug in the fragment reassembly
If
I'm seeing things like this when doing ntpq -p to a far away site with lots of
opportunities for lost packets.
***No information returned for association 21216
Has anybody seen anything similar?
I only started seeing it recently. It's probably because my DSL line has gone
flaky. I don't
The old code had several cases where there were 2 counters for things like
received NTS packets, total and bad. I changed that to good and bad.
A mix of old/new ntpq/ntpd won't show the total or good.
--
There is a lot of crap out there on the big bad internet.
NTS KE serves good:
Gary said:
> I fixed the libjsmn missing default one.
Thanks.
And thanks to whomever fixed the MacOS glitch.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
> I'm unaware of any we can't fix, except the bison one.
There are several others.
>From old CentOS:
> ntp_parser.tab.c:389:6: warning: "YYENABLE_NLS" is not defined
> ntp_parser.tab.c:1323:6: warning: "YYLTYPE_IS_TRIVIAL" is not defined
>From NetBSD on a Raspbery Pi:
>
> New warning on arm64:
Also happens on Fedora, both 64 and 32 bit.
Is it reasonable to fix the CI system to complain about warnings except for a
(hopefully short) list of known ones that we can't fix?
--
These are my opinions. I hate spam.
> Does a simple void cast work? E.g.:
> (void) strerror_r(...)
I haven't found the magic using that approach.
../../ntpd/nts.c:214:16: warning: ignoring return value of âstrerror_râ,
declared with attribute warn_unused_result [-Wunused-result]
(void) strerror_r(errno,
e...@thyrsus.com said:
> Probablty compiler version. As GCC has evolved it has gotten stricter about
> this sort of thing.
Fedora 29, no warnings:
gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
Ubuntu 18.10, warnings
gcc (Ubuntu 8.2.0-7ubuntu1) 8.2.0
Ubuntu 18.04.2 LTS, warnings
gcc (Ubuntu
It gets 23 warnings on Ubuntu:
../../ntpd/nts_client.c:436:5: warning: ignoring return value of
âstrerror_râ, declared with attribute warn_unused_result [-Wunused-result]
---
There is a trap in libntp/lib_strbuf.c that should log a message if
lib_getbuf() is called from other than
../../ntpd/nts.c:213:9: warning: ignoring return value of âstrerror_râ,
declared with attribute warn_unused_result [-Wunused-result]
I'm only getting this on Ubuntu, so a secondary question is why isn't that
check happening on other systems?
>From the man page:
int strerror_r(int
I'm adding a trap to ntplib/lib_getbuf() that needs to get initialized.
I found main() in tests/common/tests_main.c, but I can't find any similar
initialization in the python testers.
Where should I be looking?
--
These are my opinions. I hate spam.
> Assuming this isn't blocking the daemon generally, I'd probably leave it to
> the default. I can't immediately come up with a justification as to why
> NTS-KE is different from other TCP protocols. I'm not very confident in this
> answer, though, so take this with a grain of salt.
There
How long should NTS-KE wait?
The current code uses 3 seconds, but I missed the connect() so it uses the
default for that which is ballpark of 2 minutes.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
> That is zero for ten...
> I can't say why the results differ from previous tests.
Check the log file. There should be a message telling you the file or
directory it is using. If you don't find that, you probably typo-ed the
server line.
--
These are my opinions. I hate spam.
> 3. I see big differences in jitter and latency between IPv4 and IPv6.
>I want to characterize the diffeence, then select the best.
For testing jitter and latency, you can specify -4 and -6 to get NTP using the
desired protocol. Is there a reason you need to do KE using the other
> But this brings up another related issue. We're preferring IPv6 by default,
> right? That should be the default, but I just wanted to ask.
It uses the first answer it gets back from getaddrinfo
I just scanned the man page. I didn't see anything about the order of
returned answers.
ntpd
> Why? Well, my IPv6 connections have much less latency and jitter than my
> IPv4 ones. Without -4 and -6 on the NTP part of NTS I can't make those
> comparisons easily.
If you put the -4 after the "server", it does both the KE and NTP using -4.
Is there a reason you need to do KE over one
> No. LE has FIVE root certs. Maybe you can call it a split root. And you
> have no way of knowing which one they use for any particular cert.
> And note the specifically say: "Our roots are kept safely offline."
> So you can't even get the root to check it!
"root" is ambiguous without
> Most of the thread was about trying all the possible IPv4 and IPv6 addresses
> returned for the NTPD server until one worked. So assuming IPv4 for the NTPD
> when the NTS-KE is IPv4 is not what the WG expects.
I didn't see any consensus that we have to implement all possible
combinations,
> I agree with Gary in that it seems perfectly reasonable that KE
> and NTP could be on different address families. If an IPv4 KE
> server returns a hostname with only records, that would
> happen. Or if it returns an IPv6 address directly. Or vice versa,
> with an IPv6 KE server returning
> Why not? This was discussed on n...@ietf.org. People need and want it.
I don't remember that discussion. If you give me a URL to the archives, I'll
review it.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
> If nts in on the server line, any failure should be fatal.
If the "nts" is after the error, the parser won't see it.
>> You can switch the log file from the command line.
> I'd prefer a sane default.
The default is syslog.
I think most distros have some way to split the syslog stuff into
> Any way to get that into ntp.log? My /var/log/messages grows massively by
> the second...
You can switch the log file from the command line. I haven't tried it.
> So it found the moved -4 flag, but missed the other problems.
> Apr 2 11:25:42 kong ntpd[12859]: CONFIG: line 46 column 20
>> The parser actually does complain. But if you are like me and put
>> the log file in the config file rather than the command line, the
>> parser errors go to syslog.
> Uh, no:
> kong /usr/local/src/GPS/gpsd/gpsd # fgrep NTP /var/log/messages kong /usr/
> local/src/GPS/gpsd/gpsd #=20
grep
> So it does report something, just not what it should. "ca" should not need a
> "root" or "issuer" cert to work.
The text of the error messages represent the API. You gave me a directory.
It's getting plugged in as the place where openssl looks for system root certs.
The issuer line is
Gary said:
>> I think the "-4" is only valid between "server" and the
>> filename. The parser may have dropped the rest of the line.
filename => hostname (my typo)
Note that your "maxpoll 5" didn't make it either.
> Ouch. The parser bytes me again. The lack of parser diagnostics is a
>
> server pi3.rellim.com nts -4 nts maxpoll 5 ca /tmp # pi3
> My server still connected to pi3.rellim.com:
> pi3.rellim.com .PPS.1 82 643 0.5473 -0.0559
> 10.4857
Interesting.
My quick try didn't reproduce your problem. What's in your log file. There
should be
[Argh. Sorry for the duplicate. I forgot to cc the list.]
> Sad. Seems we've been around this May Pole way too many times already... You
> have nothing new to say below, and my answers are also not new.
Richard's summary matches my understanding.
> Agreed, sort of. This assumes fixes that
FreeBSD hasn't updated to 1.1.1b yet.
1.1.1a has a bug such that it can't make our C2S and S2C keys. It works if we
downgrade to TLS1.2
I've hacked the code to do that automagically.
(I also fixed the error handler for that case - 2 places.)
--
These are my opinions. I hate spam.
I split out the ssl parts of processing in nts_server. I didn't change
nts_client yet.
I think I put the routines you want into nts.h
I think you can test cookies. That will exercise the AES_SIV crypto routines.
You will need to call nts_cookie_init (to setup the crypto context)
> After staring at the code for long enough I see a number of natural cleavage
> points for solving this issue. MR in a few days.
There is some cleanup I've wanted to do in that area anyway. I'll try to get
to it tonight.
> Is there any particular reason why SSL structs need to be passed
> HPET should be OK, but if you can figure out why the TSC doesn't work that
> would be better. Check what clocksources are available, there might actually
> multiple TSC to chose from.
If I was going to chase this, I'd look at the kernel sources to see what
changed. I haven't seen similar
> A sockaddr is not meant to store the address, ...
But the API wants a sockaddr.
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
There is no hint in the man page that an IPv6 address won't fit.
sockaddr ends with
sa_data[14];
That's not big enough for an IPv6
I just pushed a fix. It was an interesting quirk. The API for accepet
includes a pointer and length to a place to put the IP Address of the remote
site. The type of that place is struct sockaddr. sockaddr is generic,
presumably big enough for the biggest address format. They botched
Gary said:
>> There is a downside. Every time it changes, you have to take
>> a leap of faith when you re-pin it, rather than getting normal
>> CA validation.
> You miss the point, this is addition to normal CA validation, not an
> alternative to it. Just like HPKP.
I'm missing something
Gary said:
> I don't think anyone suggest blocking non NTS servers, yet.
I think we should be thinking about it. Seems like a good check-box for an
auditor.
It's what I had in mind with something like a "secure yes" option.
(I included shared-key authentication as secure)
--
These are my
>> Try deleting your drift file and restarting ntpd.
> Already tried that.
Humm. Would you please try again and send me the log file.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
I've pushed a fix for my problem (numeric IP address). I had forgotten to
remove Gary's patch to avoid the segfault. I guess I did most of my testing
before I pulled that change.
Gary reported troubles with nts3-e.ostfalia.de
It works for me in a quirky sort of way.
>From
> pll frequency: 500
> frequency tolerance: 500
> How to proceed to normalize the offset?
Try deleting your drift file and restarting ntpd.
There is an old bug in this area. Nobody has any ideas on what is going wrong.
--
These are my opinions. I hate spam.
> Only if the cert is not pinned. Pretty much every else I do with certs
> eventually requires pinning. NTPsec will be no different.
Could somebody please give me a lesson on this area?
What is pinning? Why have I not encountered it before?
If ntpsec supported it, what would it look like
Richard Laager said:
> Does NTS with noval actually buy us anything over plain NTP?
It's handy for debugging.
It breaks security if the bad guy can do a MITM.
--
I was thinking along the same lines. Should we have a command line switch,
say "--secure", that requires nts (without
> Today's changes broke osfalia.
Something is screwed up. I haven't figured out what.
My test case is:
server204.17.205.23 nts noselect noval # pi3.rellim.com
It's not going through the NTS-KE dance. It will probably be simple after I
find it.
--
These are my opinions. I
> Now it does not crash, anyway to make it work?
> I need to use some IPs for private, offgrid, networking.
I use /etc/hosts, so that hasn't been a problem for me.
> If you only need the name for the cert, and you are not checking the cert, it
> should work.
Yes, but I need to get some quiet
>> Are you trying to use NTS on an IP Address? Known bug. [That
>> "(null)" happens on that case.]
> Nope. Here is the line from ntp.conf that crashes my slow RasPi. But not my
> fast RasPi:
> server 204.17.205.23 maxpoll 5 nts # pi3
That sure looks like at IP Address to me.
--
These
devel@ntpsec.org :
> Thread 4 "ntpd" received signal SIGSEGV, Segmentation fault. [Switching to
> Thread 0x75b1a460 (LWP 26062)] 0x76cfb6fc in strlcpy () from /usr/lib/
> libbsd.so.0
> Any idea how to make gdb more useful here?
"bt" (for backtrace) gives you the stack trace
In many cases,
> Always fails for me. On seversl different RasPi.
2019-03-26T13:35:09 ntpd[26050]: DNS: dns_probe: (null), cast_flags:1, flag=
s:21001
Are you trying to use NTS on an IP Address? Known bug. [That "(null)"
happens on that case.]
I thought I mentioned that case before but I guess I wasn't
> I applied today's NTPsec git head, with the mysyslog patches. Older and
> slower RasPi still crash on startup if the try to be an NTS client.
Works for me. It's old enough that it has only 2 USB ports.
--
These are my opinions. I hate spam.
I thought it had been removed.
Job #183497467 ( https://gitlab.com/NTPsec/ntpsec/-/jobs/183497467 )
Stage: build
Name: debian-oldoldstable-refclocks
Trace: Err http://deb.debian.org oldoldstable-updates/main amd64 Packages
404 Not Found [IP: 151.101.248.204 80]
W: Failed to fetch
> My slower RasPi have random startup crashes. Goes away when I do not make
> them NTS clients. Feels like another mysyslog() thing?
I'd expect garbage in the log files rather than crashes.
There is a known bug: nts doesn't work with IP Addresses. Gets a segfault.
That case might make
601 - 700 of 2329 matches
Mail list logo
