QEMU VNC websocket proxy requires non-standard 'binary' subprotocol
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned | ||
qemu (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Low
|
Unassigned |
Bug Description
[Impact]
* The exact details of the protocol/
between the projects. So qemu ended up insisting on "binary" being
used but newer noVNC clients no more used it.
* Qemu got fixed in 5.0 to be more tolerant and accept an empty sub-
protocol as well. This SRU backports that fix to Focal.
[Test Case]
* Without the fix the following will "Failed to connect", but with the fix it will work.
$ sudo apt install qemu-system-x86
# will only boot into a failing bootloader, but that is enough
$ qemu-system-x86_64 -vnc :0,websocket
# We need version 1.2 or later, so use the snap
$ snap install novnc
$ novnc --vnc localhost:5700
Connect browser to http://<IP>:6080/vnc.html
Click "Connect"
* Cross check with an older noVNC (e.g. the one in Focal) if the
connectivity still works on those as well
- Reminders when switching between the noVNC implementations
- always refresh the browser with all clear ctrl+alt+f5
- start/stop the snapped one via snap.novnc.
[Regression Potential]
* This is exclusive to the functionality of noVNC, so regressions would
have to be expected in there. The tests try to exercise the basics, but
e.g. Openstack would be a major product using
[Other Info]
* The noVNC in Focal itself does not yet have the offending change, but
we want the qemu in focal to be connecteable from ~any type of client
---
When running a machine using "-vnc" and the "websocket" option QEMU seems to require the subprotocol called 'binary'. This subprotocol does not exist in the WebSocket specification. In fact it has never existed in the spec, in one of the very early drafts of WebSockets it was briefly mentioned but it never made it to a final version.
When the WebSocket server requires a non-standard subprotocol any WebSocket client that works correctly won't be able to connect.
One example of such a client is noVNC, it tells the server that it doesn't want to use any subprotocol. QEMU's WebSocket proxy doesn't let noVNC connect. If noVNC is modified to ask for 'binary' it will work, this is, however, incorrect behavior.
Looking at the code in "io/channel-
Look at line 58 and 433 here: https:/
This code has to be made more dynamic, and shouldn't require binary.
Related branches
- Robie Basak: Approve (sru)
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 520 lines (+480/-0)6 files modifieddebian/changelog (+10/-0)
debian/patches/series (+4/-0)
debian/patches/ubuntu/lp-1849644-io-channel-websock-treat-binary-and-no-sub-protocol-.patch (+127/-0)
debian/patches/ubuntu/lp-1882774-i386-Add-2nd-Generation-AMD-EPYC-processors.patch (+191/-0)
debian/patches/ubuntu/lp-1882774-i386-Add-missing-cpu-feature-bits-in-EPYC-model.patch (+76/-0)
debian/patches/ubuntu/lp-1896751-exec-rom_reset-Free-rom-data-during-inmigrate-skip.patch (+72/-0)
Changed in qemu: | |
status: | New → Fix Committed |
Changed in qemu: | |
status: | Fix Committed → Fix Released |
description: | updated |
Changed in qemu (Ubuntu Focal): | |
status: | Confirmed → Triaged |
status: | Triaged → In Progress |
It isn't mandatory to use a standardized subprotocol, all that's required is that the client & server agree
https:/ /developer. mozilla. org/en- US/docs/ Web/HTTP/ Protocol_ upgrade_ mechanism
"The subprotocols may be selected from the IANA WebSocket Subprotocol Name Registry or may be a custom name jointly understood by the client and the server."
QEMU used/required 'binary' because that is what noVNC used when the QEMU websockets code was first implemented.
It appears that noVNC was changed though to not send a "binary" subprotocol in
commit f8318361b1b62c4 d76b091132d4a8c cfdd2957e4
Author: Pierre Ossman <email address hidden>
Date: Sat Oct 14 12:45:56 2017 +0200
Remove wsProtocols setting
It isn't in use anymore since we deprecated support for Base64 mode.
From QEMU's POV looks like we'll need to tweak code to treat 'binary' and no sub-protocol as being equivalent.