Hal Murray :
>
> > The mistake I made was putting the new field first in the structure. This
> > caused it to be randomly trashed by type-punning dynamic-allocation code
> > that was expecting a link field there.
>
> I don't understand yet. Why are we type punning there? If it's a hack to
> a
> The mistake I made was putting the new field first in the structure. This
> caused it to be randomly trashed by type-punning dynamic-allocation code
> that was expecting a link field there.
I don't understand yet. Why are we type punning there? If it's a hack to
avoid malloc, why is the cal
Hal, I think I found the bug that was messing you up.
The commit "Address GitLab issue #356: reverse function for restrict"
introduced a 'mode' field to restriction nodes in the config parser.
The mode could be T_Restrict or T_Unrestrict to specify whether this
node is meant to turn restriction fl
Hal Murray :
>
> > 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's apparently
> > not via a hack_restrict() call, which is what I'd have expected. Can you
> > give me a file and line number?
>
> ntp_proto
Hal Murray :
>
> devel@ntpsec.org said:
> > It is just possible that I broke restrict this morning at
> > e7a4b0d3cf8932feeb898ed1343f25e8e65688d9 Address GitLab issue #356: reverse
> > function for restrict
>
> I reverted that fix and it's working again.
Well, shit. That's bad.
Two reasons: (
devel@ntpsec.org said:
> It is just possible that I broke restrict this morning at
> e7a4b0d3cf8932feeb898ed1343f25e8e65688d9 Address GitLab issue #356: reverse
> function for restrict
I reverted that fix and it's working again.
--
These are my opinions. I hate spam.
_
> 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's apparently
> not via a hack_restrict() call, which is what I'd have expected. Can you
> give me a file and line number?
ntp_proto.c, line 2480, in dns_take_
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
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 break. I'm
pretty sure it used to work bu
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 have read ESR's writeup on our buglist, and agree with his assessments.
..m
On Tue, Aug 15, 2017 at 5:27 AM Hal Murray via devel
wrote:
> > * I need to work on #348: reverse function for restrict
> > * unpeer should be made to fully work from ntpq :config. This one is
> mine too.
>
> There i
> * I need to work on #348: reverse function for restrict
> * unpeer should be made to fully work from ntpq :config. This one is mine
> too.
There is a quirk tangled in this area. I don't know if there is a bug for it.
When the pool mode adds a server, if needed, it pokes a hole in the
restri
12 matches
Mail list logo
