<div dir="ltr"><div dir="ltr">On Fri, Feb 5, 2021, at 2:42 AM Hal Murray via devel <<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a> said:<br>
> 1208. I stripped out all handling of the netlink socket and fixed around the<br>
> breaks I found. This would reduce NTPsec w/ NTS and IPv4/6 to 5 sockets. They<br>
> are UDP4, UPD6, TCP4, TCP6, and netlink which only spuriously trigger DNS<br>
> retries.<br>
<br>
I scanned the patch file and didn't see what I was looking for.  But it's 3K <br>
lines so I could easily have missed it.<br></blockquote><div><br></div><div>What were you looking for in the branch?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
How much testing have you done?  I expect the easy cases will work.  Did you <br>
test anything complicated?<br>
<br>
It takes more than one interface to generate the complicated cases.  The <br>
server side needs to use the dest address from the request as the source <br>
address on the reply.  The client side needs to check that the packet came to <br>
the correct dest address.  That's the code I didn't see.  The old code with a <br>
socket per interface let the kernel do that work.  With only one interface, <br>
you can't get it wrong.<br>
<br>
To test that, you have to do something to make the packet arrive on the wrong <br>
interface.<br>
</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
At least on some OSes, you can get one socket that covers both IPv4 and IPv6.  <br>
Maybe that's only for TCP.  Mumble.  I had to set some magic flag in order to <br>
get both NTS listeners to work.  The second listener on a second thread seemed <br>
like a simple way to get some multi-threading.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Your "spuriously trigger DNS retries" path is important.  It handles the case <br>
where ntpd gets started before the link to the outside world is up and all the <br>
DNS lookups fail.  It doesn't catch all the cases, but it got at least one.  <br>
It won't recover from something like a home router being slow to start after a <br>
power fail, maybe because the owner didn't poke the power button until late in <br>
the recovery game.  I think the case it did catch involved WiFi.<br></blockquote><div><br></div><div>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.</div></div></div>