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:
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
On Wed, Apr 10, 2019, 4:47 PM Hal Murray via devel wrote:
>
> 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
Hal Murray :
>
> > 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
> 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
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:
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
Hal Murray via devel :
> I only started seeing it recently. It's probably because my DSL line has
> gone
> flaky. I don't remember any recent changes to ntpq, but it seems worthwhile
> to inquire.
I haven't touched that code in many months.
I do remember that there was a very old issue with
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
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
Yo Hal!
On Wed, 10 Apr 2019 15:01:26 -0700
Hal Murray via devel wrote:
> 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
On Wed, Apr 10, 2019, 3:01 PM Hal Murray via devel wrote:
>
> 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
Hal Murray :
> 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
13 matches
Mail list logo
