Bug 476061 - XDMCP not working
XDMCP not working
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-11 13:58 EST by Jonathan Underwood
Modified: 2015-01-14 18:22 EST (History)
5 users (show)

See Also:
Fixed In Version: 2.24.1-4.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-26 10:31:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Slight rework of patch to apply cleanly. (10.40 KB, patch)
2008-12-15 17:51 EST, Jonathan Underwood
no flags Details | Diff

  None (edit)
Description Jonathan Underwood 2008-12-11 13:58:29 EST
Description of problem:
XDMCP seems not to be working in F10 - in /etc/gdm/custom.conf I have 

[xdmcp]
Enable=true

but, don't seem to be able to connect. I tried the latest updates-testing package, which contains a patch to fix xdmcp, but doesn't seem to be working for me.

Version-Release number of selected component (if applicable):
gdm-2.24.1-2.fc10.x86_64

How reproducible:
Everytime

Steps to Reproduce:
1.Enable xdmcp
2.Try to connect
3.
  
Actual results:
Fails to connect

Expected results:
Connects.

Additional info:
Comment 1 Ray Strode [halfline] 2008-12-11 14:18:47 EST
does 
/etc/init.d/iptables stop

"fix" your problem?
Comment 2 Jonathan Underwood 2008-12-11 14:35:53 EST
(In reply to comment #1)
> does 
> /etc/init.d/iptables stop
> 
> "fix" your problem?

heh. no.

I should've been clearer - I am connecting via vnc on the same machine. I get the black and white mottled X background that usually precedes gdm firing up.. but gdm never starts.

configuration is as follows

# cat /etc/xinetd.d/vnc 
service vnc1280x1024
{
	disable         = no
	socket_type     = stream
	protocol        = tcp
	wait            = no
	user            = nobody
	group		= tty
	server          = /usr/bin/Xvnc
	server_args     = -inetd -query localhost -geometry 1280x1024 -depth 16 -once -SecurityTypes None
}

In /etc/services I have:

vnc1280x1024    6900/tcp                # Local vnc server


Connecting with a vnc viewer to localhost port 6900 therefore should start gdm - it starts X, but I never get a GDM login screen (this worked under F-9).
Comment 3 Jonathan Underwood 2008-12-15 13:37:40 EST
Looking through the build logs it doesn't look like a patch to fix xdmcp was actually added (contrary to the package changelog)?
Comment 4 Ray Strode [halfline] 2008-12-15 13:55:00 EST
woops, will fix.  Sorry about that.  Clearly, I was doing too many things at once when I pushed that update.
Comment 5 Ray Strode [halfline] 2008-12-15 13:56:23 EST
building now.
Comment 6 Jonathan Underwood 2008-12-15 17:50:33 EST
Building failed as the patch didn't apply cleanly due to the presence of 

klass->get_timed_login_details = gdm_display_real_get_timed_login_details;

in the context of the patch relating to gdm-display.c. Removing that line from the context (since in 2.24.1 there is no get_timed_login_details member of that struct) allows the patch to apply cleanly. Haven't built and tested though. Modified patch attached.
Comment 7 Jonathan Underwood 2008-12-15 17:51:44 EST
Created attachment 327034 [details]
Slight rework of patch to apply cleanly.
Comment 8 Jonathan Underwood 2008-12-16 08:30:44 EST
Oh dear: I rebuilt gdm in mock including the modified patch from Comment #7 and it seems that xdmcp is still broken.
Comment 9 Jonathan Underwood 2008-12-18 11:28:49 EST
Any hints on debugging this? I've tried enabling debugging with

[debug]
Enable=true

in custom.conf, but there's nothing at all in the log as far as I can see.
Comment 10 Ray Strode [halfline] 2008-12-18 13:13:43 EST
might be this:

  http://bugzilla.gnome.org/show_bug.cgi?id=565018
Comment 11 Jonathan Underwood 2008-12-18 18:24:46 EST
I am a total klutz. The patch in comment #7 does in fact fix the issue (I'd managed to disable xdmcp in custom.conf while trying various things and forgot to re-enable it).

I've checked the patch in comment #7 into CVS and the relevant change to the spec file and set it building in koji:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1007980
Comment 12 Jonathan Underwood 2008-12-18 18:39:37 EST
OK, that built cleanly - obviously I can't push an update for this package, so will leave that to you, if you're happy with it.

[NB. just to prove I'm a klutz, I typo'd my email address in the chagelog :)].
Comment 13 Ray Strode [halfline] 2008-12-19 11:46:42 EST
Thanks for doing the ground work on this.
Comment 14 Fedora Update System 2008-12-19 11:48:36 EST
gdm-2.24.1-4.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/gdm-2.24.1-4.fc10
Comment 15 Fedora Update System 2008-12-21 03:38:45 EST
gdm-2.24.1-4.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gdm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11524
Comment 16 Stewart Adam 2008-12-22 15:36:43 EST
I have the same setup (VNC+xinetd+XDMCP), but gdm-2.24.1-4.fc10 still isn't working for me - Xvnc starts, but I just see a grey screen and GDM doesn't start.
Comment 17 Jonathan Underwood 2008-12-22 18:26:54 EST
Stewart - that's odd. Are you sure you enabled xdmcp in custom.conf? Whats the output of running this command as root on the machine:

nmap -sU -p 177 localhost
Comment 18 Jonathan Underwood 2008-12-22 19:21:17 EST
or alternatively the output of
 netstat -lnp | grep 177
Comment 19 Stewart Adam 2008-12-22 22:24:39 EST
PORT    STATE  SERVICE
177/udp closed xdmcp

I have this in my custom.conf though:
[xdmcp]
Enable=True
Comment 20 Jonathan Underwood 2008-12-23 07:02:38 EST
That state of "closed" is not what it should be, certainly. I see:

PORT    STATE         SERVICE
177/udp open|filtered xdmcp


Did you restart gdm after the upgrade (i.e. switchin g to runlevel 3 and then back to 5, or reboot) ?
Comment 21 Stewart Adam 2008-12-23 08:08:04 EST
I've tried that many times, too. I also tried stopping the iptables and firestarter services, so it's not the firewall...
Comment 22 Jonathan Underwood 2008-12-23 08:31:48 EST
OK, I have reproduced this. You need to change

[xdmcp]
Enable=True

to

[xdmcp]
Enable=true

to fix this. Note the capitalisation of "true". Over the holidays I'll try and knock up a patch to make gdm a bit more forgiving in terms of [Tt][Rr][Uu][Ee].
Comment 23 Jonathan Underwood 2008-12-23 09:58:03 EST
Added a patch to upstream bugzilla to allow True/False:

http://bugzilla.gnome.org/show_bug.cgi?id=565465
Comment 24 Stewart Adam 2008-12-24 13:35:04 EST
Thanks, it's working now. The OS X screen sharing utility doesn't seem to work, but that's another bug. Running 'vinagre localhost:5900' on the Linux box works perfectly.
Comment 25 Fedora Update System 2009-02-26 10:31:35 EST
gdm-2.24.1-4.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 26 mayost_sharon 2009-03-03 18:44:44 EST
Hello

03/03/2009 update my fedora 10 xdmcp is work

but after connect from another computer to xdmcp server is work once time

and now is not more work

also in server
Xnest :7 -query localhost

returen gray screen



my lan:
server fedora 10 - 192.168.2.101
Client XP with vnc - 192.168.2.109
Comment 27 mayost_sharon 2009-03-04 07:55:44 EST
Hello

Re-installed on new computer the fedora 10 offered all the - update turned the option available through Xdmcp it worked well.
But after I left the computer for 2 hours, I try to connect again with Xdmcp and it does not work.
I think that the bug has also repair the last of Gdm
I'm ready to attach to your log on demand.

Thanks

Note You need to log in before you can comment on or make changes to this bug.