gdm's XDMCP server is broken in maverick

Bug #669670 reported by Tristan Schmelcher on 2010-11-01
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Fix Released
gdm (Ubuntu)

Bug Description

Binary package hint: gdm

After upgrading one of my machines from Lucid to Maverick, I am no longer able to log in to it via XDMCP from other machines. I have an appropriate /etc/gdm/custom.conf file to enable XDMCP which worked fine in Lucid, but now when I try to connect to this machine with XDMCP via Xvnc I get a broken X desktop with the classic X-style cursor and nothing running. I am attaching a syslog snippet taken with debug/Enable=true in GDM which shows that GDM is stuck in a loop trying to negotiate the session and is failing each time.

I investigated extensively and discovered that this issue is already known upstream and they already have a patch that partially fixes the issue, though it isn't committed yet and apparently more is needed to get the server-side XDMCP support working again.

Please work with upstream to resolve the problem and get any necessary patches into the gdm package in Maverick. I rely on XDMCP login a lot and it needs to work before I can upgrade any of my other machines from Lucid to Maverick.

(Just in case it isn't already clear from the above, please note that this issue is unrelated to the removal of the XDMCP chooser feature used by thin clients, which I don't care about.)

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: gdm 2.30.5-0ubuntu4
ProcVersionSignature: Ubuntu 2.6.35-22.35-generic
Uname: Linux 2.6.35-22-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Mon Nov 1 14:43:47 2010
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
SourcePackage: gdm

Changed in gdm:
importance: Unknown → High
status: Unknown → Fix Released
Sebastien Bacher (seb128) wrote :
Changed in gdm (Ubuntu):
importance: Undecided → Low
status: New → Fix Committed

As I stated on the upstream bug report, that commit doesn't fully fix the issue.

jak (jasonlife) wrote :

I got the exact same XDMCP problem on Lucid when I set my system as an XDMCP server. Interestingly enough, this problem only happens on 32bit system.

I got hints from the Comment #3, and the attached patch fixed the problem on my 32bit Lucid system.

Please resolve this issue on Lucid too.

Weird. It probably worked on 64-bit because of a coincidence of the stack layout.

The problem definitely got worse in gdm 2.30.5 though because it's broken on 64-bit too and that patch doesn't fix the problem. (As noted in the upstream bug report, there's an issue with an invalid ::ffff: in the DISPLAY environment variable and the greeter UI isn't working properly.) The upstream developers re-opened the bug today so hopefully they're going to investigate.

Changed in gdm (Ubuntu):
status: Fix Committed → Triaged
jak (jasonlife) wrote :

Since there is an issue with "invalid ::ffff: in the DISPLAY environment variable", will XDMCP on gdm-2.30.5 work if I disable ipv6? I couldn't test this yet because I don't have a Maverick system..

My understanding from reading the upstream bug and the Debian bug was that --enable-ipv6=no worked around the first two issues (the ss_len problem and the ::ffff: problem), but I would imagine that it probably doesn't fix the busted greeter UI. I didn't check that though.

Changed in gdm:
status: Fix Released → New
tags: added: patch
Paul Tagliamonte (paultag) wrote :

Linking Debian bug report. This was linked to in the GNOME bug tracker.

This bug was processed DONE on Fri, 17 Sep 2010 22:18:58 +0000

FYI, the bug is not actually fixed in Debian yet either. They have patched their package with the fix for the ss_len issue (committed upstream as and with the fix for the ::ffff: (not yet committed upstream), but the broken greeter issue remains. (I confirmed this by installing the Debian gdm3 package on Ubuntu Maverick.)

Paul Tagliamonte (paultag) wrote :

Agreed, just linking it so that everyone's on the same page.

cando (cando0815-googlemail) wrote :


Is there a solution for this issue around?

I try to use xdmcp connection via xnest on maverick and get errrors regarding ipv6

_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/GAP001:1
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
XDMCP warning: INET6 UDP socket creation failed
[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!

I have no ipv6 support on any machine enabled (boot option ipv6.disable=1).

However on lucid targets i can connect via xnest / xdmcp, on maveick it does not work at all.

is there a way to force xnest to use only ipv4?

@cando The errors you posted do not resemble this bug. It sounds like your problem is with the maverick Xnest _clients_, whereas this bug is specifically about the maverick gdm _servers_. Please open a separate bug for your issue.

Sebastien Bacher (seb128) wrote :

the issue should be fixed in natty now

Changed in gdm (Ubuntu):
status: Triaged → Fix Released

Verified fixed in Natty Alpha 3 amd64 LiveCD using Xephyr login. Thanks!

Changed in gdm:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.