> 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, errbu
> 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.
___
> 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:
> /usr/pkg/lib/libpython2.
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
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 r
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
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
> 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
agressiv
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: BSD-4-
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'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
> 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 need
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 pac
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
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: sys
> 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
> 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.
___
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
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 such
> 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 < B
> 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 use
> 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.
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 d
> 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
> 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.
___
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
time
> 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 h
> 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 c
> 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.
>> 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
> 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 al
> 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,
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 post-re
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
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
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
1,
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
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'
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 ntpq.
(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
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
> p
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 on
> 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 loo
> 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 i
> 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 equal
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. Th
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 b
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 t
--- 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
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. 591840
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 i
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 pa
>> 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.
_
>> 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 entry
> 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
http://lists.
> 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
http://lists.ntpsec.org/mailman/listinfo/d
> 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 wa
>>> But, it will break existing NTPsec NTS. So upgrade to git head now
>>> if you use NTS.
>> What's the nature of the breakage?
> The ALPN changed to what the other NTS implementations are using.
I think I see what's going on.
Our NTS client doesn't check the ALPN string from the server. So a
ntpd/refclock_gpsd.c has:
#define _XOPEN_SOURCE 600
I see the following warning:
NetBSD:
../../ntpd/refclock_gpsd.c:2118:6: warning: implicit declaration of function
'strlcpy' [-Wimplicit-function-declaration]
FreeBSD:
../../ntpd/refclock_gpsd.c:2118:6: warning: implicit declaration of functi
I've traced it as far as it's compiling some code that I think should be
ifdef-ed out.
./waf configure build says:
...
[37/94] Compiling ntpd/ntp_monitor.c
[38/94] Compiling ntpd/nts_server.c
[39/94] Compiling ntpd/nts_client.c
[40/94] Compiling ntpd/ntp_leapsec.c
...
[78/94] Linking build/main
>> Is there time to add an IPv4 only initialization option for NTS?
> Options are bad, in general. Explain why you want this>
(I was going to poke you on this.)
There is a bug waiting for your comment - #666. Looks like you found it.
> I hate options. They add complexity and proliferate tes
> Does it make sense to call this 1.2.0 instead of 1.1.7? Especially since we
> have the ALPN compatiblity fix?
I suggest 1.1.7 soon, then a round of testing and cleanup before 1.2.0.
Or maybe wait for the NTS RFC to come out so we have a good reason for the
release.
--
These are my opinio
devel@ntpsec.org said:
>> Or maybe wait for the NTS RFC to come out so we have a good
>> reason for the release.
> What is the official (or barring that, consensus) view on the quality of NTS
> in NTPsec? Is it something that is usable in production? If so, please cut a
> release sooner rather th
> I see no changes related to _XOPEN_SOURCE since 2017. Perhaps you're
> thinking of GPSD, where there was bunch of rework in that area just before
> the 3.19 release.
Thanks. You are probably right.
Eric: This area just got more complicated. See #614
strerror_r() has two modes depending
> Has anybody seen anything like this before?
> Assuming "no", I'll try bisecting tomorrow.
My attempt at bisecting hit a brick wall. I backed up many months and it
still fails.
I guessed that something strange had happened to that system. I setup a fresh
version of 7.2 on a different box.
> Would this be a better formulation? The NTS ALPN negotiation sequence now
> checks for length of the handshake string. This may break interoperability
> with other, non-compliant, NTS implementations.
> Basically, I wish to highlight that things may *break* with pre 1.2.0
Do we have any hint
e...@thyrsus.com said:
> But doing the right thing is better than a switch. And the test is a cost
> that only needs to be paid once.
I think your no-switch approach is good for things where the choice is A or B,
like picking the right baud rate.
But this isn't one of those cases. This is a
I just changed the NTS key rotation timer from 1 hour to 1 day.
The spec is setup for 1 day. 1 hour enables testing.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Stage: build
Name: fedora-rawhide-refclocks-gpsd
Trace: GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-
31-x86_64
Public key for glibc-common-2.30.9000-1.fc32.x86_64.rpm is not installed.
Failing package is: glibc-common-2.30.9000-1.fc32.x86_64
GPG Keys are configured as:
I just pushed the code for the NTS client to check the ALPN selection returned
from the NTS server.
It logs one of 3 messages. Here are samples of 2 of them:
24 Aug 13:18:38 ntpd[28519]: NTSc: No ALPN from spidey.rellim.com (TLSv1.2)
24 Aug 13:18:43 ntpd[28519]: NTSc: Good ALPN from: time.clo
> Hal, 203.123.48.1 has been downgraded to NTPsec_1_1_6-3-g8e3daaf0b
Thanks.
24 Aug 22:07:32 ntpd[6053]: NTSc: Strange ALPN returned: *ntske/1 (8)
The "*" is fixing non graphic characters.
--
These are my opinions. I hate spam.
___
devel mailing
> How does everyone feel about next Saturday, Aug 31 2019-07-31?
Looks good to me.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
> Any updates or thoughts?
[I watched the talk but not all the Q&A.]
I think our efforts would be much more productive helping to deploy NTS.
They are trying to protect against MitM attacks, but they assume that only
some of the servers can be attacked. That misses the important case where the
I think it should be fixed for the release, but I don't know how to do it.
There used to be code in the msyslog processing that handled %m if it wasn't
included in the local printf. I'm guessing it was removed to eliminate
warnings on some systems that don't support %m.
All the %m cases were c
I've tracked down the problem, but don't know how to fix it.
NetBSD 7.2 has an optional newer version of OpenSSL. pkgin has installed it.
I didn't do that explicitly so I assume it was dragged in by something I did
install. Looks like python37-3.7.3nb1
waf is using the new headers.
-I/us
How do I tell waf to fail on warnings?
I'm trying to use this to detect which API I'm getting.
STRERROR_FRAG = """
#include
int main(void) {
char buf [100];
const char *foo = strerror_r(6, buf, sizeof(buf));
return foo == NULL;
}
"""
ctx.check_cc(
fragment=STRERROR_FRAG,
> A relatively quick search suggests mandatory=True as an argument.
That makes waf fail if the code chunk doesn't work.
I'm trying to make the code chunk not-work if it gets a warning, but then let
waf put a comment in config.h to indicate that a feature test didn't work
rather than put a #defi
I think fixing the _GNU_SOURCE is going to take a lot of work, and we should
probably a change of that nature lots of time for extra testing. So I
implemented a local wrapper that uses a configure time test.
The code for mystrerror is in the bottom of libntp/msyslog.c
The waf code is in wafhe
matthew.sel...@twosigma.com said:
> And you want to pass "-Werror" (I'm not certain how off the top of my head)
> to the compiler so that warnings are fatal. waf sees the compiler exit zero
> with or without warnings, so they look the same.
I put it into ctx.env.CFLAGS, then restored CFLAGS bac
Merge Request !1026 was merged
The Subject says "Converted stat_count struct to a module level global"
The code looks like it is un-struct-ing things.
Was that "a module level global" supposed to be "module level globals"?
What's the policy on this area? I thought the general idea was to put t
Thanks.
Ahh... Part of the problem is that I misread the diffs. I didn't notice that
the additions were procedures. I thought it was restoring the individual
counters.
ianbru...@gmail.com said:
> It is reducing unnecessary globals because globals are a good thing to
> reduce.
In general,
Sanjeev Gupta said:
> Gary, ALPN string checking. The commit mentioned that it would break with
> previous NTPSec versions.
No. The client didn't check the returned ALPN string. It didn't even look to
see if there was a returned ALPN string.
I added that checking recently. It doesn't bail
Gary said:
[API for strerror_r()]
> On Linux, yes. But not on all distros. For example, on Android, which gpsd
> supports, strerror_r() always returns an int. No options.
Same on NetBSD and FreeBSD.
The quirk that's not in the man page is that the GNU version doesn't use the
buffer you pro
>> By "floating", you mean uninnitialized? In C that's going to mean it's
false
> Yes. My understanding of C is that anything not explicitly set has whatever
> random value happens to be in that memory location. Possibly changed if
> certain unknown compiler options are chosen.
I thought g
Richard Laager said:
> This is an untested (beyond building cleanly) patch for cleaning up the
> strerror_r() API issue.
What environment did you use?
I get several warnings on Fedora.
../../libntp/isc_net.c: In function âtry_protoâ:
../../libntp/isc_net.c:56:4: warning: implicit
I missed some uses of strerror_r() in the ISC routines.
I think all uses of UNEXPECTED_ERROR should switch to msyslog
Then we can delete include/isc_error.h and libntp/isc_error.c
--
These are my opinions. I hate spam.
___
devel mailing list
deve
Context is issue #615
The system is NetBSD 7.2, old but still supported.
It has a newer OpenSSL installed in /usr/pkg/
/usr/include/openssl/opensslv.h:# define OPENSSL_VERSION_NUMBER 0x1000115fL
/usr/pkg/include/openssl/opensslv.h:# define OPENSSL_VERSION_NUMBER
0x1000210fL
The old version d
I think I have figured out the big picture. PLATFORM_INCLUDES and
PLATFORM_LIBPATH are our variables rather than something waf knows about. (I
downloaded both source and book for waf, no hits.)
PLATFORM_LIBPATH is write only.
-bash-5.0$ grep PLATFORM_LIBPATH . -r
./bob2/c4che/main_cache.py:
The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.1.1d, 1.1.0l and 1.0.2t.
These releases will be made available on 10th September 2019 between
approximately 1200-1600 UTC.
These are security fix releases. The highest severity security issue
fixed by th
Any openssl command line wizards?
What do I type to find out when my certificate expires? We should make a
script that can be called from cron.
What do I type to figure out which cert in the root collection for my
OS/distro that a NTS-KE server is using? I'd like some code I can cut-paste
-* We intend to fully support Network Time Security and to be first or
- second interop on that standard once it is finalized. At that
- point, older insecure authentication methods (MAC and MS-SNTP) may
- be removed.
+* Now that we have full Network Time Security, a neasr-future
+ direction i
wscript and friends have various things like:
if ctx.env.DEST_OS in ["freebsd", "openbsd"]:
ctx.env.PLATFORM_INCLUDES = ["/usr/local/include"]
I think the PLATFORM_ part is leftover from an old old version of waf.
ctx.env.PLATFORM_INCLUDES works because our code has things like:
There are various #ifdefs testing RLIMIT_MEMLOCK and friends
The Linux man page for setrlimit says:
getrlimit(), setrlimit(): POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.
So I think we can assume it exists and remove the #ifdefs.
Any reason not to?
Why is the -D PYTHON stuff clut
Two areas to consider:
Port randomization:
https://tools.ietf.org/html/draft-gont-ntp-port-randomization-04
The basic idea is for the client side to use a random port number when sending
packets so bad guys have a harder time attacking with junk packets if they
can't monitor the traffic to
devel@ntpsec.org said:
> I'd like to see "struct shmTimme" cleaned up and move into a header file for
> system use.. Right now it is not in any header file, so clients like gpsd
> need their own copies.
Assume we had a nice header file. Where would it live? What are the
mechanics of getting
> I always liked the idea of moving to a shm or a local socket "clockd"
> interface.
My comment and Gary's was only to clean up the existing SHM interface. No
changes outside refclock_shm.c (and whatever it takes to support a new/clean
header file)
> (Under the hood, a UNIX domain socket or
> - a multicast DNS broadcaster for NTS.
> - additions to the DNS code to allow non-A/ pools. (cname/srv probably)
> - Additions to the DNS code to allow for mdns monitoring.
I'm not a DNS wizard. That area is slightly ugly in that the DNS work is done
in a separate thread so there is som
> Are UNIX domain sockets available on all OSes? If so, that's worth
> considering.
One advantage of the read-only SHM mode is that it supports multiple readers.
So you could run shmmon while ntpd is also running.
--
These are my opinions. I hate spam.
> Another is that you can allow anyone on the localhost to read the SHM without
> any risk of them messing up the SHM data.
Good point.
> It is also fast since it is memory mapped. No system call overhead.
CPU cycles aren't important for refclocks. (at least within reason)
The disadvantage
1 - 100 of 1887 matches
Mail list logo
