XDMCP Connection Process and Error Types

XDMCP(X Display Manager Control Protocol) allows you to use the X application programs on your device after connecting to a UNIX/Linux system with just an XDMCP query.

Open

As long as no network problems exist with the remote UNIX/Linux system and the XDMCP settings are properly configured on the device, an XDMCP packet exchange will first be performed through UDP port number 177 (can be changed through server settings). Finally, when Xmanager sends the ‘MANAGE’ message, the XDMCP daemon will run the first X application, a login program called Xgreeter, and asks Xmanager to draw the login screen.

After the user presents valid login information, a set of X applications, including the window manager, are drawn into Xmanager.

Types of XDMCP Connection Failures

Case 1: When communication via UDP 177 is not possible due to a firewall or NAT environment on the remote UNIX/Linux side.

Open

Solution:

• Allow UDP 177 on your firewall device.

• Allow or register UDP 177 in the firewall program of the UNIX/Linux device.

   

Case 2: When the XDMCP daemon does not exist or is improperly configured on the remote UNIX/Linux device

Solution:

• The XDMCP daemon may not be running on the remote device. The XDMCP daemon process will be one of the following: xdm, kdm, gdm, gdmm-binary, lightdm, or dtlogin. Use the ps command to check whether one of these processes is running.

• If the settings are improperly configured, you should refer to the following document and make the appropriate configurations for the UNIX/Linux type and version.
  https://netsarang.atlassian.net/wiki/spaces/ENSUP/pages/109051907

• You can check whether the daemon is running and configured properly with the following command.

  $ netstat -an |grep 177 udp 0 0 0.0.0.0:177 0.0.0.0:* udp6 0 0 :::177 :::*

Case 3: When TCP communication is impossible due to a firewall or NAT environment on the PC side where Xmanager is installed

After successful UDP communication, X applications communicate from UNIX/Linux to the PC via TCP 6000. The following image shows what happens when the TCP communication fails.

In the Xmanager log, the ‘Cannot open display’ message appears after the XDMCP MANAGE message.

Solution:

• Contact your company's system administrator and ask them to allow TCP 6000 to 6010 from your firewall device to your PC. A new Xmanager process runs for each XDMCP session, and the listening port increases sequentially starting from 6000. If you have many sessions in use, you must ensure that you have enough ports.

• Make sure the Windows firewall is also configured properly:
  https://netsarang.atlassian.net/wiki/spaces/ENSUP/pages/109183120

• If your PC has a private IP address within the router, TCP packets will not reach Xmanager. In this case, you need to set up port forwarding on your router.
  https://netsarang.atlassian.net/wiki/spaces/ENSUP/pages/109183124
  
  

In all these cases, you can instead resolve the issue by using Xmanager's SecureXDMCP feature.

Case 4: When X Display indicates a location other than Xmanager

When making an XDMCP connection, X Display is automatically set to the PC where Xmanager is installed and the port where Xmanager is waiting. However, there are cases where the location may be different due to unnecessary settings by the user or errors in the DNS settings on the remote server.

In the Xmanager log, the ‘Cannot open display’ message appears after the XDMCP MANAGE message.

Solution:

• If your startup script contains DISPLAY-related settings, you should remove them. User startup scripts vary depending on your shell: /etc/profile, /etc/bashrc $HOME/.profile, $HOME/.cshrc, $HOME/.login, $HOME/.bash_profile, $HOME/.bashrc, $HOME/.kshrc, $HOME/.zshrc etc.

• This issue can occur due to improper DNS settings. Some legacy UNIX systems attempt a reverse lookup of the hostname of the PC's IP address and will use that hostname as the X Display. This problem may occur if the IP address of the hostname looked up by the DNS server is different from the PC IP address.
  
  

  If this is the case, you would need to correct the errors in the DNS lookup and reverse lookup table, which is a difficult process. You can instead solve the problem by simply registering your PC's IP address in the /etc/hosts file.

  NOTE: The PC name does not have to be the same as the actual Windows PC name.