Hide Forgot
gdm 1.0.0-35 from the RH 6.0 distribution does not support XDMCP. 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. Chz Andrew
*** 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. more clues: $ 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 s348842.edu.au 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 sopwith 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 mkp
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