<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 26, 2021 at 11:43 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 4/26/21 11:28 AM, enh wrote:<br>
> <br>
> <br>
> On Sat, Apr 24, 2021 at 2:37 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> <br>
>     On 4/22/21 9:00 PM, enh via Toybox wrote:<br>
>     > After a network outage, a long-running telnetd was spinning trying to<br>
>     > read from a socket that was in TIME_WAIT. It's easy to reproduce this by<br>
>     > using the regular telnet client and typing ^]^D to exit abruptly.<br>
> <br>
>     Doesn't apply without the previous one. I'll apply the whole stack on the theory<br>
>     it's in pending so I don't have a strong attachment to what's there, and you've<br>
>     just put a lot more effort into understanding it than I have so far.<br>
> <br>
>     But I don't think telnet should depend on having access to a DNS server<br>
>     describing any of the machines involved...<br>
> <br>
> <br>
> this is telnet*d*, not telnet. but, yeah, it's unclear to me whether -- despite<br>
> the fact that the login argument is called "hostname" -- we're really supposed<br>
> to supply the name or just the address[1].<br>
<br>
The address has more information than the name. (In theory you can have multiple<br>
addresses map to the same name...)<br>
<br>
> that said, BSD telnetd even has an<br>
> option to disallow connections from addresses it can't do a reverse lookup on<br>
> (<a href="https://www.freebsd.org/cgi/man.cgi?query=telnetd&sektion=8" rel="noreferrer" target="_blank">https://www.freebsd.org/cgi/man.cgi?query=telnetd&sektion=8</a>).<br>
> <br>
> they were different times :-)<br>
<br>
This is only really safe to use in a LAN or through a VPN these days, and I'm<br>
uncomfortable sending reverse DNS lookups out to the internet every time your<br>
test bench behind the firewall sends scripted result data to 10.243.37.5. (Not<br>
to mention the failing lookup potentially causing multiple seconds of latency in<br>
configurations I've hit repeatedly over the years.)<br>
<br>
I just added an NI_NUMERICHOST in there to squelch the DNS lookups. (And no<br>
I didn't re-wordwrap it, because this command still needs cleanup: making<br>
forkpty() nommu aware is a largeish TODO item that hits other commands too, and<br>
I've vaguely pondered trying to merge this with netcat and tcpsvd.c which is<br>
where pollinate() came from in lib/net.c but I'd need to work out a proper<br>
design before coding anything and haven't yet...)<br>
<br>
> 1. the present code will supply the address rather than the name anyway, in the<br>
> case that there's no DNS entry. so unless your objection is "shouldn't even<br>
> _try_ DNS", i don't think this makes any practical difference.<br>
<br>
That's what I was uncomfortable about, yes. The data exfiltration and potential<br>
15 second hang on a misconfigured system that I KEEP HITTING at various<br>
employers over the years.<br></blockquote><div><br></div><div>yeah, makes sense[1]. lgtm.</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">
Rob<br></blockquote><div><br></div><div>____</div><div>1. to the extent that anyone running telnetd in 2021 makes sense :-)  </div></div></div>