xclock X connection to localhost:11.0 broken (explicit kill or server shutdown).

[J.A.R. Karremans]

Hi everybody,

I get X connection to localhost:11.0 broken (explicit kill or server shutdown). when I run xclock.

I am behind a remote VPN installation and I have 2 ux-boxed.
One is working and the other one not.

So... it's some arbitraty setting somewhere...

Who has an idea about in which file I have to hack??

Thanks for helping / sharing / your valuable time...
Regards,
Jan

[Steven E. Protter]

Shalom,

This could be caused by a manual operation such as someone killing your process.

Have you looked at /var/adm/syslog/syslog.log ?

What data led you to believe that you have to hack a file?

SEP

[Alex Glennie]

localhost:11.0

why 11 ? what are you using at the keyboard end to connect to the remote unix servers ?

what other actions do you perform prior to typing Xclock on the CLI ?

can all systems involved (3) correctly resolve hostnames & ip's.

try (if you haven't already) settih the DISPLAY to
ip_address:0 and report back where ip is at the k/b end.

sounds like Xclock never found a display to use.

[Matti_Kurkela]

The most probable reason for "localhost:11.0" is that the original poster was using SSH X11 forwarding, and happened to be the 2nd simultaneous user of forwarded X11 connections at that host at the time.

The first SSH-forwarded X11 connection gets a DISPLAY value like localhost:10.0, the second gets localhost:11.0 etc. The value refers to an X11 proxy port set up by the remote sshd, which will pass the X11 traffic in encrypted form to the user's local SSH client. The SSH client will then pass it on to whatever X server is available at the system where the client is running.

The error message means a X connection was established, but was then abruptly closed. In the case of SSH-forwarded X11 connections, this might mean the X server software on your local workstation is not responding to connections forwarded by the SSH session.

(The remote X11 proxy needs to accept incoming connections immediately, so that they won't time out while the rest of the connection is set up. But if the connection between the SSH client and the local X server fails, the SSH client must report the sad result to the remote sshd X11 proxy, which then has no choice but to kill of that part of the connection. Once the X application sees this, it outputs the "X connection broken" error message.)

So, what's on the local end? If the local workstation is running some version of Microsoft Windows, the X server software might be something like ReflectionX, eXceed, or Xming. Is it running?

MK

[J.A.R. Karremans]

Hi there everybody,

Thank you for your kind responses!!
What I failed to mention is that the system is on a remote site (WANned to me)...
Locally X has always worked fine.

@SEP, I will checkout the syslog, obvious thing to do, but still slipped my mind :(

@Matti, Okay...
1. What you see, when you start xclock several times (in test), it everytime comes with a higher portnumber (+1), os 10.0, 11.0, 12.0 etc.
2. I am running Xming on Windows 7.

The strange thing is... I have like 24 servers on this WAN (SSL-VPN based WAN). Several are working fine with X (xlock starts right off). but the major part of the servers give this error, even though there are quite some firewalls with NAT etc. there.
If SSL is working, and X is tunneled through SSL, there should be no portnumber issue, should there?

Thank you once again!
Regards,
Jan

[Matti_Kurkela]

> 1. What you see, when you start xclock several times (in test), it everytime comes with a higher portnumber (+1), os 10.0, 11.0, 12.0 etc.

The port number should change only if new SSH connection is made.

When you "start xclock", what exactly are you doing? It looks like you might be doing something other than typing "xclock" into an existing SSH session with X11 forwarding.

Perhaps you have some sort of GUI-based connection tool? That might initiate a new SSH connection on each click of a "start xclock" button.

The fact that the display number keeps increasing at the X application end (= remote) suggests the sshd X11 proxy processes may be still hanging onto their local TCP sockets. Normally they should die off after the SSH connection is broken. If they remain indefinitely, that might suggest some problems with the remote sshd - or just a really overloaded server.
(The DISPLAY numbers map directly to port numbers in the 6000+ range: for example, localhost:10.0 refers to port 6010, etc.)

Or maybe you're just reconnecting faster than the sshd processes can cleanup themselves, and each new attempt gets an unused port. That should be harmless: the port (and thus the DISPLAY variable the X application sees) is only between the application and sshd's X proxy. Once the connection gets to your workstation, the last hop between the SSH client and your Xming will use another port anyway (most likely localhost:0.0, aka TCP port 6000).

Checking the remote sshd version might be useful: even though SSH X11 forwarding is pretty well-tested technology, you might have an ancient version of sshd running somewhere, and that just might have some problems setting up a X11-forwarding connection with a very modern SSH client, or vice versa.

> 2. I am running Xming on Windows 7.

OK, that's a pretty modern X server, which is used often with SSH X11 forwarding, so it should work.

MK

[J.A.R. Karremans]

Hi there Matti,

Thank you for thinking with us.

What I do is;

1. I start Xming locally

2. Make connection with the client-DMZ (VPN-V-LAN with us) by adding the appropriate route.
Start an SSH-session with the machine.

3. This machine echo's back:

[SSH] Protocol Version 2 (OpenSSH_4.5p1+sftpfilecontrol-v1.1-hpn12v14)
[SSH] Cipher: aes128-ctr


[SSH] X11 forwarding enabled for localhost:0.0
Last login: Mon Feb 28 16:44:15 2011 from 10.0.135.251

4. I start xclock and get

[root@somehost:/] xclock
Error: Can't open display:
Error: Couldn't find per display information
[root@somehost:/]

5. I logout make a connection to another site, where I also login and start xclock:

# xclock
Warning: Missing charsets in String to FontSet conversion
Warning: Unable to load any usable fontset

But, voila! There is xclock...

I really have no clue where as to find this...

Do you?

[Matti_Kurkela]

> 4. I start xclock and get
root@somehost:/] xclock
Error: Can't open display:
[...]

Hm, that's not the same error message as in your original post. Interesting.

Normally, the message "Error: Can't open display:" includes the value of the DISPLAY variable, like:

Error: Can't open display: localhost:10.0

Because the error message ends without mentioning the DISPLAY value, it looks like the DISPLAY variable is not set. That means the X11 forwarding setup has failed.

After connecting and finding that xclock doesn't work, run "echo $DISPLAY" and "xauth list". If X11 forwarding is working, the expected result is that the DISPLAY variable contains a value like localhost:10.0 and the "xauth list" contains one line that includes the value of DISPLAY in the first column.

If the DISPLAY variable is unset, perhaps sshd on this particular host has been configured to disallow X11 forwarding.

As the remote host seems to be running the HP-provided SSH package, the sshd configuration file is at /opt/ssh/etc/sshd_config. In HP Secure Shell and all other OpenSSH-based SSH implementations, the required setting is "X11Forwarding yes". Add it to the configuration file if it does not exist or is commented out, then restart sshd:

sh /sbin/init.d/secsh stop
sh /sbin/init.d/secsh start

Then close the connection and try again.

Another possibility is that the remote sshd might have had some problems running "xauth add" (the command that adds the necessary authentication information to $HOME/.Xauthority, and creates that file if it doesn't already exist). If writing the authentication information is not successful, sshd may delete the DISPLAY variable from the session environment. The location of the xauth command can be explicitly specified in the sshd_config file, with a line like

XAuthLocation /some/path/xauth

If your sshd_config file contains such a line, make sure it has the correct path.

If sshd has problems setting up X11 forwarding, it might output an error message describing the problem into system log (typically /var/adm/syslog/syslog.log in HP-UX).

MK