Article Title           : debugging_xremote
Creation Date           : unknown
Author                  : unknown
Last Update             : 6-1-93
Last Update By          : NCD Technical Support
Expiration Rules        : 
=============================================================================

Debugging Xremote - the magic steps
-----------------------------------

Basic requirements:

	1. the target NCD, and some other display, (preferabbly X based), 
	   physically close to each other. 

	2. a known working hard-wired link for the NCD


Procedure:

	1. on the NCD, log in to the host as some user (doesn't matter who).

	2. type the command 'tty', and remember the result. 

	3. type the command 'sleep 100000', (or some huge number), to hold
	   off the shell prompt.

	4. on the other display, open two terminal windows, (e.g., xterms)

	5. to see if the helper itself works, type the command

		Xremote -line <output_of_tty_cmd_from_step_2>

	   You should see the target NCD flip out of the terminal session and
	   into the 'root weave'. If so, you've got an 8-bit clean connection.
	   If not, we have either a comm path problem or an ioctl problem 
	   when we try to set the line to 'raw' mode. If this is the case 
	   you really need to look at the whole connection, (e.g., are you
	   going through terminal servers?), or we have to examine the source
	   to Xremote (ugh :(). 

	6. assuming you made it through (5), go to the other xterm and type 
	   some simple X command. I tend towards:

		xclock -display <hostname>:1

	   if you have the NCD's network activity light on, you should see 
	   lots of blinking, and within a minute or so, an xclock. If the 
	   xclock times out, try substituting the IP address of the host for
	   <hostname> above. If this still fails, try running an X client from
	   some other host on the net, specifying the display as the first
	   hostname:1. (These last two steps are necessary due to the fact
	   that I'm seeing more and more implementations of streams for local
	   connections instead of sockets, and we have to modify Xremote for
	   each one of these systems separately :().

	7. assuming you made it through (6), the only thing left to try and
	   test is 'xinitremote' itself. Working on the second display again,
	   in one terminal window type:

		xinitremote /usr/bin/X11/xclock -- Xremote -line <tty_output>

	   In the other terminal window, go to /usr/tmp, and verify that an
	   output file exists called 'Xremote1'. If so, do a 

		tail -f Xremote1

	   to see what is being written. Hopefully the xclock will come up, 
	   but if not, this is the point where we most likely will have to 
	   resort to the source. What xinitremote does, basically, is:

		a) exec's Xremote
		b) loops in an 'XOpenDisplay' against the server, as a test
		   to see if it comes up
		c) once it gets the successful open, it exec's the first 
		   client.