Still true with kdm-4.10.2. Simple reproducer:

Enable XDMCP, start kdm, and run "X -query ::1 :1". You get some convesation on XDMCP UDP IPv6 port, but no X11 connection from the kdm to the X server. If I run "X -query 127.0.01 :1", everything is good.

The problem is XDMCP server receives connection from ::1, but it askes greeter to connect to link scope address to the X server which if course is wrong. In addition, the greeter tries to connect via wrong interface (loopback instead of ethernet in this case):

connect(3, {sa_family=AF_INET6, sin6_port=htons(6002), inet_pton(AF_INET6, "fe80::5246:5dff:fe8e:a186", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)

XDMCP should pass XDMCP client address to the greeter process ([::1]:6002 in this case).

s/XDMCP should/XDMCP server should/

This is core log when connecting XDMCP client from ::1 listing on [::1]:6002:

Apr  7 16:28:14 album kdm[19941]: select returns 1
Apr  7 16:28:14 album kdm[19941]: processRequestSocket
Apr  7 16:28:14 album kdm[19941]: header: 1 2 1
Apr  7 16:28:14 album kdm[19941]: <query> respond 1
Apr  7 16:28:14 album kdm[19941]: convertAddr returning 6 for family 10
Apr  7 16:28:14 album kdm[19941]: all_query_respond: conntype=6, addr=16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
Apr  7 16:28:14 album kdm[19941]: checkIndirectChoice
Apr  7 16:28:14 album kdm[19941]:   host not registered
Apr  7 16:28:14 album kdm[19941]: scanAccessDatabase
Apr  7 16:28:14 album kdm[19941]: send <willing> (null) 2 users, load: 0,03, 0,03, 0,06
Apr  7 16:28:14 album kdm[19941]: select returns 1
Apr  7 16:28:14 album kdm[19941]: select returns 1
Apr  7 16:28:14 album kdm[19941]: processRequestSocket
Apr  7 16:28:14 album kdm[19941]: header: 1 7 111
Apr  7 16:28:14 album kdm[19941]: <request> respond 111
Apr  7 16:28:14 album kdm[19941]: findProtoDisplay
Apr  7 16:28:14 album kdm[19941]: newProtoDisplay
Apr  7 16:28:14 album kdm[19941]: newProtoDisplay 0x00000000015f0a50
Apr  7 16:28:14 album kdm[19941]: got 0x00000000015f3c80 (18 MIT-MAGIC-COOKIE-1)
Apr  7 16:28:14 album kdm[19941]: <accept> session ID 9600001
Apr  7 16:28:14 album kdm[19941]: select returns 1
Apr  7 16:28:14 album kdm[19941]: processRequestSocket
Apr  7 16:28:14 album kdm[19941]: header: 1 10 23
Apr  7 16:28:14 album kdm[19941]: <manage> 23
Apr  7 16:28:14 album kdm[19941]: findProtoDisplay
Apr  7 16:28:14 album kdm[19941]: <manage> session ID 9600001, pdpy 0x00000000015f0a50
Apr  7 16:28:14 album kdm[19941]: computed display name: fe80::5246:5dff:fe8e:a186:2
Apr  7 16:28:14 album kdm[19941]: created new display fe80::5246:5dff:fe8e:a186:2
Apr  7 16:28:14 album kdm[19941]: convertAddr returning 6 for family 10
Apr  7 16:28:14 album kdm[19941]: checkIndirectChoice
Apr  7 16:28:14 album kdm[19941]:   host not registered
Apr  7 16:28:14 album kdm[19982]: execute: /usr/lib64/kde4/libexec/kdm_config  ; CONINFO=14 14
Apr  7 16:28:14 album kdm[19941]: started config reader ("/usr/lib64/kde4/libexec/kdm_config"), pid 19982
Apr  7 16:28:14 album kdm[19941]: getter now ready
Apr  7 16:28:14 album kdm[19941]: closed config reader
Apr  7 16:28:14 album kdm[19941]: getter now closed
Apr  7 16:28:14 album kdm[19941]: startDisplay fe80::5246:5dff:fe8e:a186:2, try 1
Apr  7 16:28:14 album kdm[19941]: file: /var/run/xauth/Afe80::5246:5dff:fe8e:a186:2-6lLMSb  auth: 0x00000000015f05c0
Apr  7 16:28:14 album kdm[19941]: forking session
Apr  7 16:28:14 album kdm[19941]: forked session, pid 19983
Apr  7 16:28:14 album kdm[19941]: select returns 1
Apr  7 16:28:14 album kdm: fe80::5246:5dff:fe8e:a186:2[19983]: before XOpenDisplay(fe80::5246:5dff:fe8e:a186:2)
Apr  7 16:28:14 album kdm: fe80::5246:5dff:fe8e:a186:2[19983]: after XOpenDisplay(fe80::5246:5dff:fe8e:a186:2)
Apr  7 16:28:14 album kdm: fe80::5246:5dff:fe8e:a186:2[19983]: OpenDisplay(fe80::5246:5dff:fe8e:a186:2) attempt 1 failed: Invalid argument

Obviously the bug is "computed display name: fe80::5246:5dff:fe8e:a186:2".

I think I understand the problem. My X server listens on [::]:6002, it connects to kdm using ::1, kdm accepts the query and X server returns request packet with list of connection addresses. kdm selects a connection address and send back authenticated reponse.

The problem is my X server puts link-local addesses into the connection addresses list which is wrong because link-local adress is not enough to make a connection. One need to specify interface in addition. However XDMCP does have place for interface identifier (at least I think).

When selectConnectionTypeIndex() called from request_respond() in kdm selects address to send a reply, it picks up first available one which is unfortuntelly the link-scope addess.

If correct display manager sees link-scope address, it should reuse the interface identifier from XDMCP `connection' because only this way is possible to use XDMCP with link-local addresses. kdm puts `0' in my case which is loop-back number in my case coincidently, so I don't know whether this was done on a purpose or it was just an unitialized variable.

Of course hyper correct XDMCP server should skip link-scope addresses if XDMCP request comes from host-scope address.

And of course correct XDMCP client should not advertize link scope addresses if it talks to XDMCP on the same host.

KDM is unmaintained and not used in KDE Plasma 5.

SDDM is the login manager used in KDE Plasma 5. If you still have this same issue with SDDM, please file an issue on the SDDM bugtracker (after doing a search for existing issues first!): https://github.com/sddm/sddm/issues/