vnc console accepts only 8 characters

Bug #1689488 reported by ustcweizhou on 2017-05-09
This bug affects 1 person
Affects Status Importance Assigned to Milestone
novnc (Ubuntu)
qemu (Ubuntu)

Bug Description

We have an issue when send message via vnc console. The vnc accepts only the first 8 characters.

The issue happens on ubuntu 15.05/15.10/16.04/16.10, but does not exist in ubuntu 14.04 and ubuntu 17.04.

After investigation, I found the issue is caused by commit;a=commitdiff;h=2deb4acc7c7ee770a0e0e75fd321effd916ca7df

and fixed by commit (it is already included in qemu v2.7.0, and ubuntu 17.04/qemu-2.8);a=commitdiff;h=c5ce83334465ee5acb6789a2f22d125273761c9e

Can we include the fix in next minor release of qemu-2.5 for ubuntu 16.04 ?


Thanks for reporting that issue and your help to make Ubuntu better.

I agree on the versions and commits that are referred.

Thereby Xenial and Yakkety are the versions that would need an SRU.
I don't know how fast I get to that, also it is hard for me to realize the importance of "only accept 8 characters".
I assume if you like mouse buffer paste more than 8 chars they are lost - is that what happens?
I totally believe in the report, but could you outline a best practice how to reproduce.
Essentially if you could provide as much as possible from [1] and edit it into the patch description that would be very kind.

Tagging and marking up the bug properly now to be in my queue ...


Changed in qemu (Ubuntu Xenial):
status: New → Triaged
Changed in qemu (Ubuntu Yakkety):
status: New → Triaged
Changed in qemu (Ubuntu Xenial):
importance: Undecided → Low
Changed in qemu (Ubuntu Yakkety):
importance: Undecided → Low
Changed in qemu (Ubuntu Xenial):
assignee: nobody → ChristianEhrhardt (paelzer)
Changed in qemu (Ubuntu Yakkety):
assignee: nobody → ChristianEhrhardt (paelzer)
Changed in qemu (Ubuntu):
status: New → Fix Released
tags: added: server-next
Changed in qemu (Ubuntu Yakkety):
status: Triaged → Won't Fix

I'm currently cleaning up dormant virtualization stack bugs.
Lets take the easy step first, Yakkety is EOL so this is Won't Fix.

As asked in comment #1 I'd need a bit more help on how to reproduce as we will need steps to reproduce to verify the SRU [1] as part of the process to fix issues in stable released.

I'll try to write to Gerd and Yang who worked on the change [2] if they can share a good testcase.
Until some sort of test is known I have to consider the SRU task incomplete.


Changed in qemu (Ubuntu Xenial):
status: Triaged → Incomplete

Hi Gerd and Yang,
I happen to consider your change [1] as a fix for [2], but so far lack a
way to reproduce.
The bug as well as the upstream discussion I found around the actual patch
lack the detail to come up with a test for it.

If you'd have a hint how you did work-on/verify the fix it would be very
kind if you could share that.


P.S. I CC'ed the LP bug to show up there as an update, feel free to
reply-to-all, if you have no LP user I I can carry the content over there
for you.

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Got feedback from Yang, trying that later today.
Quote of the reply mail:
"Hi Christian,
You could use novnc to send a bulk of text to the VM’s vnc console in one request."

Well, to some extend today I accidentally found that the default sdl frontent might have this issue as well.
If you start qemu by cmdline and e.g. just give it an ISO.
You need to slow that X11 connection down e.g. by running this via X11 forwarding across an ocean.
So the handling gets sloggy, which is fine (distance is distance, latency is ok).
Now in the framebuffer console make it roll the full console which is as easy as typing commands until the console is completely full and then do
- CTRL+C (will go down one line causing a lot of transfer)
- Immediately roll 1-0 on your keyboard
=> Result is that quiote often (>50%) only chars 1-7 or 1-8 appear.

Anyway that is even with Qemu 2.10 so no fix to port for that.
But related enough so I wanted to mention it.

Trying to reproduce:
1. Taking a recent desktop Ubuntu
2. starting that with "normal VNC" (and websocket)
   $ sudo qemu-system-x86_64 -enable-kvm -cdrom artful-desktop-amd64.iso -m 8192 -smp 8 -vnc,websocket=5701
   (Note this system is remote to increase latency and burst)
3. attach novnc
   (Whatever I tried, it didn't let me connect successfully to the 5701 websocket port that I spawned directly, so going via the novnc proxy.)
   $ git clone git://
   $ cd noVNC
   $ ./utils/ --vnc
   # Point your browser at "" or as
   # instructed in your case
4. I copied some large chunks of text around with mouse copy, with fast keyboard inputs, ...
   I couldn't make it break after 8 chars with the qemu in Xenial.

@ustcweizhou - could you describe your vnc setup in detail that was affected by it?
Because if it is close to my current sdl finding than the fix wont help.
And if it is not then I need your details to reproduce and verify the fix afterwards for an SRU process.

ustcweizhou (ustcweizhou) wrote :

Hi Christian,

Thanks for your effort on this issue.

We have a novnc server running and access the console of vms on other servers via the novnc server.

I also added a method in novnc to send a string via keyevent. The code looks like

+ sendString : function(str) {
+ if (this._rfb_state !== "normal" || this._view_only) { return false; }
+ Util.Info("Sending: "+str);
+ var arr = [];
+ for (var i = 0; i < str.length; i++ ) {
+ var char = str.substring(i, i + 1);
+ var code = char.charCodeAt(0);
+ if (shifted[char]) RFB.messages.keyEvent(this._sock, XK_Shift_L, 1); // Shift
+ RFB.messages.keyEvent(this._sock, code, 1); // (key)
+ RFB.messages.keyEvent(this._sock, code, 0); // (key)
+ if (shifted[char]) RFB.messages.keyEvent(this._sock, XK_Shift_L, 0); // Shift
+ }
+ this._sock.flush();
+ },

In my testing, only 8 chars can be accepted via novnc even the string is much longer.
As described in [1], the patch fixes the issue. I verified it is working.


Thanks for your feedback, so to confirm

You have
- Server A
  - running VMs with "normal" VNC console e.g. on 590*
  - novnc server linking the VM vnc sessions and making them available on e.g. 6800
    like novnc ./utils/launch ...
- System B
  - accessing A:6800 via local novnc
  - Here for better testing you added the JS submitting the chars

I you could confirm that setup and provide a full diff for you helper (I assume you also integrated that somewhere) that would be great.
I can - if needed - do the JS part alone but want to be sure on your setup as summarized above.

ustcweizhou (ustcweizhou) wrote :

Hi Christian,

Thanks a lot for all your testing, really appreciated.

Actually similar issue still exists on our platforms with novnc 0.6.2 and latest websockify.
We work on upgrading to novnc 1.1.0 recently.
We find this issue does not exist any more after upgrading to novnc 1.1.0.
Now we confirm it is a bug with novnc 0.6.2.

novnc 1.1 is in disco and later at least.

no longer affects: novnc (Ubuntu Yakkety)
Changed in qemu (Ubuntu Xenial):
assignee: Christian Ehrhardt  (paelzer) → nobody
Changed in qemu (Ubuntu Yakkety):
assignee: Christian Ehrhardt  (paelzer) → nobody
Changed in novnc (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers