Hal Murray via devel :
>
> Should this work?
> restrict default limited nomodify nopeer noquery
> restrict 192.168.0.0 mask 255.255.0.0
> restrict 127.0.0.1
>
> ntpwait times out. It works when they are commented out.
>
> I haven't investigated. I'm trying to catch up after a two week br
Hal Murray write:
> When the pool mode adds a server, if needed, it pokes a hole in the
> restrictions.
>
> We need to remove that hole when that server is removed.
Fair enough. I have an idea for a simple way to implement this. But
I can't find where the hole-poking is actually being done - it'
I've spent the last week triaging and resolving items from the NTPsec
issue tracker. We're making excellent progress; the count of
unresolved issues has gone from 41 to 15.
I shall round up the remaining issues and discuss where I think our
priorities need to be.
Summary:
* I need to work on #3
Hal Murray :
> One of the things we need to verify is that our code starts as fast as ntp
> clsssic. I think they get going in 11 seconds. It's on their web someplace.
>
> I don't know how to easily automate that. A hack to scan log files might
> help.
Watching ntpmon, timing it to see when
Hal Murray :
> >> ntpq fails too often on flaky links. I seem to be the only one
> >> who notices it.
> >> I assume it's something in the retransmission logic.
>
> > Are all these sentences describing one problem, or is there a
> > bug *other* than failed retransmission on flaky links?
>
> I'm
Ian Bruene :
> Well now I'm increasing this to Official /Strong/ Suggestion: the packet.py
> testing project just got moved to the top of the list because of bug #341.
> And IIRC the code in packet.py is entangled with the comm channels in ways
> that may require a significant test jig, or refactor
Ian Bruene :
> On 08/08/2017 09:01 AM, Eric S. Raymond wrote:
> >Strictly speaking you can't do that. It's the PM's decision whether
> >we want to drop the feature or change the schedule. We're pretty informal
> >here, but you need to know where those lines of authority are, because
> >many other
Ian Bruene via devel :
>
> Oh, and I can confirm that the code in agentx.py (also ntpsnmpd but I
> haven't merged that) is completely separate from everything else.
>
> agentx.py can be ripped out for 1.0 without problems, it could be shipped in
> a perfectly broken state without problems outside
Ian Bruene via devel :
> I was already on the verge of calling it, given the above I am now
> Officially Calling SNMP support as slipping past 1.0.
Strictly speaking you can't do that. It's the PM's decision whether
we want to drop the feature or change the schedule. We're pretty informal
here,
Hal Murray :
>
> There is one bug that I think should get fixed. I don't know the number.
>
> ntpq fails too often on flaky links. I seem to be the only one who notices
> it.
>
> I assume it's something in the retransmission logic.
Are all these sentences describing one problem, or is there
Gary E. Miller :
> > Gary, Hal, Matt, Daniel: Would all of you check in on this, please?
>
> Done.
Good. Please confirm that you're not identifying any potential blockers
other than #341.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Please consider contributing to my Patreon p
Gary E. Miller via devel :
> Yo Ian!
>
> On Mon, 7 Aug 2017 15:04:34 -0500
> Ian Bruene via devel wrote:
>
> > Only thing I know of is bug #341, which I have repeatedly forgot or
> > deliberately ignored because other things were higher priority. *If*
> > the bug still even exists, as I have hea
Daniel Franke :
> If we're aiming for a September 28 release then I propose we should
> have a dev freeze by September 1. Bug fixes only during that month;
> anything that's mere polishing goes on a branch.
>
> I don't want to release 1.0 without having
> https://tools.ietf.org/html/draft-ietf-ntp
John D. Bell :
>
> I thought that one necessity before 1.0 were at least preliminary
> "packaged" version for the major distros - i.e., .deb and .rpm files,
> conformant to the conventions (file locations, etc.) of the systems that
> used them.
>
> Am I wrong? If not, do you know what the status
Summary:
* We need to start working towards a 1.0 release no later than 28 September.
* I need our senior devs to identify any release-blocker issues
and tell me what they think our pre-release priorities should be.
Details:
On Saturday, I had a phone conversation with Mark Atwood during whic
Paul Theodoropoulos via devel :
> Howdy,
>
> I just finished migrating my Raspberry Pi from classical NTP to NTPsec. I
> used the howto here:
>
> https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/
>
> There are a number of errors - small - procedural, ordering, spelling, etc.
> -
Ian Bruene via devel :
> Nice timing; in testing the getopt version I think there is an assumption
> that needs to be examined.
>
> Does there need to be a default logfile name in the first place?
>
> The only time it is needed is when the user specifies logging to a file.
> Implementing a defaul
Ian Bruene :
>
>
> On 06/14/2017 02:30 PM, Eric S. Raymond wrote:
> >Yeah, I thought I recalled that this was an issue.
>
> But wait! There's more!
>
> >argparse works just fine on Python 2.6: pip install argparse
>
>
> So which is it? Is requiring argparse installation acceptable?
>
> The c
Ian Bruene via devel :
>
>
> On 06/14/2017 01:39 AM, Matt Selsky via devel wrote:
> >Only new NTPsec programs use argparse. Everything that's replacing NTP
> >Classic C code uses getopt, so that we can support python2.6 (RHEL 6 default
> >python)
>
> Well that settles that. I'll get the getopt
Hal Murray :
>
> I remove the SO_BINTIME mode. It's only supported by FreeBSD and they don't
> support it for IPv6. They do support SO_TIMESTAMP.
>
> The downside of that is reduced resolution on the time stamps. BINTIME gives
> 32 bit fractions of a second while TIMESTAMP gives microseconds
Gary E. Miller via devel :
> > You might want to think about this, though: the problem with argparse
> > is that it has hidden state and magic action at a distance. You
> > shouldn't stop at the correct observation that the compactness of an
> > argparse spec makes it look simpler; you should ask
Ian Bruene via devel :
> First: I am not considering performance here *whatsoever*, even if there
> were a meaningful difference, which I doubt, option parsing happens once
> during program startup, and ntpq doesn't need high speed anyway.
And you should not be. See Knuth's dictum: Premature (per
Hal Murray via devel :
> The recvmsg man page
> SunOS 5.11 Last Revised 27 Feb 2006
> It has some info about SO_TIMESTAMP, but I don't see any hints about the CMSG
> macros.
They're a semi-separate issue. They're used to extract all kinds of
out-of-band infirmation from the data block return
Ian Bruene via devel :
>
>
> On 06/08/2017 05:29 PM, Gary E. Miller via devel wrote:
> >NTPsec does not use Python's getopt(). It uses argparse().
>
> So the real alternatives here are:
>
> 1. Have the dual -l/-L flags
>
> 2. Convert ntpq from getopt to argparse
Ian, I'm going to mutter that
Gary E. Miller via devel :
> Well, more to be learned, my getopt(3p) is not the same as what I see on
> unix.com. The online copy did not include the snippet I quoted. You
> can confirm on the POSIX site for getopt(3P):
>
> http://www.unix.com/man-page/posix/3p/getopt/
>
> But they both had thi
Hal Murray :
>
> >> If Solaris doesn't support time stamps, I would expect
> >> ntp_packetstamp to die on a #error. What happened with it?
>
> > I factored the code so that if waf configure doesn't find a way to get
> > packet arrival times from the UDP layer it uses the arrival time collected
>
Hal Murray via devel :
> Can anybody confirm that Solaris really doesn't have time stamps? I thought
> we decided that all modern OSes did. That's why we could rip out the SIGIO
> stuff.
>
> I took a quick google and couldn't find any mention of anything that looked
> like a time stamp in a S
Gary E. Miller via devel :
> Yo Eric!
>
> On Wed, 7 Jun 2017 22:46:42 -0400
> "Eric S. Raymond" wrote:
>
> > Gary E. Miller via devel :
> > > Just make the filename optional. So -l or -l filename
> >
> > Sadly, not practical with any varint of C or Python getopt. We'd have
> > to roll our own
Gary E. Miller via devel :
> Just make the filename optional. So -l or -l filename
Sadly, not practical with any varint of C or Python getopt. We'd have to
roll our own, and that way madnes lies.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Please consider contributing to my Pa
Sanjeev Gupta via devel :
> I am not sure that there will be any Sysadmins who will install NTPSec on
> HPUX, the few installations I know are strictly in "do not touch, very
> important business application running, last guy who understood this left
> three years ago".
I share your skepticism.
--
Mark Atwood via devel :
> Hilariously, I don't know where we can get a HPUX lab machine.
>
> I want to support it, but I also want us to stick to "POSIX only, unless
> it's really important".
>
> How much HPUX only code is there? What does it do?
I didn't think there was any left (I thought I'd
Hal Murray via devel :
>
> > I have run tests removing the fuzz code. Never found any change with or
> > without the clock fuzz. I was too scared to remove it.
>
> It's scattered all over the place so I'm impressed if you really removed it
> all.
>
> The code that I was looking at in ntp_pack
Gary E. Miller via devel :
> Yo Hal!
>
> On Tue, 06 Jun 2017 16:49:57 -0700
> Hal Murray via devel wrote:
>
> > ntpd has a lot of ugly code to fuzz the clock. I don't really
> > understand that area. I think it makes sense if the clock has big
> > ticks. Do we want to support those systems?
Ian Bruene via devel :
>
> After consolidating the relevant macros into ntp_debug.h and cleaning up all
> of the simple if(debug)s I have done another grep through the codebase. It
> appears that there aren't anymore cases where it is worth creating a macro
> for debugging. What's left is either b
Hal Murray via devel :
> I don't plan to commit any small changes like that. That module needs
> serious work, not minor tweaks. Besides, I should be working on the DNS
> stuff.
Agreed. I'll get on cleaning up the sandbox stuff. I don't understand
the async-DNS stuff as well as you do, so th
Ian Bruene :
>
>
> On 05/30/2017 06:36 PM, Eric S. Raymond via devel wrote:
> >Sometime there are couple of tiers of easy cases, so you'll loop back
> >to step 2. The point, be lazy. Don't spend more attention on the easy
> >cases than you have to, so you ca
Gary E. Miller via devel :
> Yo Ian!
>
> On Tue, 30 May 2017 16:34:07 -0500
> Ian Bruene via devel wrote:
>
> > Every instance I've seen has the logging code enclosed in an #ifdef
> > block for the debug compilation switch, whether directly where it is
> > used, of inside of a macro. It would
Hal Murray :
>
> Eric said:
> > I don't think this needs to be pre-1.0, and there's a KISS case for simply
> > documenting it as a known bug. Opinions?
>
> I agree that it doesn't need to be fixed anytime soon and/or for 1.0.
>
> The reason I sent that message is that it's a good example of wh
We have a bug relating to unpeer:
#315: unpeer doesn't remove server from reslist
Also, Hal wrote me as follows:
>This is just the tip of an iceberg:
> ntpsec | unpeer doesn't remove server from reslist (#315)
> Issue 315: https://gitlab.com/NTPsec/ntpsec/issues/315
>
>Background:
> If you ge
Matthew Selsky via devel :
> On Sat, May 13, 2017 at 10:10:23PM -0700, Hal Murray via devel wrote:
> >
> > If you are missing a library or header, --enable-seccomp gives a warning
> > but
> > doesn't bail. Should that be changed?
> >
> > There are 3 seccomp symbols setup in config.h
> > #def
Hal Murray :
> I've been running it for a long time. Have you tried it?
No. I will now.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give
Hal Murray :
> >> Should we change the default to be --enable-seccomp? (If on Linux)
>
> > I didn't know it wasn't already defaulted to on. Was it in the Classic
> > build?
>
> It's not on in classic. I doubt if they test it often. I had to add several
> syscalls before our version started
Hal Murray :
> Is the interface cleanup (still) on your list? If so, where is your list
> and/or how do I find more info on why it didn't work?
It is not on my list - not since we found out that the pro-gread admin tools
like Puppy all assume that filtering by interface is possible. That sugges
Hal Murray :
>
> Eric said:
> > Especially since...well, we're supposed to be about security. It would be a
> > bit perverse to drop a security feature just because it's occasionally
> > inconvenient.
>
> How many of you are using it?
>
> Should we change the default to be --enable-seccomp? (If
Hal Murray via devel :
>
> In case anybody isn't familiar with this area... The idea is to tell the
> system that this program will only use a specified list of system calls. If
> a bad guy finds something like a stack overflow, their evil code can only use
> those calls. Seems like a useful
Achim Gratz via devel :
> Achim Gratz via devel writes:
> > Last contacted + headway gives 8192s or poll=13? What is hpoll? The
> > other raspPi that doesn't have that problem (at the moment anyway, has
> > this as 16s and correspondingly ppoll=hpoll=4 as configured.
>
> I've had to restart some
Gary E. Miller via devel :
> get_lsb_ulong() takes an unsigned and returns and unsigned.
>
> So it makes sense just to keep everything unsigned, but gcc thinks
> this is all insigned:
> retval |= *((*bufppa)++);
>
> But that there is an implicit conversion to int here:
>
>retval |=
Gary E. Miller via devel :
> Yo Eric!
>
> Commits:
> 0ecdf682 by Eric S. Raymond at 2017-05-11T14:10:41-04:00
> Address Coverity CID 161765: Integer handling issues (SIGN_EXTENSION).
>
> Bad patch:
>
> ../../libparse/binio.c: In function 'get_lsb_ulong':
> ../../libparse/binio.c:43:10: warning:
Hal Murray :
> You like to close issues, but frequently I can't figure out why. Here is a
> good example.
> https://gitlab.com/NTPsec/ntpsec/issues/296
>
> Did you fix something? Did you decide it's not a bug? Did you decide it is
> too hard to fix, or any fix would break something else? ..
Gary E. Miller via devel :
> As a compatibility measure, how about we change the .py file to be explicitly
> UTF-8?
Works for me.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisi
Hal Murray :
> [What packet types do we support?]
>
> man ntp.conf says:
>peer
>NTP peer mode has been removed for security reasons. peer is now
>just an alias for the server keyword. See above.
>
> It's not clear what "has been removed" means. Just the server set
Trevor N. via devel :
> I have a device that will rollover after week 1998 (in 2018) that I
> just tested with a GPS simulator set to 2 years in the future,
> attached to ntpd classic with a +2 year offset in get_ostime (and
> "disable ntp" in conf) and ntpcal_get_build_date() of 2016. The
> 512-w
Hal Murray :
>
> Eric said:
> > Possible work item (me): Change Mode 6 so it no longer ships system status
> > bits in hex, decoding them into a string token list instead, old behavior
> > preserved under ENABLE_CLASSIC_MODE. This is because the PLL* definitions
> > aren't guaranteed to be consist
Hal Murray :
>
> I don't think they are right. I get occasional timeouts/crashes but haven't
> had time to investigate. Possibly the logic is correct and we need to bump
> the retry count.
>
> Has anybody else noticed troubles?
I have never seen this problem.
--
http://www.c
Hal Murray :
>
> devel@ntpsec.org said:
> > Work item: Replace
> > typedef uint64_t l_fp;
> > with
> > typedef uint64_t l_fp_time;
> > typedef int64_t l_fp_offset;
>
> I think that should be rejected in favor of eliminating l_fp except at the
> very edge and doing the pivot at the edge.
Hal Murray :
>
> >> You could use it as an example of how to do it right.
> > Er, *what*?
>
> Fix the code. Do it right and cleanly. Add a comment pointing to the page
> with a full description of the whole mess. Have that page point back there
> as an example of how to fix the GPS week rol
Mark Atwood via devel :
> I find it unlikely we're going to find a real Jupiter to test against, if
> nobody has raised this issue against NTP Classic.
I do, too. Seventeen years!
*plonk*
--
http://www.catb.org/~esr/";>Eric S. Raymond
Please consider contributing to my Patreon p
Gary E. Miller via devel :
> No. GPS uses 10 bit weeks on the L1 C/A channel, which is what
> most consumer GPS use. The other systems use 13 bit weeks.
Ah, that is the crucial bit on information I lacked. Thanks.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Please consider c
Gary E. Miller via devel :
> On Tue, 25 Apr 2017 16:32:17 -0700
> Hal Murray wrote:
>
> > So the answer is simple. Not yet. All GPS receivers still have roll
> > over problems.
>
> Not so simple. If your GPS picks up GLONASS, Beidou, Galileo, etc.
> then it will not have the gps week rollover
Gary E. Miller via devel :
> So get to it! I'm trying to get action items checked off. This was one
> that was checked off, validated, and working, until you reverted it.
Would have failed in 2036. Probably the existing code would have,
too, but still. You're not going to push me into moving f
Hal Murray :
>
> devel@ntpsec.org said:
> > I think we can drop the Jupiter driver. I looked for rollover compensation
> > and didn't find it. Instead there's this at line 1019:
>
> You could use it as an example of how to do it right.
Er, *what*?
--
http://www.catb.org/~esr/
This is the list of work items and potential work items I have
extracted from my back mail.
Serious bug: We have a report from MAYER Hans that
ifstats is broken, returning no output. It should be possible to pin down
when this broke with a regression test.
Possible work item (Ian): See how much
Gary E. Miller via devel :
> > Not yet. We know that code stinks, but there is still thinking to be
> > done before replacing it.
>
> Rush? Thinking was already done, Hal was happier with the code than
> what it is now. What about that code have I not explained clearly yet?
The thinking is not
Hal Murray :
>
> e...@thyrsus.com said:
> > We can't fix *that*, either. All we can do is add a warning to the man
> > pages for NMEA-related drivers that if your GPS is older than 1024 weeks you
> > may be cruising for a bruising. I think I'll go do that.
>
> We need to find out when they add
I think we can drop the Jupiter driver. I looked for rollover
compensation and didn't find it. Instead there's this at line 1019:
instance->timecode =
GPS_EPOCH + (instance->gweek * WEEKSECS) + sweek;
I think that means this driver will have timewarped as of the GPS
rollover
Gary E. Miller :
> Yo Eric!
>
> On Tue, 25 Apr 2017 09:58:10 -0400
> "Eric S. Raymond" wrote:
>
> > > The code in step_systime() is really really ugly. (to my eye)
> >
> > Not just to yours...
>
> So, can we now got back to my better version? The one that had no
> l_fp or pivot needs or de
801 - 866 of 866 matches
Mail list logo
