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.
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.
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.
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
Curious if this may help kick lightdm into using ipv4 instead, could you try replacing: -query localhost with -query 127.0.0.1 ??
> -query 127.0.0.1 Yes, it works.
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.
Strange, in the initial comment it is (seems to be?) trying to connect to ipv6 localhost (::1) and now it's using something else?
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.
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 :-)
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)
Done: https://lists.freedesktop.org/archives/lightdm/2016-April/000957.html
Bug and patch now reported at https://bugs.launchpad.net/lightdm/+bug/1575200 upon upstream request.
Thanks, will pull the fix into fedora's packaging soon
lightdm-1.10.6-4.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-88326bc57c
lightdm-1.10.6-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9bbad38893
lightdm-1.10.6-4.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-258f25d58f
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
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
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
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.
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.
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.