From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Description of problem: When we use host names that begin with a number, such as 50dhcp26, xterm doesn't work. For example, renwick:svls50 (7): setenv DISPLAY 50dhcp26:0.0 renwick:svls50 (8): xterm xterm Xt error: Can't open display: 50dhcp26:0.0 However, if we use the IP address of the same server, it does work. Version-Release number of selected component (if applicable): xterm-179-5.EL How reproducible: Always Steps to Reproduce: 1.Login to a host with a name beginning with a number. 2.remotely login to a linux system running Red Hat Enterprise. 3.set the DISPLAY to the local host. 4.Run xterm. Actual Results: renwick:svls50 (7): setenv DISPLAY 50dhcp26:0.0 renwick:svls50 (8): xterm xterm Xt error: Can't open display: 50dhcp26:0.0 No window. Expected Results: renwick:svls50 (7): setenv DISPLAY 50dhcp26:0.0 renwick:svls50 (8): xterm xterm window appears. Additional info:
Could you file a bug report at the X.Org bugzilla at https://bugs.freedesktop.org/ please? Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates. Thanks
I've submitted a bug to Freedesktop as you asked; https://freedesktop.org/bugzilla/show_bug.cgi?id=1605
Update on issue from upstream bugzilla: ------- Additional Comment #1 From Thomas Dickey 2004-11-22 17:00 [reply] ------- This is not specific to xterm; it's down in the X libraries. For instance I can see the same issue with rxvt. ------- Additional Comment #2 From Alan Coopersmith 2005-03-20 09:18 [reply] ------- 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.
*** Bug 132979 has been marked as a duplicate of this bug. ***
This is a bug in Xtrans which affects all applications, rather than an xterm bug. It's also not limited to x86_64. Reassigning bug to XFree86 component, and taking ownership.
Patch from freedesktop.org applied and built for U6. I reproduced the bug on an x86_64 box (and the problem *is* limited to 64 bit boxes, since INADDR_NONE != -1L there) and the patch from Alan Coopersmith does fix it. 32 bit machines shouldn't be affected by this change and I've verified this on my x86 desktop machine. Closing bug.
Please test XFree86-4.3.0-85.EL and provide feedback as to the results of testing. Beta rpms are available for testing at the following URL: ftp://people.redhat.com/mharris/testing/3.0E Setting status to "MODIFIED", awaiting testing results.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-501.html