Bug 1322775 - lightdm-1.10.6-2 breaks XDMCP: Error connecting to XServer via ipv6
Summary: lightdm-1.10.6-2 breaks XDMCP: Error connecting to XServer via ipv6
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: lightdm
Version: 23
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-31 10:28 UTC by Patrick Monnerat
Modified: 2016-05-08 10:30 UTC (History)
3 users (show)

Fixed In Version: lightdm-1.10.6-4.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-06 19:23:46 UTC
Type: Bug


Attachments (Terms of Use)
Avoid link-local address use if possible (4.48 KB, patch)
2016-04-07 17:16 UTC, Patrick Monnerat
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1575200 0 None None None 2016-05-02 18:01:46 UTC

Description Patrick Monnerat 2016-03-31 10:28:43 UTC
Description of problem:
After upgrading from 1.10.5-4, dynamic (i.e.: xinetd controlled) vnc sessions using XDMCP close connection immediately.
After strace'ing the vnc server, I can see lightdm pretend it cannot connect to display: this used to work with 1.10.5-4 and the same vnc server (and remote client).

Version-Release number of selected component (if applicable):
lightdm-1.10.6-2.fc23.x86_64
tigervnc-server-1.6.0-1.fc23.x86_64

How reproducible:
Always


Steps to Reproduce:
1. Install tigervnc-server, xinetd.
2. Set service "vnc-1152x864x24 5929/tcp" in /etc/services
3. Create xinetd service:
service vnc-1152x864x24
{
 	flags		= IPv4
	 socket_type	= stream
	 wait		= no
	 user		= root
 	log_on_failure	+= USERID
	 server		= /usr/bin/Xvnc
	server_args	= -inetd -once -query localhost -geometry 1152x864 -dpi 100 -depth 24 -securitytypes=none +extension GLX
 	disable		= no
}
4. [XDMCPserver] enabled=true in /etc/lightdm/lightdm.conf
5. Restart xinetd, lightdm
6. Connect from a vnc client to port 5929.

Actual results:
Connection, then immediate stop.


Expected results:
A working vnc/XDMCP  session.

Additional info:
Extracted from the vnc server strace:
----
recvfrom(6, "\0\1\0\10\0.\0\0006\3\0\0\0\0\0\22MIT-MAGIC-COOKIE-1\0\20\2621)\372\24\267\372C;4R9d(\30\231", 8192, 0, {sa_family=AF_INET6, sin6_port=htons(177), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 52
sendto(6, "\0\1\0\n\0\27\0\0006\3\0\35\0\17MIT-unspecified", 29, 0, {sa_family=AF_INET6, sin6_port=htons(177), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 29
select(512, [0 1 3 4 5 6 7], NULL, NULL, {2, 0}) = 1 (in [6], left {1, 999657})
recvfrom(6, "\0\1\0\f\0&\0\0006\3\0 Failed to connect to display :29", 8192, 0, {sa_family=AF_INET6, sin6_port=htons(177), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 44
write(2, "(EE)", 4)                     = 4
write(2, " ", 1)                        = 1
write(2, "\nFatal server error:\n", 21) = 21
----
After reinstalling 1.10.5-4, it works again.

Comment 1 Rex Dieter 2016-03-31 13:39:31 UTC
It would appear to be some problem with your X server (Fatal server error does not come from lightdm).


For completeness, what are your /etc/lightdm/lightdm.conf config entries for the following keys:

[LightDM]
xserver-allow-tcp=

[XDMCPSever]
enabled=


Per the release announcement, it does appear to include a few xdmcp-related changes:
* New upstream release:
...
    - Check the version of the X server we are running so we correctly pass
      -listen tcp when required. (LP: #1449282)
    - Use IP address of XDMCP requests to contact X server if available.
      (LP: #1481561)
    - Implement XDMCP ForwardQuery. (LP: #1511545)
    - Add an option for XDMCP and VNC servers to only listen on one address.
      (LP: #1390808)
    - Don't start LightDM if the XDMCP server is configured with a key that
      doesn't exist. (LP: #1517685)
    - Add IP addresses to XDMCP log messages.
    - Refactor XDMCP error handling.
    - Fix small memory leak in XDMCP logging code.

Comment 2 Patrick Monnerat 2016-03-31 14:33:33 UTC
Many thanks for your reply.

> It would appear to be some problem with your X server (Fatal server error does not come from lightdm).
Yes, but it is caused by lightdm replying: "Failed to connect to display :29".
My X server is the tigervnc server itself.

> [LightDM]
> xserver-allow-tcp=
Unset. Although it seems that if you set it, it should be in the [SeatDefaults] paragraph.
From what I understand, this is for using lightdm as an XDMCP client. This is not what I'm doing.

> [XDMCPServer]
> enabled=
enabled=true
This is the only line I added in lightdm.conf.
This works because XDMCP replies to vnc server. When unset or set to false, the vnc server waits for an XDMCP reply and the vnc client window stays black, but the connection is not closed.

>     - Implement XDMCP ForwardQuery. (LP: #1511545)
This is not what I'm doing.

>     - Use IP address of XDMCP requests to contact X server if available.
>      (LP: #1481561)
Well, the vnc server is scheduled by xinetd when triggered by an ipv4 address. It then contacts the local lightdm XDMCP server using IPv6 ::1. I can see (with 1.10.5-4) that tigervnc server listens on both IPv4/IPv6 port 6029. Does 1.10.6-2 trigger a change in vnc server here ? I can't see because with 1.10.6-2, connections are vanishing too fast. Might it be an IPV4/IPv6 problem ?

Thanks for your support.

Comment 3 Rex Dieter 2016-03-31 14:45:02 UTC
Based on your findings in the original comment, it does appear to be attempting to use ipv6 now:

sendto(6, "\0\1\0\n\0\27\0\0006\3\0\35\0\17MIT-unspecified", 29, 0, {sa_family=AF_INET6, sin6_port=htons(177), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 29
select(512, [0 1 3 4 5 6 7], NULL, NULL, {2, 0}) = 1 (in [6], left {1, 999657})
recvfrom(6, "\0\1\0\f\0&\0\0006\3\0 Failed to connect to display :29", 8192, 0, {sa_family=AF_INET6, sin6_port=htons(177), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 44

Comment 4 Rex Dieter 2016-04-02 14:30:38 UTC
Curious if this may help kick lightdm into using ipv4 instead, could you try replacing:
-query localhost
with
-query 127.0.0.1
??

Comment 5 Patrick Monnerat 2016-04-04 08:46:10 UTC
> -query 127.0.0.1
Yes, it works.

Comment 6 Patrick Monnerat 2016-04-05 14:25:10 UTC
Some more information:

Failing connection debug log (with vnc connection on port 5928):
-----
[+101508.45s] DEBUG: Got Manage(session_id=19120 display_number=28 display_class='MIT-unspecified') from ::1:46943
[+101508.45s] DEBUG: Seat: Starting
[+101508.45s] DEBUG: Seat: Creating greeter session
[+101508.45s] DEBUG: Seat: Creating display server of type x
[+101508.45s] DEBUG: DisplayServer x-fe80::9657:a5ff:fe54:5450-28: Connecting to XServer fe80::9657:a5ff:fe54:5450:28
[+101508.45s] DEBUG: DisplayServer x-fe80::9657:a5ff:fe54:5450-28: Error connecting to XServer fe80::9657:a5ff:fe54:5450:28
[+101508.45s] DEBUG: Seat: Can't create display server for greeter
[+101508.45s] DEBUG: Seat: Session stopped
-----
Seems that xcb_connect_to_display_with_auth_info() returns an error...

fe80::9657:a5ff:fe54:5450 matches one of the non-loopback interface.

I tried with empty ip6tables and with only INPUT/OUTPUT/FORWARD policies set to ACCEPT: both fail --> not an ip6tables rule blocking.
From a wireshark trace of all ipv6, connection is not even attempted.

I hope you'll find these info useful.
Thanks for investigating.

Comment 7 Rex Dieter 2016-04-05 14:44:09 UTC
Strange, in the initial comment it is (seems to be?) trying to connect to ipv6 localhost (::1) and now it's using something else?

Comment 8 Patrick Monnerat 2016-04-05 17:20:01 UTC
OK, I think I found the problem.
- vnc client connects to IPv4 vnc server port: no problem.
- vnc server requests XDMCP to ::1 --> xdmcp dialog OK.
- lightdm XDMCP server maps is client address (::1) to a non-loopback address it finds on some interface (I don't know why and how). This is also done for IPv4 address 127.0.0.1 in the working configuration.
- This mapped address is used for connecting to X session.

With IPv4, it's OK. However IPv6 fails because the mapped address is a link-local address without an interface index: the connect() call in libxcb fails with EINVAL.

The solution is either to specify an interface (which seems heavy) or to map to a non-local link address, or even better, to not map at all if possible.

I hope this helps.

Comment 9 Patrick Monnerat 2016-04-07 17:16:59 UTC
Created attachment 1144820 [details]
Avoid link-local address use if possible

Some more info: (I'm learning every day :-))

There is no address mapping: instead, the XDMCP client transmits the list of possible addresses for connections to Xserver in the "Request" message, and the XDMCP server chooses one.
Xvnc (maybe xorg server itself) transmits link-local addresses, causing lightdm to fail on these connection because the local interface index is not known.
OpenSuse has fixed it in the client: https://lists.opensuse.org/opensuse-commit/2013-07/msg00209.html, so maybe this bug could be reassigned (to tigervnc or xorg server?). However I've attached a patch that improves the address selection performed by lightdm:
- It prefers a non-local link address, whatever its family.
- It then prefers the source address family.
- Finally, it prefers the source address itself.

This is not 100% full-proof (we may have only link-local addresses), but improves a lot the chance of successful connection.
As a side-effect, it prefers an IPv4 address if all IPv6 addresses are link-local, even if the XDMCP connection was IPv6. Similarly, the source address is not the preferred one if it is a link-local address.

To complete the work, link-local addresses should be allowed only if attached to one of the local interface, or if a single local interface is bound to a link-local ipv6 address. In addition, the interface index should be resolved before connect().

Even if this problem is fixed in the XDMCP client, this patch improves the "cleverness" of lightdm.

I've tested it here (without changing the XDMCP client) successfully.
I hope you'll like it :-)

Comment 10 Rex Dieter 2016-04-07 19:55:49 UTC
excellent work, if you don't mind, would you consider posting your findings to
https://lists.freedesktop.org/mailman/listinfo/lightdm
mailing list?

(I can do it in your stead, but I won't be able to answer questions as well as you, if they require more dialog)

Comment 12 Patrick Monnerat 2016-04-26 14:12:27 UTC
Bug and patch now reported at https://bugs.launchpad.net/lightdm/+bug/1575200 upon upstream request.

Comment 13 Rex Dieter 2016-05-02 18:01:46 UTC
Thanks, will pull the fix into fedora's packaging soon

Comment 14 Fedora Update System 2016-05-03 14:23:51 UTC
lightdm-1.10.6-4.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-88326bc57c

Comment 15 Fedora Update System 2016-05-03 14:25:02 UTC
lightdm-1.10.6-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9bbad38893

Comment 16 Fedora Update System 2016-05-03 14:25:44 UTC
lightdm-1.10.6-4.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-258f25d58f

Comment 17 Fedora Update System 2016-05-04 06:53:02 UTC
lightdm-1.10.6-4.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-258f25d58f

Comment 18 Fedora Update System 2016-05-04 07:25:22 UTC
lightdm-1.10.6-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9bbad38893

Comment 19 Fedora Update System 2016-05-04 14:29:52 UTC
lightdm-1.10.6-4.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-88326bc57c

Comment 20 Fedora Update System 2016-05-06 19:23:44 UTC
lightdm-1.10.6-4.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2016-05-06 19:51:14 UTC
lightdm-1.10.6-4.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Comment 22 Fedora Update System 2016-05-08 10:30:36 UTC
lightdm-1.10.6-4.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.