Troubleshooting X

Try using X2Go instead of a “pure” X server. Even if your local machine is a Linux or OS/X box with a built-in X server, you are likely to find X2Go faster for remote connections.

Choose your applications carefully. Applications with fancy tool bars and graphics may run slowly, or may take a long time to appear on your screen but then run at acceptable speeds. If my network connection is sluggish, I am, for example, more likely to run nemiver or gdb-mode within emacs than to use ddd.
You can reduce the amount of network traffic required by X by telling your X server software to always use a “backing store”. In X-Win32, this option is found by right-clicking on the small blue “X”, selecting X-config, and going to the “Display” tab. A backing store is simply a copy of the window’s graphics kept in your local memory. This can be used to refresh the screen when part of your X application gets momentarily covered up by some other window, or if you iconify the X application and then restore it from the task bar. Without a backing store, all the graphics may need to be retrieved from the remote client over your modem connection.

This won’t speed up all applications (the default setting of many X servers is to use a backing store only if the application program requests one, so some X applications may already be getting a backing store). But, for some, this might make a big difference.
Get out the old modem and find a cheap dial-up ISP. I have had students in remote, mountainous regions report that, although they would continue to use their satellite broadband (their only available broadband option) for web browsing, they got better responses by using dial-up for their programming work.

1.2 “Cannot Open Display”

This message is the most common problem that arises when trying to run X applications. Possible causes:

If you are also getting a message “connection … refused by server” and/or “Client is not authorized to connect to Server”, see .
You forgot to start the X server before trying to launch an application.
You made a text-mode connection to a remote machine (e.g., used an ssh command without the -Y option) and then tried to launch a graphics-mode X program from there.
You are running behind a firewall that is set to an particularly paranoid level of protection.

This can be a problem with ZoneAlarm and other firewalls that prompt you for permission every time a new program tries to access the network. It’s all too easy to answer “Block” just once and have that program be locked out forever afterwards.

It can also be a problem with some LINUX distributions (e.g., some RedHat versions) that, by default, are configured with a firewall that blocks any X connections from other clients. See below.

1.3 “connect localhost port 6000: Connection refused” [connect-localhost]

The important thing about this message is that it indicates that the problem was with “localhost” (or “127.0.0.1”), which is the local machine that you are sitting at. The problem is not that some remote machine out on the Internet has refused you access, but that the machine you are sitting at has in fact refused to allow a connection from itself to itself.

This is pretty much an obvious sign of a firewall or other security program getting in the way. You might have gotten a pop-up window warning that a program (such as XWin.exe or ssh.exe) was trying to make or accept a connection on port 6000. If you told the firewall to block it, that’s the problem. If your firewall or security program is set to block unexpected connections without even asking you, that could be the problem.

The easiest way to check this would be to temporarily turn off your firewall and security software, then try launching an X client again. Unfortunately, I’ve seen some cases where even a switched-off firewall stays partly active and continues blocking things that it believes it has been previously told to block.

The exact fix for this depends a great deal on what firewall/security software you are running, but somehow you need to convince them to trust the X and ssh programs. Here are instructions for telling the Windows firewall to allow exceptions. Try adding those programs as exceptions. You might also want to try opening port 6000.

1.4 “connection … refused by server” or “Client is not authorized to connect to Server” [refusedByServer]

The “not authorized” and “refused by server” messages means that you got at least part way through the process of forming an X connection. The X client (xterm) running on the remote machine was able to actually talk to your X server software (running on the PC you are seated at) but your X server software’s security settings shut it down.

This message generally comes from StarNet’s XWin32. I’ve never seen it reported from users of Cygwin/X.

Things to check:

If you are using ssh to connect to X-win32, and if you downloaded it from the ODU site, then it is important that you followed these instructions for installing it, rather than the instructions included in the downloaded package.

In particular, did you enter the OCCS registration key during installation instead of just “demo”? (XWin32 should warn you that you are in demo mode every time it starts up.) If you entered that code, you cannot use ssh to launch a session and therefore cannot use X-Win32 from behind a firewall/NAT server. You will need to uninstall X-Win32 and then reinstall using my directions.

Run the X-Win32 X-config program and check the “Security” tab. Make sure that “Access Control” and “Use XAuth” are both clear. Click OK in X-config and shut down XWin32 if you have it running. Restart XWin32 and try to connect again.
If you still get the “not authorized” message, then go back to that security tab again. This time, click “Access Control” and use the “Add…” button to add to the X-host list:

localhost
127.0.0.1

Again, click OK in X-config and shut down XWin32 if you have it running. Restart XWin32 and try to connect again via ssh.

1.5 “xterm: unable to locate a suitable font”

This message is usually caused by a font configuration problem on the Unix side. There is a simple workaround, however.

Log into your Unix account. Using emacs or some other editor, create a file named ~/.Xdefaults In that file, place the following lines:

xterm*facename:dejavu sans mono:pixelsize=12
xterm*Geometry:80x36
xterm*foreground:midnight blue
xterm*background:white

Actually the first line is the critical one for this error - but you might find the effects of the other lines interesting. You may also want to play around with other combinations. To see what options you can put in for the facename, give the command

fc-list :scalable=true:spacing=mono: family

You might also experiment with changing “medium” to “bold” or changing the pixelsize.

1.6 Nothing at all seems to happen

If you are launching via ssh, check and make sure that you remembered to start your X server software and that it is running on your PC before you try to launch a client on the remote machine.

You may have an issue with your firewall or other security software.

1.7 If You Suspect Your Security Software is Blocking Your X Connections

If you are able to make an ordinary text-mode ssh connection, then leave your router firewall alone. No need to weaken it or to try turning it off. It’s not the problem.

(Windows, Mac) See if your X server will display clients running on your local machine. Start your X server software. Then
- (Mac) Open a command/terminal window and give the command “xterm &”. You should see a window pop up that issues commands to your local Mac.
- (Windows running Cygwin/X) Open a CygWin command window and give the command “xterm &”. You should see a window pop up that issues commands to your local PC.
- (Windows running Xming): Install the “Tools and Clients” option and try running xcalc or xclock.
If you are able to view an X client program running on your local PC, then you know at least that the X server software is working and the problem is definitely in your communications with the remote machine.
(Windows, Mac, Linux) If you have a router protecting you with it’s firewall, try disabling or turning off the software firewall on your PC. If that relieves the problem, then turn it back on, find the instructions for allowing specific programs to communicate through the firewall, and give your X server software that permission. If you are asked about specific port numbers, try 22 and 6000.
(Windows, Mac, Linux) If your PC is connected directly to your cable or DSL modem, i don’t recommend turning off your software firewall even momentarily. Find the instructions for allowing specific programs to communicate through the firewall, and give your X server software that permission. If you are asked about specific port numbers, try 22 and 6000.
(Windows, Mac, Linux) Find the instructions for modifying the settings of whatever security monitors you may be running. Look for any evidence that wither your X server software and/or your ssh client are being blocked. Or try (temporarily) disabling them, one by one, to see if they are the problem, reactivating them if the disabling has no effect on your communications.
(Windows) Try running the X server as an administrator. (Right-click on a shortcut or on the program executable. Look for “advanced properties” and a checkbox to “run as administrator”.) This will probably cause the UAC to pop up every time you run the program to ask if you really want to do that, but you can ignore that warning.

2 X, Firewalls and Security Monitors

One serious barrier to using X on some machines is the action of other programs that deliberately block signals from the X client from reaching the local server software.

Firewalls are software security programs that many people use to protect their networks from outside hacking. One of the features of most firewalls is to block incoming communications to sockets other than the reserved socket numbers for email, http, or other services the corporation wants to support.

Virus scanners inspect files on your disk, files that you download and/or receive as email attachments, and files that you try to execute. The scanner compares these against a database of known malware, warning you and sometimes acting immediately to quarantine or delete the offending file.

Spyware scanners perform many of the same functions as virus scanners, but watch for a variety of less-dangerous malware. These include email filters that watch for phishing and hijacking attacks that display an apparently innocuous link that takes you to a site very different from what the visible content of the email would lead you to expect.

Security monitors watch for suspicious behaviors by running programs. Such behaviors can include opening communications channels to other machines or the overwriting of system files.

Many software packages that provide one of the above services will also provide others. For example, some virus scanners support a “heuristic” mode that tries to detect viruses by “patterns” of behavior rather than by matching its code against a database of known viruses. Such a mode is, in essence, a security monitor.

We’ll start this discussion by looking a bit more closely at what a firewall really does.

2.1 What Does a Firewall Do?

Communication of any kind of service or data over the Internet is addressed to a socket, a combination of a specific machine’s address (the IP address) and the number of a specific port (a communications channel). Some port numbers are reserved for specific network services: ssh, ftp, and email, for example, all have their own specific port numbers. But any program can try to accept communications from, or send communications to, any port number on itself or on some other machine.

A firewall is a hardware or software system that restricts the ports that can actually be used to communicate with a particular machine. A firewall can be set to

allow both incoming and outgoing communications on any port (in effect, no firewall at all)
allow outgoing communications (from your PC) on any port to other machines, and replies from that machine on that same port. Incoming communications from other machines and on other ports are blocked.
allow only outgoing communications (from your PC) on selected ports (such as those for web browsing and email) to other machines, and replies from that machine on that same port.
allow no communications on any port, in either direction (in effect, unplugging from the network)

Most firewalls are designed to run at level 2 or 3 above. At level 2, your PC can initiate communications with other machines, and can get responses from them. But other machines cannot initiate contact with your PC. Another way of saying this is that your PC can be a client for services, but it cannot be a server taking requests for services from other machines. At level 3, your PC can only initiate communications for selected network services such as web browsing and email.

Many firewalls will allow you to choose the level you want when you install the firewall. The problem with level 3 is that it assumes that you can predict all of the future network services that you will want to use from your PC. Some firewalls try to “learn” whether new kinds of connections are legitimate by popping up a dialog window whenever a new program tries to open a new port number. The dialog asks you whether to allow or block the connection, and the firewall tries to remember your choice for future sessions. (And woe to you if you don’t understand the choice you’re being asked to make and select the wrong option the first time that you are asked.)

2.2 Problem: Displaying X is a Server’s Job

When you connect to a remote machine is text mode, using ssh or the older telnet protocol, your PC functions as a client that initiates communications with the server via a specific port number (port 22 for ssh, 23 for telnet). The server responds using that port.

Even if your PC is behind a firewall, such a communication is well within the guideline of “local PC can initiate contact with other machines and other machines can then reply on that port”. So this should get through a level 2 firewall. It will get through a level 3 firewall only if the ssh or telnet ports are specifically allowed, and it will get through a “learning” firewall only if you allow it the first time you try using your ssh or telnet client program.

What makes X a bit messy is that your local PC is actually supposed to behave as a server, not a client. When you start your X server software running, it is configured to accept graphics for display along a specific port, usually port 6000. (X servers generally refer to a “display number”, usually starting with display number 0, and the X server watches for incoming communications on port number $6000 + display-value$.)

An X connection begins with an ordinary ssh or telnet session. Eventually, you issue a command to run some X program such as xterm. That program, running on the telnet server, then tries to open a connection via socket 6000 ( I’m assuming thatyou are using display number 0, as is usually the case.) to your local PC. If you are running X server software on your local PC, it accepts the socket 6000 connection, and a new communications path is thereby established for X windowing information.

Now, throw in a firewall, and things get messy. From the viewpoint of the firewall, the socket 6000 connection is being initiated by an outside machine. Most firewalls will block any such attempt. The connection attempt fails. You may get a message saying the communication failed. You may see nothing at all happen.

Luckily, there’s a way around this problem that does not require you to poke holes in your firewall (which most firewall will let you do - many gamers do so to play multi-player games over the Internet, but it can be risky). ssh can be used to tunnel communications to other ports within its own data stream.

2.3 Tunneling X via ssh

ssh connections start off much like Internet client connections. Your local PC requests an ssh service on port 22 from a remote server. Because the communication is initiated by the local PC, the firewall should let it through. But if X tunnelling has been specified, and we send a command to the ssh server to start running an X program, things get interesting. The ssh server will launch X programs with a $DISPLAY value that maps right back to the ssh server, though usually on an unusually large display number. Therefore when the X program tries to open a connection to the X server that will display its windows, it connects to itself, on a socket number that is watched by the ssh server software. That ssh server software then sends a signal along the already-established ssh communications path indicating that an X connection was attempted. Back at your local PC, your ssh client software then opens a connection to socket 6000 on your local PC, where it gets picked up by your X server software.

It’s a neat dodge when it works. So what can possibly go wrong?

You have to remember to configure your ssh client to do X tunneling.
- Luckily, if you are using an X package like X2Go or Xming that includes its own ssh client, the package handles this when you configure a new connection.
Although the connection on port 6000 is from a local PC to itself and should never even touch the firewall, software firewalls running on the same PC sometimes don’t recognize that this is a purely local connection and block it anyway.
Security monitors may consider the act of opening any strange socket, even from a PC to itself, and suspicious and try to block it.
Other security monitors may consider the act of opening any port other than the standard ones for browsing, email, etc., to be task requiring permission of an “administrator”.

2.4 So Much Security, So Little Safety

What we’ve learned about firewalls needs to now be examined in the context of an overall security configuration.

Most people actually connect to the Internet via a router that provides wired or wireless access to the Internet to one or more devices in their home. Even if you have only a single PC as your only Internet-connecting device, it’s likely that your cable or DSL provider would have placed a router between your PC and the cable modem or DSL modem that provides direct access to your service.

Some people may, however, have a PC connected directly to a cable or DSL modem.

What’s important about the difference between these two configurations is that the router provides a firewall. Level-2 firewall protection is actually “built in” to the fundamental behavior of the router, although some can be configured for even stronger protection. The router’s firewall is your first line of defense against anyone trying to exploit your computer from outside. And it’s a pretty good one. When you read about large “botnets” of security-breached computers being controlled remotely, it’s almost never because a router firewall was breached. Almost always, the breach started with someone downloading a virus-laden file, letting a malicious program onto the protected side of the firewall, from where that program can initiate new connections to the outside world without tripping the firewall’s normal protections. Preventing that sort of infection is, first and foremost, a human behavior issue. Catching and cleaning up the human lapses is a matter for virus and spyware scanners (which we won’t be discussing further) and for security monitors.

If your PC is connected directly to your cable/DLS modem with no router, you should be running a software firewall on that PC (e.g., the Windows firewall that comes with your Operating System). Otherwise, you’re wide open to exploitation.

But what if you are behind a router? Most Windows PCs still will be running the Windows firewall. Why? Because Windows nags you if it detects that the firewall is switched off. It doesn’t know that your router is providing the same service. Is there any point to having a firewall behind a firewall? Well, it probably does not add any additional protection against outside intruders. It’s not a total waste, however. It does help provide protection in the event that one machine gets infected. If all your machines have their own firewalls, the infection might not spread to every other machine in your home.

Similar observations can be made about Macs and, with more variations, about Linux PCs. Most will come with a software firewall installed and running.

In addition to firewalls, security is provided by scanners that you use to periodically sweep your disk to look for infected files, and by security monitors that watch for “suspicious” activities by running programs. Unfortunately, some of these monitors may regard any socket communications that their programmers didn’t anticipate as suspicious.

For Windows users (Vista, Win7, and later), the operating system provides the UAC (User Account Control), which is the monitor that asks you if you want to actually run a program when you try to launch something not recognized by Microsoft. UAC can be annoying, but it’s generally harmless because it has no memory. If it asks you whether you want to run your X server software and you say “No”, you can change your mind by launching the same program again and answering “Yes” next time.

Also, some third-party anti-virus or security suites may install security monitors of their own.