GNOME Bugzilla – Bug 627428
XDMCP broken in version 2.30.5?
Last modified: 2011-03-14 17:33:06 UTC
Created attachment 168326 [details] My custom.conf file Hi. I use Xvnc through inetd which uses XDMCP to query the localhost so that logging in through gdm from an external host is possible. This was working just fine before my most recent upgrade from 2.30.2 to 2.30.5 (I'm running ubuntu maverick). I'm attaching the custom.conf file and my inetd.conf file (in case this helps debugging). Thanks.
Created attachment 168327 [details] My inetd.conf file
Could you turn on GDM debugging by editing /etc/gdm/custom.conf, and adding a line that says "Enable=true" after the line that says "[debug]" so it looks like this: [debug] Enable=true Then restart GDM (or reboot), and try to connect via XDMCP. Immediately after this fails, review the debug messages in your syslog file (/var/log/messages or /var/adm/messages depending on your system). Share the debug messages with us as an attachment in this bug report if the issue isn't clear. Sometimes people have XDMCP problems if there are firewall issues, but this is probably not your issue if it started to fail only after updating to the new GDM. Note GDM also uses libwrap for XDMCP control, so any change there could also affect XDMCP availability. Lastly, you might want to verify that the Xserver isn't being started with "--nolisten tcp", which can cause problems for XDMCP. It is also good to check the Xorg log files in /var/log just to verify that the problem isn't caused by an Xserver issue.
Created attachment 168526 [details] gdm debug output Hi Brian. It's hard for me to make much of the debugging output so I'm attaching it. I made two attempts to connect via XDMCP (by running `xvncviewer localhost:7000' in my gnome session) and waited. All that appeared was the black and white X screen so I closed the xvncviewer window (normally gdm comes up in the window). I hope the debugging output provides some useful information. I gathered the debugging output by running `cat /var/log/syslog | grep "DEBUG"'. I hope it provides all the needed information.
Looking at the log I can see that the GDM XDMCP server is receiving QUERY messages and sending WILLING messages, but the connection doesn't seem to happen. This could happen if the routing between the machines isn't set up properly or if you have a firewall causing the WILLING signal to get lost on the way. But that shouldn't be the problem if you are connecting via localhost. Could you check on the client and server machine and log at the log files in these directories and see if there are any error or warning messages that might highlight the problem: - the logs in /var/log/gdm. - the Xorg logs in /var/log. Is the Xserver failing to start, for example?
Looks like yet another IPv6 issue, from the logs of http://bugs.debian.org/579033 - especially the claim that rebuilding with --enable-ipv6=no works.
Created attachment 169998 [details] [review] Fix IPv6 XDMCP support This patch from Julien Cristau and myself brings back XDMCP functionality with --enable-ipv6=true. There were 2 bugs actually: - gdm_sockaddr_len being called with an unitialized structure - DISPLAY=::ffff:a.b.c.d not working, you need to strip the ::ffff: part
I can confirm that the patch makes XDMCP work again allowing remote logins using Xvnc to query gdm through inetd. However, now the greeter for the remote session gets stuck on this system only showing the computer name, but not showing any buttons, etc. for logging in. This was happening also with the older version of gdm I was using to workaround this bug but did not report it because I thought the older version was outdated and incompatible with newer packages installed on the system. I suppose this would be a separate issue. Right?
Note that gdm_sockaddr_len is a macro in common/gdm-address.h, defined as follows: #define gdm_sockaddr_len(sa) ((sa)->ss_family == AF_INET6 ? sizeof(struct sockaddr_in6) : sizeof(struct sockaddr_in)) The proposed patch makes this change: - ss_len = (int)gdm_sockaddr_len (&clnt_ss); + ss_len = sizeof (clnt_ss); Note that clnt_ss is defined to be a "struct sockaddr_storage". Any ideas why the gdm_sockaddr_len macro isn't working on your architecture? There are other distros (such as FreeBSD) which require gdm_sockaddr_len to be a macro like this because the size of the structure can be different and on FreeBSD, it doesn't work unless you use the right size. Perhaps this code should be reworked a different way? The changes tgo common/gdm-address.c look reasonable to me and I think that change should go into git master and the 2.30 branch. I think we should discuss how to deal with the gdm_sockaddr_len macro more though.
Calling gdm_sockaddr_len on an uninitialized structure doesn’t work on any architecture. In this case, sa->ss_family being unitialized is not AF_INET6, so the macro returns the size of an IPv4 structure. This leads to garbage instead of the address. According to Julien, the only thing that is required for the length passed to XdmcpFill is that the buffer is lengthy enough. Which is why sizeof(clnt_ss) is appropriate.
We actually fixed this recently: http://git.gnome.org/browse/gdm/commit/?id=832d49174f86782b7e2b994e86357582c9d69ed6 I'm going to close this one out, but please reopen if the problem persists in gdm 2.32 We could potentially cherry-pick the patch to 2.30 if that would be useful.
The ::ffff: issue in gdm-address.c still needs to be addressed, though.
Please re-open this bug, it isn't fully fixed by the commit that Ray mentioned. Josselin's change to strip ::ffff: still needs to be committed. Furthermore, I can confirm Jose's comment from 2010-09-12 that the greeter doesn't work properly in the XDMCP sessions even with Josselin's patch. There are no buttons anywhere in the UI and no users in the user list. (Like Jose, I'm also using Ubuntu Maverick.)
The buttons, etc. not showing makes gdm entirely unusable for remote access. I've had to resort to use kdm. It'd be nice if there was a fix for these issues.
Is anyone looking into this? It would be great if this could be fixed for the next GNOME release. If anyone has ideas on where to start investigating the broken greeter issue then I could volunteer some time to try and track down the problem.
FYI, this bug no longer occurs in Ubuntu Natty Alpha 3 (gdm package version 2.32.0-0ubuntu9), so probably this was fixed in GNOME 2.32, unless Ubuntu is shipping a patch for this. Sebastien Bacher notified me that it was fixed in Natty at https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/669670 so if it's not working then contact him for their patch.
I can confirm that the bug is gone in ubuntu natty (11.04) with the latest packages as of today.
yea we fixed this a while ago, I think. Latest relevant commit is 13bf767bfbdeca3850874b1ef9fea9bb59ebc551