[LightDM] LightDM as XDMCP server, multiple pathes to client

[Robert Ancell]

Hi Lupe,

I've filed a bug for this issue [1].

I can't seem to find any documentation on exactly what you should do if you
have multiple connections specified in the XDMCP Request. I'm not sure if
LightDM should try them all or pick one based on some criteria. I can't
tell it's actually wrong for the client to report an address that the
daemon can't route to (I guess the client couldn't know in advance?).

I've changed the behaviour for LightDM to use the address the Request came
from if it is in the list. This will mean it matches the GDM behaviour in
the simple case but also continues to work for other cases.

Note that LightDM 1.6 is no longer supported. You will either need to
upgrade to 1.10 or patch your version.

Hope this helps,
--Robert

[1] https://bugs.launchpad.net/bugs/1481561
[2] http://www.x.org/releases/X11R7.6/doc/libXdmcp/xdmcp.html

On Wed, 5 Aug 2015 at 02:11 Lutz Christoph <
lchristoph at extern.creativedata.de> wrote:

> Hi!
>
>
> This is part of a complicates scenario involving RHEL7, virtualization
> with KVM, VMs with multiple interfaces, and Xorg on the hypervisor host.
> The reason I'm trying to use LightDM is that the NVidia driver does not
> work with GDM (black screen). (GDM is the only DM offered by RHEL7.)
>
>
> The Xorg setup works OK when using Nouveau and GDM.
>
>
> When I switch the VM to LightDM, the connection starts OK, but LightDM is
> confused by the connection offerings of the client Xorg. GDM uses the
> address the request came from, but LightDM uses the first connection
> offering, which happens to be the outside interface of the hypervisor, and
> we do not permit many things in the firewall for that interface.
>
>
> I found no way to limit the connection offerings in the XDMCP Request
> packet, and frankly I should not need to since the sending IPv4 address is
> included in the list, but as #3.
>
>
> This is with these EPEL RPMs:
>
> lightdm-gobject-1.6.3-4.el7.x86_64
> lightdm-gtk-1.6.1-4.el7.x86_64
> lightdm-1.6.3-4.el7.x86_64
>
>
> Relevant log entries with IP addresses obfuscated (nice logging, BTW):
>
>
> [+1952.58s] DEBUG: Got Query(authentication_names=[])
> [+1952.58s] DEBUG: Send Willing(authentication_name='' hostname=''
> status='')
> [+1952.92s] DEBUG: Got Request(display_number=2 connections=[(0, 0A11xxxx)
> (0, C0A8xxxx) (0, C0A8xxxx) (6, FE80xxxx...xxxx) (6, FE80xxxx...xxxx) (6,
> FE80xxxx...xxxx) (6, FE80xxxx...xxxx) (6, FE80xxxx...xxxx) (6,
> FE80xxxx...xxxx) (6, FE80xxxx...xxxx) (6, FE80xxxx...xxxx)]
> authentication_name='' authentication_data=
> authorization_names=['MIT-MAGIC-COOKIE-1' 'XDM-AUTHORIZATION-1'
> 'SUN-DES-1'] manufacturer_display_id='')
> [+1952.92s] DEBUG: Send Accept(session_id=1015 authentication_name=''
> authentication_data= authorization_name='MIT-MAGIC-COOKIE-1'
> authorization_data=3C46DEAE1D40A959820F497B1526DF38)
> [+1952.92s] DEBUG: Got Manage(session_id=1015 display_number=2
> display_class='MIT-unspecified')
> [+1952.92s] DEBUG: Starting seat
> [+1952.92s] DEBUG: Starting new display for greeter
> [+1952.92s] DEBUG: Connecting to XServer 10.17.xx.xx:2
> [+1952.92s] DEBUG: Error connecting to XServer 10.17.xx.xx:2
> [+1952.92s] DEBUG: Send Failed(session_id=1015 status='Failed to connect
> to display :2')
>
>
> Any ideas how I can force LightDM to use the requesting address for the X
> connection?
>
> Mit freundlichen Grüßen / Kind regards
>
> *Lupe Christoph*
> im Auftrag von / on behalf of
> *Creative Data AG*
> - Standort Süddeutschland -
> Otto-Lilienthal-Str. 36
> D-71034 Böblingen
>
> Mobil:    +49 (0) 172 630 1004
> E-Mail:   lchristoph at extern.creativedata.de
> Web:www.creative-data.de
>
> Firmensitz: Robert-Bosch Str. 10 D-50769 Köln, Deutschland
>
> Sitz der Gesellschaft: Köln, Registergericht Köln, HRB: 45125 Köln
> Vorstand: Heinz Friebel, Aufsichtsratvorsitzender: Gerhard Böhm
> _______________________________________________
> LightDM mailing list
> LightDM at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/lightdm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/lightdm/attachments/20150805/20ef94fc/attachment.html>