Bug 1393971

Same was filed for fedora https://bugzilla.redhat.com/show_bug.cgi?id=891802

In addition to above

There also should be a socket unit file. (xinetd is a thing of the past)

I've combined this solution :
https://access.redhat.com/solutions/2516
and same story for centos that is not behind a firewall
http://www.itzgeek.com/how-tos/linux/centos-how-tos/remote-login-with-gdm-and-vnc-on-centos-7-rhel-7-configure-vnc-on-xinetd-with-xdmcp-centos-7-rhel-7.html

with this one
https://access.redhat.com/solutions/2681531

ie use a systemd socket and service not xinetd

Then you have a working xdmcp and vnc setup.

Also a readme explaining how to use these two socket files with an adjustment of the /etc/gdm/custom.conf

cat/etc/gdm/custom.conf
# GDM configuration storage

[daemon]

[security]
AllowRemoteRoot=true
DisallowTCP=false

[xdmcp]
Enable=true
MaxSessions=30

[greeter]

[chooser]

[debug]



cat /etc/systemd/system/xvnc.socket
[Unit]                                                                                                                                             
Description=XVNC Server                                                                                                                            
                                                                                                                                                   
[Socket]
ListenStream=5900
Accept=yes

[Install]
WantedBy=sockets.target


cat /etc/systemd/system/xvnc.socket                                                                                                
[Unit]                                                                                                                                             
Description=XVNC Server                                                                                                                            
                                                                                                                                                   
[Socket]
ListenStream=5900
Accept=yes

[Install]
WantedBy=sockets.target


cat /etc/systemd/system/xvnc@.service
[Unit]
Description=XVNC Per-Connection Daemon

[Service]
ExecStart=-/usr/bin/Xvnc -inetd -query localhost -geometry 1024x768 -depth 24 -once -SecurityTypes=None -fp /usr/share/X11/fonts/misc

User=nobody
StandardInput=socket
StandardError=syslog

Love this solution! Unfortunately, it is insufficient for me or I'm doing something wrong trying to use it.

The default display manager for F23 and subsequent is SDDM, which does not include any XDMCP capability. A suggestion I found somewhere is to run "dnf install kdm; systemctl enable --force kdm.service". Then proceeding to follow these instructions and those at RH Solutions 2516 and 2681531, and modifying /etc/kde/kdm/Xaccess to uncomment "*", I get a connection but no login screen, just a blank screen with a momentary note about using F8. The log shows several errors at different times in my experiments. Sometimes Plymouth is not running. Sometimes I'm told the VNC service got more than one socket. Usually KDM reports that it can't open the display, using an IPv6 notation for the display.

(In reply to Dave Close from comment #5)
> Love this solution! Unfortunately, it is insufficient for me or I'm doing
> something wrong trying to use it.
> 
> The default display manager for F23 and subsequent is SDDM, which does not
> include any XDMCP capability. A suggestion I found somewhere is to run "dnf
> install kdm; systemctl enable --force kdm.service". Then proceeding to
> follow these instructions and those at RH Solutions 2516 and 2681531, and
> modifying /etc/kde/kdm/Xaccess to uncomment "*", I get a connection but no
> login screen, just a blank screen with a momentary note about using F8. The
> log shows several errors at different times in my experiments. Sometimes
> Plymouth is not running. Sometimes I'm told the VNC service got more than
> one socket. Usually KDM reports that it can't open the display, using an
> IPv6 notation for the display.

I have this all working well and have answered your question on the Fedora Users List.  Let's follow-up there instead of here.

Here's what I actually had to do to make this work on a reasonably vanilla Fedora 23 system.

# dnf -y install kdm
# systemctl enable --force kdm.service
# cat >/etc/systemd/system/xvnc@.service <<EOF
[Unit]
Description=XVNC per Connection Daemon
After=syslog.target
[Service]
ExecStart=-/usr/bin/Xvnc -inetd -query localhost -geometry 1280x1024 -depth 24 -once -SecurityTypes=None -fp /usr/share/X11/fonts/misc
StandardInput=socket
StandardError=syslog
EOF
# cat >/etc/systemd/system/xvnc.socket <<EOF
[Unit]
Description=XVNC Server
[Socket]
ListenStream=5900
Accept=yes
[Install]
WantedBy=sockets.target
EOF
## edit /etc/kde/kdm/Xaccess # uncomment the line, "#* #any host can get a login window"
## edit /etc/kde/kdm/kdmrc # set "Enable=true"
# systemctl enable xvnc.socket
# sed -i 'GRUB_CMDLINE_LINUX/s/"$/ ipv6.disable=1"/' /etc/default/grub
# grub2-mkconfig >/boot/grub2/grub.cfg
# reboot

Change the sed line above to,

# sed -i '/GRUB_CMDLINE_LINUX/s/"$/ ipv6.disable=1"/' /etc/default/grub

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2000

Nothing in the advisory addresses the complaint in this ticket.

IMO, this RFE was written to provide a functionality which did not previously exist.  It did so, and worked well for me.

In our off-line troubleshooting of the problem you encountered we determined that it was necessary, for some unknown reason, for you to disable IPv6 to get things to work while I did not need to take that same action.

Therefore, I believe it is not relevant to this RFE and a new bugzilla be written against either Xvnc (tigervnc-server-minimal) or GDM.  It would appear, I'm guessing, that in your case an IPv6 connection was first tried and when unsuccessful a IPv4 connection was not tried as a fallback.