Re: SIGINT, longjmp
On Tue, Jan 26, 2016 at 01:07:04PM -0800, Hal Murray wrote: > > The problem is that somebody is masking off SIGINT. It works if I replace > setjmp+longjmp with sigsetjmp+siglongjmp. > > The SIGINT handler was getting called with SIGINT masked off. That seems a > bit strange. It was coming from deep within getnameinfo. > > I haven't figured out if this is a bug in getnameinfo or if longjmp-ing is > basically evil. It's not clear to me when this longjmp() is called. But if changing to siglongjmp() fixed it, it seems the signal handling got changed in between? Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: SIGINT, longjmp
On Tue, Jan 26, 2016 at 01:38:52PM -0800, Hal Murray wrote: > > k...@roeckx.be said: > > It's not clear to me when this longjmp() is called. But if changing to > > siglongjmp() fixed it, it seems the signal handling got changed in between? > > It's called from the ^C signal handler. It's the brute force way of > terminating a command. Why do you set up a signal handler for this, and don't let the OS take care of it? Or alternativly, just call _exit() from the signal handler. > I haven't found anyplace in our code that messes with the signal mask. I > could easily be overlooking something that will be obvious in hindsight. Maybe getnameinfo() does. Like I said before, you need to be careful of what you do in signal handlers. Calling longjmp() clearly isn't documented as being safe to do in that context, for a list of functions see man signal(7). Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: SIGINT, longjmp
On Tue, Jan 26, 2016 at 11:03:01PM +0100, Kurt Roeckx wrote: > > I haven't found anyplace in our code that messes with the signal mask. I > > could easily be overlooking something that will be obvious in hindsight. > > Maybe getnameinfo() does. I want to add that it likely does at least something with the signal handlers so that it can time out. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: An ontology of clocks
On Fri, Feb 19, 2016 at 03:19:01PM -0800, Gary E. Miller wrote: > Yo Daniel! > > On Fri, 19 Feb 2016 18:12:52 -0500 > Daniel Franke wrote: > > > On 2/19/16, Gary E. Miller wrote: > > > No, resolution is the smallest time increment a clock can represent. > > > Precision is a measure of the quality of the clock time. > > > > I've seen "precision" used both ways by different authors, but I think > > you're right that resolution is a better choice of terminology because > > it avoids that ambiguity. > > > Yes, people get sloppy, but since we are on the ntpsec mailing list we > should prolly to stick to the NTP definitions. > > According to ntp.org: > > http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm > > "The smallest possible increase of time the clock model allows is > called resolution." > > "Precision is the random uncertainty of a measured value, expressed > by the standard deviation or by a multiple of the standard > deviation." > > "Accuracy is the closeness of the agreement between the result of a > measurement and a true value of the measurand." And that is not even specific that NTP, that's just what those terms mean. But you can argue how you express the precision exactly, and standard deviation is probably the easiest to understand and what most people will care about. (I was also about to comment about this, but then saw the other mails.) Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: An ontology of clocks
On Fri, Feb 19, 2016 at 05:56:04PM -0500, Daniel Franke wrote: > At a high level, a clock is characterized by the answers to three questions: I guess that should be four ... > # II - What drives it? > > A typical PC has several oscillators. In addition to the main one, > which sends clock interrupts to the CPU, there's likely to be a > separate one on each NIC (important for PTP), one driving the RTC (aka > BIOS clock), and perhaps an external oscillator providing a PPS > signal. You're missing at least a few ones here that are available on typical PC hardware, including the pit, hpet, tsc, ACPI timer. > * CLOCK_MONOTONIC_RAW is an atomic clock with an unspecified epoch and > a precision of one nanosecond. It is driven by the system oscillator. > It supports no adjustments at all. It is corrupted by suspending or > rebooting the machine. I'm sure what you mean by corrupt in the case of suspending. It's still measuring something, but maybe not something you (or ntp) cares about. I guess this falls under your category of "clocks that count time selectively". Also, the 1 nanosecond might not be the resolution. It's going to depend on the system. You need to call clock_getres() to find out what the real resolution is. But 1 nanosecond is the best you can expect. > * /dev/rtc0 is a clumsy clock with a specified epoch and a precision > of one second. It is driven by the RTC oscillator. It supports > stepping. It is corrupted only by the death of the CMOS battery. It actually supports various frequencies. There is also at least /dev/hpet that you might want to look at. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: An ontology of clocks
On Mon, Feb 22, 2016 at 03:16:54AM -0800, Hal Murray wrote: > > dfoxfra...@gmail.com said: > > I've seen "precision" used both ways by different authors, but I think > > you're right that resolution is a better choice of terminology because it > > avoids that ambiguity. > > A good glossary would be a big help. > > > g...@rellim.com said: > > "Precision is the random uncertainty of a measured value, expressed > > by the standard deviation or by a multiple of the standard > > deviation." > > I can't figure out what that means. > > I think it's something different than the simple digital sort of things that > Daniel has been discussing. Standard deviation makes me think that it's > interested in the noise of capturing a PPS signal. If you look carefully, > you might get a bell curve or something like it, probably not symmetric. I suggest you read the article on wikipedia about it. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: An ontology of clocks
On Mon, Feb 22, 2016 at 03:39:58AM -0800, Hal Murray wrote: > > There are two interesting corner cases that should get documented someplace. > > Reading the RTC only gives you an answer to the second. You can actually get > a lot better than that if you spin and wait for it to tick. (I carefully > avoided using whatever word I should have used.) read() and select() actually wait until the next second. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: PROPOSED, change of stance, release metronome
On Sun, Mar 13, 2016 at 08:31:04PM +, Mark Atwood wrote: > Hi! > > One of the policy mistakes that was killing MySQL 5.0, back in the day, is > that they would not make a point release until a target feature for that > point release was done. This was killing them/us, because of the standard > difficulties with estimation was causing every announcement to just be the > announcement of a delay, while users were waiting for bug fixes and for > proof of momentum. > > Solaris and OpenSolaris had a different philosophy: they released > regularly, metronomically, by a schedule. Features that were not ready > "missed the train", but could catch the next one. Users got their regular > bug fixes, and each announcement was positive. > > I propose that we move to a scheduled release model, with the addition of > security fast releases. > > I'm thinking every two weeks, on Tuesday morning. > > Discussion? Comments? Objections? As someone from a distribution, I'm wondering if you'll have stable release that you'll support with at least security fixes and possibly bug fixes, and how long you think you'll support those releases. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: PROPOSED, change of stance, release metronome
On Sun, Mar 13, 2016 at 10:52:17PM +, Mark Atwood wrote: > Hello Kurt, > > We have not yet had that discussion yet. > > As someone from a distribution, what would you like from NTPsec? In the ideal world, we'd like to have some releases supported for something like 5 years. And if you indicate that some releases will be supported for a long time, we'll probably pick that version to ship with our stable releases. The 5 years would be the time that some distributions support their releases. The version would actually be in the distribution some time before the release, before we have a freeze, so it would actually be longer than those 5 years. But we'll take whatever you offer. Even if it's only like 2 years it would be useful. What we have the most problems with is applying the patches to the versions that is in our release. Making sure it actually fixes things. Code tends to change over the years and it my be non-obvious how to fix it in older versions. And so we would love for you to do all that work. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What is a release?
On Mon, Mar 21, 2016 at 04:20:38PM -0400, Eric S. Raymond wrote: > Mark Atwood : > > Speaking of which, the next cadence point release is going to be next > > Tuesday, the day after tomorrow, while I will literally be standing before > > the LF CII making the case for our work. So, this is a really good time > > to be doing work that merits entries in the NEWS file. > > You'll be happy to hear that I've been doing exactly that, then. > > I've forward-ported eight recent bug fixes from Classic; the entries > are in the NEWS file. Likely I'll get one or two more this evening. > It'd be more, but I have a vicious cold just now and aren't 100%. > > Things to emphasize to LF: these are bugs we inherited from Classic, > and I'm able to focus on fixing them because we haven't introduced > *any* of our own. Zero. Zip. Nada. (I just reviewed the issue > tracker to verify this.) > > So from the LF's point of view, the case for our work is that we > have significantly hardened the code and reduced its bulk by over > 50% while introducing zero new bugs. Significant hardening can > be measured by the fact that since the fork we've seen three CVEs go > by that we dodged because we had already fixed the hole in question. You can probobably add that people are still waiting for fixes of the "reference implementation" for CVEs for which they have released the details 5 months ago. A few things that I think you can improve is a download link somewhere on the website. It would also be nice if you provide a SHA256 sum of that, and that someone signs the release. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What is a release?
On Mon, Mar 21, 2016 at 09:47:27PM +0100, Kurt Roeckx wrote: > A few things that I think you can improve is a download link > somewhere on the website. It would also be nice if you provide a > SHA256 sum of that, and that someone signs the release. You probably also want to make the NEWS file available on the website. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Release of NTPSec 0.9.3
On Mon, May 23, 2016 at 08:51:06PM +, Mark Atwood wrote: > There should be a tag in gitlab. If there is not, it is my mistake, and I > will fix it this evening. ..m There are also no releases on ftp://ftp.ntpsec.org/pub/releases/, 0.9.1 is the latest. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: We need a release checklist
On Mon, May 23, 2016 at 02:38:42PM -0700, Hal Murray wrote: > > fallenpega...@gmail.com said: > > There should be a tag in gitlab. If there is not, it is my mistake, and I > > will fix it this evening. ..m > > k...@roeckx.be said: > > There are also no releases on ftp://ftp.ntpsec.org/pub/releases/, 0.9.1 is > > the latest. > > I'll make a file if people feed me ideas. For things like this, I like > chunks of code that can be copy-pasted. If I can make a suggestion, I suggest that you: - Send a PGP signed mail to the list when you make a release that includes the sha256sum - You put that sha256sum also on the ftp dir - You also sign the the released files with pgp Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: HOWTO: Security
On Tue, May 24, 2016 at 02:38:23PM -0700, Gary E. Miller wrote: > Yo Eric! > > On Tue, 24 May 2016 17:33:06 -0400 > "Eric S. Raymond" wrote: > > > Hal Murray : > > > > > > e...@thyrsus.com said: > > > > See my reply to Gary and your text about NATs and firewalls. > > > > Nobody has convinced me that this procedure *isn't* taking > > > > security seriously, nor will they until I understand how any > > > > machine other than the one I port-forward to is visible to > > > > outsiders. > > > > > > Your mention of port-forward assumes you are behind a NAT box. > > > That's not true in all setups. > > > > Would it suffice to say "Never put a Pi on an un-NATted address until > > you have removed the default account?" > > Most people's NATs leak a lot. Or they have IPv6 end around. > > Just change the password, to a good one, the FIRST step. Can I just suggest that you don't allow password based logins over the network? Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Use of pool servers reveals unacceptable crash rate in async DNS
On Sat, Jun 25, 2016 at 11:00:39AM -0400, Eric S. Raymond wrote: > > While this did enable me to recover from my errors, it also turned up > a serious problem. The combination of the buggy async-DNS code we > inherited from Classic and use of pool servers causes *very* frequent > crashes. Can you give some more details about the issue you're seeing? If it's the one I'm thinking about, I think the solution is to remove the locking of memory. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Use of pool servers reveals unacceptable crash rate in async DNS
On Sat, Jun 25, 2016 at 06:13:56PM -0400, Eric S. Raymond wrote: > Hal Murray : > > > > e...@thyrsus.com said: > > > 1. Apply Classic's workaround for the problem, which I don't remember the > > > details of but involved some dodgy nonstandard linker hacks done through > > > the > > > build system. *However, I did not trust this method when I understood > > > it.* > > > It seemed sure to cause porting difficulties and is inherently fragile. > > > > k...@roeckx.be said: > > > If it's the one I'm thinking about, I think the solution is to remove the > > > locking of memory. > > > > We may be confusing several bugs. > > > > There was a problem with locking stuff into memory. Some library needed by > > end of thread processing wasn't loaded yet and things worked out such that > > with the default memory 32 bit systems worked but 64 bit systems didn't > > have > > enough room. > > > > I think one solution was to create a dummy thread early on to get that > > module > > loaded. Or disable memory locking, or tell it to use more memory, or ... > > This matches what I remember, except for "use more memory". There was a third > workaround involved weird linker options to force early loading of the > library. Like -WL,-z,now? That's not such a weird option. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Possible abuse from fetching the leap second file
On Sun, Aug 14, 2016 at 03:49:15PM -0700, Hal Murray wrote: > Matt Selsky is working on Pythonizing the script that grabs a new leap second > file. The idea is to run a cron job that keeps it up to date. That opens an > interesting can of worms. I've been pondering about using ntp-classic's script for that in Debian, but decided not to. I also don't know if there is any other Linux distribution that automates this. However, I already get a /usr/share/zoneinfo/leap-seconds.list from the tzdata package that updates the timezone information and I should probably look into using that file to update things. Those files get regular updates. The t...@iana.org list has been notified, the git repository updated, there just hans't been a release since. There has been a proposal by Poul-Henning Kamp to use an DNS A-record for it, see: http://phk.freebsd.dk/time/20151122.html I don't know if this went anywhere. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Possible abuse from fetching the leap second file
On Mon, Aug 15, 2016 at 08:37:14AM -0400, Eric S. Raymond wrote: > Hal Murray : > > > > e...@thyrsus.com said: > > > While I accept this as a general principle, is there anything about the > > > new > > > ntpleapfetch that inflicts a heavier load than the old ntpleapfetch has > > > been > > > causing for decades with the tolerance of NIST and USNO? > > > > The old stuff has poor publicity. None of the major distros/OSes come > > setup > > to run it from a cron job. As long as you don't change that we won't have > > any problems. > > > > The problem will happen if somebody improves our documentation enough so > > that > > somebody notices, and that seems reasonably likely. > > I've thought about this some more, and now I am in doubt that the > general principle (don't use other peoples' resources without their > permission) applies here. I think we need to apply what tort law > would call a reasonable-person test. > > Some kinds of public-facing offer of a resource clearly constitute an > implied invitation to download it as needed. Consider, for example, a web > page. > > I think the NIST/IERS public offer of an authoritative leap-second resource > constitutes the same sort of invitation. If you disagree, ask yourself > if your evaluation would change if that data were in HTML and accessed > through port 80, or accessed by anonymous FTP. Surely the mechanics > of how it's downloaded are irrelevant to the ethics of the situation! That doesn't mean you should go and have millions of clients change from not checking it to downloading it without at least warning them about it. It doesn't help anybody if we overload the servers. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Possible abuse from fetching the leap second file
On Mon, Aug 15, 2016 at 11:14:10AM -0400, Eric S. Raymond wrote: > Mark Atwood : > > Let's do that! Hal, others, do you happen to have copies of all the past > > leap files, so we can synthesize a git history for it? > > We don't need all the past leap files. The data is only ever modified by > appending a line. There is also at least a timestamp until when it's valid updated. It also contains a hash sum. They have actually changed the text over the years. You can at least get a short history at: https://github.com/eggert/tz/commits/master/leap-seconds.list If you want to contact the NIST people, there is actually a contact address in the file. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Possible abuse from fetching the leap second file
On Mon, Aug 15, 2016 at 01:26:31PM -0700, Hal Murray wrote: > > k...@roeckx.be said: > > However, I already get a /usr/share/zoneinfo/leap-seconds.list from the > > tzdata package that updates the timezone information and I should probably > > look into using that file to update things. Those files get regular updates. > > The t...@iana.org list has been notified, the git repository updated, there > > just hans't been a release since. > > Thanks. I didn't know it was getting distributed. That looks like the way > to go. > > You don't need to "update things". Just point ntp.conf at that file. With update things I was just thinking that I would need to add a trigger when tzdata is update so I can either reload the config file or restart ntpd, depending on what's needed to get it to check the file. In any case, I will never use a cron job in Debian for this, I will use the one provided by tzdata. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: How much do we care about high-load scenarios?
On Wed, Sep 14, 2016 at 04:40:57PM -0500, Dan Drown wrote: > > This page from cloudflare does a nice job of describing the limitations of a > single process UDP receive model: > https://blog.cloudflare.com/how-to-receive-a-million-packets/ > > The limit they hit with their hardware was around 370kpps (with a single > process receive), which is a lot of NTP. I wanted to bring this up too, and that page has some important points if you want to improve performance. > From my own testing with iperf high rate 64 byte UDP packets, max rate > before 1% receive packet loss: > > i3-540 / Intel 82574L nic: ~469kpps > Athlon(tm) 64 X2 4400+ / RTL8168 gig nic: ~64kpps > Odroid C2: ~62kpps > Raspberry Pi 2: ~19kpps > Beaglebone Black: ~9kpps > Raspberry Pi B+: ~4kpps Is there a way to make this ntp packets, or where those ntp packets? My guess is that you'll have plenty of CPU to process the maximum packets the nic can handle. Once you add crypto this might change slightly. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: How much do we care about high-load scenarios?
On Wed, Sep 14, 2016 at 06:00:45PM -0400, Eric S. Raymond wrote: > Dan Drown : > > Quoting "Eric S. Raymond" : > > >Achim Gratz : > > >>…or move the refclocks out of ntpd altogether and use some shared memory > > >>or mailbox system to have ntpd have a look at the timestamp stream from > > >>each refclock. > > > > > >Yeah, this is one of my longer-term plans. It was in the original > > >technical > > >proposal I wrote 18 months ago, labeled REFCLOCKD. > > > > I'll add my +1 to this, setting the local time is a logical process split > > from serving time to clients. > > One good reason to do this that I've just realized recently is that if > we moved PPS handling to a refclockd we could take the timer tick out > of ntpd. This would lower power consumption in the pure-client case, > which I think is significant (consider embedded and mobile > deployments). Isn't the timer also used for the PI loop? Or has much of that design been changed? Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fw: [Git][NTPsec/ntpsec][master] 2 commits: Some u_long -> unsigned int changes.
On Fri, Sep 23, 2016 at 01:41:07PM -0500, Joel Sherrill wrote: > On Fri, Sep 23, 2016 at 1:08 PM, Gary E. Miller wrote: > > > Yo Eric! > > > > > > > These are valid because the invention and major uses of u_long in this > > > codebase predate the 64-bit transition - it may look like we're > > > narrowing size from 64 to 32 bits, but what we're actually doing is > > > replacing an earlier hack for guaranteeing 32-bit size by people > > > who cut their teeth on 16-bit ints. > > > > I disagree with this patch. > > > > -extern voidauthtrust (keyid_t, unsigned long); > > +extern voidauthtrust (keyid_t, unsigned int); > > > > In C, ints are not guaranteed to be longer than 16 bits. > > > > http://stackoverflow.com/questions/5256000/integer- > > size-in-c-depends-on-what#5256195 > > > > > See C99 "5.2.4.2.1 Sizes of integer types" for the normative definition. > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (pg 33 of PDF) > > If you have expectations of precise size of integers rather than required > minimum, you should used the stdint.h types like int32_t and uint64_t. Exactly. And if it's just a minimum you could use int_least32_t. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: fuzzing NTPsec with afl
On Mon, Nov 21, 2016 at 02:11:12PM -0900, Royce Williams wrote: > > If those minimal changes are turned into a compile-time option, this > would enable adding fuzzing to the rolling test suite, perhaps using > some of Susan's resources. Google also provides resources via oss-fuzz. If you can read from stdin, it should also be easy to fuzz with other fuzzers like libfuzzer. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Recent NTP pool traffic increase
On Sat, Dec 17, 2016 at 07:03:16PM -0800, Gary E. Miller wrote: > Yo All! > > On Sat, 17 Dec 2016 17:56:32 -0800 > "Gary E. Miller" wrote: > > > # tcpdump -nvvi eth0 port 123 |grep "Originator - Transmit Timestamp:" > > > > And I do indeed get odd results. Some on my local network... > > To follow up on this. The weirdness is just what chronyd has done > since before version 2.2. Chronyd gets 'clever' when it fills in > the data fields of an NTP packet. > > The RFC says a clients sends a server a packet with its current time in > the 'Transmit Timestamp'. Chronyd instead puts in a random number. The > server does not care, it just parrots back that timestamp back as the > 'Originator Timestamp', plus the time the server received that packet, > and the time it replied to the packet. > > The client uses 'Orignator Timestamp' as an index to lookup when it > really sent the request, and then does the usual math with the real send > time. > > So, red herring, back to the mystery hunt. > > Unless someone thinks this 'cleverness' is worth implementing in ntpsec. I think openntpd might be doing something like that too. That of course breaks if you try to do symmetric synchronization. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: The end of the beginning is in sight
On Fri, Jan 06, 2017 at 12:14:35PM -0500, Eric S. Raymond wrote: > and the other is ripping out all > the interface-scanning stuff so we lose the dependency on > getifaddrs(3) and use wildcard interfaces only. Are you sure this is going to work? As far as I know there are (or were) good reasons to do this, but I can't remember them currently. But it's at least something that's specific to UDP. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: The end of the beginning is in sight
On Fri, Jan 06, 2017 at 11:43:01PM -0500, Eric S. Raymond wrote: > (mutt hiccupped. You might see this twice.) > > Kurt Roeckx : > > On Fri, Jan 06, 2017 at 12:14:35PM -0500, Eric S. Raymond wrote: > > > and the other is ripping out all > > > the interface-scanning stuff so we lose the dependency on > > > getifaddrs(3) and use wildcard interfaces only. > > > > Are you sure this is going to work? As far as I know there are (or > > were) good reasons to do this, but I can't remember them > > currently. But it's at least something that's specific to UDP. > > If you can remember a blocker, please tell us about it before I > put a large amount of work into this. > > A little Googling found this from 2012: > > https://blog.powerdns.com/2012/10/08/on-binding-datagram-udp-sockets-to-the-any-addresses/ That at least matches my understanding of things. And since a nameserver seems to be using it, it should be possible to get it to work. So 1 question I have is if you care about Windows or not. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: New blog draft on the TESTFRAME debacle
On Sun, Jan 08, 2017 at 12:40:45AM -0500, Eric S. Raymond wrote: > Hal Murray : > > > > I don't understand your section about the PLL. I think it's tangled up in > > some bogus terminology. If you say a bit more, I'll try to sort things out. > > Alas, "say more" is not really actionable advice. Can you tell me > what seemed bogus to you? > > > What OSes are the odd-balls? What makes them odd? Is this just a > > different > > API to the kernel that turns into significantly different paths through > > ntpd? > > MacOS, Windows, and ... damn, I don't remember which BSD it was (not > FreeBSD). What the oddballs lack is ntp_adjtime(). They can only step, > not slew. I think you're talking about OpenBSD. But their adjtime() probably does something that might be close to what you want but probably not exactly. As far as I know it behaves different than all the other OSs. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: New blog draft on the TESTFRAME debacle
On Sun, Jan 08, 2017 at 06:35:58AM -0800, Hal Murray wrote: > > >> Using the term PLL. > > But that's how the code is organized. In the absence of a PLL it doesn't > > slew. Or am I missing something here? > > (at least) One of us is confused. > > The text from the blog: > > There are two kinds of NTP hosts; one uses a kernel facility known as the > > "PLL" for doing fine adjustments to the tick speed of the system clock, the > > other kind does not. > > That just seems wrong. There is no PLL involved with slewing a clock. Since there seems to be confusion about whta a PLL is, I will try to explain. In very short, a Phase Lock Loop will compare the phase of 2 systems, and use the difference of that to change the frequency of one of them so that the phases (and frequency) match. It consist of at least 3 things: - A phase (or time) comparison - An oscilator whose frequency you can change - A feedback loop There might also be a filter in it. I guess the important thing here is that the frequency of your local oscilator changes, to match the one from the master clock. What I wouldn't call a PLL is that you calcualte a time difference, temporary change the frequency to work away that offset, and then return to the old frequency. It should instead permantly change the frequency, until the next time you calculate the difference in time, and possibly change the frequency again. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Replacing C
On Sun, Jan 08, 2017 at 09:48:09AM -0500, Eric S. Raymond wrote: > On the other hand, I don't consider requiring a runtime to be an > *intrinsic* disqualifier. The real question is, in my view, the > 95th-percentile length of latency-inducing stop-the-world stalls. > If it's below 100 microseconds that is almost certainly good enough. I guess this is my biggest concern with some of the newer languages that at least some of them can have large and unprediticable latencies, and latency is something we do care about. 100 microseconds seems acceptable for things over the internet, but I guess I expect better than that for over LAN where I expect the delay to be in that order. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Replacing C
On Sun, Jan 08, 2017 at 07:11:22PM +0100, Kurt Roeckx wrote: > On Sun, Jan 08, 2017 at 09:48:09AM -0500, Eric S. Raymond wrote: > > On the other hand, I don't consider requiring a runtime to be an > > *intrinsic* disqualifier. The real question is, in my view, the > > 95th-percentile length of latency-inducing stop-the-world stalls. > > If it's below 100 microseconds that is almost certainly good enough. > > I guess this is my biggest concern with some of the newer > languages that at least some of them can have large and > unprediticable latencies, and latency is something we do care > about. 100 microseconds seems acceptable for things over the > internet, but I guess I expect better than that for over LAN where > I expect the delay to be in that order. I had a quick look at some of the stats of my peers over internet, and most actually seem to have an average jitter in the order of around 100 microseconds. Some are lower, some are higher. So I'm not sure how I feel about adding an other 100 to that. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Replacing C
On Sun, Jan 08, 2017 at 02:12:21PM -0500, Eric S. Raymond wrote: > Kurt Roeckx : > > I had a quick look at some of the stats of my peers over internet, > > and most actually seem to have an average jitter in the order of > > around 100 microseconds. Some are lower, some are higher. So I'm > > not sure how I feel about adding an other 100 to that. > > OK, fair point. > > The rule in my head has been that for whatever jitter maximum we want > to hit, we need the the 95th-percentile value of the stop-the-world > bound to to be an order of magnitude below that. I guess it depends on how often this stop-the-world thing happens. If it happens every packet 100 us is probably too much, if it happens every 1000 packets it's probably acceptable. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: I'm off to learn Rust
On Sun, Jan 08, 2017 at 03:59:51PM -0500, Eric S. Raymond wrote: > Susan and I have decided to revive an old idea we were originally going > to do in Python and implement it in Rust instead - a better IRC > server. Susan has years of field experience with IRC servers written > in C and says they're kludgy and terrible inside. A symptom is that > they tend to stall out at ridiculously low user counts; this is one > reason they have to be federated. As someone who has expierence writing an IRC server, we've been doing 10K connections with a single threaded server on a single CPU system 20 years ago. And the bottleneck never was in the IRC server. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Replacing C
On Sun, Jan 08, 2017 at 02:37:43PM -0800, Hal Murray wrote: > > >> OTOH, if the OS is time stamping packets, and PPS, for the ntpd daemon > >> then the daemon can tolerate 'some' jitter. > > > In normal operation we can expect lots of pairs of small allocations at UDP > > datagram sizes with deallocation fairly rapidly thereafter. So the heap will > > have lots of churn, which is bad... > > We don't care about the timing in most of the code. The only critical > section is the chunk between grabbing the time and sending the packet. That > chunk is likely to involve crypto. > > We could fix that with another packet. The idea is that you get a time stamp > from the kernel on the transmit side. Then you have to send another packet > to get that time stamp to the other end. Didn't the support for that get removed? Or am I confusing it with something else? Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Replacing C
On Sun, Jan 08, 2017 at 06:02:36PM -0500, Eric S. Raymond wrote: > Hal Murray : > > We don't care about the timing in most of the code. The only critical > > section is the chunk between grabbing the time and sending the packet. > > That > > chunk is likely to involve crypto. > > > > We could fix that with another packet. The idea is that you get a time > > stamp > > from the kernel on the transmit side. Then you have to send another packet > > to get that time stamp to the other end. > > > > Maybe we should add that to the NTPv5 list. > > No, I'd much rather put in a GC lockout on the critical region than > complicate the protocol. > > That said, I continue to admire your cut right to the heart of the issue. > ntpd spends enough time in I/O waits that I do not think latency spikes > will otherwise induce any problems above measurement noise. The extra packet will improve the precision. It will eliminate one source of jitter. And I guess there will be people who would want to use it, but now have to use PTP. They probably have the right hardware for it to be really useful. But I think in the general case, the jitter caused by the network will be higher than then what this would win. But then I have no idea if someone actually tried something like this over the internet with standard hardware and what the effect of it is. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Replacing C
On Sun, Jan 08, 2017 at 03:51:13PM -0800, Hal Murray wrote: > > We should measure the time from grabbing the time stamp to sending the > packet. That might include some crypto. We might get better results by > adjusting the time stamp to compensate for that. Adjusting the timestamp to when you think it'll leave will clearly improve the accuracy, assuming it's a good estimate. And is something that you could in theory when not using crypto either by keeping stats and when the packet actually left. It would then not need this extra packet. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Replacing C
On Sun, Jan 08, 2017 at 04:53:57PM -0800, Gary E. Miller wrote: > Yo All! > > On Mon, 9 Jan 2017 01:30:30 +0100 > Kurt Roeckx wrote: > > > > That said, I continue to admire your cut right to the heart of the > > > issue. ntpd spends enough time in I/O waits that I do not think > > > latency spikes will otherwise induce any problems above measurement > > > noise. > > > > The extra packet will improve the precision. It will eliminate > > one source of jitter. I should probably have added that it will improve the accuracy too. > > And I guess there will be people who would > > want to use it, but now have to use PTP. > > Now that is an interesting idea. Could NTP hook into the hardware > level timestamps that PTP uses? I thought we were already talking about that ... > > They probably have the > > right hardware for it to be really useful. > > Very finicky. I've tried PTP on a number of different ethernet > chips. Most chips do not support hardware PTP all. Most chips that > say they support hardware PTP have weird bugs. Only a few have really > worked for me. > > Hard to fix too, since the problems are baked into the silicon. The hardware stamps depend on support of both MAC and the PHY to begin with, and that you have drivers that support them. > Some network switches are smart enough to fast tack PTP packets, if > we can prove they are the bottleneck they could be fixed. Some switches are PTP aware and do more than just fast track them. > > But then I have no idea if someone actually tried something like > > this over the internet with standard hardware and what the effect > > of it is. > > Then you can be the first. I have no time for this other than maybe help test it. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Replacing C
On Mon, Jan 09, 2017 at 08:22:42PM +0100, Achim Gratz wrote: > Eric S. Raymond writes: > > Good idea. I'd do it something like this: > > > > 1. Every time we ship a packet, take timestamps at the beginning and end of > > the > > critical region. > > If it is possible to get the actual time the packet left, then that's > the data to get the adjustment value from. I'm not sure exactly how > hardware timestamping is implemented in the kernel, but at least some of > the interfaces should be able to read back the timestamp that was > attached to the outgoing packet. See: https://www.kernel.org/doc/Documentation/networking/timestamping.txt Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
On Thu, Jan 19, 2017 at 01:32:20PM -0500, Eric S. Raymond wrote: > > INSTALL says: > > Debian: libsodium > > > > apt-get install on my debian box says: > > E: Unable to locate package libsodium > > Running Wheezy, I take it? It's libsodium-dev Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
On Thu, Jan 19, 2017 at 02:30:35PM -0500, Eric S. Raymond wrote: > Gary E. Miller : > > > - to fuzz the low-order bits of the clock. > > > > Hmm, can you expand on this a bit? Which clock? How much fuzz? > > Does this degrade anything? > > Whenever ntpd polls the system clock, it fuzzes the lowest-order digits > of the result. The amount of fuzz to apply is bounded by half the measured > interval between system clock ticks. > > That shouldn't degrade anything. I presume it's a measure to foil timing > attacks of some sort. Daniel might be able to say more. Adding random (white) noise to a measurement is done to improve the resolution after averaging, it's ussually in combination with oversampling. Adding this white noise is done in the analog signal, before you convert it to digital. I guess there is an assumption that there is a random time between the clock tick and the time that you asked it, and that by adding an other random time to it that you can somehow improve the resolution. And I guess improving the resolution was important when on some systems you have a resolution in the order of 1 to 50 ms. But I'm currently not really sure that it either improves things, make things worse, or has no effect at all. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
On Thu, Jan 19, 2017 at 01:00:50PM -0800, Gary E. Miller wrote: > Yo Kurt! > > On Thu, 19 Jan 2017 21:20:23 +0100 > Kurt Roeckx wrote: > > > On Thu, Jan 19, 2017 at 02:30:35PM -0500, Eric S. Raymond wrote: > > > Gary E. Miller : > > > > > - to fuzz the low-order bits of the clock. > > > > > > > > Hmm, can you expand on this a bit? Which clock? How much fuzz? > > > > Does this degrade anything? > > > > > > Whenever ntpd polls the system clock, it fuzzes the lowest-order > > > digits of the result. The amount of fuzz to apply is bounded by > > > half the measured interval between system clock ticks. > > > > > > That shouldn't degrade anything. I presume it's a measure to foil > > > timing attacks of some sort. Daniel might be able to say more. > > > > Adding random (white) noise to a measurement is done to improve the > > resolution after averaging, it's ussually in combination with > > oversampling. Adding this white noise is done in the analog signal, > > before you convert it to digital. > > Yeah, I have seen that before. It can be good, or it can be bad. You of course need to know what you're actually doing for it to be useful. > In my GR-601W experiments I can show it would be bad. I really have no idea what kind of experiment that was, but I doubt that it somehow has an ADC. > > And I guess improving the resolution was important > > when on some systems you have a resolution in the order of 1 to 50 > > ms. > > I'm worried about 1 micro Second or less. And one should not > confuse accuracy with resolution. A PPS signal only has a resolution > of one Second, but can eaaily have an accuracy of 10 nano seconds. Please don't confuse accuracy with precision. I'm not sure your 10 nano seconds is the accuracy or precision, both are possible, but I think you're talking about precision. The accuracy is probably not that easy to measure. > A signal on a USB 2.0 bus can only have a resolution of about 1 micro > Second, but that can be locked to a PPS to 100 micro Seconds jitter. I'm not sure what you're trying to say. But if you're talking about jitter, you're really talking about the precision. > > But I'm currently not really sure that it either improves > > things, make things worse, or has no effect at all. > > Hal does not think it is in the measurement path at all. If it is > then it will be eauy to do some testing. As far as I understood, the packets that go out have their timestamp adjusted to add a random value. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
On Thu, Jan 19, 2017 at 02:40:08PM -0800, Gary E. Miller wrote: > > > I'm worried about 1 micro Second or less. And one should not > > > confuse accuracy with resolution. A PPS signal only has a > > > resolution of one Second, but can eaaily have an accuracy of 10 > > > nano seconds. > > > > Please don't confuse accuracy with precision. I'm not sure your 10 > > nano seconds is the accuracy or precision, both are possible, but > > I think you're talking about precision. The accuracy is probably > > not that easy to measure. > > You are right, I probably should have said the resolution of the PPS is > just one second That PPS just fires once a second. There is no way to > tall anything about anything, except that one moment in time at the top > of the second. > > I tend to use precision interchangeabley with resolution. They're clearly different things. > The number of significant digits past the second is zero. > > If you doubt a PPS is accurate to 10 nano Seconds then head over to > time-nuts. They'll give you an earfull. I'm happy just to know that > the ACCURACY of when the PPS pulse happens is quoted as 10 nano Seconds > on the data sheets of many GPS. Other GPS only claim 1 micro Second. Please note that I say both precision and accuracy is possible. But it's not because they have the time to such accuracy that they can output it with such accuracy, or that you can measure it with such an accuracy. I was under the impression that you said you could sync your clock to 10 ns using PPS, but I guess I misunderstood that. > > > A signal on a USB 2.0 bus can only have a resolution of about 1 > > > micro Second, but that can be locked to a PPS to 100 micro Seconds > > > jitter. > > > > I'm not sure what you're trying to say. > > Each USB 2.0 device is polled 1024 times a second. So you would think > you could only sync time over a USB 2.0 bus to 1/1024th of a second. > About 1 micro Second. But that is not true, you can sync time over USB > 2.0 to 100 microseconds. 1/1000 of a second would 1 millisecond, not microsecond. > If you said the resolution is only 1 micro second, and you added > 500 micro Seccond of jitter, you would make the sync 5 times worse, > not better. You seem to be confusing milli with micro again, I'm going to assume the first is milli. I guess you're saying: - I can read about every 1 ms - But there is jitter on that 1 ms in the order of 0.002 to 0.1 ms - You could add an other random 0.5 ms in software. First, even though the PPS signal is only once per second, you're really measuring the pulse, and you could say you're measuring that with a resolution of 1 ms. But your problem is that you probably have no idea what the distribution is of your 0.1 ms jitter, and if you have no idea what it is you can't properly correct for it, and you probably make things worse. Adding the 0.5 to the 0.1 ms would probably give something in the order of 0.6 ms, and would probably end up better like a normal distribution, which is what you want. But in the end the you're not going to get much better than the 0.1 ms. Adding noise here after the measurment really doesn't make sense to me. You would instead need to modify the output of the PPS signal to add random jitter to it, so that it doesn't always happen every 1024 polls. That is assuming you now almost always get it every 1024 polls. If you make sure that you get different numbers you can average it and get something better then your 1 ms. But I'm not sure this is actually useful. You probably want to have a signal of more than 1 Hz for something like that. > > But if you're talking about jitter, you're really talking about > > the precision. > > NTP uses yet another definition for precision, so it is confusing. NTP > calculates precision from jitter. NTP precision (not accuracy) is > assumed to be slightly worse than the jitter. The NTP precision can be > no better than the jitter. Conversly the NTP jitter is better than > the precision. NTP uses the smallest difference in time the program can see as precision, which is at least confusing. Precision is about how repeatable something is. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libsodium mess
On Thu, Jan 19, 2017 at 05:03:29PM -0800, Gary E. Miller wrote: > > > > > A signal on a USB 2.0 bus can only have a resolution of about 1 > > > > > micro Second, but that can be locked to a PPS to 100 micro > > > > > Seconds jitter. > > > > > > > > I'm not sure what you're trying to say. > > > > > > Each USB 2.0 device is polled 1024 times a second. So you would > > > think you could only sync time over a USB 2.0 bus to 1/1024th of a > > > second. About 1 micro Second. But that is not true, you can sync > > > time over USB 2.0 to 100 microseconds. > > > > 1/1000 of a second would 1 millisecond, not microsecond. > > Sorry typo. But my conclusion, and my data, is unchanged. > > > > If you said the resolution is only 1 micro second, and you added > > > 500 micro Seccond of jitter, you would make the sync 5 times worse, > > > not better. > > > > You seem to be confusing milli with micro again, I'm going to > > assume the first is milli. > > Nope. ntpd clearly tells me that my jitter is 100 micro Seconds. > I get the same results using chronyd. Yes, but i think you're saying your resolution is 1 ms. > > > > I guess you're saying: > > - I can read about every 1 ms > > - But there is jitter on that 1 ms in the order of 0.002 to 0.1 ms > > No, there is jitter on that of 1 mS to 0.1 mS. I have no idea why you always write S or Seconds. The correct SI unit is s, not S, and it's also just second. Is this some German capitalization thing? > > First, even though the PPS signal is only once per second, you're > > really measuring the pulse, and you could say you're measuring that > > with a resolution of 1 ms. > > No, the resolutin of my measurement is the resolution of the system > clock. But you only check about every 1 to 2 ms as I understand it. I was under the impression that you talked about that as your resolution. Normally you would call that the sample period, but we're measuring time here which always confuses things somewhat. In this case jitter and precision really are the same thing. But if what you're measuring isn't time they're different things. But I have no good other term other than the sample period / frequency. It will clearly limit your accuracy, but it's not the accuracy itself. NTP seems to be calling this precision. > > You would instead need to modify the output of the PPS > > signal to add random jitter to it, so that it doesn't always > > happen every 1024 polls. > > That would be many mS of jitter. Also not good. This might be counter intuitive, but adding noise can improve your results, but it needs to be white noise. But there are usually other ways to improve things to, like having a higher sample rate in this case. > > > > But if you're talking about jitter, you're really talking about > > > > the precision. > > > > > > NTP uses yet another definition for precision, so it is confusing. > > > NTP calculates precision from jitter. NTP precision (not accuracy) > > > is assumed to be slightly worse than the jitter. The NTP precision > > > can be no better than the jitter. Conversly the NTP jitter is > > > better than the precision. > > > > NTP uses the smallest difference in time the program can see > > as precision, which is at least confusing. Precision is about how > > repeatable something is. > > Uh, no. The smallest difference in time it can see is about sys_fuzz. > Basically how fast the clock can be read and/or the smallest tick in the > clock that it can see. Not to be confused with the LSB of the > read system clock. > > The precision can be 10e6 worse than that sys_fuzz. > > Once again, we really need an NTP specific dictionary because NTP defines > things in unusual ways. Oh, I do agree that NTP is confusing the terms, and I hope we can at least agree on how they are used now. ntp returns for me: precision=-23 That means it can read my system clock at a rate of 2^23 times per second, and get a different value each time, with the difference in time being 2^-23 (or about 0.12 us) Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Precision and accuracy
On Fri, Jan 20, 2017 at 12:44:38PM -0800, Gary E. Miller wrote: > Imagine in front of you are two handheld voltmeters, and a super > precision voltage source. So let me correct all those terms to what people normally use them for. You have a voltmeter those shows volt with 3 digits behind the decimal place, so for example 1.234. The resolution is 1 mV. (That's millivolt) It does not say anything about the precision or the accuracy of that meter. Suppose you have a reference voltage that has a voltage of exactly 1.0 V. And you measure that voltage with your voltmeter, and it shows you 0.995, 0.994, 0.993, 0.994, 0.992, 0.994, 0.995, and so on. Let's assume the average value is 0.994 V, that it's a normal distribution and that the standard deviation is 1 mV. People could say that that 1 mV is the precision, and 6 mV is the accuracy. Suppose you take a different voltmeter, and that one always shows 1.002 V. People might claim the precision is 0, but a better number would be halve the resolution, so 0.5 mV. An even better number could be 0.43 mV. That's sqrt(3) / 2 * halve the resolution. I has at least a rectangular distribution, and I think that's the correct formule to match the coverage of 1 standard deviation. But the 2nd example already shows why the first's precision is actually wrong, and they both need to get added together, and the first would be 1.1 mV (sqrt(1^2+0.43^2)). It's also possible that that 2nd meter is averaging over a longer period of time than that first one, and in that way improve it's precision. And if you really start to care about putting numbers of what the accuracy and precision is, you get into troubles. Which is why they're never talked about like that. You don't start from a measurement and then come up with what the precision and accuracy is. Because you're probably forgetting all kinds of errors like the drift. But you can ussually find values for some of those in the datasheets of your device, and they're ussually not even clear what they really mean. If you go and look at the calibration sheet of your reference voltage, or one of those 8 digit volt meters, you're not going to find a mention of the accuracy and precision. Instead they're going to talk about the uncertainty, and say your reference voltage gives a voltage of 1.1 +/- 3 nV, where the 3 nV is an expanded uncertainty, maybe that it's a normal distribution, and that it has a k factor of 2 to have a 95% coverage. For your voltmeter they're going to measure multiple values and each time give you the reference voltage they, the uncertainty of the measurment, and the value your device is showing, and if that's within specification or not. > Now plug in the Fluke meter. I feed in the same 1.0 Volts > and I read on the meter 1.000 Volts. How accurate, NIST traceable, > would you say the Fluke meter is? You guess 0.1%? Maybe, maybe not. > > Now I set the calibrator to 1.00049 and the meter still reads > 1.000. I set the meter to 1.0005 and the meter changes to > read 1.001. How accurate is the meter? I say the meter is accurate > to 0.001% That's some very nice fluke meter you got there. The best I could find claims an accuracy of 0.05% (I assume of reading, but could also be of range) + 1 digit, which would be at least 1.5 mV. All the others are worse with most doing 0.5% + 2 digits. > The Fluke meter can in fact reliably, repeatably, NIST traceably, > differentiate between two inputs that are only 0.001% apart! When that > Fluke meter said a voltage was 1.000, you know it was between 0.99951 > Volts and 1.00049 Volts. You could in fact use it to accurately, > repeatedly, NIST traceably tune a voltage divider to 1.000 Volts > +/-0.001% That error would still be 0.5 mV, or 0.05%. > Compare that to the cheap meter that is only 5%. And yet they both have > a precision of 0.1%. That cheap meter probably also does 0.5%. (And they both have the same resolution, not precision.) Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Precision and accuracy
On Fri, Jan 20, 2017 at 05:39:37PM -0800, Gary E. Miller wrote: > Yo Kurt! > > On Sat, 21 Jan 2017 01:23:47 +0100 > Kurt Roeckx wrote: > > > On Fri, Jan 20, 2017 at 12:44:38PM -0800, Gary E. Miller wrote: > > > Imagine in front of you are two handheld voltmeters, and a super > > > precision voltage source. > > > > So let me correct all those terms to what people normally use them > > for. > > You use your terms, I'll use mine. As long as we understand each other. > > You left out the part where I started with: > > "Many will disagree with my terms, for those that do, just think > of the names I use as random variable names and try to follow the > concept." > > I really did try to find some online definitions of these that are > widely agreed on, and failed. Everyone has their 'one true' dictionary, > but they can never seem to find it. If you can find one I'd like to see > it. https://en.wikipedia.org/wiki/Accuracy_and_precision There are many places that describe it like that, and if you really want I can find more references. > > Suppose you have a reference voltage that has a voltage of > > exactly 1.0 V. And you measure that voltage with your > > voltmeter, and it shows you 0.995, 0.994, 0.993, 0.994, 0.992, > > 0.994, 0.995, and so on. Let's assume the average value is 0.994 > > V, that it's a normal distribution and that the standard deviation > > is 1 mV. People could say that that 1 mV is the precision, and 6 > > mV is the accuracy. > > Ah, but now you have added in jitter. I don't call that jitter. Jitter is only about variances in the time base. Which is why I also said that for time jitter and precision are very related. > I said nothing about jitter, > which not really a thing in real DVMs. I have tested a lot of > NoName DVMs and expensive DVMs and never seen them jitter. I've seen them in many. For instance my fluke scopemeter in meter mode will change at least over 5 different values. (It also has crappy specifications.) > > Suppose you take a different voltmeter, and that one always shows > > 1.002 V. People might claim the precision is 0, but a better > > number would be halve the resolution, so 0.5 mV. An even better > > number could be 0.43 mV. That's sqrt(3) / 2 * halve the resolution. I > > has at least a rectangular distribution, and I think that's the > > correct formule to match the coverage of 1 standard deviation. > > Which, since standard deviation is usefull only when you are already > lost, and only for one particular type of noise, not useful. > > Time and time again I have heard: you only use standard deviation > when you are already lost. I 100% agree with that. This is really about having the same coverage as the standard deviation so that you can add the errors. > > If you go and look at the calibration sheet of your reference > > voltage, or one of those 8 digit volt meters, you're not going to > > find a mention of the accuracy and precision. Instead they're > > going to talk about the uncertainty, and say your reference voltage > > gives a voltage of 1.1 +/- 3 nV, where the 3 nV is an > > expanded uncertainty, maybe that it's a normal distribution, > > and that it has a k factor of 2 to have a 95% coverage. > > We must be buying from a different class of vendors. I have only > rarely seen normal or standard deviations in the real world. At least in Europe you should always find that on calibration information about your device that traces back to one of the standard bodies like NIST. I doubt it's that much different for NIST. > > > Now plug in the Fluke meter. I feed in the same 1.0 Volts > > > and I read on the meter 1.000 Volts. How accurate, NIST traceable, > > > would you say the Fluke meter is? You guess 0.1%? Maybe, maybe > > > not. > > > > > > Now I set the calibrator to 1.00049 and the meter still reads > > > 1.000. I set the meter to 1.0005 and the meter changes to > > > read 1.001. How accurate is the meter? I say the meter is accurate > > > to 0.001% > > > > That's some very nice fluke meter you got there. The best I could > > find claims an accuracy of 0.05% (I assume of reading, but could > > also be of range) + 1 count, which would be at least 1.5 mV. All > > the others are worse with most doing 0.5% + 2 counts. > > Yes, John Fluke Mfg. Co., Inc. made damn fine stuff. And I'm saying that the best you can buy now from Fluke in that range of devices is 0.05% + 1 count. And that 1 count is just as important. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: sys_fuzzMime-Version: 1.0
On Wed, Jan 25, 2017 at 02:12:05AM -0800, Hal Murray wrote: > I think kernels went through 3 stages: > > Old old kernels were very coarse. They bumped the clock on an interrupt. > End of story. > > Old kernels use the TSC (or equivalent) to interpolate between interrupts. > (A comment from Mills clued me in. I was plotting temperature vs drift. It > got a lot cleaner when I moved the temperature probe from the CPU crystal > over to the RTC/TOY clock crystal. I haven't looked for the code.) > > Current kernels don't use interrupts for keeping time. It's all done with > the TSC. All my real amd64 boxes show: [0.540511] Switched to clocksource hpet [3.327348] Switched to clocksource tsc But my armel shows: [5.722800] Switching to clocksource orion_clocksource A KVM guest shows: [0.392136] Switched to clocksource kvm-clock Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘sys_fuzz * ntp_random()
On Tue, Jan 24, 2017 at 10:38:50PM +0100, Achim Gratz wrote: > sys_fuzz (which whitens the quantization noise on the clock reading) > doesn't make a difference or you might not. But presumably Dave Mills > didn't put it in there just because he was trying to add useless code. So it seems to me that this is the wrong order, you first add the noise and then do the quantization, not the other way around. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: sys_fuzzMime-Version: 1.0
On Wed, Jan 25, 2017 at 01:14:50PM -0500, Eric S. Raymond wrote: > Kurt Roeckx : > > All my real amd64 boxes show: > > [0.540511] Switched to clocksource hpet > > [3.327348] Switched to clocksource tsc > > > > But my armel shows: > > [5.722800] Switching to clocksource orion_clocksource > > > > A KVM guest shows: > > [0.392136] Switched to clocksource kvm-clock > > Sorry, I don't know how to interpret this. I was just looking at what was available on the various platforms, and what is used. On amd64 I see: $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm On the kvm guest: kvm-clock hpet acpi_pm on my armel: orion_clocksource An other armel: armada_370_xp_clocksource All the armhf / arm64 machines I tried: arch_sys_counter On mips: MIPS Other mips boxes: OCTEON_CVMCOUNT Powerpc: timebase s390x: tod Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Crypto tangle
On Fri, Jan 27, 2017 at 08:38:06PM +0100, Achim Gratz wrote: > Eric S. Raymond writes: > > It depends on which MAC algorithms we want to support, a question I've > > opened > > in a recent email. It looks like libsodium's support for hash functions in > > our set is limited to SHA-2, so libsodium can't replace OpenSSL. > > SHA1 will go out of OpenSSL sooner than you might wish and I guess it > wasn't a simple oversight that it isn't in libsodium. SHA1 is > considered broken for cryptography (not quite as badly as MD5) and the > crypto folks will weed it out to prevent people from still using it. I think it's unlikely that SHA1 will be removed from OpenSSL soon. We still have things like MD2 in it, but very recently decided it was time to disable it by default. I think that as there still are clearly users for, it won't go away by default. But you should move away from it as soon as you can. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Current status of --enable-crypto
On Fri, Jan 27, 2017 at 03:42:09PM -0500, Eric S. Raymond wrote: > Daniel Franke : > > Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1 > > support any time soon? That's inconceivable to me. > > I think it was either Achim Gratz or Kurt Roecx (I can't easily search to find > out right now). Somebody serious, anyway. So as one of the OpenSSL people, it seems unrealistic to even have a compile time option to remove MD5 and SHA-1 at this time. Both are needed for TLS 1.0. It seems unrealistic that we can drop support for that in the next 5 years. We still support SSLv3, but it's disabled by default. I hope to be able to disable TLS 1.0 by default in a few years. At that time it _might_ be possible to have an option to disable MD5 and SHA-1, but it would require someone to actually put an effort into that. And some people might actually want to have such an option, so maybe someone will. But even then it seems unlikely that they get disabled by default the first 5 years. If you only care about the preimage resistance, they are still fine. There are also just too many applications that would get broken by disabling it. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Hash function support, MD5 / SHA256, strawman proposal
On Fri, Jan 27, 2017 at 03:00:42PM -0800, Hal Murray wrote: > > fallenpega...@gmail.com said: > > How hard would the following be? > > Just go ahead and add SHA256 to NTPsec then Write an I-D modifying the NTP4 > > protocol documenting it. then Write a patch to NTP classic for it. > > (yes, I know, icky code) > > I think you are overlooking how long it takes to update the installed base. Just to compare this with SSL/TLS. SSLv3 exists since 1996. There are still webservers on the internet that only speak SSLv2 in the top 1 million sites. So if you really care that you can still talk to all servers, you would need to support things for over 20 years. But at a certain point we're willing to break things. No modern webbrowser will talk to those servers. And if they want you to talk to them, they'll just have to upgrade. And the question really becomes how much you're willing to break. And it seems that most people don't care about 0.1%. > CentOS 6.8 and NetBSD 6.1.5 are still shipping ntp 4.2.6p5 > (I assume they have back ported all the important security patches.) > 4.2.8 was released at the end of 2014 I think redhat supports their release for 10 years, so you'll probably still get near 10 years that you might see 4.2.6 servers. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Timings for random
On Sat, Jan 28, 2017 at 12:48:34PM -0800, Gary E. Miller wrote: > Yo Hal! > > On Sat, 28 Jan 2017 12:39:02 -0800 > Hal Murray wrote: > > > Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz > > Stdlib: 100 calls to rand() took 0.021 microseconds each > > Sodium: 100 calls to randombytes_buf() took 0.367 microseconds > > each > > OpenSSL: 100 calls to RAND_pseudo_bytes() took 0.630 > > microseconds each > > rand() and RAND_pseudo_rand() are not random, just psuedo random, thus > not for NTP. I have no idea what you're using random numbers for, but if unpredicable is what you want rand() is probably not what you want. > What about the OpenSSL RAND_bytes()? RAND_pseudo_rand() has been deprecated anyway. The only difference in behaviour was when it didn't get seeded properly. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Crypto timings
On Sun, Jan 29, 2017 at 09:09:56PM +, Greg Rubin wrote: > Mind running the timings with the legacy interfaces as well? We may > determine that the speed benefits are outweighed by the risks and > complexities of an older API, but it would be good to have the data so we > can make an informed decision. > > https://www.openssl.org/docs/man1.0.2/crypto/md5.html > https://www.openssl.org/docs/man1.0.2/crypto/sha.html On an i5-2500 @ 3.3 GHz, with openssl 1.0.1t: openssl speed md5 sha1: The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 57722.54k 170970.22k 379334.74k 545487.19k 625227.09k sha1 67990.28k 189759.61k 407470.34k 571764.74k 649565.53k openssl speed -evp md5 sha1: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes sha1 67922.42k 189184.53k 407347.80k 571157.85k 649428.99k md5 69949.09k 196024.75k 407446.02k 561352.70k 628984.49k (Note that it changed the order of sha1 and md5, but I've made the order the same) Instead with the 1.1.0d version: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes md5 108391.99k 257522.09k 468072.79k 586233.51k 633440.94k 636813.31k sha1105271.81k 253953.34k 485931.43k 629915.65k 688802.47k 693933.40k vs: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes md5 56006.90k 165390.34k 372050.26k 541776.48k 626789.03k 631794.35k sha1106968.33k 259511.66k 491601.07k 631022.93k 690307.07k 694250.15k (I guess I need to talk to Andy about the md5 results on 1.0.1d with -evp.) on Opteron 6128 @ 2 GHz with 1.0.2j: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 31425.80k94665.83k 224058.91k 338552.83k 399575.72k sha1 33109.40k92994.65k 198053.12k 275247.45k 311880.36k vs: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 37516.02k 108757.61k 241711.45k 348012.54k 401257.81k sha1 32777.98k92063.98k 197674.24k 274422.10k 311388.84k On an i5-5200U @ 2.2 GHz with 1.0.1t: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 49263.92k 143836.15k 316048.30k 455134.21k 523655.11k sha1 59227.40k 167068.95k 361932.12k 521637.89k 614361.77k vs: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 60008.47k 165981.64k 336796.42k 467899.39k 517005.01k sha1 58571.46k 166523.95k 360590.29k 521334.10k 616609.11k On a armel kirkwood (600 MHz?) with 1.0.1t: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 3728.56k13010.79k36292.53k66204.26k86466.90k sha1 3820.86k11280.40k25024.39k35906.32k41140.50k vs: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 4688.57k15861.30k41397.71k70352.28k87673.64k sha1 3837.16k11275.29k24967.28k35942.06k41140.83k Plenty of other boxes I could run this on. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Crypto timings
On Sun, Jan 29, 2017 at 10:44:49PM +0100, Kurt Roeckx wrote: > On Sun, Jan 29, 2017 at 09:09:56PM +, Greg Rubin wrote: > > Mind running the timings with the legacy interfaces as well? We may > > determine that the speed benefits are outweighed by the risks and > > complexities of an older API, but it would be good to have the data so we > > can make an informed decision. > > > > https://www.openssl.org/docs/man1.0.2/crypto/md5.html > > https://www.openssl.org/docs/man1.0.2/crypto/sha.html > > On an i5-2500 @ 3.3 GHz, with openssl 1.0.1t: > openssl speed md5 sha1: > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes > md5 57722.54k 170970.22k 379334.74k 545487.19k 625227.09k > sha1 67990.28k 189759.61k 407470.34k 571764.74k 649565.53k > > openssl speed -evp md5 sha1: > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes > md5 69949.09k 196024.75k 407446.02k 561352.70k 628984.49k > sha1 67922.42k 189184.53k 407347.80k 571157.85k 649428.99k > > (Note that it changed the order of sha1 and md5, but I've made the order the > same) > > Instead with the 1.1.0d version: > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes > 16384 bytes > md5 108391.99k 257522.09k 468072.79k 586233.51k > 633440.94k 636813.31k > sha1105271.81k 253953.34k 485931.43k 629915.65k > 688802.47k 693933.40k > > vs: > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes > 16384 bytes > md5 56006.90k 165390.34k 372050.26k 541776.48k > 626789.03k 631794.35k > sha1106968.33k 259511.66k 491601.07k 631022.93k > 690307.07k 694250.15k So in 1.1.0, not using the -evp switch actually makes the MD5 call use the legacy interface, and you'll get less overhead. Didn't really look at how things are implemented. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Wildcard-socket simplification hits a wall
On Thu, Mar 30, 2017 at 12:06:36PM -0400, Eric S. Raymond wrote: > Head up, Mark! Policy issue. > > I fear the wildcard-socket simplification, last of our pre-1.0 major > ambitions, has just hit a wall. > > The problem is not with the code simplification itself. The problem is > that there is a configuration feature called "NIC rules" that depends > on knowing what actual physical interface a packet arrived on. NIC > rules are address filters applied to individual interfaces. > > In order to implement this against a packet flow that is all being > accepted by the wildcard interface, we need a way to back out of each > packet which physical interface it arrived on. > > One might expect this to be available via a CMSG lookup into recmvsg's > per-package auxiliary headers, analogously to the way we now get the > packet-arrival timestamp (see ntpd/ntp_packetstamp.c). It's the only > place for the information to be that has the right locality. Have you look to things like IP_PKTINFO? Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Wildcard-socket simplification hits a wall
On Fri, Mar 31, 2017 at 07:30:05PM -0400, Eric S. Raymond wrote: > Kurt Roeckx : > > > One might expect this to be available via a CMSG lookup into recmvsg's > > > per-package auxiliary headers, analogously to the way we now get the > > > packet-arrival timestamp (see ntpd/ntp_packetstamp.c). It's the only > > > place for the information to be that has the right locality. > > > > Have you look to things like IP_PKTINFO? > > Nope. Thanks to the @!%^#~! crappy documentation, I didn't know that was an > identifier of interest until you pointed it out. Neither the CMSG(3) or ip(7) > manual pages hint that it exists. Because heaven forfend that they should > either list CMSG capabilities or point unambiguously at someplace that > does, that would be too fscking much like being *helpful*. > > *grumble* > > Now that I've looked at it, it halfway solves the problem in a rather > frustrating way...maybe. Or maybe not at all. Yeah, it means you can > back out an "interface index" which designates a physical interface, or its > local address. But then you have the problem of intepreting that index or > address. I was under the impression that you can also use that index when sending something. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: _DATE__, version string, and distros
On Mon, Apr 17, 2017 at 06:41:01PM -0700, Hal Murray wrote: > I think we can kill two birds with one stone. > > The first step is to change the code that uses __DATE__ to use the time stamp > from autorevision. Have you seen https://reproducible-builds.org/specs/source-date-epoch/ ? Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Standard set of terms for precision, accuracy, related concepts.
On Mon, Apr 24, 2017 at 12:36:17PM -0400, Eric S. Raymond wrote: > Having almost recovered from post-viral fatigue syndrome, I have > enough energy to work now and am attempting to clear out my old > project-related mail. I'd like to have my decks cleared for the > face-to-face team meeting this coming Saturday - don't know if > I'll actually manage that but I'm giving it a mighty effort. > > One of the unresolved threads that has been mouldering in my > mailbox is Gary Miller and Achim Gratz arguing about what terms > to use in the numerical-analysis parts of our comments and > documentation. I agree that it would be desirable to have > a uniform set of terms; that area is bewildering enough without > additional terminological confusion. > > This has been sitting there unaddressed because I more or less own > the documentation end of things and have been telling myself that I > ought to digest that entire thread and write a glossary. I am now > confronting the fact that this was staggeringly unrealistic of > me considering everything else on my plate. > > So here's what I'm going to do... > > Achim, you and Gary *both* get to write glossaries covering terms like > precision, accuracy, drift, and related stuff. Give it your best > shot(s). If, after a reasonable period of time, I have a glossary > only from one of you, tha person wins and the glossary gets blessed > and added to the official documentation. > > If you both step up, I will engage the two of you in Socratic dialogue > until we have a merged version. Note however that I am neither > willing nor able to allow this pricess to become an infinite time > sink. If I think you two are arguing in circles, I will ruthlessly > terminate the process and bless something you may not like. I think one of the problems is that such terms are used at many different places. And you might need to be more specific at which one you mean. That is, there might be variables called precision, but not all of them mean exactly the same. A text that works for one might be wrong for the other. So I suggest you start by finding out where you all use such terms. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Standard set of terms for precision, accuracy, related concepts.
On Mon, Apr 24, 2017 at 10:07:47AM -0700, Gary E. Miller wrote: > frequency offset: > The difference between the ntpd calculated frequency and the local system > clock frequency (usually in parts per million, ppm) > jitter, dispersion: > The short term change in a value For me jitter is about chances in the interval. Some examples which I think are relevant are: - For a PPS signal, the signal generated by the source is not exactly 1 second each time, but on average it's 1 second. - For the same PPS signal, there is a variable delay between the source generating the edge and the PC having seen it and measured the time. - A packet send over a network doesn't always have the same delay. dispersion for me is the standard deviation Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: OpenSSL quirk
On Fri, Oct 25, 2019 at 01:26:53AM -0700, Hal Murray via devel wrote: > I haven't seen any examples of OpenSSL on distros that are so old that they > don't support TLS 1.2 TLS 1.2 got added in 1.0.1, which was released in 2012. I'm guessing there are some old redhat versions that are still supported running something older, like 0.9.8. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: OpenSSL 3.0.0
On Mon, Jun 15, 2020 at 11:54:57PM -0700, Hal Murray via devel wrote: > > They are up to alpha3. I've been trying it. > > I added a tweak to wscript to support this, and some notes in HOWTO-OpenSSL > That recipe also works for getting 1.1.1 on old systems so they can use NTS. > > - > > There are several big changes in 3.0.0 > The CMAC_* API that we have been using is now DEPRECATED. > The low level crypto stuff that we use has slowed down. > There is a blizzard of shadow warnings for freefunc if Python.h is included. > > I added attic/cmac-timing to time the various ways to do the CMAC > calculations. > It's also a convenient place to debug the recipe. In addition to the old > way, > there is a way that works on both old and new OpenSSL, and another way that > only works with the new code. > > The new way has split the setup/init code into two parts. One does the setup > stuff derived from a key. The other initializes the internal data. The > second part is quick. If we can afford the memory for a context for each > key, > we can speed up CMAC calculations a whole lot. We should be able to get half > of that speedup on the server by having the transmit side reuse the context > setup by the receive side. But the new way is so slow that even with that > hack, the CMAC calculation much slower than the old code. Note that we're still waiting for a reply from you about your test code. I would like to see if it's possible to improve the speed in 3.0.0, or at least understand where the slowdown comes from. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Clock tracking
On Mon, Mar 22, 2021 at 02:24:50PM -0700, Hal Murray via devel wrote: > > Since you mentioned PTP, can we use the PTP time stamping stuff to get better > time stamps for NTP packets? (without dragging in any/much PTP stuff) NTP can make use of some of the features that PTP hardware supports. NTP will not be able to use PTP support in switches, but your ethernet controller might have PTP support, and NTP can make use of it. Chrony has support for it, and also supports interleaved mode. Combining those 2 can give you very good results. On Linux you can query your hardware capability using ethtool -T. I have 2 hosts that supports hardware timestamps. The first returns: # ethtool -T eth0 Time stamping parameters for eth0: Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE) PTP Hardware Clock: 0 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on(HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL) ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) ptpv1-l4-delay-req(HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) ptpv2-l4-delay-req(HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) ptpv2-l2-delay-req(HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) ptpv2-sync(HWTSTAMP_FILTER_PTP_V2_SYNC) ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ) The other returns: ethtool -T eno1 Time stamping parameters for eno1: Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE) PTP Hardware Clock: 0 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on(HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL) The difference is which received packets get timestamped. If you want to use hardware timestamping with NTP, the filter support doesn't really matter, there is no NTP filter support in hardware, so you'll end up timestamping all incoming packets. Here is an example of a host that doesn't do hardware timestamping: Time stamping parameters for enp1s0: Capabilities: software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) PTP Hardware Clock: none Hardware Transmit Timestamp Modes: none Hardware Receive Filter Modes: none And yet an other: Time stamping parameters for eth0: Capabilities: software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) PTP Hardware Clock: none Hardware Transmit Timestamp Modes: none Hardware Receive Filter Modes: none Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Interleaved Mode (Was: Re: Using Go for NTPsec)
On Tue, Jul 06, 2021 at 12:18:26PM -0500, Richard Laager via devel wrote: > On 7/5/21 8:38 AM, Eric S. Raymond via devel wrote: > > > There is a close-to-RFC to handle this area. "Interleave" is the > > > buzzword. I > > > haven't studied it. The idea is to grab a transmit time stamp, then > > > tweak the > > > protocol a bit so you can send that on the next packet. > > > Daniel discovered it was broken and removed it from the protcol machine. > > Broken implementation or broken design? If the latter, is the current IETF > proposal (wherever that is) still broken? It at least seems to work without problem using chrony. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: seccomp ratsnets: crypto using threads
On Sat, Nov 25, 2017 at 05:09:02AM -0800, Hal Murray wrote: > > k...@roeckx.be said: > > This means that when we initialize a global variable we use the > > pthread_once() function, which internally uses the futex to do that. It's > > not using threads itself, it's just making sure that if you use threads > > things work properly. > > Thanks. > > Do we have to link with pthread, or is there a dummy/backup pthread_once() > available for things like this if we are not using threads? OpenSSL itself now linked to pthread, there is no need for you to also link to it unless you use threads. The only way to avoid it is to build OpenSSL without thread support. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: seccomp ratsnets: crypto using threads
On Sat, Nov 25, 2017 at 01:26:18AM -0800, Hal Murray via devel wrote: > (gdb) bt > #0 0x76ebf104 in futex_wake (private=0, processes_to_wake=2147483647, > futex_word=0x76eaf618) at ../sysdeps/unix/sysv/linux/futex-internal.h:231 > #1 __pthread_once_slow (once_control=0x76eaf618, init_routine=0x76de9f50) > at pthread_once.c:127 > #2 0x76e21fbc in CRYPTO_THREAD_run_once () >from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1 > #3 0x76dea538 in OPENSSL_init_crypto () >from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1 > #4 0x76de4098 in EVP_get_digestbyname () >from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1 So you've upgraded for an OpenSSL 1.0.2 to 1.1.0. In 1.1.0 we made changes to the thread support, and assume applications might be using threads instead of relying on them to set things like locking up properly. This means that when we initialize a global variable we use the pthread_once() function, which internally uses the futex to do that. It's not using threads itself, it's just making sure that if you use threads things work properly. I think if you want to use seccomp you can really expect to get such breakage from time to time when libraries or the kernel change. Libc might for isntance start to use different syscalls depending on the running kernel, or just changes in the wey libc does something. And so everything you link to might cause such changes. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: All hands alert - NTPsec gets bad responses from Amazon NTP servers
On Sun, Dec 03, 2017 at 02:43:04PM -0500, Eric S. Raymond via devel wrote: > All hands alert. We have our first, or maybe second depending on how > you count, serious bug. About 33% of the time, NTPsec is eliciting bad > packets from Amazon time service. Classic does not have this problem. I would argue that no matter what the client sends, the server should send back a correct packet, and it more seems to be a problem with the Amazon time service. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Crypto, passwords
On Fri, Jan 05, 2018 at 10:04:44AM -0500, Eric S. Raymond via devel wrote: > > MD5 is no longer considered safe. > > Is SHA1 considered safe? What other types should we test and/or suggest > > people use? > > No, SHA1 is no longer considered safe. The first collision was generated > early last year. The git team is considering a move to SHA-2 (I think - I > might be out of date on this.) For both MD5 and SHA1 it depends on what property of it is important, which depends on how you use it. (I have no idea how NTP uses it.) Both are still secure for preimage attacks but not for collisions. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Crypto, passwords
On Fri, Jan 05, 2018 at 04:24:01PM -0500, Eric S. Raymond wrote: > Kurt Roeckx : > > On Fri, Jan 05, 2018 at 10:04:44AM -0500, Eric S. Raymond via devel wrote: > > > > MD5 is no longer considered safe. > > > > Is SHA1 considered safe? What other types should we test and/or > > > > suggest > > > > people use? > > > > > > No, SHA1 is no longer considered safe. The first collision was generated > > > early last year. The git team is considering a move to SHA-2 (I think - I > > > might be out of date on this.) > > > > For both MD5 and SHA1 it depends on what property of it is > > important, which depends on how you use it. (I have no idea how > > NTP uses it.) Both are still secure for preimage attacks but not for > > collisions. > > This is true. However, it is also the case that - based on historical timing > of attack discoveries - preimage attacks tend to follow collision iductions > relatively rapidly. For the git team to act on the assumption that a SHA-1 > preimage attack will be discovered soon is reasonable. So I want to clarify this a little. As far as I know MD5 is actually broken for preimage resistance, but it's only slightly faster than bruce force. For SHA-1 it's only a reduced version that's broken. In the long run you should not trust them, but I don't think there is a reason to panic (if only preimage resistance is important). I have no idea how it's used in NTP. But I understand it's some kind of shared password? You should clearly look in how it's being used and if that actually makes sense. Maybe it needs more than just replacing the hash algorithm. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Crypto, passwords
On Fri, Jan 05, 2018 at 02:41:39PM -0800, Hal Murray wrote: > > > I have no idea how it's used in NTP. But I understand it's some kind of > > shared password? You should clearly look in how it's being used and if that > > actually makes sense. Maybe it needs more than just replacing the hash > > algorithm. > > It appends a digest to the packet. This digest covers the shared password, > the body of the packet, and a 4 byte keyid. I'm not an expert in this sort of things, but I would suggest you at least change that to an HMAC. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Why admin's do not trust daemons to do their own packet filtering (was Re: Resuming the great cleanup)
On Tue, May 29, 2018 at 03:15:15PM -0400, Eric S. Raymond via devel wrote: > [[interface]] > +interface+ [+listen+ | +ignore+ | +drop+] [+all+ | +ipv4+ | +ipv6+ | > +wildcard+ | 'name' | 'address'[/'prefixlen']]:: > This command controls which network addresses +ntpd+ opens, and > whether input is dropped without processing. Do we only have 1/2 socket by default, or do we still have a listen socket per interface / ip address? If there is still a socket per interface / ip address, at least some of this will be useful to some people. There are actually people that have more interfaces than you can have open files. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp_random - please check
On Fri, Jul 06, 2018 at 01:27:30PM -0700, Hal Murray via devel wrote: > Also, it didn't check the return code. That raises an interesting question. > What should we do if there isn't enough entropy? > > How much entropy is there in a typical system? Can a malicious user use it > all up? Could a busy server run out? You're actually using OpenSSL to generate those random bits, so it depends on OpenSSL too. In OpenSSL 1.1.1 the CSPRNG will actually reseed itself from the OS by default. It needs to get 256 bits from the OS by default every hour, or every 2^24 calls, which ever comes first. So that would mean more than 4660 calls per second to need more than 256 bit / hour of the OS. Any OS really should be able to deliver that much. And hardware RNGs can actually be pretty cheap and deliver very high rates. In older versions it just once reads the 256 bit, and then never gets new data from the OS. Note that this change in OpenSSL's behaviour to reseed can cause problems for processes that chroot and don't have access to /dev/urandom in the chroot nor have a system call like getentropy() that can be used instead. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp_random - please check
On Fri, Jul 06, 2018 at 06:05:49PM -0700, Hal Murray wrote: > > k...@roeckx.be said: > > Note that this change in OpenSSL's behaviour to reseed can cause problems > > for > > processes that chroot and don't have access to /dev/urandom in the chroot > > nor > > have a system call like getentropy() that can be used instead. > > Interesting. Thanks. > > Is that documented someplace we can reference? There is https://github.com/openssl/openssl/blob/master/CHANGES that has: *) Modified the random device based seed sources to keep the relevant file descriptors open rather than reopening them on each access. This allows such sources to operate in a chroot() jail without the associated device nodes being available. This behaviour can be controlled using RAND_keep_random_devices_open(). [Paul Dale] And: *) Grand redesign of the OpenSSL random generator The default RAND method now utilizes an AES-CTR DRBG according to NIST standard SP 800-90Ar1. The new random generator is essentially a port of the default random generator from the OpenSSL FIPS 2.0 object module. It is a hybrid deterministic random bit generator using an AES-CTR bit stream and which seeds and reseeds itself automatically using trusted system entropy sources. Some of its new features are: o Support for multiple DRBG instances with seed chaining. o Add a public DRBG instance for the default RAND method. o Add a dedicated DRBG instance for generating long term private keys. o Make the DRBG instances fork-safe. o Keep all global DRBG instances on the secure heap if it is enabled. o Add a DRBG instance to every SSL instance for lock free operation and to increase unpredictability. [Paul Dale, Benjamin Kaduk, Kurt Roeckx, Rich Salz, Matthias St. Pierre] (I guess I need to change this, the last line is not true anymore.) The RAND_keep_random_devices_open manpage can be seen here: https://www.openssl.org/docs/manmaster/man3/RAND_keep_random_devices_open.html Various applications already ran into problems because of the reseeding, which is why we now keep it open by default. You might also want to read: https://www.openssl.org/docs/manmaster/man7/RAND.html If you generate random bytes that you don't send to the peer you might also want to look into using RAND_priv_bytes(). Note that 1.1.1 is not released yet, but it should be "soon". Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Against certain proposed TLS client-side options
On Sat, Feb 02, 2019 at 05:52:25PM -0500, Eric S. Raymond via devel wrote: > Gary E. Miller via devel : > > On Sat, 2 Feb 2019 06:16:45 -0500 (EST) > > "Eric S. Raymond via devel" wrote: > > > > > NEVER CONFIGURE WHAT YOU CAN DISCOVER > > > > > > These are from nts.adoc: > > > > > > *tls1.2* Allow TLS1.2 connection. > > > > > > *tls1.3* Allow TLS1.3 connection. > > > > > > We don't need these because in this 'graph > > > > > > Implementations MUST NOT negotiate TLS versions earlier than 1.2, > > > SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and > > > MAY refuse to negotiate any TLS version which has been superseded by a > > > later supported version. > > > > > > the last normative is a MAY, not a MUST. Thus, you never need to do > > > anything but allow some connection at 1.2 or up even once 1.2 is > > > superseded. Correct[racticr is to use the highest version you have. > > > > As previously asked, discussed and answered here: > > > > The list of allowed versions, and even names, will change. Sometimes > > overnight as we have seen many times. > > Of course it will. That is irrelevant to where options to suppress > capabilities are needed, because the right behavior is always "allow > everything above the last version implicated in a crypto emergency"... > > > Being able to force a version is required for testing. > > ...UNLESS you're forcing for testing. That is a valid point. > > But if that were your concern you should have specified a forcetls > option, not these silly allow flags. If you wish to add that to nts.adoc > I will consider it on my to-do list. It can go with mintls. Doesn't > need to be per-peer, obviously. I really recommend to use a minimum version, and not a list of supported versions. Having a list causes all kinds of problems. > > Oh, and discovery of these is a bitch. > > Nevertheless, that is what we are going to do, because it is the right thing. > > We may not be able to do it before first ship to Cisco, but it must remain > the eventual goal unless it is demonstrated to be > impractical/impossible rather than merely difficult. Users are not likely to change the configuration of every application in case like a protocol or cipher needs to be disabled, they will likely not know which applications all need to be modified. And if they do modify it, most likely some time later that configuration will cause problems. I suggest you stick to the defaults. In case of problems they will be modified by the library maintainers so that they no longer are part of the default. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: mintls, maxtls, enclair, and cipher.
On Sun, Feb 03, 2019 at 03:15:55PM -0600, Richard Laager via devel wrote: > On 2/3/19 1:01 PM, Eric S. Raymond wrote: > > I guess it will have to be an empty string that disables encryption. > > I'm not sure if you wrote this before the recent messages on the NULL > ciphers. But you said you were going to use that, so... > > It's not an empty string... the NULL ciphers have specific names that > are valid in an OpenSSL ciper string. > > See `openssl ciphers -v 'NULL'`. > > You would use: > ciphers NULL > > or something more specific if you want: > ciphers NULL-SHA256 > > That would select a NULL cipher. Note that by default that doesn't work. You need to lower the security level to 0. You can do that with NULL@SECLEVEL=0: $ openssl ciphers -tls1_2 -s -v NULL@SECLEVEL=0 ECDHE-ECDSA-NULL-SHATLSv1 Kx=ECDH Au=ECDSA Enc=None Mac=SHA1 ECDHE-RSA-NULL-SHA TLSv1 Kx=ECDH Au=RSA Enc=None Mac=SHA1 AECDH-NULL-SHA TLSv1 Kx=ECDH Au=None Enc=None Mac=SHA1 NULL-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=None Mac=SHA256 NULL-SHASSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1 NULL-MD5SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5 Note that I've added the -s option, which limits it to the usable ciphers, and I've added -tls1_2 to prevent it from showing TLS 1.3 ciphers. Note that TLS 1.3 does not support a NULL cipher. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: TLS Versions
On Wed, Feb 06, 2019 at 02:05:27PM -0800, Hal Murray via devel wrote: > > float mintls = 1.2; /* minimum TLS version allowed */ > float maxtls; /* maximum TLS version allowed */ > > Floats? The API to OpenSSL doesn't work in floats. We'll have to translate > those to something useful. I'd like to push that back to ntp_config. > > From /usr/include/openssl/tls1.h > # define TLS1_VERSION0x0301 > # define TLS1_1_VERSION 0x0302 > # define TLS1_2_VERSION 0x0303 > # define TLS1_3_VERSION 0x0304 > # define TLS_MAX_VERSION TLS1_3_VERSION > > We should initialize those slots to TLS1_2_VERSION and TLS_MAX_VERSION Please use 0 instead of TLS_MAX_VERSION, it means the same. I've marked TLS_MAX_VERSION for deprecation. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: TLS Versions
On Wed, Feb 06, 2019 at 10:31:39PM -0800, Hal Murray wrote: > > k...@roeckx.be said: > > Please use 0 instead of TLS_MAX_VERSION, it means the same. I've marked > > TLS_MAX_VERSION for deprecation. > > Thanks for the heads up. > > Is there any documentation on that? (man page?) There is SSL_CTX_set_max_proto_version(), which documents the 0 value: Setting the minimum or maximum version to 0, will enable protocol versions down to the lowest version, or up to the highest version supported by the library, respectively. The current file in master looks like this: # define TLS1_VERSION0x0301 # define TLS1_1_VERSION 0x0302 # define TLS1_2_VERSION 0x0303 # define TLS1_3_VERSION 0x0304 # if !OPENSSL_API_3 # define TLS_MAX_VERSIONTLS1_3_VERSION # endif Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's left to doo on NTS.
On Sat, Mar 02, 2019 at 09:23:51PM -0800, Hal Murray via devel wrote: > *) There is actually one interesting point that authentication makes more > interesting. On receive, we get a time stamp when the packet arrives. We > can > take all day to inspect the packet and run authentication code. On transmit, > we grab the time and put it in the packet. All the delays between then and > when the packet hits the wire are contributing to a misleading time stamp. > Authentication code is on that path. The same thing happens on both client > and server. If they are similar CPUs, the offsets should cancel. If not, > ... > I think we can measure this by comparing IPv4 and IPv6 with NTS on one. If this is something you're worried about, this can be solved with the interleave mode, which was removed. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's left to doo on NTS.
On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote: > > k...@roeckx.be said: > > If this is something you're worried about, this can be solved with the > > interleave mode, which was removed. > > How well does it work? It works great, the errors are much smaller when it's enabled. > Is there an option to get a kernel timestamp on transmit packets? On 10 year old server hardware you can get: $ ethtool -T eth0 ethtool -T eth0 Time stamping parameters for eth0: Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE) PTP Hardware Clock: 0 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on(HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL) ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) ptpv1-l4-delay-req(HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) ptpv2-l4-delay-req(HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) ptpv2-l2-delay-req(HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) ptpv2-sync(HWTSTAMP_FILTER_PTP_V2_SYNC) ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ) While on a desktop it might look like: $ ethtool -T eth0 Time stamping parameters for eth0: Capabilities: software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) PTP Hardware Clock: none Hardware Transmit Timestamp Modes: none Hardware Receive Filter Modes: none The software transmit/receive should always be available, the support depends on what hardware you have. Software TX/RX should always be available, and if it's not, it should be easy to add support for it. If the OS doesn't provide it, you can still do something in the daemon itself. See: https://www.kernel.org/doc/Documentation/networking/timestamping.txt Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's left to doo on NTS
On Sun, Mar 03, 2019 at 08:56:55PM +0100, Achim Gratz via devel wrote: > Hal Murray via devel writes: > > There is no security in the pool anyway, so let's put that discussion > > aside for a while. > > I'd take exception with that statement. If the pool was upgraded to use > NTS one way or the other, it _would_ provide some extra security over > the status quo. It's a different kind of security than what you get > from running your own time servers, but if I can be sure that I'm > talking to the NTP server that the pool has assigned me instead of > talking to some random IP address that the pool thinks is an NTP server > but can't be sure of, then that's a lot better than what we have today. I don't see how it can work with the current pool system. You look something up like pool.ntp.org and get some IP addresses. But none of those will have a certificate for pool.ntp.org, so the verification of the certificate will fail. ntp.org currently doesn't use dnssec, so that DNS is not even secure, so there really isn't much changed compared to what we have now. I think what we need is a secure way to get a list of hostnames. One way is to run some https query. This will probably require more resources to run the pool then what it currently uses. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's left to doo on NTS
On Sun, Mar 03, 2019 at 10:25:31PM +0100, Achim Gratz via devel wrote: > Kurt Roeckx via devel writes: > > I don't see how it can work with the current pool system. You look > > something up like pool.ntp.org and get some IP addresses. But none > > of those will have a certificate for pool.ntp.org, so the > > verification of the certificate will fail. > > You will still look up a pool address, just for the NTS-KE of that pool, > which will have a proper certificate by definition. The NTS-KE will > then give you back a different NTS server to use. Since this server > needs to agree on the master key and the initial set of cookies with the > NTS-KE, if you can successfully communicate with the NTS, it is indeed > the server that the NTS-KE has assigned to you. No certificate for that > server is needed. There currently isn't a protocol defined between the NTP server and the NTS-KE. This would mean that if you want to use it with the pool that such a protocol would need to be defined. I also don't think NTS is designed for this use case. I'm not sure what the security implications are, but at least hacking the pool then seems like a way to be able to impersonate all servers in the pool. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's left to doo on NTS.
On Sun, Mar 03, 2019 at 05:59:11PM -0500, Daniel Franke wrote: > On Sun, Mar 3, 2019 at 8:45 AM Kurt Roeckx via devel wrote: > > On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote: > > > > > > k...@roeckx.be said: > > > > If this is something you're worried about, this can be solved with the > > > > interleave mode, which was removed. > > > > > > How well does it work? > > > > It works great, the errors are much smaller when it's enabled. > > Interleaved mode in NTP Classic doesn't do what you think it does. > > The concept behind interleaved mode is sound: get packet timestamps > from the NIC at the moment they cross the wire, thus eliminating the > contribution of local buffers to jitter. But ntpd doesn't do anything > of the kind! > > Actually getting timestamps from the NIC is fairly involved. The NIC > has its own clock and its own oscillator, which has to carefully be > kept in sync with the system clock. Furthermore, all the APIs for > doing this are OS-specific. Check out the linux-ptp project to see > what it looks like when it's done right; it's a fair bit of code, and > nothing of the kind is present in ntpd. But it is present in chrony. It supports both interleaved mode and hardware timestamping. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's left to doo on NTS.
On Sun, Mar 03, 2019 at 03:30:53PM -0800, Gary E. Miller via devel wrote: > Yo Kurt! > > On Mon, 4 Mar 2019 00:19:44 +0100 > Kurt Roeckx via devel wrote: > > > > Actually getting timestamps from the NIC is fairly involved. The NIC > > > has its own clock and its own oscillator, which has to carefully be > > > kept in sync with the system clock. Furthermore, all the APIs for > > > doing this are OS-specific. Check out the linux-ptp project to see > > > what it looks like when it's done right; it's a fair bit of code, > > > and nothing of the kind is present in ntpd. > > > > But it is present in chrony. It supports both interleaved mode > > and hardware timestamping. > > I'm looking for it, but can not find it. Can you point out where? > > I do see that chronyd has a "PTP hardware clock (PHC) refclock driver". > But that is Linux only and not the same thing. In the config file you just add: hwtimestamp eth0 (It doesn't start if you don't actually have hardware support.) On the server line you add xleave. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: CI: debian-oldoldstable
On Mon, Mar 25, 2019 at 04:00:23AM -0700, Hal Murray via devel wrote: > > 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] It has been removed from the debian mirrors: https://lists.debian.org/debian-devel-announce/2019/03/msg6.html So you need to use archive.debian.org if you still want to support it. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Garbled IPv6 printout
On Sat, Mar 30, 2019 at 02:35:18PM -0700, Hal Murray via devel wrote: > 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 > something, > I'm not sure what. A sockaddr isn't big enough for an IPv6 address. A sockaddr is not meant to store the address, it just provides you with fields that are there for all variants like sockaddr_in, sockaddr_in6 and sockaddr_un, so that you can at least see which type of address it is. You should consider using sockaddr_storage. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Garbled IPv6 printout
On Sat, Mar 30, 2019 at 08:05:41PM -0700, Hal Murray wrote: > > 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]; POSIX defines it as "char sa_data[]" and that it is variable length. You should really use any of the other compatible sockaddr structs and cast it to a struct sockaddr *. > That's not big enough for an IPv6 address. I assume somebody suggested > making it bigger and/or changing the parameters to accept when IPv6 was > added. It would be interesting to review that discussion. Nobody suggested that sockaddr was ever something that can hold an IPv4 address or UNIX domain socket, it was never designed to hold that. Instead you always had the give the proper type and cast it. A sockaddr_storage was added as part of adding IPv6 support. If you really want to know all kinds of historic information about such things, I suggest you read Stevens' TCP/IP Illustrated. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
