After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 627428 - XDMCP broken in version 2.30.5?
XDMCP broken in version 2.30.5?
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
2.30.x
Other Linux
: Normal major
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2010-08-19 20:59 UTC by José Alburquerque
Modified: 2011-03-14 17:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
My custom.conf file (271 bytes, text/plain)
2010-08-19 20:59 UTC, José Alburquerque
  Details
My inetd.conf file (502 bytes, text/plain)
2010-08-19 21:00 UTC, José Alburquerque
  Details
gdm debug output (242.92 KB, text/plain)
2010-08-22 22:05 UTC, José Alburquerque
  Details
Fix IPv6 XDMCP support (2.17 KB, patch)
2010-09-10 23:41 UTC, Josselin Mouette
none Details | Review

Description José Alburquerque 2010-08-19 20:59:03 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.
Comment 1 José Alburquerque 2010-08-19 21:00:38 UTC
Created attachment 168327 [details]
My inetd.conf file
Comment 2 Brian Cameron 2010-08-20 21:54:05 UTC
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.
Comment 3 José Alburquerque 2010-08-22 22:05:21 UTC
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.
Comment 4 Brian Cameron 2010-08-25 19:29:51 UTC
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?
Comment 5 Josselin Mouette 2010-09-06 12:03:23 UTC
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.
Comment 6 Josselin Mouette 2010-09-10 23:41:20 UTC
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
Comment 7 José Alburquerque 2010-09-12 03:18:00 UTC
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?
Comment 8 Brian Cameron 2010-09-13 18:37:19 UTC
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.
Comment 9 Josselin Mouette 2010-09-13 18:56:49 UTC
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.
Comment 10 Ray Strode [halfline] 2010-09-13 19:51:51 UTC
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.
Comment 11 Josselin Mouette 2010-09-13 20:26:03 UTC
The ::ffff: issue in gdm-address.c still needs to be addressed, though.
Comment 12 Tristan Schmelcher 2010-11-01 21:30:56 UTC
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.)
Comment 13 José Alburquerque 2010-11-01 21:54:40 UTC
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.
Comment 14 Tristan Schmelcher 2011-01-17 20:59:47 UTC
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.
Comment 15 Tristan Schmelcher 2011-03-12 22:05:40 UTC
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.
Comment 16 José Alburquerque 2011-03-13 20:23:33 UTC
I can confirm that the bug is gone in ubuntu natty (11.04) with the latest packages as of today.
Comment 17 Ray Strode [halfline] 2011-03-14 17:33:06 UTC
yea we fixed this a while ago, I think.  Latest relevant commit is 13bf767bfbdeca3850874b1ef9fea9bb59ebc551