We've just started using AMD64 systems with RedHat Enterprise 3.0. Our DHCP server is setup to assign numeric beginning host names, such as 50dhcp28. When I login to an AMD64 from a system with a numeric beginning name, xterm will not display back. If I change the DISPLAY setting to the IP address instead of the host name, it works. For Example; renwick:svls50 (7): setenv DISPLAY 50dhcp26:0.0 renwick:svls50 (8): xterm xterm Xt error: Can't open display: 50dhcp26:0.0 The version of the xterm code is; xterm-179-5.EL
This is not specific to xterm; it's down in the X libraries. For instance I can see the same issue with rxvt.
If libX11 is built without IPv6 support, then the old IPv4-only code in TRANS(SocketINETConnect) in xc/lib/xtrans/Xtranssock.c assumes that any host address string starting with a digit is a numeric hostname and calls inet_addr() on it instead of gethostbyname(). If built with IPv6 support, it should do the right thing, because it passes all addresses to getaddrinfo() which determines if it's a numeric address or hostname.
Does anyone have an opinion on how the best way of fixing this for builds that do not include IPv6 support? IPv6 is the default build option IIRC, but there are systems out there that might disable IPv6 support, and if we make IPv6 optional, we should fix the problem. Any opinions?
Created attachment 2675 [details] [review] Proposed patch to xc/lib/xtrans/Xtranssock.c On looking at this further, it appears I misread the code before, and it does the right thing in 32-bit mode, but has a 32-bit/64-bit conversion error. Xtranssock.c currently has: unsigned long tmpaddr; [...] /* check for ww.xx.yy.zz host string */ if (isascii (host[0]) && isdigit (host[0])) { tmpaddr = inet_addr (host); /* returns network byte order */ } else { tmpaddr = -1; } PRMSG (4,"SocketINETConnect() inet_addr(%s) = %x\n", host, tmpaddr, 0); if ((long)tmpaddr == -1L) { if ((hostp = _XGethostbyname(host,hparams)) == NULL) { So on platforms where inet_addr returns -1 on error, it should fall through to call gethostbyname. Newer platforms however define inet_addr to return INADDR_NONE on error. On a SuSE Linux machine I just checked, /usr/include/netinet/in.h has: #define INADDR_NONE ((in_addr_t) 0xffffffff) Since tmpaddr is unsigned long, it won't sign extend the 32-bit in_addr_t, so the comparison to -1 fails. Given that, I think this patch should fix it, but I haven't tested it.
Comment on attachment 2675 [details] [review] Proposed patch to xc/lib/xtrans/Xtranssock.c Patch verified on a x86_64 box.
I've reproduced the problem on a x86_64 box and verified that the patch does indeed fix the bug. Patch committed on HEAD and nominated for 6.8.x. Closing bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.