DescriptionDaniel Berrangé
2017-01-26 09:28:45 UTC
When used with QEMU at least, both SPICE and VNC live in the same port
range (5900+). It is thus not entirely uncommon for a user to mistakenly
connect to a SPICE server with a VNC client, or vica-verca.
When connecting to VNC server with a SPICE client, you quickly get an
error. This is because the VNC server sends its short greeting and then
sees the RedLinkMess from the SPICE client, realizes its garbage and
drops the connection.
When connecting to a SPICE server with a VNC client though, you get an
indefinite hang. The VNC client is waiting for the VNC greeting, which
the SPICE server will never send. The SPICE server is waiting for the
RedLinkMess which the VNC client will never send.
In VNC the protocol starts with the follow data sent:
Server: "RFB 003.008\n"
Client: "RFB 003.008\n"
The GTK-VNC client is going to be changed such that it does
Client: "RFB "
Server: "RFB 003.008\n"
Client: "003.008\n"
From the VNC server POV, it'll still be receiving the same 12 bytes from
the client - it just happens that 4 of them might arrive a tiny bit
earlier than the other 8 of them. IOW nothing should break in the VNC
server from this change.
Now the SPICE server is waiting to receive RedLinkMess, the first 4
bytes of which are a magic number. Upon a (modified) VNC client connecting
it will receive "RFB " as the magic number, The SPICE should check this
magic number and drop the bogus connection, before waiting for the rest of
the RedLinkMess message to arrive.
This is implemented by this paach:
https://lists.freedesktop.org/archives/spice-devel/2017-January/035211.html
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/RHBA-2017:1866