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

[Kimmo Suominen]

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