1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
network: 0.916
instruction: 0.916
assembly: 0.916
graphic: 0.915
device: 0.914
semantic: 0.911
socket: 0.906
vnc: 0.902
other: 0.888
boot: 0.839
KVM: 0.836
mistranslation: 0.728
QEMU VNC websocket proxy requires non-standard 'binary' subprotocol
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-websock.c" it seems it's quite hard-coded to binary:
Look at line 58 and 433 here: https://git.qemu.org/?p=qemu.git;a=blob;f=io/channel-websock.c
This code has to be made more dynamic, and shouldn't require binary.
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 f8318361b1b62c4d76b091132d4a8ccfdd2957e4
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.
Thank you for your response, Daniel!
Do you think this is something you will have the opportunity to look at soon?
I have sent a patch about this problem.
Please see https://lists.nongnu.org/archive/html/qemu-devel/2019-11/msg03924.html
Did anyone at QEMU get a chance to look at that patch?
Hi, Samuel
This patch has been viewed by Daniel.
Please see https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg00264.html
However, Daniel has not sent a PR which includes this patch.
Thanks.
Ok, thanks!
Fixed here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=c64e1e75381d
This is in v5.0.0 so fixed in Groovy.
The related noVNC change is in upstream version >=v1.0.0 which correlates with Ubuntu >=20.04, threfore fixing this in Focals Qemu seems good.
Repro steps:
$ sudo apt install qemu-system-x86 novnc
/usr/share/novnc
python3 -m http.server
Connect browser to http://<IP>:8000/vnc.html
Click "Settings"
Open "advanced"
Open "websocket"
Set port 5700
Clear path
Click "Connect"
And it works ...
Turns out my former check on the offending noVNC commit was wrong.
There are
https://github.com/novnc/noVNC/commit/f8318361b1b62c4d76b091132d4a8ccfdd2957e4 (referenced on this bug before)
$ git tag --contains f8318361b1b62c4d76b091132d4a8ccfdd2957e4
v1.0.0
But only really gone later with:
https://github.com/novnc/noVNC/commit/c912230309806aacbae4295faf7ad6406da97617
$ git tag --contains c912230309806aacbae4295faf7ad6406da97617
v1.2.0
So the novnc of Focal isn't affected but anyone who uses a newer noVNC >=1.2 would be.
=> lower SRU priority
=> Modify above repro steps to not use noVNC from Focal via apt but use 1.2 from snaps
Repro steps:
$ snap install novnc
$ novnc --vnc localhost:5700
Connect browser to http://<IP>:6080/vnc.html
Click "Connect"
TODO: repro steps to be verified with a qemu that has the fix applied
I can confirm the test steps mentioned above. In an unchanged scenario a formerly failing-to-connect case got working when replacing the qemu (on Focal) in use with a patched one.
Adding an SRU Template for Focal to the bug description ...
SRU Template for qemu added and MP linked to fix this in Ubuntu 20.04
Hello Samuel, or anyone else affected,
Accepted qemu into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.7 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.
Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
All autopkgtests for the newly accepted qemu (1:4.2-3ubuntu6.7) for focal have finished running.
The following regressions have been reported in tests triggered by the package:
casper/1.445.1 (amd64)
Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#qemu
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
Trying to connect using
novnc latest/stable: 1.2.0 2020-07-31 (6) 18MB -
as-is failing to connect
Keeping VNC up and refreshing qemu.
Updating to the new qemu from focal proposed (by now resolved the archive publishing issues we had before this morning).
Get:67 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-utils amd64 1:4.2-3ubuntu6.7 [975 kB]
Get:68 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-common amd64 1:4.2-3ubuntu6.7 [1056 kB]
Get:69 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-block-extra amd64 1:4.2-3ubuntu6.7 [53.8 kB]
Get:70 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-data all 1:4.2-3ubuntu6.7 [563 kB]
Get:71 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-kvm amd64 1:4.2-3ubuntu6.7 [13.1 kB]
Get:72 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-x86 amd64 1:4.2-3ubuntu6.7 [6720 kB]
Get:73 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-gui amd64 1:4.2-3ubuntu6.7 [40.8 kB]
Get:74 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-mips amd64 1:4.2-3ubuntu6.7 [12.9 MB]
Now the same novnc1.2 can connect to it \o/
Setting verified
This bug was fixed in the package qemu - 1:4.2-3ubuntu6.7
---------------
qemu (1:4.2-3ubuntu6.7) focal; urgency=medium
* d/p/ubuntu/lp-1882774-*: add newer EPYC processor types (LP: #1887490)
* d/p/u/lp-1896751-exec-rom_reset-Free-rom-data-during-inmigrate-skip.patch:
fix reboot after migration (LP: #1896751)
* d/p/u/lp-1849644-io-channel-websock-treat-binary-and-no-sub-protocol-.patch:
fix websocket compatibility with newer versions of noVNC (LP: #1849644)
-- Christian Ehrhardt <email address hidden> Mon, 27 Jul 2020 11:45:26 +0200
The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
|