Bug 446224

Summary: xdmcp broken in gdm
Product: [Fedora] Fedora Reporter: Michael Young <m.a.young>
Component: gdmAssignee: jmccann
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: axelilly, cschalle, dant, gustavo, jonathan.underwood, kas, lkundrak, marcel, mathias.debelder, mattwilkens, miroslav, mozstuff, nphilipp, pza, rstrode, stanislav.polasek, whanlon
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-03 18:31:01 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Illustrative patch
none
gdm debug output
none
Patch to get cookies at the right place none

Description Michael Young 2008-05-13 11:43:52 EDT
I can't get gdm to start xdmcp. I have put enable=true in the [xdmcp] section of
/etc/gdm/custom.conf but no xdmcp listener is started. It seems
gdm_manager_constructor is being called before manager->priv->xdmcp_enabled is
configured, so manager->priv->xdmcp_factory is never set. I am attaching an
illustrative patch which allows XDMCP to start listening.
Comment 1 Michael Young 2008-05-13 11:43:52 EDT
Created attachment 305245 [details]
Illustrative patch
Comment 2 Michael Young 2008-05-16 10:27:40 EDT
Created attachment 305688 [details]
gdm debug output

If I work around the about problem, gdm crashes when I try to connect with the
attached debugging output. It seems the cookie length isn't being set.
Comment 3 Michael Young 2008-05-16 12:48:35 EDT
It looks like things aren't been done in the right order again. Cookies are set
in gdm_display_access_file_add_display, called from
gdm_display_create_real_authority, called from gdm_display_create_authority,
called from gdm_display_real_manage, called from gdm_display_manage. For xdmcp
this is called from gdm_xdmcp_handle_manage which is in reply to the "MANAGE"
request in XDMCP.
Unfortunately, the cookie is first required at the "REQUEST" stage in 
gdm_xdmcp_handle_request for the "ACCEPT" response, which comes before the
"MANAGE" request.
Comment 4 Michael Young 2008-05-19 10:54:17 EDT
Created attachment 305955 [details]
Patch to get cookies at the right place

This is an illustrative patch to fix the second problem. This might not be the
best way to do it (and might break other things), but with both patches (and an
additional hack to disable gdm on the local display) I can get a functioning
xdmcp /gdm server.
Comment 5 Jonathan Underwood 2008-06-08 18:12:34 EDT
William - any comment on the situation with this, this is a bit of a major
problem, breaking vnc sessions, ltsp, etc.
Comment 6 Miroslav Pragl 2008-06-26 09:03:40 EDT
Hello,
seems gdm simly DOESN'T DO XDMCP. I couldn't make it listen on 177/udp. Also
gdmsetup was deprecated to make works even harder.

I worked it around using kde as display manager (whi is it not kdm?) and gnome
as default desktop

Miroslav
Comment 9 Jonathan Underwood 2008-08-08 12:54:58 EDT
Ping William Jon Mcann? AWOL?
Comment 10 Jason Fenner 2008-09-18 15:24:49 EDT
Ping broadcast.

Can we get someone to take a look at this issue?  It would be nice to get XDMCP working in Fedora 9 again.
Comment 11 Fedora Update System 2008-09-23 14:48:16 EDT
gdm-2.22.0-9.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/gdm-2.22.0-9.fc9
Comment 12 Fedora Update System 2008-09-24 20:16:09 EDT
gdm-2.22.0-9.fc9 has been pushed to the Fedora 9 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/F9/FEDORA-2008-8279
Comment 13 Fedora Update System 2008-09-29 12:05:14 EDT
gdm-2.22.0-10.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/gdm-2.22.0-10.fc9
Comment 14 Fedora Update System 2008-10-01 02:32:53 EDT
gdm-2.22.0-10.fc9 has been pushed to the Fedora 9 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/F9/FEDORA-2008-8449
Comment 15 Phil Anderson 2008-10-01 02:40:49 EDT
XDCMP is working for me with 2.22.0.9-fc9.
Comment 16 Fedora Update System 2008-10-03 18:30:55 EDT
gdm-2.22.0-10.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 17 Dan Thurman 2008-12-22 16:43:24 EST
Running gdm-2.22.0-10.fc9, but not able to
get this to work - can someone tell me what
I need to do to get this working?

I have: /etc/gdm/custom.conf configured as:

# cat /etc/gdm/custom.conf 
# GDM configuration storage

[xdmcp]
Enable=true
Willing=/etc/gdm/Xwilling
Xaccess=/etc/gdm/Xaccess
Port=177

[chooser]

[security]

[debug]

... and I tried:

# nmap -sU -p 177

Starting Nmap 4.53 ( http://insecure.org ) at 2008-12-22 13:24 PST
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.098 seconds

Seems that a listener is not showing it....

Thanks!
Dan
Comment 18 Michael Young 2008-12-22 17:34:10 EST
That proves nothing. "0 hosts scanned" means you didn't scan anything, so it gives you no information on what might or might not be listening on that port. netstat -l will tell you what ports are listening.
Comment 19 Dan Thurman 2008-12-22 17:49:56 EST
Ok.... I guess that was my problem?

I tried what you said: netstat -l

[...]
udp        0      0 *:xdmcp                     *:*
[...]
tcp        0      0 *:vnc-1600x1200x32          *:*                         LISTEN      
tcp        0      0 *:vnc-1024x768x8            *:*                         LISTEN      
tcp        0      0 *:imaps                     *:*                         LISTEN      
tcp        0      0 *:vnc-1280x1024x8           *:*                         LISTEN      
tcp        0      0 *:vnc-1600x1200x8           *:*                         LISTEN      
tcp        0      0 *:pop3s                     *:*                         LISTEN      
tcp        0      0 *:vnc-640x480x16            *:*                         LISTEN      
tcp        0      0 *:vnc-800x600x16            *:*                         LISTEN      
tcp        0      0 *:rsync                     *:*                         LISTEN      
tcp        0      0 *:vnc-1024x768x16           *:*                         LISTEN      
tcp        0      0 *:netbios-ssn               *:*                         LISTEN      
tcp        0      0 *:vnc-1280x1024x16          *:*                         LISTEN      
tcp        0      0 *:vnc-1600x1200x16          *:*                         LISTEN      
tcp        0      0 *:pop3                      *:*                         LISTEN      
tcp        0      0 *:imap                      *:*                         LISTEN      
tcp        0      0 *:http                      *:*                         LISTEN      
tcp        0      0 *:vnc-640x480x24            *:*                         LISTEN      
tcp        0      0 *:vnc-800x600x24            *:*                         LISTEN      
tcp        0      0 *:vnc-1024x768x24           *:*                         LISTEN      
tcp        0      0 *:vnc-1280x1024x24          *:*                         LISTEN      
tcp        0      0 *:vnc-1600x1200x24          *:*                         LISTEN      
tcp        0      0 *:ssh                       *:*                         LISTEN      
tcp        0      0 *:https                     *:*                         LISTEN      
tcp        0      0 *:pcsync-https              *:*                         LISTEN      
tcp        0      0 *:vnc-640x480x32            *:*                         LISTEN      
tcp        0      0 *:microsoft-ds              *:*                         LISTEN      
tcp        0      0 *:vnc-800x600x32            *:*                         LISTEN      
tcp        0      0 *:vnc-1024x768x32           *:*                         LISTEN      
tcp        0      0 *:vnc-640x480x8             *:*                         LISTEN      
tcp        0      0 *:vnc-1280x1024x32          *:*                         LISTEN      
tcp        0      0 *:vnc-800x600x8             *:*                         LISTEN  

Does this mean it is active?

If so, then it seems that I cannot get my Vnc to connect
to this port - Vnc says that connection is being refused...

Is there another way to test/prove that XDMCP is being
served?

Thanks alot!
Dan
Comment 20 Dan Thurman 2008-12-22 18:01:23 EST
Uh, ok - I forgot the <hostname> when using nmap!

It works - so please forget everything I posted!

# nmap -sU -p 177 localhost

Starting Nmap 4.53 ( http://insecure.org ) at 2008-12-22 14:59 PST
Interesting ports on localhost.localdomain (127.0.0.1):
PORT    STATE         SERVICE
177/udp open|filtered xdmcp

Nmap done: 1 IP address (1 host up) scanned in 2.050 seconds

Dan