Remote Login via XDMCP is not working

Bug #150193 reported by Mahmoud Kassem
144
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gdm
Fix Released
Medium
gdm (Baltix)
Invalid
Undecided
Unassigned
gdm (Ubuntu)
Invalid
High
Ubuntu Desktop Bugs
Gutsy
Won't Fix
High
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gdm

XDMCP is not working.
I have 2 Gusty desktops on the same network with no firewall settings, one has XDMCP enabled.
" When I try to connect to it, I see a "dead" X screen (with the X cursor in the middle) for a split second, then I'm return to my local login screen. "

http://ubuntuforums.org/showthread.php?p=3490207

** The GDM starts without problems while XDMCP is enabled ,but the XDMCP connection does not work as explained above.

Steps to Reproduce:
1. Enable Remote Login on PC1 running Ubuntu Gusty/7.10 from Administration > Login Window > Remote with Style same as Login
2. Reboot PC1 to complete enabling the Remote Login.
3. From another PC (PC2) running Ubuntu Gusty/7.10, use Options > Remote Login via XDMCP from the Login Screen
4. PC1 appears on the list, connect to it

Result:
I see a "dead" X screen (with the X cursor in the middle) for a split second, then I'm returned to my local login screen.
Or If I was using the switch user option, I'm returned to the lock screen window asking for my local login password.

Related branches

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

Changed in gdm:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Invalid
Revision history for this message
K. Lange (k-lange) wrote :

I'm not entirely sure they're the same bug. The problem here is when trying to login to a remote computer, GDM doesn't start. The bug you say this is a duplicate of is GDM not starting when XDMCP is enabled on the local computer, the exact opposite of this.

Revision history for this message
Mahmoud Kassem (mmkassem) wrote :

After reading bug #118193, I think they are not the same bug too. As KevinLange said, this bug occurs while GDM is already started.

Revision history for this message
Mahmoud Kassem (mmkassem) wrote :

Changing back to New since this bug is not the same as bug #118193

Changed in gdm:
status: Invalid → New
description: updated
description: updated
Revision history for this message
K. Lange (k-lange) wrote : Re: Remote Login via XDMCP is not working in Ubuntu Gusty/7.10

My remote server has the following in its syslog:
gdm_slave_xioerror_handler: Fatal X error

Revision history for this message
K. Lange (k-lange) wrote :

I think we have enough evidence to show that there is a bug. Switch to "confirmed"?

Changed in gdm:
status: New → Confirmed
Revision history for this message
Steve Jackson (aearenda) wrote :

I have come across this too, I believe. However, setting the remote greeter to 'plain with facebrowser' instead of 'same as local' works around the issue.

Revision history for this message
Steve Jackson (aearenda) wrote :

Cannot replicate my workaround on a different remote system, same local system. May be a red herring.

Revision history for this message
CassieMoondust (cassie-lx) wrote :

XDMCP do not work for me too. Al works fine, but if I try to connect from another Machine (Cygwin,Xming, Feisty or Gutsy) the screen goes black and i see the gdm loginscreen again. In Feisty it works. In Gutsy don't. SSH etc. works fine.

Revision history for this message
Nick McGill (nick-mcgill) wrote :

I don't know whether this helps, but it seems to be a problem with the 7.10 remote login.
I set up 2 machines, 1 Feisty, and one Gutsy. The fiesty machine can login to Gutsy and Feisty systems, but the Gutsy machine cannot connect to any remote systems with XDMCP.

This happens with Ubuntu and Xubuntu (I haven't tested Kubuntu).

These machines are still 'vanilla', so if I ca be of any assistance, please let me know.

Nick

Revision history for this message
CassieMoondust (cassie-lx) wrote :

Yes, my gusty machine cannont connect to the feisty machine and from another machines with Feisty or Cygwin installed I can connect to them. But it works about two or three weeks ago during the beta test. After an update it loose it's funktionality and I do not know why.
Gutsy as a XDMCP- "server" do not work, but it can still be seen in the xdmcp chooser from any machine, but login does not work for me.

Revision history for this message
Steve Jackson (aearenda) wrote :

Force-downgrading gdm to the version as at gutsy beta (2.20.0-0ubuntu2) fixes the remote end for me - I can connect to it with other systems; but it does not fix the client end (I still can't use XDMCP to connect out from Gutsy).

Revision history for this message
Marco A L Barbosa (malbarbo) wrote :

Why importance is Low?

I have two computers in home, the old one connect to the new one with xdmcp.
I upgraded the two computers to gutsy and cannot use the old one anymore.

My systems was working, but now are not. This is bad.

Revision history for this message
CassieMoondust (cassie-lx) wrote :

Think this bug is higher than low. We want to connect several old machines based on win/cygwin and ubuntu to one server in an office environment. But with gutsy this does not work. I WIll try this downgrading thing. Hope this bug will be fixed soon for us, i think xdmcp is an essential feature of linux!

Revision history for this message
Nick McGill (nick-mcgill) wrote :

I agree that this is an important feature, so its status shpuld reflect that.

What is worrying is that the functionality has not been removed, but has been broken!

Revision history for this message
Sebastien Bacher (seb128) wrote :

What difference will a status change do? This bug should rather be sent upstream or worked by somebody getting the issue, there is ten of thousand of bugs and limited ressources working on those that's why it takes time to reply on bugs, not because the settings are not correct

Revision history for this message
Stefano Angeleri (weltall) wrote :

Same problem here. I can connect to whathever host i want with the feisty pc (even to the gutsy one), but there is no way to connect to whathever from the gutsy pc (i can't connect even to feisty and fedora). i still can see the hosts fine but trying to connect to the makes the nvidia logo shown and then gdm crashes entirely or just returns to the normal login window. i can use fine from the same computer other solutions like xnest.
The Steve's workaround worked for me to connect to the gutsy machine from the feisty one

Revision history for this message
Grizzly (sven-witterstein) wrote : Duplicate, if error message ist the same

[Bug #148474] mentions an error message, so this bug is a dupe i should say.
However, I also have the problem. Whereas LinuxTSC works fine under XP, but kills the Applets and Keyboard Layout when connecting to an x64-Arch server
It is hateful to have this feature broken but it definitely is broken.

Could you please all look if you have this in /var/log/syslog:
Oct 3 11:02:10 Id2ndR-SFF gdmchooser[6424]: GLib-GObject-WARNING: /build/buildd/glib2.0-2.14.1/gobject/gsignal.c:1019: unable to lookup signal "activate" of unloaded type `GtkMenuItem'

Revision history for this message
Grizzly (sven-witterstein) wrote : Might have to do with visual effects

I researched why my applets broke when logging in with LinuxTSC. Big difference between local display on the machine and remeotely accessing is:
Local, "Visual effects" and "Wobbly Windows" are activated.
I found out that then you cannot name your desktops in the desktop chooser, only after disabling.
It might be worth trying to disable all visual effects on the machine locally, then trying to xdmcp to it.

Revision history for this message
Steve Jackson (aearenda) wrote : Re: Remote Login via XDMCP is not working in Ubuntu Gusty/7.10

I do have the messages in /var/log/syslog that Grizzly mentioned, on the local machine, if I use a local Gutsy to try to connect to remote Gutsy with XDMCP from the GDM login screen (it always works using Xnest on the local machine instead of GDM).

On reflection I believe this bug has been discussing two issues which are often encountered together, but which may be unrelated:
1. Gutsy's inability to be connected inwards to using XDMCP from GDM on other machines, regardless of the version on the connecting machine - this is worked-around by reverting gdm on Gutsy to 2.20.0-0ubuntu2.
2. Gutsy's inability to connect outwards using XDMCP from GDM to other machines, regardless of version of the other machine. This is not fixed by reverting gdm to 2.20.0-0ubuntu2.

One or both of these may be duplicated in Bug #148474 (BTW, how do I insert a link to that bug? It isn't obvious to me.)

I have no wobbly windows or other effects in use.

Revision history for this message
Nick McGill (nick-mcgill) wrote :

I also have Grizzly's error message.

I have no video effects enabled (video cardds are not upt to it!)

Revision history for this message
CassieMoondust (cassie-lx) wrote :

I don't know why, but scince yesterday it works on my home machine. I can connect from another machine (windowsxp with xming) to my gutsy gibbon. And locally wiht Xnest :1 -query 127.0.0.1 works to. In booth cases i had the ugly empty grey x-window with the x-cursor, now i see the login screen. At work it does not work, but i don't know why this is the case, booth machines have the same updates and the same settings...perhaps i have installed a package that brings me the funktionality for xdmcp?
I'm a little confused...

Revision history for this message
Steve Jackson (aearenda) wrote :

Xnest has always worked for me, both from other systems and from Gutsy systems - it is broken when connecting by selecting XDMCP from the GDM screen, rather than a nested session. It seems to me that during connection establishment, the remote Gutsy GDM now sends a response that the local GDM (no matter what version) cannot handle, but a local Xnest can (this is avoided by downgrading GDM as above). This is further confused by Gutsy as local GDM failing to connect to other remote systems that previous versions can connect to (which is not so avoided).

Revision history for this message
Andrés Rassol (anra) wrote :

I have the same problem trying to login from Feisty to Gutsy.

Revision history for this message
Israel Benítez Esquivel (israelbz) wrote :

I have the same problem, and partialy solved:

1. GDM greeter must be plain.

2. I need execute metacity from a command line because it don't start when the session starts.

I'been tried to find more data, but I couldn't find in any log.

Revision history for this message
Id2ndR (id2ndr) wrote :

I can confirm that it works using tsclient on localhost (that use Xnest). I just have a keyboard layout trouble but that not the trouble of this bug.

Revision history for this message
Nick McGill (nick-mcgill) wrote :

This seems to be a problem with gdm

I installed kdm on my gutsy machine and was then able to connect to a remote (feisty) machine running gdm.

I have not yet been able to test whether I can connect from to a guty machine using this setup.

Revision history for this message
hd (hd-dyballa) wrote :

I use 14 thin clients to login via XDMCP on feisty. Since the update yesterday 12 of them get an login screen and work, 2 not, also cygwin connect fails. The login screen starts , you can see just the cursor, and then restarts. Feisty was working very well with all clients ( even cygwin ).

Revision history for this message
Chocwise (chocwise) wrote :

I'm just here to confirm this bug. On the remote machine I've Dapper Server Edition installed. On the local machine Gutsy upgraded from Feisty. Since the Upgrade XDMCP doesn't work anymore.

Grizzly asked for that row out of the syslog. I have it as well after trying to connect via XDMCP:
chocwise@asgard:~$ cat /var/log/syslog | grep gobject/gsig
Oct 26 02:47:33 asgard gdmchooser[29214]: GLib-GObject-WARNING: /build/buildd/glib2.0-2.14.1/gobject/gsignal.c:1019: unable to lookup signal "activate" of unloaded type `GtkMenuItem'

Would be happy to see it fixed soon. I love that feature.

Revision history for this message
Michał Straszak (mstraszak) wrote :

From what I saw from strace output, one of gdm child-processes ends with SIGSEGV signal. I don't know exactly at which point (it was after sending GDM_LOCAL_GET_NEXT or something like this, I can't check now), I don't know how to use gdb with multiprocess applications, nor how to force gdm to generate corefile - can anyone give some hint here?
Anyway, I'll keep investigating.

Revision history for this message
Jonas Eberle (jonas-eberle) wrote :

I have the same bug. Gutsy (GDM) tries to XDMCP to Gutsy. See the relevant /var/log/syslog messages on the client side attached. The server side does not log anything to /var/log/syslog. Changing to "simple" ("einfach" in german) interface has no effect. BTW, I use the "fglrx" driver.
This is a bad thing, graphical remote login is an essential feature on Linux desktops. I would like to help out if I can do anything.

Revision history for this message
Jonas Eberle (jonas-eberle) wrote :

here comes the syslog when "debug output" is enabled. this time from the other machine, not running on "fglrx".
Please take this bug serious.

Revision history for this message
K (kkumar) wrote :

I too end up with this issue. but I can see a error message on my laptop screen when I tried to login from my laptop into desktop.

Quote:
There already appears to be an X server running on display :1. Should another display number tried? Answering no will cause GDM to attempt starting the server on :1 again. (You can change console by pressing Ctrl-Alt plus a function key, such as Ctrl-Atl-F7 to go to console 7. X servers usually run on consoles 7 and higher.

After pressing 'yes' there is a popup box saying ..

Quote:
The specified display number was busy, so this server was started on display :2.

after that it returned to normal local login screen where i can login to my laptop.

Revision history for this message
CassieMoondust (cassie-lx) wrote :

I have installed Gutsy 7.10 to our server and XDMCP ist NOT working. in /etc/gdm/gdmconfig-custom ist XDMCP enabled, but with Xnest :1 -query 127.0.0.1 i get only a gray checked window with the xcursor inside. On my home-machine it works! But if I compare the booth config-files there is no difference and installed are the same packages of gdmon booth machines! I am very confused. We need this functionality for our Terminalclients.

Revision history for this message
Israel Benítez Esquivel (israelbz) wrote : Re: [Bug 150193] Re: Remote Login via XDMCP is not working in Ubuntu Gusty/7.10

¿the X server is accepting TCP conections?

Check the DisallowTCP parameter in section [security], it must be false:

DisallowTCP=false

El mié, 07-11-2007 a las 22:10 +0000, Papamatti escribió:
> I have installed Gutsy 7.10 to our server and XDMCP ist NOT working. in
> /etc/gdm/gdmconfig-custom ist XDMCP enabled, but with Xnest :1 -query
> 127.0.0.1 i get only a gray checked window with the xcursor inside. On
> my home-machine it works! But if I compare the booth config-files there
> is no difference and installed are the same packages of gdmon booth
> machines! I am very confused. We need this functionality for our
> Terminalclients.
>

Revision history for this message
Id2ndR (id-2ndr) wrote :

The trouble should be at client side. Server configuration is OK since
tsclient allow to connect to.

Revision history for this message
hd (hd-dyballa) wrote : Re: Remote Login via XDMCP is not working in Ubuntu Gusty/7.10

on my PC at home XDMCP with gdm is not working, XDMCP with kdm does, both with cygwon or Igel Thinclient.
At school we need gdm. With 12 Igelclients it is working, 2 can't login, first the gray window appears and then you
can see for a short moment the start of gdm, and this behavior repeats, also with cygwin. All Igelclients have the
same configuration. I need gdm working as soon as possible.

Revision history for this message
robsyd (robsydemail) wrote :

I don't understand why the importance of this bug is kept low.
The separation between the GUI and the kernel is one of the most important difference between Linux and Windows.
This bug is very serious, mainly In the education environment, where many clients often refers to one server.
I guess the education environment should be considered a strategical target by developers.

Revision history for this message
Haulbag (tim-ideadynamics) wrote :

I'm connecting to a Gutsy remote from a Debian Sid gdm client. It kept crashing, like everyone mentioned above, but I followed Steve's advice to "setting the remote greeter to 'plain with facebrowser' instead of 'same as local' " and followed Israel's advice to change DisallowTCP=false in the gdm.conf file, and everything works now. I tried just changing DisallowTCP=false, but that didn't solve anything. I don't know if it really did anything at all (I was too lazy to change it back), and it was probably Steve's solution that fixed it.

If this workaround fixes things for people, I would agree that this is a low priority. You can still have a background picture if you set it as the Logo file if you need a pretty login screen.

Revision history for this message
Gustavo Rahal (gustavo-grahal) wrote :

Yeah, really seems a problem on the client
from a gutsy machine to a gutsy machine
X :1 -query <hostname_of_gutsy_machine_running_gdm>

Works fine...

Changed in gdm:
importance: Low → High
status: Confirmed → Triaged
Changed in gdm:
status: Unknown → Fix Released
Changed in gdm:
status: Triaged → Fix Released
Changed in gdm:
assignee: nobody → desktop-bugs
importance: Undecided → High
status: New → Confirmed
Martin Pitt (pitti)
Changed in gdm:
status: Confirmed → Fix Committed
66 comments hidden view all 146 comments
Revision history for this message
Hendy Irawan (ceefour) wrote :

Sebastien:

$ gdm --version
GDM 2.20.1

"sudo X :1 -query xx" works, but unfortunately it's a very rough workaround.

Revision history for this message
Sebastien Bacher (seb128) wrote :

could you rather use dpkg -l gdm, your command doesn't list the revision

Revision history for this message
Hendy Irawan (ceefour) wrote :

Sebastien:

Seems to be: 2.20.1-0ubuntu1

$ dpkg -l gdm
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii gdm 2.20.1-0ubuntu GNOME Display Manager

$ aptitude show gdm
Package: gdm
New: yes
State: installed
Automatically installed: no
Version: 2.20.1-0ubuntu1
Priority: optional
Section: gnome
Maintainer: Ubuntu Desktop Team <email address hidden>
Uncompressed Size: 15.8M
Depends: libart-2.0-2 (>= 2.3.18), libatk1.0-0 (>= 1.13.2), libattr1 (>=
         2.4.4-1), libc6 (>= 2.6-1), libcairo2 (>= 1.4.0), libdbus-1-3 (>=
         1.1.1), libdbus-glib-1-2 (>= 0.74), libdmx1, libfontconfig1 (>= 2.4.0),
         libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.14.0), libgnomecanvas2-0
         (>= 2.11.1), libgtk2.0-0 (>= 2.12.0), libpam0g (>= 0.99.7.1),
         libpango1.0-0 (>= 1.18.3), librsvg2-2 (>= 2.18.1), libselinux1 (>=
         2.0.15), libwrap0, libx11-6, libxau6, libxcomposite1 (>= 1:0.3-1),
         libxcursor1 (> 1.1.2), libxdamage1 (>= 1:1.1), libxdmcp6, libxext6,
         libxfixes3 (>= 1:4.0.1), libxi6, libxinerama1, libxml2 (>= 2.6.29),
         libxrandr2 (>= 2:1.2.0), libxrender1, debconf (>= 0.5) | debconf-2.0,
         adduser, libpam-modules (>= 0.72-1), libpam-runtime (>= 0.76-13.1),
         gnome-session | xterm | x-window-manager | x-terminal-emulator,
         xbase-clients, alsa-utils, gksu (>= 1.0.7), lsb-base (>= 3.0-10),
         librsvg2-common, kbd | console-tools
Recommends: whiptail | dialog, zenity, gdm-themes, xserver-xephyr | xnest,
            ubuntu-artwork | edubuntu-artwork | xubuntu-default-settings,
            ubuntu-sounds, libpam-gnome-keyring
Suggests: locales, hibernate
Breaks: gnome-session (<= 2.17.91-0ubuntu1), gnome-screensaver (<=
        2.17.7-0ubuntu2), fast-user-switch-applet (<= 2.17.3-0ubuntu1),
        powermanagement-interface (<= 0.3.11)
Provides: x-display-manager
Description: GNOME Display Manager
 gdm provides the equivalent of a "login:" prompt for X displays- it pops up a
 login window and starts an X session.

 It provides all the functionality of xdm, including XDMCP support for managing
 remote displays.

 The greeting window is written using the GNOME libraries and hence looks like a
 GNOME application- even to the extent of supporting themes! By default, the
 greeter is run as an unprivileged user for security.

PS: I apologize for addressing you before as "Sebastian".

Revision history for this message
Sebastien Bacher (seb128) wrote :

you don't have the gutsy-proposed version which has the patch, could you try with this one? Don't worry about the name mispelling, that's a common one ;-)

Revision history for this message
Hendy Irawan (ceefour) wrote :

Now using this version on both client and server (both Gutsy):

$ aptitude show gdm
Package: gdm
New: yes
State: unpacked
Automatically installed: no
Version: 2.20.1-0ubuntu2
Priority: optional
Section: gnome
Maintainer: Ubuntu Desktop Team <email address hidden>
Uncompressed Size: 15.8M
Depends: libart-2.0-2 (>= 2.3.18), libatk1.0-0 (>= 1.13.2), libattr1 (>=
         2.4.4-1), libc6 (>= 2.6-1), libcairo2 (>= 1.4.0), libdbus-1-3 (>=
         1.1.1), libdbus-glib-1-2 (>= 0.74), libdmx1, libfontconfig1 (>= 2.4.0),
         libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.14.0), libgnomecanvas2-0
         (>= 2.11.1), libgtk2.0-0 (>= 2.12.0), libpam0g (>= 0.99.7.1),
         libpango1.0-0 (>= 1.18.3), librsvg2-2 (>= 2.18.1), libselinux1 (>=
         2.0.15), libwrap0, libx11-6, libxau6, libxcomposite1 (>= 1:0.3-1),
         libxcursor1 (> 1.1.2), libxdamage1 (>= 1:1.1), libxdmcp6, libxext6,
         libxfixes3 (>= 1:4.0.1), libxi6, libxinerama1, libxml2 (>= 2.6.29),
         libxrandr2 (>= 2:1.2.0), libxrender1, debconf (>= 0.5) | debconf-2.0,
         adduser, libpam-modules (>= 0.72-1), libpam-runtime (>= 0.76-13.1),
         gnome-session | xterm | x-window-manager | x-terminal-emulator,
         xbase-clients, alsa-utils, gksu (>= 1.0.7), lsb-base (>= 3.0-10),
         librsvg2-common, kbd | console-tools
Recommends: whiptail | dialog, zenity, gdm-themes, xserver-xephyr | xnest,
            ubuntu-artwork | edubuntu-artwork | xubuntu-default-settings,
            ubuntu-sounds, libpam-gnome-keyring
Suggests: locales, hibernate
Breaks: gnome-session (<= 2.17.91-0ubuntu1), gnome-screensaver (<=
        2.17.7-0ubuntu2), fast-user-switch-applet (<= 2.17.3-0ubuntu1),
        powermanagement-interface (<= 0.3.11)
Provides: x-display-manager
Description: GNOME Display Manager
 gdm provides the equivalent of a "login:" prompt for X displays- it pops up a
 login window and starts an X session.

 It provides all the functionality of xdm, including XDMCP support for managing
 remote displays.

 The greeting window is written using the GNOME libraries and hence looks like a
 GNOME application- even to the extent of supporting themes! By default, the
 greeter is run as an unprivileged user for security.

---
Nothing is improved, same issue. Using plain face browser for remote logins, doesn't work.

sudo X :1 thingy works, but it's a workaround not a fix.

Revision history for this message
Alexandre Racine (alexandreracine) wrote :

Hendy, try the simple mode.

More details: On your remote machine, go in system - admin - connection Window (this is a translation, I don't know the correct terms in English), choose remote and then you have 3 choices. Deactivated, identical to local connection, or simple. Use the simple one.

Revision history for this message
Alexandre Racine (alexandreracine) wrote :

Follow up. The weird part.

So I reinstalled my old machine with gutsy (7.10) and I could connect from my new machine gutsy with terminal server and xnest in XDMCP mode.. I put the old machine in a closet ;) and connect to it and it work, do some things and poof. It's gone. Can't connect to it anymore with XDMCP. It does work with ssh -X -Y and I can run some graphical apps with this.

So I search the web, try those two patch (32bit and 64bit) and try it again. Does not work again. I switch to the simple mode type on the remote machine and it works. Just like that.

Can some confirm that this is actually happening? Simple mode works and "same has local" does not work? Should I open a new bug report or this is the same? Thanks

Revision history for this message
Harry Sufehmi (harry-sufehmi) wrote :

Just to confirm that setting remote login to plain in gdm made LTSP 4.x works in Gutsy.

Also this issue needs to be given a higher priority.
A case study : I have had cases where LTSP5 doesn't work because the workstations are of lower spec. LTSP 4.x works just fine in these cases.

But with this problem, I can't deploy Gutsy as its server (nor Hardy it seems for now)
I can workaround it, indeed, but this has been confirmed to work only on plain Gutsy installation (eg: no updates installed yet). I don't know yet whether it will continue to work after you updated it.

Another thing, it seems that gdm 2.20.2 will bring this issue back.
RedHat has managed to fix it on their gdm 2.20.1 package, but the problem returned when they released gdm 2.20.2
Please be careful not to repeat their mistake.
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=379511

Thanks for the discussions so far, keep it coming guys.

Thank you.

Revision history for this message
Richard Seguin (sectech) wrote :

Confirmed as working on hardy beta PROVIDING you manually make the change in gdm.conf

Revision history for this message
Meethoss (steve-thepicketts) wrote :

I installed the patch on my server to update GDM (http://exportdriver.com/gdm_2.20.1-0ubuntu2_i386.deb) after having already enabled XDMCP and the Remote Greeter. I then installed xnest on both server and client and rebooted both machines. I can connect using sudo X :1 -query xxx.xxx.xxx.xxx but still cannot connect from the login screen. I'm not sure if I've missed something but I hope the fact of installing xnest on both machines helps someone else get this far as I've not seen that mentioned yet (I couldn't get anything working with xnest being installed first).

Also out of interest, when I run dpkg -l gdm after installing the patch it gives me the following:

steve@linux:/var/www$ dpkg -l gdm
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii gdm 2.20.1-0ubuntu GNOME Display Manager

Revision history for this message
Jurgis Pralgauskis (jurgis-pralgauskis) wrote : Re: [Bug 150193] Re: Remote Login via XDMCP is not working in Ubuntu Gusty/7.10

just in case: connecting to gutsy from hardy beta works

Revision history for this message
Martin Pitt (pitti) wrote : Re: Remote Login via XDMCP is not working in Ubuntu Gusty/7.10

So apparently the version in gutsy-proposed (-0ubuntu2) does not fix this bug completely, but according to Sebastien it should fix it partly.

How many people are running this version? Does it cause any apparent regressions or other problems?

Revision history for this message
markusd112 (markusd112) wrote :

I have updated to Ubuntu 8.04 in the hope, that this problem is fixed in the new release, but the problem still exists: I cannot connect to another machine in my local LAN, both now running ubuntu 8.04. I will get only a black screen and it doesn't work. The discussions about the bug are a little bit confusing. Has the reason for the bug been found? Changing the session manager to KDM is not really helpful, because some essential functions of the ubuntu gnome desktop doesn't work with kdm (e.g. switching the user).
When will the bug be fixed? Thanks a lot.

Revision history for this message
Martin Pitt (pitti) wrote :

Reopening. Neither the gutsy SRU nor the hardy version seem to fix this.

Changed in gdm:
status: Fix Released → Confirmed
Revision history for this message
Martin Pitt (pitti) wrote :

I removed the gutsy-proposed version again, since there was unclear feedback, and the problem is not solved yet in intrepid and hardy.

Changed in gdm:
status: Fix Committed → New
Revision history for this message
Fabrix (spedisci) wrote :

Very very bad thing!
No connection to remote XDMCP from Ubuntu 8.04 and praevious 7.10.
It's a long time bug and none fix it!
I must switch to another distro! Sigh Sigh, bye bye Ubuntu!

Revision history for this message
Sebastien Bacher (seb128) wrote :

you should rather switch to an another os since the bug is a GNOME one and not an ubuntu one and other distribution will likely the a similar issue

Revision history for this message
Jurgis Pralgauskis (jurgis-pralgauskis) wrote :

for me it works connecting from Hardy to Gusty (still, haven't tried Hardy to Hardy)

Revision history for this message
Hendy Irawan (ceefour) wrote :

The strange thing is that LTSP is working fine....

And LTSP uses XDMCP, GDM, and other technologies... which is more complex setup than just XDMCP

Revision history for this message
J Armando WP Jeronymo (jose-armando) wrote :

Then, couldn't it be that this bug is never solved because gnome or ubunto or whoever is involved would have us rather use LTSP instead of XDMCP? I had never heard of LTSP but liked what I read in Wikipedia and will give it a try.

By the way, with the patch mentioned above I can login from Gutsy to Gutsy.

Revision history for this message
Hendy Irawan (ceefour) wrote :

LTSP is not a replacement for XDMCP.

Rather, XDMCP (I guess) is needed as part of LTSP.

XDMCP plays a much smaller role (i.e. only the X/graphics part) than LTSP (which covers everything from routing sound to USB devices).

So it surprises me that XDMCP can't work while I can use LTSP without problems (Gutsy-Gutsy and Hardy-Hardy). If this is indeed a GNOME bug that is distro-independent, why LTSP+GNOME is working?

Revision history for this message
Andrés Rassol (anra) wrote :

LTSP doesn't use GDM, it uses LDM.

Revision history for this message
Steve Jackson (aearenda) wrote :

Just to clear up any confusion and speculation, LTSP in Ubuntu uses LDM for the terminal sessions by default, but earlier versions used to use GDM via XDMCP from the terminals and it can still be configured do so. This suits slower, older terminals. LTSP addresses a different need to XDMCP and both should work and be supported by Ubuntu.

Terminals use a tailored version of the operating system and do not run GDM locally - this is why they work when others do not.

Revision history for this message
Georg Graf (georg-graf) wrote :

Hardy LTSP doesn't work with XDMCP! I have set this in my lts.conf:
SCREEN_07 = startx
Result: No GDM-Login appears on the terminals!
The settings in /etc/gdm/gdm.conf-custom where checked and ok, ufw is disabled.
Only a X - Pointer appears in the middle of the screen.

with SCREEN_07 = ldm : It works fine, but have an evolution problem with the login keyring on the terminals.

Richard Seguin (sectech)
Changed in gdm:
status: New → Confirmed
Revision history for this message
Fabrix (spedisci) wrote : Re: [Bug 150193] Re: Remote Login via XDMCP is not working
  • unnamed Edit (822 bytes, text/html; charset=ISO-8859-1)

I changed distro (centos 5.1) not OS and here it works fine! Try yourself.

2008/5/27 Sebastien Bacher <email address hidden>:

> you should rather switch to an another os since the bug is a GNOME one
> and not an ubuntu one and other distribution will likely the a similar
> issue
>
> --
> Remote Login via XDMCP is not working
> https://bugs.launchpad.net/bugs/150193
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Martin Pitt (pitti) wrote :

Unsubscribing ubuntu-sru. Please resubscribe once this is fixed in the development release, and a patch exists for the SRU process.

Revision history for this message
Mehul J. Rajput (mehulrajput) wrote :

I have this problem in hardy too. Is there a work around for this bug?

Revision history for this message
adamis (adamis) wrote :

I've had this problem in Hardy as well as in the Alpha of Intrepid Ibex. Whenever I try to connect to my file server I have no problems seeing the file server using the remote login manager and clicking on it starts the connection however I never get a login window to login into the file server machine, I just get the Grey background with the "X" as a cursor.

I've looked at everything from firewalls, IVP6, I've even switched between kdm and gdm on the file sever to see if that was the issue. I've also walked through the guides several times to make sure that I had everything enabled correctly.

I've had XDMCP working before but it was a very long time ago. Both machines started out as Fiesty Fawn machines and I've upgraded them both to Hardy Heron and now to Intrepid Ibex.

Revision history for this message
n3ko (n3ko74) wrote :

I had the same problem tonight. I googled, and found nothin'. It seemed the problem serious. Tried to stace gdm and see, the connection start...

To be short: installed bind, and ... magic ... gdm works.
Googled some for find a way, to turn of authoritative reverse name lookups... found nothin' :(

Revision history for this message
n3ko (n3ko74) wrote :

sorry i forgot:
it was an up to date Hardy as server the clients:
 - another hardy with X -query and Xnest: both ok now.
 - debian 4.0 with X -query and Xvnc4: both ok now.
 - some Wyse thin client with a linux (unknown version) they are not working yet.

the wyse clients not work with kdm eighter. They can connect and login to xdm, but there is problem with keyboard configuration. (cant change us->hu)
the same clients with an older gdm on the debian works fine. (can connect, login, the keyboard is ok).

it's realy a new bug?

Revision history for this message
GercoKees (gercokees) wrote :

Is this still a bug in intrepid?

Revision history for this message
n3ko (n3ko74) wrote :

Which one?
1) The `Gdm isn't workin, when reverse dns lookup fails'
2) Or the `Old X terminals can't connect to new gdm'

Revision history for this message
bford16 (bford16) wrote :

This is still a problem in intrepid. I see the exact behavior described above. "gdmchooser[10437]: GLib-GObject-WARNING:."
Kernel is 2.6.27-7-generic (AMD64)

Originally I was able to use XDMCP with no problem at all. Some update broke it.

Revision history for this message
bford16 (bford16) wrote :

Also, this appears to have happened before. A bug filed for Gentoo (marked SOLVED) claims that updating GDM to version 2.20.2 fixed the issue. Intrepid uses version 2.20.8.

http://bugs.gentoo.org/show_bug.cgi?id=199606

Revision history for this message
bford16 (bford16) wrote :

One more comment: I opened Firestarter (not installed by default; do "sudo apt-get install firestarter") and enabled port 177 from my XDMP server. Suddenly XDMCP works again. However, "sudo ufw status" says "not enabled," so I don't know why that works.

Revision history for this message
cu_ (avkv-prasad) wrote :

It is still a problem in Intrepid. Little more information from syslog.
There are two more threads with exact same issues in ubuntuforums...but no solutions.
Again, it worked before. Some update broke it.

Dec 22 17:06:18 server gdm[5366]: DEBUG: gdm_xdmcp_host_allow: client->hostname is 127.0.0.1
Dec 22 17:06:18 server gdm[5366]: DEBUG: Attempting to parse key string: debug/Enable=false
Dec 22 17:06:18 server gdm[5366]: DEBUG: gdm_xdmcp-handle_manage: Got display=1, SessionID=1181938353 Class=MIT-unspecified from MIT-unspecified1
Dec 22 17:06:18 server gdm[5366]: DEBUG: gdm_xdmcp_handle_manage: Failed to look up session id 1181938353
Dec 22 17:06:18 server gdm[5366]: DEBUG: XDMCP: Sending REFUSE to 1181938353
Dec 22 17:06:18 server gdm[5366]: DEBUG: gdm_forward_query_lookup: Host ::ffff:127.0.0.1 not found
Dec 22 17:06:18 server gdm[5366]: DEBUG: decode_packet: GIOCondition 1
Dec 22 17:06:18 server gdm[5366]: DEBUG: XDMCP: Received opcode QUERY from client ::ffff:127.0.1.1 : 60899
Dec 22 17:06:18 server gdm[5366]: DEBUG: gdm_xdmcp_host_allow: client->hostname is 127.0.1.1
Dec 22 17:06:18 server gdm[5366]: DEBUG: XDMCP: Sending WILLING to ::ffff:127.0.1.1

Revision history for this message
DalaiDakkar (dalaidakkar) wrote :

Same problem with me, trying to connect to intrepid ibex via a fedora client and screen flashes with login window, then dissapears and back to fedora,

cat /var/log/messages
Jan 5 18:37:22 localhost acpid: client connected from 5644[0:0]
Jan 5 18:37:22 localhost acpid: 1 client rule loaded
Jan 5 18:37:23 localhost gdmchooser[5660]: GLib-GObject-WARNING: gsignal.c:1019: unable to lookup signal "activate" of unloaded type `GtkMenuItem'
Jan 5 18:37:27 localhost acpid: client connected from 5675[0:0]
Jan 5 18:37:27 localhost acpid: 1 client rule loaded
Jan 5 18:37:28 localhost acpid: client connected from 5675[0:0]
Jan 5 18:37:28 localhost acpid: 1 client rule loaded
Jan 5 18:37:30 localhost kernel: gdm-binary[5671]: segfault at 000004d0 eip 05c4d328 esp bfbdc470 error 4
Jan 5 18:37:30 localhost gdm-binary[2262]: WARNING: gdm_cleanup_children: child 5671 crashed of signal 11
Jan 5 18:37:30 localhost gdm-binary[2262]: WARNING: gdm_cleanup_children: Slave crashed, killing its children

Revision history for this message
cu_ (avkv-prasad) wrote :

Hi,

I forgot to post. My problem got resolved (accidentally). It had (for some reason had to do with the router). The problem is, XDMCP tries to get to port 177 on the local host. For some reason, it is going thru the router and my router was blocking it. My mistake was I upgraded Ubuntu AND changed my router at the same time. I ended up moving back to my old router.

To test to see if you have the same problem... please remove the network chord and try vnc-ing into local machine and it works fine.
The curx of the issue is port 177 on the host needs to be reachable from the client.

Hope this helps.

Revision history for this message
Sergio Zanchetta (primes2h) wrote :

The 18 month support period for Gutsy Gibbon 7.10 has reached its end of life -
http://www.ubuntu.com/news/ubuntu-7.10-eol . As a result, we are closing the
Gutsy task.

Changed in gdm (Ubuntu Gutsy):
status: Confirmed → Won't Fix
David Futcher (bobbo)
tags: added: patch-accepted-upstream
Revision history for this message
Sebastien Bacher (seb128) wrote :

the issue is deprecated in the new gdm so closing the bug

Changed in gdm (Ubuntu):
status: Confirmed → Invalid
Changed in gdm:
importance: Unknown → Medium
Richard Seguin (sectech)
Changed in gdm (Baltix):
status: New → Invalid
Displaying first 40 and last 40 comments. View all 146 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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