Re: Buildbot with gcc5
v...@darkbeer.org said: > If you have any other ideas / permutations for builds please feel free to > suggest. Many OSes/Distros have 2 supported versions. For Intel, they come in both 32 and 64 bit versions. I'm assuming the above systems would have all packages interesting to ntpsec installed. It would also help to build on a system with minimal installed packages, just enough to build a useful version of ntpd. We would need to document what packages were installed. I think we should also include some ARM systems. The main distro for the Raspberry PI is Raspbian, derived from Debian. Pi-s come in two CPU versions. The old/slow ones take 6-9 minutes for a build (no doc, no check) and another 1-2 minutes for check. The new CPU takes 2.5 minutes to build and under 1 to check. I think NetBSD and FreeBSD both run on the Raspberry Pi, but I haven't found a good install HOWTO for either. We also need to actually run the code. I don't know how to monitor for obscure quirks but we should be able to setup something for a sanity check. We also need a way to test refclocks. I'd be happy if we could run one of each major type on any OS. Where are OS-x and RTEMS on the radar? A wrong endian system would be high on my list. That requires actually running the code. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: I have resolved all pending merge requests
e...@thyrsus.com said: > Hal, if you can port over the Classic fix for the MRU ^C bug that would be a > good thing. I took a look. It's not simple. There have been lots of changes to ntpq. Taking everything risks dropping some of our fixes and/or picking up some of their new bugs. I think I'll see if I can work out a simple fix. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: planning ntpsec 0.9.1 release at about 7pm PST tonight
e...@thyrsus.com said: > Sure would have been nice if we could have crossported Classic's fix for the > ^C bug in ntpq, though. That particular bug isn't a big deal or somebody would have worked on it sooner. The real question is are we going to track fixes from NTP Classic and if so who, how, when, etc? There were a lot of patches released in the past few days. I haven't scanned them. I don't think anybody has reviewed all the changes since the fork. I looked into the ^C tangle. I'm trying to do it from scratch rather than blindly copy the new code. Maybe I'll learn enough to understand why the new code seems so complicated. It should be simple. The general idea is that the code that calls the command dispatcher does a setjmp and sets a flag for the ^C signal handler. If the flag is on, the signal handler does a longjmp to bail from the command. I put a printf in the top of the signal handler. The problem I'm seeing is that the ^C handler goes away after the first jump. If it doesn't jump, it keeps on working. An additional complication is that readline sets a bunch of signal handlers. I haven't investigated. Since it isn't mentioned in the man page, I assume it puts things back the way they were and/or calls the old signal handler. I tried blindly setting the signal handler again but that didn't fix it. That's as far as I got before it was time for sleep. Maybe it's masked? I've spent some time googling but haven't found anything interesting yet. Are there any obvious gotchas associated with signals and longjmp that I should know about? I'm working on Linux/Fedora. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: POOL keyword in ntp.conf non resolving
gha...@gmail.com said: > 01-26T23:14:40 ntpd[28107]: error resolving pool hk.pool.ntp.org: No address > associated with hostname (-5) That tells you that DNS isn't working. The pool stuff works for me. Have you tried simple command line tools to verify that your DNS setup is working? I use host and dig. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
SIGINT, longjmp
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. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: SIGINT, longjmp
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. 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. Nor have I found the API specs that mention this tangle. There is an opportunity for storage leaks if a routine returns storage that should be free-ed or even uses/frees storage internally. I'm fishing for a list of routines that shouldn't be used with longjmp similar to the list that shouldn't be used with threads, or rather for the discussion of that list. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: SIGINT, longjmp
k...@roeckx.be said: > I want to add that it likely does at least something with the signal > handlers so that it can time out. You don't need signals to time out on network activity. Most reads/writes have a timeout option. I forget the details. It's been a long time. If that doesn't work, you can use select. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: SIGINT, longjmp
k...@roeckx.be said: > 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. It's not trying to exit, just get out of a long running command. ntpq has two long-running commands. (Maybe more.) One is peers (which has many variants). Normally, it tries to translate the IP address of the slot to a name. The other is mrulist. It runs in two passes. The first pass collects the data. Since slots may get updated while being collected there is the possibility to go back and fetch them again. The second pass sorts and prints things out. With two passes, you would like ^C during the collect pass to stop collecting and print out what it has. So the ^C handler just sets a flag and the collect loop stops collecting. The print pass resets the flag as it starts, then watches the flag so another ^C will stop printing. I think I could avoid the longjmp by having the peers loop check the flag. I haven't checked to see if there are any other commands that might run too long. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: SIGINT, longjmp
e...@thyrsus.com said: > I don't know of any functions that are specifically unsafe around setjmp()/ > longjmp(). The interesting case is longjmp-ing from a signal handler. > The right way to think about setjmp()/longjmp() is as a save/restore of the > processor's register state, including the stack and frame pointers. It > doesn't have the concurrency issues that threads do because it doesn't alter > static memory or the heap. It doesn't alter the heap, but it doesn't restore it either. Anything that calls malloc is an opportunity for a storage leak. Jmp-ing from a signal handler yanks you out of the middle of a routine without any opportunity for cleanup. I suspect getaddrinfo masks or intercepts SIGINT, but I haven't found anything like that in the man pages. The symptom is that ^C doesn't work right away but does work after several seconds, a reasonable time for a DNS lookup if you need to retransmit or have a bloated link. A signal handler is roughly equivalent to a short-lived thread. The Linux man page has a list of routines that are guaranteed to work crrectly from a handler. It doesn't say anything about longjmp. The man page for longjmp doesn't say anything about signals other than siglongjmp restores the mask. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: SIGINT, longjmp
> Ah, it's probably doing a sigsuspend(2). I doubt it. That ties up your process/thread waiting for a signal. If you want to wait for IO, there are simpler ways. My guess was sigprocmask(2). They way that I discovered that somebody was masking SIGINT was using it to read the current mask. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: recurring "standup"
v...@darkbeer.org said: > * Modify build system and rewind it back to the initial NTPSec commit -- > this is a WIP no ETA. What does that mean? It sounds interesting. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Real World Crypto conference
I went to the Real World Crypto conference in early Jan. I met Daniel. He might have corrections or additions. Many of the slides are here (no videos): http://www.realworldcrypto.com/rwc2016/program My primary interest was in trying to find a way to get secure NTP off the ground. Typical crypto using certificates assumes you know the time. DNSSEC assumes you have valid time. I didn't find a solution, but at least nobody I talked to told me I was asking a stupid question. I though the best talk was the first one. Jon Callas from Silent Circle was describing their Blackphone project/product. It's a seriously secure phone targeted at CEOs rather than geeks. He had lots of good comments, but the one that attracted my attention was that good Software Engineering was as important as good crypto. Have your act together so you can get fixes out quickly. Get rid of old cruft. Crypto geeks are not good UI designers. ... Their WiFi was connected to the main CPU via a serial port rather than DMA so they didn't have to worry about bugs in the WiFi taking over the system. Check out his slides. There were good talks by Nate Cardozo from the EFF and Daniel Kahn Gillmor from ACLU. The latter had lots of good info/advice for sysadmins: SSLMate and Let's Encrypt. One of his concerns is privacy/security for people without a lot of money. They are likely to be running old phones. That leads to an interesting conflict. You would like software projects to simplify things by dropping support for old hardware. Adrienne Porter Felt from Google/Chrome discussed the UI side of security issues in browser error messages. A significant fraction of their certificate errors were actually bogus time on the users system. (Yes, there really was a link with time.) -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: recurring "standup"
fallenpega...@gmail.com said: > What have you all worked on in the past couple of weeks, what successes and > frustrations have you had, and what do you see yourself working on over this > next week? I've been poking around with shared key crypto and various ways of getting connected to a server. A lot of ways to establish a connection default to requiring crypto. Everything I tried worked, but it often took me a while to figure it out. The ntpq peers command could be tweaked to tell you how a "peer" got setup. That would be a minor incompatibility. We might be able to eliminate some of the modes. Mumble, they probably don't cost much. I should try to document all the modes in one place. That would be easier after ntpq was "fixed" to help. ntpq uses ^C to bail out of the current command. The mrulist command is two passes, the first collects data and the second prints it out. (The order may change while the data is being collected.) ^C is supposed to stop collecting and print out what it has collected. Another ^C is supposed to stop printing. I looked into porting the fix from NTP Classic, but it seemed unreasonably complicated. I tried the obvious code. It didn't work. Eventually, I tracked the problem back to somebody masking SIGINT. It's tangled with setjmp/longjmp and/or what's being jmp-ed out of. siglongjum works as expected. I haven't found any documentation of the need to do that. At that point, I got sidetracked. I think I can fix the code not to use longjmp, but that will probably take a while. I'll have to find out where the people who work on longjmp and/or getaddrinfo hang out and/or try it on other OSes/distros. The man pages are not getting installed where my man command is looking. Are we installing them in the wrong place or do I need to tell my man command to look where we put them? We need to document this. We probably have the same issue with executables, but I fixed that ages ago so I'm not noticing any troubles. I may have blundered into a bug in ntpd's startup logic. I think it's stepping the time when the first server responds rather than waiting to hear from a few more servers. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Real World Crypto conference
fallenpega...@gmail.com said: > An idea that is being floated is an extension to UEFI and equivalents to > allow admins to set or pin a cert, a signing cert, or a psk, that will be > used by a trusted time source. But people are waiting on the release and > stabilization of the new secure ntp standard(s) before having UEFI et al > start pushing it. Pinning a cert gets you tangled up with certs. I think you can avoid a huge pile of code if you just pin the public key of several servers. The question is how deep does that key get buried. Is it in a file system where it is easy to update? Does that box (or that level of a bigger/smarter box) even have a file system? > Another idea is to be pushing time around on the BMC-connected management > network, and let the BMC set the motherboard clock before the main CPU > boots. This will require a trusted and secured ntp client running on the > BMC I think the BMC is a reasonable example of the category of small/dumb box I'd like to support. Think IoT. The low end can be pretty low. I see several general approaches: Get your time from a within a trusted network. How much you need to trust depends on how paranoid you are. If you have smart switches, do you have to consider the bad guys taking over your switch? How about WiFi? If your box has a RTC/TOY clock you can use it. But batteries die and clocks go berserk. You can sanity check with dates from the file system and build date of the code. (You need a plan for gear that's been in storage for a long time.) You can ask a human operator. They make mistakes. You can start with public keys from several servers. The idea is to require sane answers from N out of M servers. Normally when picking N and M, you would consider dead servers and broken servers. Now you also have to consider leaked private keys and the lifetime of the gear and/or how often you get to update the list of keys. You can obviously use various combinations. > Other ideas are to let the L2/L3 switches try to keep accurate time, and to > raise alarms if they ever see an NTP packet heading towards a machine in > early boot stage with a time field that is too incorrect. Do you want your switches wasting cycles on that? (and probably screwing up the timing while it is at it) It also sounds like an opportunity for harassment. Just send a packet and the alarm bells go off. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: recurring "standup"
fallenpega...@gmail.com said: > Tweaking ntpq to show the setup is interesting. Is ntpq called by anything > of note in any of the main distributions. It may be worth adding that to > the display in a way that doesnt change too much, and then wait for bug > reports from distros and users. ntpq is primarily used by humans. Somebody might have a script that parses it, but the format sure isn't friendly for that sort of hacking. There are two changes that would make sense. One would be to show some slots that now get skipped over. This is needed anyway to debug some pool cases. I was just going to round it up to show everything. I'll have to look to see what other cases don't show currently. The other change would be in the "t" column. (t for type) The details of the current code are in the man page. I'd be adding a few new codes. I think the changes are localized enough so that we could add a switch. It would just be clutter to maintain. > Interesting about the bug in the startup. Does NTP Classic do it too? > If so, report it to their bugtracker, after we release 0.9.2 I'm pretty sure it does. I noticed the problem because I stumbled into a test case where the first clock to respond just happens to be my home system and my DSL line has a bad case of buffer bloat. That distorts the timing enough to make ntpd step the time which puts an ugly entry into the log file. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: utmpx on OpenBSD.
v...@darkbeer.org said: > In 7d8b2d1 utmpx.h was always assumed to be available. This is not true as > OpenBSD does not have utmpx support. > Can someone look at this please and bring it back? The old way seems a > little convoluted if there is a better way we should try it. I took a quick look. It won't be hard to put that stuff back, but it's typical of the sort of code that Eric ripped out for good reasons. But do we want to go there? Is that a slippery slope? We could easily and cleanly bypass the code that uses utmpx. That would screwup accounting if time stepped by more than a second. Just curious, does anybody use accounting these days? If so, are they running OpenBSD? > There is no point in hoping for utmpx support in OpenBSD either I won't > repeat the discussions here but there are plenty on the OpenBSD lists. utmpx is part of POSIX. I didn't find a good reason why OpenBSD doesn't support it. I did find one "strong +1" comment for not supporting non-posix workarounds. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: (forw) When stratum zero Just. Won't. Do.
> "Obtain your time signal from The Very Fabric Of The Universe - an array of > 30 meter dishes on the roof of your building receives the unwavering echo of > the Big Bang, the Cosmic Microwave Background. ... Don't laugh too hard. The astronomers are very close to GPS accuracy. VLBI is the magic word. They have antennas scattered around the earth. In order to do the math, you have to know the locations of the antennas. I think they calibrate things by looking at a known-good strong signal and back computing the locations. They got good data after the big Alaska quake of 2002 from an antenna that was conveniently located on the other side of the fault. Note that there are tides in solid earth. They are about a foot. There was an experiment at CERN where the data got much better after they corrected for the "phase of the moon". It was extremely sensitive to the diameter of the ring. That changed slightly with earth tides. For a while, people were working on using pulsars as clocks. Atomic clocks are (much) better. Neutron stars have things like star quakes that change the timing if you are looking that carefully. Atomic clocks are riding a curve similar to Moore's Law. There is a fun paper on it: Time Too Good to Be True, Daniel Kleppner Physics Today, March 2006, page 10 http://scitation.aip.org/journals/doc/PHTOAD-ft/vol_59/iss_3/10_1.shtml It's 2 magazine pages. There is a very good paper on practical uses of GPS for timing. Timing for VLBI Tom Clark and Richard Hambly http://www.gpstime.com/files/TOW/tow-time2015.pdf It's 47 pages of slides. It's great background for GPS timing. They start at the microsecond level so don't expect any discussions of errors from USB. It's actually a series that gets updated every year or two. I think an older version of that talk covered Hanging Bridges. They seem to have dropped it. There are good graphs here: http://www.leapsecond.com/pages/m12/sawtooth.htm (Time sink warning if you start following links.) Hanging bridges are important. They basically mean that you can't guarantee that you will get the right answer if you average for a reasonable time. That's a real monkey wrench for testing. We should put together a web page to collect info like that. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: utmpx on OpenBSD.
e...@thyrsus.com said: > >We could easily and cleanly bypass the code that uses utmpx. That would > > screwup accounting if time stepped by more than a second. > I'm not entirely clear on the referent of "that". The *bypass* would screw > up accounting if time stepped by more than a second? I assume the time-changed info is used by accounting programs. Without that info, any accounting and possibly billing data for the time logged in will be off one way or the other if the time gets stepped while you are logged in. Normally, time is only stepped when ntpd is first run at boot time, and even then it's often under a second. You can test your system by grepping your /var/log/messages or /var/log/syslog for "clock_step". Look in something like /var/log/ntp/ntpd.log if your ntp.conf puts logging in a separate file. Joel says RTEMS doesn't support utmpx.h so I'll start by making that case build. But you are right. It was ifdefed out in ntp classic so I won't bother to recover the utmp (no x) case. Does buildbot have an OpenBSD machine? Do we have a way to test on RTEMS? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: utmpx on OpenBSD.
I just pushed the fix to bypass that chunk of code if utmpx.h isn't available. It should build on OpenBSD and RTEMS, or at least not fail for that reason. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: utmpx on OpenBSD.
j...@rtems.org said: > What is this really used for? How could the same goal be achieved in a > single process, multi-threaded OS? Accounting. Think back to the days of time sharing where you got billed for how many minutes you were dialed in and how many CPU seconds you used. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Graphs from NTP servers
I'll turn this into a web page, but this is what I have now. Corrections/feedback encouraged. Off-list is fine. The place to start is a system's loopstats file. This is from a low cost DigitalOcean cloud server in San Francisco. http://users.megapathdsl.net/~hmurray/ntpsec/SFO-self.png That is the system's opinion of how good its clock is. There are two types of errors to consider. The first is the wiggles in that graph. That tells you how stable the local clock is. In this case, except for a few spikes early on, the system mostly thinks it is within 1/2 ms of the correct time. So as long as we are interested in millisecond accuracy rather than microseconds, this system is probably a good place to stand while looking at other servers and/or the internet connections from here to there. The other type of error is systematic errors, for example, using the wrong edge of a PPS pulse or asymmetric network delays. They don't show up in loopstats. You can't detect them without digging deeper. Both types of errors are something you need to keep in mind when looking at graphs. After the typical request-response packet exchange, a NTP client has 4 time stamps: The time the request left the client The time the request arrived at the server The time the response left the server The time the response arrived at the client Note that there are two different clocks used to make those time stamps, either of which may be inaccurate. NTP servers also act as clients to get their time from lower stratum servers. ntpd logs those time stamps in the rawstats file. If you use the "noselect" option on a "server" line in your config file, you can collect info without letting dirty data corrupt your local clock. Here is a graph of the round trip times from San Francisco to several servers on the east coast: http://users.megapathdsl.net/~hmurray/ntpsec/SFO-east-rtt.png The steps in the green and red dots are due to routing changes. The fuzz on the blue dots is queuing delays on some overloaded link. The cap on the fuzz indicates that the overloaded link has 10 ms of buffering. There are a few scattered red dots. The ones that indicate extra delays are typical network glitches. I don't have a good story for the ones at 14 and 15 hours that indicate reduced time. My guess would be a transient network path that was a few ms shorter but didn't happen often enough to show up clearly. Normally, ntpd assumes that the network delays are symmetrical. That lets it compute the offset between the local clock and the remote clock. Here is a graph of results of that calculation: http://users.megapathdsl.net/~hmurray/ntpsec/SFO-east-off.png If instead, you assume that both clocks are accurate, you can compute the network transit delays in each direction. I picked well run servers for this experiment, so that assumption is probably valid. The limiting factor is probably the ms or so on the local clock. Here is a graph of the delays to/from rackety: http://users.megapathdsl.net/~hmurray/ntpsec/SFO-rackety-out-back.png That shows that the congestion is on the return path. It also shows that the return path takes about 5 ms longer than the forward path. Here is the out/back graph for the NIST systems: http://users.megapathdsl.net/~hmurray/ntpsec/SFO-nist-out-back.png The first thing to notice is that the outgoing path takes over twice as long as the return path. Going back to the round trip time graph, it's suspicious that systems located relatively near each other have such large differences in round trip times. The return times are close to the times to/from rackety. Note that there are only a few steps in the bottom/return path and the steps in the top/forward path match the steps in the round trip time so most of the routing changes are on the long forward path. There is an interesting event associated with time-d from 17.5 to 18.5 hours. Note that the out/back steps are mirror images of each other and that there is no change in the round trip time during that time slot. That would happen if the time on the remote system was offset. It could also happen with some unlikey changes in routing. Here is the round trip time graph for the nearby clocks used as references by this system: http://users.megapathdsl.net/~hmurray/ntpsec/SFO-local-rtt.png And the corresponding offset graph: http://users.megapathdsl.net/~hmurray/ntpsec/SFO-local-off.png The routing to all 3 clocks is stable, but something is off by 1/2 ms. Here is the out/back graph: http://users.megapathdsl.net/~hmurray/ntpsec/SFO-local-out-back.png (I dropped one of the HP clocks to reduce clutter.) The mirror image pattern is due to offsets/errors in the local clock. (It could be due to errors in the remote clocks, but all 3 have GPS/PPS inputs and the return paths all agree.) Note the 1/2 ms offset between the two out times. In order to figure out which clock/path is correct, I'll
More on utmpx and friends
On my fedora box, grep finds updwtmpx in /usr/include/utmpx.h but config.h says: /* #undef HAVE_UPDWTMPX */ Looking deeper, it's inside an #ifdef __USE_GNU -- That routing gets used in libntp/systime.c, there is about 10 lines of code. Looks like it writes a couple of records to the file. It looks redundant to me. Is there a reason we are preserving that code? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Tessting for sys/timex.h
>From a NetBSD box: Checking for header sys/timex.h: not found Compilation check failed but include exists sys/timex.h Checking for header sys/audio.h: not found On NetBSD and FreeBSD 9, sys/timex.h needs sys/time.h It works without it on FreeBSD 10 Some/many of the places where timex is used in pylib/configure.py include time but some don't. Should I/we just add it to the places where it is missing? Is there a chance that will break something? ... -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: More on utmpx and friends
fallenpega...@gmail.com said: > I agree, drop it. It's gone. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cross compiling.
> Cross compiling works. Usage is really simple: Great/congrats. > I'll be hooking up an ARM cross build to buildbot that will download and run > on one of the RPI2s I have here to ensure the cross compiling actually > works. I think it would be great if you wrote up a HOWTO type document, including the setup stuff and the required (if any) cflags and ldflags. I think any combination of host OS/distro and target hardware/OS would be very helpful. I'm thinking of a checklist as well as specifics for a specific host and target. I have a Pi where I can test things. I'll be glad to be a guinea pig on such a document. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cross compiling.
v...@darkbeer.org said: > It's so straight forward to use. You literally just need to supply it the > compiler and any cflags. There is nothing fancy at all required. I can > write a paragraph on how to do this. > For instance when I tested on Ubuntu all I did was install gcc-arm-linux-gnu > eabihf and did: I think there are two things I'm looking for. One is the concepts. The other is the details. Text that I can cut/paste cover the details. It probably takes a sentence or two to explain the concept. It can be as simple as "Install the compiler" to decode things like "gcc-arm-linux-gnu". But is it really just the compiler or does that package also include other tools? It may take a bit of background info on the target environment to set things up. If you have an example worked out for Ubuntu, I can probably find the corresponding packages on other distros/OSes. That's assuming that I'll have to go through the same steps but some of the names have changed. In the simple case, somebody could cover another distro/OS by adding a set of cut-paste steps. > waf configure --cross-compiler=arm-linux-gnueabihf-gcc Where do the header files and libraries come from? What does "waf install" do? > It built fine. No OpenSSL or libevent2. I built those later using the same > compiler and it all worked as expected. What did you do to get OpenSSL or libevent2? > OK.. if anyone has any suggestions where the docs should go I can write > something. devel/HOWTO-cross -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
// for comments
There are quite a few uses of // as comments. (Also several in URLs in comments) Do we plan to use any compilers that don't support that? Is it OK to use them? If we find occasional uses, should they be fixed? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: next week: version 0.9.3
fallenpega...@gmail.com said: > Hal, Susan, Joel, Daniel, Chris, Eric: go or nogo for a release? Looks good to me. Not much has changed. I'm working on a fix for the ntpq/longjmp tangle. More in another msg. It should probably wait so it gets more testing. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Why does waf configure require perl?
As far as I can find, perl is only used by a couple of utilities that are not part of the build process. Is it even worth checking for it at all? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Why does waf configure require perl?
v...@darkbeer.org said: > When I first started the build I wanted to make sure we compiled NTP classic > 1:1. It's a soft dependency now you can add mandatory=False to the check. What do we gain by leaving it in at all? Looks like awk is in the same boat. One of these days we should go through the scripts in util/ and verify that they still work and/or do something useful. There are several of them for analyzing or plotting log files. They probably need some sample log files. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Why does waf configure require perl?
v...@darkbeer.org said: > Eventually I want to add tests for the perl scripts and library. We need > perl for that. Sounds good. I assume wa will skip those tests if it can't find perl. There is another test opportunity. If built with --enable-saveconfig, ntpd/check-config.sh will sanity check the parser. It's probably worth making one of the buildbot systems run it. > awk is no longer needed. It's used by some of the utility scripts. sh too. I added a comment and added mandatory=False to all 3 of them. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
^C/SIGINT, longjmp, getnameinfo
I found the glibc-users mailing list. They explained the problem to me. As far as I can tell, there isn't a clean fix. The basic problem is that signal handlers can't legally call many routines. It's similar to the thread-safe issue but not mentioned on individual man pages. From signal (7): A signal handler function must be very careful, since processing else- where may be interrupted at some arbitrary point in the execution of the program. POSIX has the concept of "safe function". If a signal interrupts the execution of an unsafe function, and handler calls an unsafe function, then the behavior of the program is undefined. That is followed by a list of safe functions. If you longjmp out of the signal handler, you are still in the restricted context and can only call safe functions. The glibc version of th eman page for setjmp/longjmp has been updated to make that clearer. I don't know how long it takes that to migrate to what distros distribute. If you want to write solid code, longjmp-ing out of a signal handler is basically a no-no. If you want to do that, you have to go through your code and mask interrupts every time you call a function that is not signal-safe or when you call in to a library/package which might call an unsafe function. An alternative is for the interrupt handler to just set a flag and teach the main code to bail from loops if the flag is set. That works as long as you don't call anything that takes a long time on a human scale. Many routines that might take a while return EINTR if they get interrupted by a signal. Unfortunately, getnameinfo doesn't work that way. Another approach is to put the getnameinfo in a different thread and use pthread_cancel. Canceling has similar problems so the thread has to mask getting canceled at the wrong times which means waiting for getnameinfo to finish. (But since our thread wouldn't be doing anything else, there is no point in canceling it.) So we would have to set things up so the thread gets abandoned and cleans up after itself. I'm sure I could write that code, but it seems unreasonably complicated. My plan is to set a flag and wait for getnameinfo to finish, and then try it to see how annoying the wait is. If it takes too long, I'll consider the separate thread approach. Now I have to find (and test) all the places where it should check the flag. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: An ontology of clocks
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. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: An ontology of clocks
k...@roeckx.be said: > 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". Some clocks get turned off when suspended to save power. Details vary. It takes time to get the crystal started so you may not want to turn it off between keystrokes. k...@roeckx.be said: > There is also at least /dev/hpet that you might want to look at. Most of that sort of clock are all derived from the main CPU crystal which generates several clocks via PLLs. For the detail collection... The CPU clock and friends are probably smeared slightly to dance around the FCC's EMI rules. That means wiggling the frequency slightly. I think the wiggle is typically in the ballpark of 50kHz. It's slow enough so that PLLs can track it and fast enough to keep the FCC happy. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: An ontology of clocks
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.) Do you know about hanging bridges? http://www.leapsecond.com/pages/m12/sawtooth.htm That problem shows up if you try to get a PPS pulse in via USB. The USB clock is coarse enough to make things interesting. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpfrob: stepback for RS6000
gha...@gmail.com said: > I suggest that ntpfrob drop support for testing for this bug. I will clean > up related docs, and review tests, as well, and submit a PR on Github for > review. Sounds good to me. I took a quick look at the code but didn't figure out what it was trying to do. I may try harder, but it's not high on my list. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Alternatives to GPS
gha...@gmail.com said: > Hal is on that list, so I expect he will figure things out first. My reading is that GPS has captured the time market. It would be good if we could work out a reasonable backup and document how to set it up and how good it is. The answer probably depends upon where you are located. (and time of day) NIST changed the modulation pattern on WWVB back in 2012. That pulled the rug out from under the old high end receivers. Some/most of them were in trouble anyway due to the general rise of EMI. If you are near enough to Ft Collins CO, the low cost receivers should work. There is/was at least one package that uses PPS technology to watch the carrier and decode the signal. I think that went in to ntpd via shared memory rather than being an official refclock driver. I tried it many years ago and never got anything that worked well enough to be interesting. I think the German DCF77 covers most of Western Europe. I think there are several low to moderate cost receivers available. There is a similar setup in Japan. LORAN is dead in the US. I think they pulled the plug in most of Europe at the end of 2015. There is some sort of trial in the US using an old LORAN site and frequency. There are occasional reports of old gear springing to life for a day or two. I haven't seen any serious long range plans. WWV is a possibility. I've never tried it. Whether it works for you probably depends on your distance from Ft Collins (or Hawaii) and the quality of your receiver and antenna. There is/was a driver that knew how to tell a specific model of short wave receiver to switch bands/frequencies so it would use the best of several frequencies that WWV transmits on. There are low cost ($20?) USB radios. (They are about the size of a large thumb drive.) I think the target is over the air TV reception. I'm pretty sure they cover WWV. Most of the work is done in software. The SDR (Software Defined Radio) geeks are having fun with them. This would be an interesting area to explore. CHU is a similar in Canada. Another possibility is ACTS. The idea is to dial in to a phone bank at NIST. It measures the delay of the phone line. If anybody has an old modem and low cost land line, this would be an interesting experiment. We should probably investigate a fallback setup of using a PPS derived from a low cost Rubidium. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
tg2
Document that tg2.c may need to be rewritten, and is likely obsolete The WWV family is gone. Use this as a start to attempt a compile: gcc -I ../build/ -I ../include/ -I ../libisc/unix/include/ \ -I ../libisc/include/ tg2.c tg2 is far from obsolete. It is actually a useful utility. It makes various flavors of IRIG which is a popular standard (with many variations) for sending time info over an audio channel. It's used on lots of old gear, like many channel tape recorders collecting data for things like flight tests. There is some documentation in a comment at the top of the source code. There is an IRIG refclock. We should be able to use headphones to debug tg2 and then use tg2 to debug the IRIG driver, and then use other modes of tg2 to debug some of the other audio drivers. I just fixed waf to build tg2 on Linux. I haven't managed to get any audio out yet. It may be a bug in the code. The audio stuff hasn't been tested much. It may be that it is something simple like it needs a few magic keystrokes on alsamixer. Or both. It does make sounds on NetBSD. If anybody is familiar with audio on Linux, please give it a try and see if you can figure out how to get sound out. You can test with a pair of headphones. It needs "modprobe snd-pcm-oss" to setup /dev/audio and chmod... --- The transmitters for the WWV family are alive. What is "gone" is high quality receivers for WWVB. Those are unlikely to return. The low price chips used in battery powered clocks are likely to return in some form. Or somebody may design a receiver that is reasonable for hobbyists to build. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: PROPOSED, change of stance, release metronome
Kurt's comments look good. This is what I was typing in while that was in the pipeline. fallenpega...@gmail.com said: > I propose that we move to a scheduled release model, with the addition of > security fast releases. I think it's more complicated than that. There are several tangled ideas. One is release. The other is support. You haven't said anything about support yet. What is the target audience for a release? How long are we going to support a release? I'm assuming support for older releases means apply security fixes. If we have releases every 2 weeks, that turns into a lot of work. I think that combination means we only support selected releases. One of the main tasks of the project manager is to figure out which releases to support. You could say the same thing with different words. A release is something that gets supported. The things that go out every 2 weeks need a different term, maybe mini-releases or dev-releases. If we have supported releases every 6 months or so, I think we should spend a few weeks before the release concentrating on testing and checking the documentation. This is handwaving, but I'll start with there being 2 classes of users. The first is bleeding edge. Developers can grab the latest from git. In this context, testers count as developers even if they don't write any code. Support consists of going forward. Old releases are never fixed. They are supported only in that you can get them from git to back out of recent changes if they break something in your environment and/or you are bisecting a bug. The second target is distros. Within a distro, there are probably several sub-targets. Many distros have 3 "supported" releases. I'll call them testing, stable, and old. The stable release is the one most users are expected to run. The old release is the previous stable. It stays around to give users plenty of time to upgrade to the new stable. The testing area is for testing new releases from upstream and whatever local changes they make. Many distros have releases every 6 months to a year. Ubuntu LTS supports selected releases for 5 years. https://wiki.ubuntu.com/LTS RHEL goes out to 10 years. https://access.redhat.com/support/policy/updates/errata/ In an ideal world, we would support all the releases that our users are using. In that context, support means security fixes and major bug fixes but not feature updates. (The idea with not adding features is to reduce the risk of breaking something.) If we do things right, after we release a security fix, our users can just grab the fixed version, test it, and release. If distros are helping us test our code by running our 2-week releases in their testing area, we need to coordinate things when they make a release. We need to do a release when they start their pre-release testing and they need to use that release and stop grabbing our 2-week releases. With some coordination, we could reduce the total workload by getting several distros to use the same release(s). If that happens, it makes sense for us to support the old releases since the work of fixing a security bug only needs to be done once. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
warnings from clang on ARM (FreeBSD on Raspberry Pi)
Eric: Would you please take a look at the second one. It's a real bug. You
removed the 2 lines that setup tvlast on Oct 8. Were you trying to move them
out of the "time-critical path"? (and forgot to put them back in)
I haven't investigated the others.
[ 6/121] Compiling libisc/netaddr.c
../../libisc/netaddr.c:145:3: warning: variable 'i' is incremented both in
the loop header and in the loop body [-Wfor-loop-analysis]
i++;
^
../../libisc/netaddr.c:142:22: note: incremented here
for (; i < ipbytes; i++) {
^
1 warning generated.
--
[ 62/121] Compiling libntp/systime.c
../../libntp/systime.c:451:37: warning: variable 'tvlast' is uninitialized
when used here [-Wuninitialized]
tvdiff = abs_tval(sub_tval(timetv, tvlast));
^~
../../libntp/systime.c:351:2: note: variable 'tvlast' is declared here
struct timeval timetv, tvlast, tvdiff;
^
1 warning generated.
--
[151/186] Compiling tests/libntp/sfptostr.c
../../tests/libntp/sfptostr.c:31:19: warning: shifting a negative signed
value is undefined [-Wshift-negative-value]
s_fp test = -200 << 16; // exact -200.00
^
../../tests/libntp/sfptostr.c:45:20: warning: shifting a negative signed
value is undefined [-Wshift-negative-value]
s_fp test = (-200 << 16) - (1 << 15); // -200 - 0.5
^
../../tests/libntp/sfptostr.c:59:20: warning: shifting a negative signed
value is undefined [-Wshift-negative-value]
s_fp test = (-200 << 16) + (1 << 14)*3; // -200 + 0.75
^
3 warnings generated.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: PROPOSED, change of stance, release metronome
fallenpega...@gmail.com said: > I was unclear about the scope of my proposal for 2 week releases. We should > not have a cadence that fast once we are at a 1.0 or beyond, the fast fixed > cadence is while we are still at 0.9 What's the criteria for 1.0? Do we have a list of things that need to be fixed or implemented? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: PROPOSED, change of stance, release metronome
v...@darkbeer.org said: > This can get complicated real fast. I would encourage distros to do rolling > testing but we cannot pin our releases to their schedule in any way. > As long as we have our test results online and they can pinpoint the 'best' > version to run they can go back a release or two in order to find one they > are comfortable with. I'm not sure what you have in mind for "test results". How is a non-wizard going to be able to evaluate anything other than a yes/no, and we will already have filtered out the no-s. > This also encourages us to release more frequently. I don't believe we have > any reason to have 10 releases in a month but we should always have at > least 2 and no fewer than that. This is to avoid stacking changes and lets > things get tested in the test system. What is the purpose of a release? I'm assuming it's a tag on a pile of bits so we have a way to talk about them and a way to focus testing and usage on a smaller number of things to keep track of and support. > We could also solve this by having a 'recommended' version on our website > and point to test results. It would be good to keep distros at least 30 > days behind our development cycle. I expect the full run of run-time > testing to take at least one week per built release. I have a bunch of > RPIs here that I will run ntpd on to make sure it keeps time properly one > that test passes then we can say that is a 'stable' version of a release > and recommend it as the next version to try. The idea of "recommended" sounds good. It looks like you are automating the 2 week-ish release cycle. We still have to work out which releases to support long term and how long. In terms of testing... I look at a lot of graphs by hand. I think I could automate some of that, but that would still leave a lot of work. It may not be possible (or worth the effort) to totally automate the testing. This will probably change when Eric's TESTFRAME starts working. (I'm assuming we can run some real servers setup to collect data so we can gather a bunch of test cases when "interesting" things happen.) We also have to test refclocks. We can get real traffic by putting up pool servers. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
What is a release?
I think I have figured out part of the disconnect on some of the recent discussion. There are two types of releases. I'll call them "big" and "little". Does anybody have suggestions for better terms? A little release is no big deal. Every two weeks would be fine. It's just a useful handle on the state of our repository. When I hear the word "release", my immediate reaction is to think of a big release. That's something to be well tested, preferably by users rather than just insiders, and something that we will support for a while. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What is a release?
e...@thyrsus.com said: > I believe a generally accepted term for a lile release is "point > release". I've often heard "major release" used as its opposite. I like it. Thanks. Will anybody talking about releases please remember to add the appropriate qualifier. I expect that a major release would get some advance notice and we would stop adding features and focus on testing and bug fixes and documentation cleanup. But I suppose a particularly stable point release that users liked could get turned into a major release. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Bug: deadlock from msyslog
e...@thyrsus.com said: > I just ported in the Classic fix "[Bug 2814] msyslog deadlock when > signaled." I think that'll do it for this one. Is there any software that will check signal handlers to see if they call (or call anything that calls) any non-signal-safe routines? I don't know if it's possible to write real code following that rule. The case I'm thinking of is a trap handler that catches a fatal error and wants to print out a useful message and then exit somewhat cleanly. I think I'd be willing to handle the hard cases by hand, or with as much help as I can get. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Bug: deadlock from msyslog
g...@rellim.com said: > Check out "man 7 signal", almost nothing is legal to call from within a > signal. You can't even open() of fopen() anything. About the best you can > do is write(STDERR,) and exit(). Right. I was wondering if there was any software that would check that. For ntpd, writing to STDERR doesn't work since it's a daemon and has nuked STDOUT and STDERR. syslog(3) isn't on the approved list. The call restrictions mean that you can't longjmp out of a signal unless you know you were't doing anything dangerous when the signal went off. After the jump, you are still in the signal handler. On the other hand, it mostly works so all sorts of web pages show you how to do it without mentioning the restrictions. In the case of ntpq, it's likely to be doing a DNS lookup. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
./waf install hangs on FreeBSD 10.2-RELEASE-p14/amd64
Has anybody seen this? Or hints on how to debug it? --- installing host --- Waf: Entering directory `/home/murray/ntpsec/play/ted3/host' Waf: Leaving directory `/home/murray/ntpsec/play/ted3/host' --- installing main --- Waf: Entering directory `/home/murray/ntpsec/play/ted3/main' ^C doesn't work. kill -9 does. I normally run it from a script. It does the same thing when I run it by hand. It builds and checks on that system. Running as non-root hangs before it complains about permission problems. It builds, checks, and installs on other FreeBSD systems: 9.3-RELEASE-p33/i386 10.2-RELEASE-p9/i386 10.2-RELEASE/arm (BeagleBone Black) 11.0-CURRENT/arm (Raspberry Pi) It was working a while ago. I think that was before I did a freebsd-update to get from -p9 to -p14. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ./waf install hangs on FreeBSD 10.2-RELEASE-p14/amd64
> No idea try running python -v -v waf and see where it hangs?
Thanks.
> I'm thinking it's Python itself.
Me too, but I need a bit more into before I can submit a bug report.
# pylib/util.pyc matches pylib/util.py
import util # precompiled from pylib/util.pyc
# trying pylib/rtems_trace.so
# trying pylib/rtems_tracemodule.so
# trying pylib/rtems_trace.py
# pylib/rtems_trace.pyc matches pylib/rtems_trace.py
import rtems_trace # precompiled from pylib/rtems_trace.pyc
Waf: Leaving directory `/home/murray/ntpsec/play/ted3/host'
--- installing main ---
Waf: Entering directory `/home/murray/ntpsec/play/ted3/main'
^C^C^C^C
Nothing new if I delete all the *.pyc
What does @ do in python:
@feature("rtems_trace")
@after_method('apply_link')
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Snapshots are now available.
Nice. Thanks. v...@darkbeer.org said: > Snapshots will appear here: > https://ftp.ntpsec.org/pub/snapshots/ How long will they stay around? My vote would be something like snapshots for point releases stay around forever and snapshots for non-releases stay around for a month or two after the following point release. Is there a page on the main web site that explains where to get them and what to do to build, test, and install, and run? Much of that may be after untar, look in XXX. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cross-building.
> I will be setting up MIPS as well. Do you have any wrong-endian systems in your collection? That would be high on my list. > Eventually the binaries will be archived and shipped to real ARM and MIPS > devices to run the testsuite and make sure the binaries work. I've been running on Raspberry Pi and BeagleBone Black, but that's self compiled rather than cross. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cross-building.
v...@darkbeer.org said: >> Do you have any wrong-endian systems in your collection? >> That would be high on my list. > Got some examples? I'll see what I can do. I really want to keep all of > this low-heat and low-power I may be able to find some old boards. The best suggestion I have seen is an old PowerPC laptop. I don't know anything about the Apple environment. Is something that old new enough? Are there any wrong-endian ARM boards? (I think I saw something about one recently, but I forget where.) It might be we should just put support for wrong endian systems off to the side until somebody comes up with an interesting modern platform. Maybe just mark it as "might-work but untested," -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Version bump.
v...@darkbeer.org said: > devel shouldn't be at 0.9.2 still as it has already been released. This > will make the snapshots easier to understand as users are always testing the > next release not the current. 0.9.3 isn't right either. It will look like the real 0.9.3 I think we need some conspicuous way to distinguish the latest git pull from various releases. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
util/monitoring/ntploop{stat,watch}
ntploopstat starts: ;# Poll NTP server using NTP mode 7 loopinfo request. ;# Log info and timestamp to file for processing by ntploopwatch. Should we drop them, or fix ntploopstat to use mode 6? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Version bump.
v...@darkbeer.org said: >> 0.9.3 isn't right either. It will look like the real 0.9.3 > I can change it to add a revision to the version number. But there is no > other way to denote the next version all the current changes go into 0.9.3 > so it is the correct number to use. I don't see how the next version is any better than the previous one. It may seem that way to you, but it will be just as logical to somebody else who gets started the other way. > We can add a -git- to the end of the version. > 0.9.2 has support for tarballs, I will put one on the FTP tomorrow. The current code says: ./build/main/ntpd/ntpd --version ntpd 0.9.2-afceec0 Mar 24 2016 22:43:18 I think I'll be happy if the tarball drops the "-afceec0" part. I'll be happier if the text from the git version has some indication of whether it's post 0.9.2 or pre 0.9.3 but that's getting down into the noise. As long as the git tag is there, we can figure out what is going on. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: util/monitoring/ntploop{stat,watch}
e...@thyrsus.com said: > I don't know enough about the tool's use cases to have an informed opinion. > Who uses it, and what are they looking for? I don't know.Nobody has reported that it doesn't work so I doubt if it gets a lot of use. I don't use it. I didn't even know it existed until I stumbled into it while looking for something else. I feed loopstats to gnuplot. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Version bump.
> So, ntpd 0.9.2-afceec0+ I'd put the + right after the 2: ntpd 0.9.2+afceec0 or ntpd 0.9.2+ if you build without git. My normal mode of operation is to have a master copy on one system, rsync to other systems dropping the .git directory to save space and time, and then build there. (.git is 75% of the space) -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: util/monitoring/ntploop{stat,watch}
> How much effort is it to make it use mode 6? Probably not much. I'd guess a day or so, but that's mostly coming up to speed, and is obviously a rough/wild guess. It's written in perl. I don't know anything about perl nor do I have any desire to learn. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: util/monitoring/ntploop{stat,watch}
fallenpega...@gmail.com said: > Sanjeev, do you know Python? Would you like to take a crack at > re-implementing loopstats in Python? Plan B would be to drop it. The first step would be to figure out what it does. Probably the best approach would be to setup an old system to run it against and collect some data... I'm guessing that it roughly collects the same data that is in the loopstats log files, and then graphs it. If so, the collecting part is redundant (and probably doesn't get the timing as accurate) so we should focus on the graphing. That opens up a whole new can of worms which is worth a lot of thought and work: how can you tell how well your server is working? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Monday checkin, please.
fallenpega...@gmail.com said: > Chris, Hal, Eric, everyone else: what have you been hacking on, and what > ntpsec codebase puzzles are you thinking about? No code shipped recently. The ^C fix for ntpq is the top of my list, but that's lots of small changes scattered all over the place and hard to test and it isn't seriously broke so I'm waiting until I get in the right mood. e...@thyrsus.com said: > Follopwing our IRC conversation about I'm now switched about 75% to > forward-porting fixes from Classic. None of these are very serious bugs. Am > now caught up to early January on their timeline. Would you please take a look at any ntpq changes? I think there has been a lot of work on it since the fork trying to fix the ^C bug. If you are going to grab those changes, I'll procrastinate on fixing it. --- I have NetBSD running on a Raspberry Pi. Our code builds, but ntpd dies with an obscure error. Same with NTP Classic. Their version of NTP Classic works. They have a patch for the critical area, but I haven't tracked down what/why. -- I've been thinking about crypto/authentication. More in another message. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Crypto - what algorithms to use?
The current ntpd has a simple shared key setup to make sure the client is talking to the right server. The payload is not encrypted. This is authentication, not confidentiality. It uses MD5 or SHA1. Those are getting a bit old. We should probably update things. Is there a good list of what algorithms are currently thought to be secure? I think the code changes will be simple - libcrypto does all the work. I don't know my way around that area, but I think I've seen an API to get a list of the algorithms it supports. Should we drop support for insecure algorithms, or retain it for backwards compatibility? Odds and ends: ntpd gets the SHA1 code from libcrypto from the openssl-libs package (on Fedora) There is MD5 code in libntp/a_md5encrypt.c, so you can use MD5 without libcrypto. Looks like there is also MD5 and SHA1 code in libisc They both use libcrypto is it's available, otherwise they provides real code. I don't think the MD5 code is ever used. The SHA1 code is used to verify the leap-file. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
NTS - Network TIme Security
There is work in progress in the IETF on authenticated NTP. As far as I can tell, getting off the ground is a really hard problem. All the classical crypto work uses time to decide if the info you have is still valid and prevent replay attacks and things like that. I think we should have a way for something dumb, like a toaster, to be able to get the right time. Another nasty case is a board that has been on the spares shelf for 10 years. There is a specific proposal called NTS. The next to last draft is 40 pages. (I'm one behind.) It takes 6 packets to set things up. The last step uses a certificate chain so you need to know the time. ... There is another proposal on how o use the above on NTP. (It's intended to cover PTP too.) The basic problem there is that the NTP packet format wasn't designed with extensions in mind. It seems simple to me. Just grandfather the old magic lengths and make all the new stuff use TLV (type, length, value) type formats. But it hasn't settled down yet. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec versions
The date string in the version printout is the date/time it was built, not the date of the last change in git. That gives you a useful string if you have a sequence of local edits that aren't committed yet. The git hash is there if you want the git info. You can find version.c in build/main/ntpd/ and friends. It would be nice if waf was smart enough to recompile version at all the right times. It might miss some case. I mostly use a script that rm-s the build directory so I haven't had problems. I have another script that lets waf do its thing to save time. It rm-s the version stuff. I think that used to relink things that didn't change, but I just tried it and it skipped the relinking. Maybe I was confused. Maybe Amar fixed something. Speaking of version strings, the current string doesn't include the time zone. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec versions
v...@darkbeer.org said: > Can you elaborate on this please? Are you talking about rebuilding each > version.c for the respective tool it is meant for if a file for that tool > changes? Yes, If you are relinking ntpd, waf should recompile ntpd/version.c as part of this batch. It doesn't need to rebuild version.c unless git HEAD has changed. (The git hash is in version.c) The problem is that version.c is using __DATE__ and __TIME__ which are the compile times and we want the link times. Plan B would be to get the build/link time at runtime somehow. I think we discussed it but didn't come up with a way to do it. (That was a long time ago.) > If so this can be done. That would be great, but far from high priority in my opinion. It might be a good example for how to do things with waf. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Version bump.
dtpoi...@gmail.com said: > Folks also use odd numbers for development branches and adding a dot release > for new features. I think we should seriously consider the odd-even aproach. That solves most of the ambiguity problem. It uses the bottom bit of a numeric slot to indicate firm vs fuzzy status rather than our schemes for adding a "+" or "-" to the version string. waf calls our version string MAJOR.MINOR.REV I think we would use odd/even in two places, one for MINOR and again for REV. git tags would only have even numbers in both slots. We would bump the REV slot on an old release if we go back and patch it. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Is there a roster of contributors?
dtpoi...@gmail.com said: > I am starting up a NTPsec instance of the suite of Synopsys development > testing tools - Coverity, Defensics and Protecode. Thanks. ... > Is there any interest in this level of integration and reporting? I think we should fix any problems. I don't think we should clutter up issues tracker with simple Coverty bugs. If they don't get fixed promptly, they will get rediscovered next time. The Coverty printout that I've looked at have been quite verbose. If there is a way to automatically run it after (or better, just before) a release, I think a summary of the problems to this list would be helpful. I might change my mind if I get bored with too many "All OK" reports. I'm not familiar with the other tools. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Crypto - what algorithms to use?
fallenpega...@gmail.com said: > We should live with MD5/SHA1 in shared key protocol, for now, for reasons of > compatibility, but document that we know it's not the current best practice. I think we can add support for new algorithms and leave the old stuff. Maybe add a nasty message at startup time. > Who maintains the leap-file? A few years ago, there were versions from NIST and USNO. There is now a version from IERS (the source of the raw data) and a mirror at IETF. I think the payloads are all the same. The differences are in the comments. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec versions
fallenpega...@gmail.com said: >> Speaking of version strings, the current string doesn't include >> the time zone. > We should configure it to be TZ=0 GMT The version string comes from the compiler's __DATE__ and __TIME__ I assume that's the local time. We Amar can tell the compiler which time zone to use. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Reference clocks.
v...@darkbeer.org said: > My initial tests will be via PPS signals wired to the GPIO pins on RPIs. > This will only let me test one type of refclock driver. I should be able > to find something to test audio, too. Actually, that lets you test 4 different drivers. There is the ATOM driver for the raw PPS signal. You need some other driver to number the seconds. The NMEA driver can use PPS directly. You can feed the PPS (and NMEA or whatever) to GPSD. That lets you test SHM and JSON. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Reference clocks.
v...@darkbeer.org said: > OK that's good news at least. I haven't looked into many of the refclock > drivers. Thanks for the info. Keep in mind that many of the drivers have sub-drivers or modes. The obvious example is the parse driver which is an umbrella for several drivers. The Palisade driver has several modes to support different hardware/firmware. The NMEA driver can use the PPS or not. If it is using PPS, it's hard to tell how well the serial port is working. Mumble. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Reference clocks.
v...@darkbeer.org said: > I wonder how will this will work using the PPS via GPIO system I'm working > on. Should be fine and it should be far, far more reliable than serial. Why do you think it will be more reliable? It's the same idea. Changing a signal on a pin generates an interrupt which wanders through a few layers of bit testing and dispatching and eventually gets to the PPS code that grabs the time. > Another method to get a lot of code coverage is to write shims between each > driver and a general time interface so we can mock the API for each device. > Not sure how feasible that is as some of them are radically different. May > not be worth it at all in the end. Once Eric gets TESTFRAME going, then we can start collecting samples. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Reference clocks.
v...@darkbeer.org said: [Serial vs GPIO] > Because modern serial ports can suck, so do serial cables. I wouldn't trust > anything other than a high-end serial card to handle the data it's not > something that's given much thought in modern motherboards. I haven't had any troubles with serial ports. (other than not finding them on modern systems) There is a potential problem with feeding a "TTL" signal into a RS-232 receiver. 3V CMOS signals may not be high enough voltage to cross the threshold. I think the threshold is usually 1.4V, but I doubt if it's in the specs. It's clearly cheating and something to keep an eye on, but I haven't had any problems. There is a problem with the typical 10 to 20 microsecond PPS pulses from GPSDOs. They aren't wide enough and/or the driver is buggy. The GPIO code may be simpler and cleaner and less likely to miss short pulses. You can get a pulse stretcher from TAPR. v...@darkbeer.org said: > This is for live testing since I can control the GPS signals I can expect > the same data to be received by the clock and then ntpd. I will need a way > to dump that info but it's easy. Even if you broadcast the same GPS data, there is noise in the system and edge cases may not get the same results. Even if the GPS unit spits out the exact same text strings the timing may be slightly different in interesting ways. Going in at the GPS level lets you test the Kernel. That's got to be worth something. If you also run in record mode, we can save interesting patterns for regression testing at places other than your site. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Testing - leap seconds
While you are setting up a testing environment, you might keep in mind how to test leap seconds. We will test kernels too while we are at it. There is a tangle of code that doesn't get used very often, including the GPS leap-pending area. I think the key part of automating things will be having a pool of systems that can be borrowed from to run this sort of test and an automated way to configure them. We would need several stratum 1 servers, and several stratum 2 and/or 3 clients. If your GPS simulator is smart enough, we can use it. If not, we can patch a driver. We need to test the leap file case too. I think the client code is supposed to use a majority vote from upstream servers. There may be some fine print on which servers it uses. We should run this sort of test before a major release (even if we have to set it up by hand). -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Finding abusive NTP clients
I just pushed a tweak to ntpq's mrulist command to provide more info if the average interval between requests is tiny. Anybody running a pool server might like to try it out. It now looks like this: ntpq> hostnames no ntpq> mru mincount=1000 sort=avgint Ctrl-C will stop MRU retrieval and display partial results. Retrieved 239 unique MRU entries and 0 updates. lstint avgint rstr r m v count rport remote address == 35374 0.03 190 . 3 4 5046 44762 64.72.56.95 670 0.04 190 . 3 4 4148 38778 162.243.188.66 57962 0.06 190 . 3 4 1345 33523 96.41.112.161 90455 0.07 190 . 3 3 1877 49488 2601:644:500:e800:a9d6:8245:1f95:b31b 66199 0.07 190 . 3 3 2081 54645 159.191.174.119 47234 0.07 190 . 3 3 1084 40403 108.227.128.23 62845 0.08 190 . 3 3 1956 47876 71.95.206.54 19026 0.08 190 . 3 1 3931 63329 190.14.219.238 460 0.08 190 . 3 4 1877 56897 72.130.39.211 40670 0.08 190 . 3 3 1629 42184 98.203.248.229 90375 0.09 190 . 3 4 1185 38002 24.56.50.247 60720 0.09 190 . 3 3 1599 65462 216.100.91.14 16506 0.09 190 . 3 3 1026 57813 75.172.167.145 7633 0.09 190 . 3 3 1557 37974 67.1.146.70 58813 0.10 190 . 3 1 3134 2410 73.179.193.171 5947 0.10 190 . 3 3 1171 52276 104.32.81.108 90798 0.11 190 . 3 4 1388 34042 198.199.99.66 ... -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Finding abusive NTP clients
gha...@gmail.com said: > lstint avgint rstr r m v count rport remote address > == > 0 0.01 1f0 L 3 4 32250 123 27.126.220.102 > 0 0.02 1f0 L 3 4 35659 123 27.126.220.105 > 0 0.02 1f0 L 3 4 35789 123 27.126.220.106 > 0 0.02 1f0 L 3 4 35766 123 27.126.220.103 > 0 0.02 1f0 L 3 4 35780 123 27.126.220.101 > 0 0.02 1f0 L 3 4 32843 123 27.126.220.104 > 1 0.51 1f0 L 3 3 2877243 18012 202.136.171.166 > 0 1.14 1f0 L 3 4 1282569 54878 52.74.115.126 Wow! The bottom two take the record. If I read that right, they have been hammering away for over 2 weeks. 52.74.115.126 is Amazon. A polite note to their abuse dept might get some action. Whois says 202.136.171.166 is NTT SINGAPORE. I don't know how they will react. You will probably have to explain things to them. See if you can find out what sort of broken software they are using. Looks like your server has been up for a long time and also that you are using the default mrulist setup. ntpq monstats will give you a summary If you give it more memory, it won't recycle the slots so quickly and you will be able to see the abusive users who stop after a while. Here is what I'm using: rlimit memlock 200 mru initmem 25000 maxmem 15 maxage 20 The maxage gets rid of stuff that is 2+ days old. I run a script each night that saves the mru output. Someday, I should be able dig out the IPv4 vs IPv6 traffic levels. (If anybody does that before I do, please let me know.) -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Raspberry Pi HOWTO progress
dtpoi...@gmail.com said: > I WANT THIS! > Warming up the credit card... My list: $39.95 Pi-3 https://www.adafruit.com/products/3055 $7.95 5V 2.4A Power supply https://www.adafruit.com/products/1995 $7.95 Pi-3 Case https://www.adafruit.com/products/2258 $19.95 MicroSD 16GB https://www.adafruit.com/products/2693 $44.95 GPS Hat https://www.adafruit.com/products/2324 You probably want the battery too. I'm running without one so I can test cold start by power cycling things. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Pi HOWTO
I think there are two interesting variables: the HAT and the case. There is a 3rd minor variable of Pi-3 vs Pi-2 vs B+ I think you should write up something that works and put the rest of the options in an appendix. (or something like that) You can add a few references to the appendix at the critical places in the main text. I think all the GPS HATs I've seen put the PPS on a different pin. It may be worth putting a small table at the right place in the text. - The case in the list I sent out recently works with the Adafruit HAT if you use the internal antenna. I think you can get the cable out the slot for the ribbon cable if you want to use an external antenna. The picture for Gary's no-soldering HAT shows an antenna connector that won't fit in that case. There is at least one "case" that is two clear plates connected by 4 corner posts. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Pi HOWTO
> Hm. Remind me what that case us? I should out it in the draft. https://www.adafruit.com/products/2258 You should get one to play with. You have to put the Pi in first, then install the HAT. When installing the Pi, I find it easiest to use a small screwdriver from underneath to bend the hooks out of the way. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: on the NTP security issues and fixes
Summary here: http://support.ntp.org/bin/view/Main/SecurityNotice#April_2016_NTP_4_2_8p7_S ecurity -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Reference clocks.
[I'm scanning old mail looking for something else.] v...@darkbeer.org said: > Does anyone here have any reference clocks they're not using? I'm looking > for different clocks to test as many of the refclock drivers as possible. What's your current collection? > I should be able to find something to test audio, too. util/tg2.c will generate audio in various formats. You can sanity check with headphones. If the transmit side works, then you can plug it into a PC and try to get the receive side working. I tried one of the audio drivers a while ago but didn't get it to work. I didn't try very hard. I forget the details. It did work many years ago. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: eport from the 20160501 F2
> A from-scratch proven and verified C implementation of "simple NTP broadcast > client" will be written. Lead on that project will be Daniel. Could you say a bit more? How "simple"? What does "verified" mean? What are you expecting in the way of timekeeping accuracy and/or glitch avoidance? Is there a target audience? Are you expecting it to work (well) on WiFi as well as Ethernet? > The diag dump "nameless horror" shall be removed from NTPsec. What is that? I don't recognize the term. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Reference clocks.
v...@darkbeer.org said: >> What's your current collection? > I don't have any right now other than the various GPS chips and boards on > the way to run off of GPIO connections. You should probably get a couple of the USB "mice" or hockey puck style units. They run $25-$50 each. Most speak NMEA and don't have PPS. SiRF used to have most of the market but I think uBlox is getting in there now. Eric reports that gpsd had nasty troubles with the SiRF-S4 aka Star Vi. It's newer than the -S3 (aka Star III) so I expect the S3 may be impossible to get any more. If you can find one, I'd grab it unless the price is insane. Odroid has a uBlox USB unit for $25. It would be good to be able to test PPS over USB. The no-soldering approach is to get one of the 601W. (I think that's the right number.) Gary may still have some or Mark may order a batch. The soldering approach is to get a Sparkfun breakout board and a USB-serial breakout and add several wires. For a real serial port, the Garmin GPS-18X LVC has PPS but needs soldering and power. You can steal power from USB. There are 2 flavors of GPSDOs that are popular with hackers and hams because they have been widely available on the surplus/recycled market at reasonable prices. They are older units so they need a good antenna location. One is the Trimble Thunderbolt. I think it was used in 911 call centers. The other is the HP Z3801A. I think it was used in cell phone towers. There are various other Z38xx units that speak roughly the same protocol and there is a 5 part number for the still in production version. They tend to show up on eBay in batches. There is no current good deal. There is a TBolt with power supply and antenna for $450. There is a package that claims to be a Z3801A for $450. I don't know what it really is. The picture is not the old/real Z3801A. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Reference clocks.
e...@thyrsus.com said: > The audio drivers are near the top of the list of things I'd like to remove. > I strongly suspect they're both obsolete and broken, and they're surrounded > ny a lot of poorly-documented cruft like tg.c that could stand to go. My vote would be to carry them along until we do the great refclock cleanup. They are off to the side, so they aren't cluttering up any of the main line code. I think IRIG is still widely used outside of NTP. I think Susan was in touch with some of those people. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: RaspbPi HOWTO
e...@thyrsus.com said: > Accordingly, I'll be extending the breadth of the HOWTO to cover more > hardware - not just two additional HATs but the Odroid C2 as well and > probably the BeagleBone Black later. Could you please say a bit more about that area? There are a lot of small Pi-like ARM boards. How did you pick the Odroid C2? How many other boards did you consider? How many of them will be around for a while? How many of them have serious software support? How much will supporting other boards add to the clutter of a HOWTO? I took a quick scan at the Odroid C2 web pages. It has a 40 pin header, but I didn't find any claims about Pi compatibility. Does anybody know if it takes any of the Pi GPS HATs? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: RaspbPi HOWTO
cbwie...@gmail.com said: > The GPS Hat should just work. The GPS Hat will also provide an RTC for both > the ODroid and the RPi. Is there really a RTC on a GPS HAT? Which one? The battery is to keep the RTC equivalent inside the GPS chip going. It's the difference between cold start and warm start. That clock is not normally available to the outside world. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Reference clocks.
g...@rellim.com said: > Please, no GPS-18s. The Garmin Binary protocol is a mess and the chip is > over 10 years old with a weak sensitivity, no GLONASS, etc. Many better GPS > LVC solutions. The GPS-18x is only 5 years old. 1/2 :) It speaks NMEA so you don't have to mess with the binary stuff. The USB versions don't speak NMEA. I assume they ran out of ROM or such. But they don't have a PPS so they aren't very interesting so I don't care if I can talk to them. Do you have suggestions for better "LVC" gear? - One unit I forgot to mention on my previous message is the Sure demo board. It has both USB and serial connections. Power from USB. No PPS, but you can wire it up. Some of the pins are tiny so that wiring requires some skill. http://www.ebay.com/itm/SKG16A-Bluetooth-RS232-USB-UART-GPS-Module-Demo-Board- /230844194302 Lots of info here: http://www.satsignal.eu/ntp/Sure-GPS.htm The same data on USB and serial port allows easy comparison. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: regarding excising PLL
fallenpega...@gmail.com said: > At the F2F this weekend, ESR brought up that you think we may be able to > excise the PLL code from NTPsec. > Can you expand on that, please? It's more complicated that a simple excise. My knowledge may be buggy. It's not clear that any of this makes Eric's job easier. There are two RFCs describing PPS stuff. RFC 1589, 37 pages A Kernel Model for Precision Timekeeping https://tools.ietf.org/html/rfc1589 RFC 2783, 31 pages Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0 https://tools.ietf.org/html/rfc2783 The second is the API to read the info the kernel captures when a PPS type pulse happens and all the stuff to turn it on/off and such. The first describes a PLL that lives in the kernel. I thought the RFC included large code fragments, but I didn't see them. The idea is that ntpd hands off timekeeping duties to the kernel and the kernel does all the work. ntpd just monitors things and tells the kernel to stop if things get out of whack. Why is there that much code in the kernel? I think that's leftover from when machines were slow and busy and schedulers were dumb. I think it should be possible to wake up user code on the PPS, read the time stamp, do the calculations in user land, and tell the kernel what to do all within a reasonable amount of time. That's basically moving the inner loop of the kernel PLL out to user land. One complication in this area is that most kernels don't implement the wake-on-PPS option. ntpd polls. The part of this area that I don't understand is the PLL parameters. ntpd already adjusts the polling rate and along with that various parameters. Will the pseudo-kernel mode work at the extreme end of the normal parameters or is the kernel PLL totally different? -- Linux has rewritten that area. Several years ago, there was a time when there was no kernel PLL. ntpd kept on working. We should be able to comment out a few lines of code and just try it to see how well/poorly it works. It would be interesting to compare various OSes running on the same hardware. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: RaspbPi HOWTO
>> There are a lot of small Pi-like ARM boards. How did you pick the Odroid C2? > I heard reports that it's HAT-compatible. That makes it low-hanging fruit. Sounds like a good reason. I think I saw some comments about the Pi being flaky with a list of better boards. If I find it again I'll add it to this discussion. I don't remember any that looked great. The problem with the Pi was USB related. I don't see troubles when using the Ethernet, but WiFi hangs occasionally (days). All the USB WiFi gizmos from Adafruit use the same chip. My guess is that the WiFi chip does something strange and the hardware/firmware doesn't handle that case. I've got a couple of units that use a different chip on order. That might tell me something. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Pi HOWTO
e...@thyrsus.com said: > Given the geometry it looks like it will handle a single HAT with the lid > on, though. The Adafruit GPS HAT fits fine with the lid on. I think you can get the antenna cable out through the slot they left for a ribbon cable to hit the 40 pin GPIO connector. But I've been happy with the built-in patch antenna. I may have mentioned this before. Getting the Pi into that case is a bit tricky. You have to tilt it to poke the HDMI connector and friends into the holes and then rotate the other side down. That doesn't work with the HAT on. You might want to put a string through the mounting holes on the HAT nearest the 40 pin connector so you can remove the HAT. At least one of the GPS HATs looks like it has an antenna connector that will need a hole cut in most case designs. I've seen one "case" that was 2 sheets of plastic and 4 posts in the corners. That left all sorts of room for cables to go in/out the sides. I don't remember where I saw it. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: RaspbPi HOWTO
> Conveniently, the build doesn't require either USB or WiFi. On a Pi, the Ethernet is on USB. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Pi HOWTO
> There is a case like that from GeauxRobot available through Amazon. ... Thanks. That's the one I was thinking about. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Reference clocks.
> and still USB 1.1: That's unlikely to change. It's a hack that lets them use thinner cable. The signaling is slower so they don't need as much shielding to pass EMI. Compare the size of the cable on a typical USB GPS mouse with a typical real USB cable. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: RaspbPi HOWTO
bellyac...@gmail.com said: > Reply to self. Nevermind, simply apt-get install rpi-update on the Jessie > Lite image. Does anybody understand rpi-update? Why is an extra program required rather than being packaged so that the typical apt-get update+upgrade updates those files? What is the relation to the kernel that rpi-update installs to the kernel that apt-get upgrade installs? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Reference clocks.
g...@rellim.com said: >> Do you have suggestions for better "LVC" gear? > GR-801T: > http://www.navisys.com.tw/products/GPS&GNSS_%20receivers/flyer/GR-801_flyer= > -150703.pdf > Or the GR-801R has real RS-232 levels. ... Have you been able to order small quantities? I tried their order page. The Buy-Now button looks like it's getting setup to sell me one, but it doesn't tell me which flavor or offer me a way to specify the flavor that I want. (The shipping will be more than the cost of the unit.) I understand that the -W models are only available with a min order of 100. I was hoping that the -T or -L would be available in small quantities. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: TESTFRAME
e...@thyrsus.com said: > It would certainly simplify some ugly code if we knew that kernel receive > timestamps are both standardized and actually implemented all across our > target range. There are socket options SO_TIMESTAMP, SO_TIMESTAMPNS, SO_TIMESTAMPING and SCM_ variants. They add a time stamp to the recv path. I haven't tracked down the details. Google found a kernel doc page with some info. Google found one comment about it not being POSIX. It is available on Linux, FreeBSD, and NetBSD. (Or at least it's in /usr/include/. I haven't actually verified that it works. Things may be different on older (or newer) versions than the boxes I checked. YMMV...) There is also SO_BINTIME. It's defined on FreeBSD but not Linux or NetBSD. http://lists.ntp.org/pipermail/hackers/2007-October/003321.html Looks like a candidate for cleanup. There is a comment in pylib/configure.py where it doesn't set ENABLE_SIGNALED_IO so I think any of my comments about using a signal to get the time stamp are bogus and/or way out of date. ntp_io has a paragraph describing grabbing info from a SIGIO handler. It's in a if defined(SYS_WINNT) There is also a USE_PACKET_TIMESTAMP. It's set in ntp_io.c if one of 3 ways to get time stamps is defined. -- > Sounds simple, yes? Actually, no. One headachy detail is that the simulated > select has to interrupt correctly in the presence of simulated timer > signals. And the timers themselves have to be emulated. I was wrong on thinking the big select used a timeout. There is a timer and a signal handler that sets a flag... The main loop checks that flag. I think you can intercept that by recording an event when the main loop notices the flag and then on replay, when the select finds that line, the replay logic can set the flag and return EINTR or whatever. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: New 0.5 draft of the SemPiTernal HOWTO
e...@thyrsus.com said: > Now I get to figure out how to install NTPsec to autostart on boot. > Curiously, though Raspbian uses systemd, the control files in the stock ntp > package are clearly System V init scripts. Er, systemd does the right thing > with those? I think so. Try "service ntp restart" or "systemctl status ntp" and such. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: eport from the 20160501 F2
dfoxfra...@gmail.com said: > >> The diag dump "nameless horror" shall be removed from NTPsec. >> What is that? I don't recognize the term. > Support for the ntpq saveconfig command. The term is a joke from the meeting > because it took five minutes before any of us could remember what it was > called. I'm happy to remove that. I assume the goal is to reduce security exposure rather than simplify the code. There is also the :config ntpq command which has similar file-write exposure. There is a saveconfiquit command line option. It's used as a check for the parser. It rearranges things and drops comments. See ntpd/check-config.sh -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: eport from the 20160501 F2
[Context is "simple NTP broadcast client"] > The primary target audience is IoT devices. Expect nothing impressive in > terms of timekeeping precision. I like the idea of a small/simple implementation. There are 2 parts to a ntp client. One is getting the time right. The other is calibrating the local crystal so that the time stays close(er). Are you planning to implement the drift? Does the OS even support the idea? (It's not hard, but may take some double precision arithmetic.) One of the advantages of all the complexity of ntpd is that you can monitor and debug things. The builtin server allows monitoring even without logging anything on the target machine. How are people going to monitor/debug IoT devices? - Drift correction gets complicated in seriously low power environments. The trick is that there are usually two clocks used for timekeeping. The normal CPU clock is used while the CPU is powered up, but the RTC/TOY clock is used when the CPU is powered off. We probably need 2 drifts, one for each clock. Our current code doesn't do this. This may show up on phones before we see it on IoT class devices. Mumble. I don't have a good answer. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
GPSD/JSON driver
g...@rellim.com said: > 46GPSD NG client protocol > I suggest avoiding #46. Why? I thought the party line was that json was the preferred way to talk to gpsd. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: [gpsd-dev] New 0.5 draft of the SemPiTernal HOWTO
fr...@nicholasfamilycentral.com said: > dhcpcd will merge DHCP supplied NTP servers at the > bottom of a ntp.conf. This has not caused me any issues (on Gentoo). NTP > generally does the right things and uses all the NTP > servers in the config & will decide the local server, with PPS is the > best. It uses the other servers to sanity check the local refclock. Bugs and quirks are far from uncommon. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: New 0.5 draft of the SemPiTernal HOWTO
e...@thyrsus.com said: > I'm not sure I understand this comment. Are you saying that a dhcpd hpook > modifies /etc/ntp.conf? Yes. If your dhcp server provides NTP servers, somebody copies /etc/ntp.conf over and appends server lines for the ones from dhcp. The startup script then passes in the new conf file if it exists. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
