MR 1208

James Browning jamesb.fe80 at gmail.com
Fri Feb 5 15:30:50 UTC 2021


On Fri, Feb 5, 2021, at 2:42 AM Hal Murray via devel <devel at ntpsec.org>
wrote:

>
> devel at ntpsec.org said:
> > 1208. I stripped out all handling of the netlink socket and fixed around
> the
> > breaks I found. This would reduce NTPsec w/ NTS and IPv4/6 to 5 sockets.
> They
> > are UDP4, UPD6, TCP4, TCP6, and netlink which only spuriously trigger DNS
> > retries.
>
> I scanned the patch file and didn't see what I was looking for.  But it's
> 3K
> lines so I could easily have missed it.
>

What were you looking for in the branch?


> How much testing have you done?  I expect the easy cases will work.  Did
> you
> test anything complicated?
>
> It takes more than one interface to generate the complicated cases.  The
> server side needs to use the dest address from the request as the source
> address on the reply.  The client side needs to check that the packet came
> to
> the correct dest address.  That's the code I didn't see.  The old code
> with a
> socket per interface let the kernel do that work.  With only one
> interface,
> you can't get it wrong.
>
> To test that, you have to do something to make the packet arrive on the
> wrong
> interface.
>

I tested it using ntpdig on a couple of machines running Kubuntu 20.04 and
one w/ macOS High Sierra. Nothing complicated though, I can't be bothered
to think of and set up cases.


> At least on some OSes, you can get one socket that covers both IPv4 and
> IPv6.
> Maybe that's only for TCP.  Mumble.  I had to set some magic flag in order
> to
> get both NTS listeners to work.  The second listener on a second thread
> seemed
> like a simple way to get some multi-threading.
>

Ah, I wondered about that a little. I could get a single UDP6 to work in a
robot dog but not in NTPsec. Going with separate sockets for IP4 and IP6
also allows me to skip writing/finding helpers to convert from IP6
namespace to IP4 namespace for file I/O. I'm sure that if IP4 addresses
were banned tomorrow, everyone would gripe.


> Your "spuriously trigger DNS retries" path is important.  It handles the
> case
> where ntpd gets started before the link to the outside world is up and all
> the
> DNS lookups fail.  It doesn't catch all the cases, but it got at least
> one.
> It won't recover from something like a home router being slow to start
> after a
> power fail, maybe because the owner didn't poke the power button until
> late in
> the recovery game.  I think the case it did catch involved WiFi.
>

When combined with some other code in the DNS path it is wrong-headed.
"let's retry DNS every 5 minutes or whenever someone acts on the netlink
socket, and pack on extra pool servers until we have twenty." It will
probably come back in a diminished form later. If you absolutely must
dns_try_again periodically it a couple of single line fixes to ntp_io:837
and ntp_io:325, switching to true and maybe a new period respectively.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20210205/56d62bac/attachment.htm>


More information about the devel mailing list