[Tcsh] [PATCH] REMOTEHOST causes hang with IPv6 addresses

[Chuck Anderson]

If you open the bugzilla link, you can find the versions and system
being used.  In summary:

tcsh-6.24.07-2.fc37.x86_64 (Fedora 37)

I don't want the shell doing any built-in DNS resolution at all,
unless I configure or script that feature.  There is too much
variation and complexity in different DNS resolver
configurations/nsswitch/etc, and one would have a tough time
convincing the systemd maintainers to change how it does "local"
resolution (names without dots)--I've see the discussion threads.

However, it would be nice if it parsed utmp correctly to set
REMOTEHOST to IPv4 and IPv6 addresses.  Right now I get no REMOTEHOST
at all if it is an IPv6 address (after it times out trying to resolve
fdd1).


With systemd-resolved:

>cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search lan

>resolvectl
Global
       Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
       resolv.conf mode: stub

Link 2 (enp0s25)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wlp3s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
     Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
        DNS Servers: 192.168.1.1 fdd1:19ae:f1ae:1::1
	
>/usr/bin/time host fdd1
Host fdd1 not found: 2(SERVFAIL)
Command exited with non-zero status 1
0.00user 0.00system 0:03.93elapsed 0%CPU (0avgtext+0avgdata 12996maxresident)k
0inputs+0outputs (0major+778minor)pagefaults 0swaps


Without systemd-resolved:

>cat /etc/resolv.conf
nameserver 192.168.1.1
search lan

/usr/bin/time host fdd1
Host fdd1 not found: 3(NXDOMAIN)
Command exited with non-zero status 1
0.00user 0.00system 0:00.05elapsed 24%CPU (0avgtext+0avgdata 13084maxresident)k
0inputs+0outputs (0major+782minor)pagefaults 0swaps


On Fri, Feb 24, 2023 at 11:44:22PM +0200, Kimmo Suominen wrote:
> Yes, should really convert to using inet_pton(). But should also test
> for it in configure, then.
> 
> But if DNS resolution is being slow, that's the problem that really
> should be fixed. That's why I was curious about more details on the
> system being used, as well as the version tcsh.
> 
> I have already fixed a similar issue with screen:
> https://github.com/NetBSD/pkgsrc/blob/trunk/misc/screen/patches/patch-al
> 
> And I have a local tool called netname, which does the right thing
> with inet_pton(). I just cannot link to the code, as I haven't
> converted the repo from CVS to git yet... But I have the code that I
> think should go into tcsh to make it parse utmp more correctly, and to
> detect IPv6 and IPv4 addresses using inet_pton().
> 
> Cheers,
> + Kimmo
> 
> On Fri, 24 Feb 2023 at 15:04, Jamie Landeg-Jones <jamie at catflap.org> wrote:
> >
> > Jamie Landeg-Jones <jamie at catflap.org> wrote:
> >
> > > I didn't have the delay, though - it turns out that no DNS lookups are
> > > done on startup here.
> >
> > Looking further at this (using the latest code from github):
> >
> > |     /* Look for host:display.screen */
> > |     /*
> > |      * There is conflict with IPv6 address and X DISPLAY.  So,
> > |      * we assume there is no IPv6 address in utmp and don't
> > |      * touch here.
> > |      */
> > |
> > |     if ((sptr = strchr(name, ':')) != NULL)
> > |       *sptr = '\0';
> > |     /* Leave IPv4 address as is */
> > |     /*
> > |      * we use inet_addr here, not inet_aton because many systems
> > |      * have not caught up yet.
> > |      */
> > |     addr.s_addr = inet_addr(name);
> > |     if (addr.s_addr != (unsigned int)~0)
> > |     {
> > |       host = name;
> > |     }
> > |     else {
> > |       if (sptr != name) {
> >
> > As Chuck discovered, the "if ((sptr = strchr(name, ':')) != NULL)"
> > itself causes "name" to be truncated for IPv6 addresses.
> >
> > Later on, the following "inet_addr" function is now run on the truncated
> > name.
> >
> > With me, on a 2001:...... address, this meant calling inet_addr on the
> > value "2001", which doesn't fail, as it's a valid IP4 address. Hence
> > "host" gets set to "2001".
> >
> > In Chucks case, he was using a "fdd1:...." address - the hex part, I
> > assume, would cause the inet_addr to fail, and as sptr was now set to
> > NULL, the following part that does the DNS lookup was attempted in his case.
> >
> > So, to replicate his issue, connect to the machine on a link-local IP
> > address that doesn't have a PTR DNS record!
> >
> > Hope this helps a bit,
> >
> > Cheers, Jamie