summaryrefslogtreecommitdiff
path: root/htmlhelp/xdmcp.html
blob: b926a515f1ced72906c7219ea5829cb32bef1364 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=utf-8">
<title>XLaunch XDMCP settings</title>
<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="common.css">
<link rel="stylesheet" type="text/css" charset="utf-8" media="screen" href="screen.css">
</head>
<body lang="en" dir="ltr">
<div id="logo"><a href="additional.html"><img src="X2.bmp" title="XLaunch Additional parameters" alt="XLaunch Additional parameters"></a><span style="color:#2b5e82;vertical-align:super;font-family:Bitstream Vera Sans,sans-serif;font-weight:bold;font-size:30pt;">Launch</span></div>
<p style="clear: both;">
<div id="content" lang="en" dir="ltr">
<h2><a name="1"></a>XDMCP settings</h2>
Settings for the <a class="external" href="http://en.wikipedia.org/wiki/XDMCP"><img src="moin-www.png" alt="[WWW]" height="11" width="11">XDMCP</a> mode. This mode is the most problematic, is not secure, and usually requires altering of the remote machine's settings.
Remote Display Managers listen for the XDMCP protocol will send and receive data on port 177/UDP. But the actual connections will be made to the local port 6000+<i>n</i> /TCP, where <i>n</i> is the display number.
<h3><a name="3"></a>Connect to host</h3>
Enables XDMCP and sends <i>Query</i> packets to the specified host.<p>
<h4><a name="4"></a>Use indirect connect</h4>
Enables XDMCP and sends <i>IndirectQuery</i> packets to the specified host. This host presents a chooser box of several hosts or sends <i>ForwardQuery</i> to another host depending on how it's X Display Manager is configured (via Xaccess file entries).
<h3><a name="5"></a>Search for hosts (broadcast)</h3>
Enables XDMCP and broadcasts <i>BroadcastQuery</i> packets to the network. The first responding display manager will automatically be chosen for the session.
<h3><a name="6"></a>Terminate on server reset</h3>
Shut down the X server after logging out of the XDMCP server, rather than returning to it's login screen.
<h3><a name="7"></a>XDMCP remote settings</h3>
A quick guide to setting insecure XDMCP mode on a remote machine running kdm, gdm, xdm or wdm...<p>
On the remote *nix machine edit the following files, restart the X Display Manager.
<ul><li>
Edit the file Xaccess (each Display Manager has its own).
Make sure you have a line like this that is uncommented.
<pre>*     	#any host can get a login window
</pre></li>
<li>
Edit the X Display Manager config file (kdmrc, gdm.config, xdm-config or wdm-config) and change
<pre>[Xdmcp]
Enable=false <i>(may be shown as 0 in some distributions)</i>
  <i>to</i>
[Xdmcp]
Enable=true <i>(or 1 in some distributions)</i>
</pre>
or for a xdm style configuration
<pre>DisplayManager.requestPort:	0
  <i>to</i>
!DisplayManager.requestPort:	0
</pre></li></ul>
<h3><a name="8"></a>Troubleshooting XDMCP</h3>
If you are having problems use Wireshark or equivalent to monitor UDP traffic on the remote host and look for the sequence <i>Query</i> 177/UDP, <i>Willing</i> x/UDP, <i>Request</i> 177/UDP, <i>Accept</i> x/UDP, <i>Manage</i> 177/UDP and see where it stops. If it gets through the sequence then test with local and remote <b>xeyes</b> in multiwindow mode, because the Display Manager acts just like an X client from then on in to provide its login window.
</div>
</body>
</html>