Debugging XDMCP X-Windows Service

XDMCP is the protocol by which an X-server asks an execution server to put a greeter on its screen and then to run a session for the authenticated user. When there's an issue with XDMCP it's always a struggle to debug it from home through multiple firewalls. Here's the procedure I worked out.

In the examples the execution server is called remexe (for remote execution). The machine where you are working is referred to as localhost. RFC 1918 addresses of 192.168.1.1 and 192.168.1.2 are used for the tunnel, but you could substitute any suitable pair of addresses. Display :2 is used but if this is occupied on your machine you could pick any unused display number. The firewall (if any) on the local and remote hosts have to be jiggered to allow ports 177/udp (for XDMCP) and 6002/tcp (for display :2) to be passed by the tunnel. Firewalls on intermediate router(s) only need to let ssh through, port 22/tcp.

• Executing on localhost, get a secure shell session to remexe in the normal way, in a separate terminal window.

  xterm -e slogin remexe

• Executing on localhost, set up a ssh tunnel. This could actually be combined with the shell session, but it seemed simpler to use separate processes becuase if there were an error in the tunnel parameters I could kill it and do it over, without killing the shell session.

  Note: On remexe the ssh daemon needs to allow tunnels. /etc/ssh/sshd_config needs to say PermitTunnel yes or PermitTunnel point-to-point. The default is to not allow tunnels. You may need to edit the configuration file and reload the daemon.

  ssh -w any -N -n remexe & # in background

• Executing on both localhost and remexe, identify which tunnel device is being used. If there are several, the date on the symbolic link is the date when the tunnel was created, which you should know. The examples assume that both are using tun0.

  
  ls -l /sys/class/net

• Assign IP addresses to the endpoints; I'm using 192.168.1.1 on remexe and 192.168.1.2 on localhost. Create a point-to-point route between them through the tunnel. On remexe do this:

  ifconfig tun0 192.168.1.1
  route add -host 192.168.1.2 dev tun0

  On localhost do this, interchanging the IP addresses:

  ifconfig tun0 192.168.1.2
  route add -host 192.168.1.1 dev tun0

• To test the tunnel, try this on localhost:

  ssh 192.168.1.1 uname -a

  It will ask you to confirm the validity of remexe's host key; or if your security rules are extra paranoid you can pre-add 192.168.1.1 as an IP address of remexe in $HOME/.ssh/known_hosts.

• If you need to monkey with your firewall, now is the time to do it.

• Now start the Xephyr X-server on localhost. It opens a window on your display which it uses as a framebuffer for the X objects sent from remexe. It will connect through the tunnel to remexe and attempt to get a session.

  Xephyr :2 -screen 1024x768 -from 192.168.1.2 -query 192.168.1.1

• What could go wrong?

  • A raw X session over a DSL line can be quite slow. Give it plenty of time: as much as a minute to send over the greeter window(s) and the background picture.

  • The most likely case is that Xephyr sends XDMCP solicitation packets and gets no reply, due to an error setting up the tunnel, or firewall paranoia, or if xdm is not running on remexe. It will keep trying for two to three minutes, then print a message and some statistics. But it will not exit; you have to kill it or close the window explicitly.

  • You can use tcpdump on either end of the tunnel. This command line just spits out every packet.

    tcpdump -i tun0 -l

  • If xdm is configured to reject your X-server, Xephyr will print the rejection message followed by statistics.

  • It is also possible that xdm tries to put a greeter on the X-server but the packets are blocked or are rejected by the X-server. tcpdump could distinguish between these cases.

  • If you do authenticate and start your session, expect it to go at the speed of an arthritic snail, unless you have a FIOS connection.

• When finished, just kill Xephyr or close its window, and kill the ssh process for the tunnel. The tunnel devices and the routes through them will be deleted automatically.