Bug 446224 - xdmcp broken in gdm
Summary: xdmcp broken in gdm
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: jmccann
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-13 15:43 UTC by Michael Young
Modified: 2015-01-14 23:21 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-03 22:31:01 UTC
Type: ---


Attachments (Terms of Use)
Illustrative patch (547 bytes, patch)
2008-05-13 15:43 UTC, Michael Young
no flags Details | Diff
gdm debug output (5.63 KB, patch)
2008-05-16 14:27 UTC, Michael Young
no flags Details | Diff
Patch to get cookies at the right place (1.21 KB, patch)
2008-05-19 14:54 UTC, Michael Young
no flags Details | Diff

Description Michael Young 2008-05-13 15:43:52 UTC
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 15:43:52 UTC
Created attachment 305245 [details]
Illustrative patch

Comment 2 Michael Young 2008-05-16 14:27:40 UTC
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 16:48:35 UTC
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 14:54:17 UTC
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 22:12:34 UTC
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 13:03:40 UTC
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 16:54:58 UTC
Ping William Jon Mcann? AWOL?

Comment 10 Jason Fenner 2008-09-18 19:24:49 UTC
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 18:48:16 UTC
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-25 00:16:09 UTC
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 16:05:14 UTC
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 06:32:53 UTC
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 06:40:49 UTC
XDCMP is working for me with 2.22.0.9-fc9.

Comment 16 Fedora Update System 2008-10-03 22:30:55 UTC
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 21:43:24 UTC
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 22:34:10 UTC
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 22:49:56 UTC
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 23:01:23 UTC
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


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