gdm 1.0.0-35 from the RH 6.0 distribution does not support
Host running the RH 6.0 + gdm does not appear on chooser
lists of other computers.
Also starting the X with options -indirect <HOSTNAME> or
-query <HOSTNAME> has no effect.
PS. although the gdm is supposed to listen to port 177, this
port is closed.
*** Bug 2538 has been marked as a duplicate of this bug. ***
When trying to access my machine from another using exceed,
it refuses to connect. If I use xdm it works.
Running Netstat -an shows that port 117 is not being
answered and after a few moment the Recv-Q is quite high.
*** Bug 2270 has been marked as a duplicate of this bug. ***
stock 5.9 installation, gdm starts by default.
attempt to run
Xnest :1 -query localhost from an xterm
results in blank Xnest.
Same command on 5.2 brings Xnest with login prompt.
according to the gdm config file, remote access is enabled.
$ netstat -a | grep 177
udp 11152 0 *:177 *:*
number '11152' is a queue length which increases with every
Xnest attempt. looks like requests are igonored.
------- Additional Comments From email@example.com 05/05/99 05:31 -------
It works if debugging is enabled in /etc/X11/gdm/gdm.conf. However
logout doesn't work.
The current workaround is to turn on debugging in gdm.conf
The proposed workaround of enabling debugging does not work for me.
*** Bug 3927 has been marked as a duplicate of this bug. ***
I can not connect with exceed nor X-WinPro with xdmcp from
another host. (xdm instead of gdm seemed to work, so there
seems to be a bug in gdm)
------- Additional Comments From firstname.lastname@example.org 08/31/99 15:12 -------
Just fixing the title, and verifying.
Just to add more comments on the bug that has languished too long (and
to get mkp into the Cc: list)...
gdm2, currently in development, will support xdmcp and will have a few
less problems than gdm 1.x - if you're interested in helping the
author test, please let him know at email@example.com
assign to mkj for now, since he's the current point man for gdmassign to mkj for now, since he's the current point man for gdm
(doh, actually click the right radio button)
Enabling debug doesn't always cure the problem.
Moving the gdm_debug() call in gdm_xdmpcp_send_accept() to before
the XdmcpFlush() mysteriously cures the problem even with debug off.
The problem is that the XdmcpFlush() doesn't flush the XDMCP packet.
Either something weird in NLS gettext() or something in kernel.
The gdm included in RHL 6.1 should do a better job of this - are you
up to giving it a try?
Bug reporter has indicated this works in RHL 6.1