vnc console accepts only 8 characters

[Wei Zhou]

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
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2deb4acc7c7ee770a0e0e75fd321effd916ca7df

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

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

Thanks.

[Christian Ehrhardt  (paelzer)]

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 ...

[1]: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template

[Christian Ehrhardt  (paelzer)]

Hi,
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.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates
[2]: http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg00397.html

[Christian Ehrhardt  (paelzer)]

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.

[1]: http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg00397.html
[2]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1689488

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

[Christian Ehrhardt  (paelzer)]

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.
https://github.com/novnc/noVNC"

[Christian Ehrhardt  (paelzer)]

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
   $wget http://cdimage.ubuntu.com/daily-live/current/artful-desktop-amd64.iso
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 0.0.0.0:1,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://github.com/novnc/noVNC
   $ cd noVNC
   $ ./utils/launch.sh --vnc 10.245.168.50:5901
   # Point your browser at "http://127.0.0.1:6080/vnc.html?host=127.0.0.1&port=6080" 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.

[Wei Zhou (ustcweizhou)]

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.

[1] http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg00397.html

[Christian Ehrhardt  (paelzer)]

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.

[Wei Zhou (ustcweizhou)]

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.

[Christian Ehrhardt  (paelzer)]

novnc 1.1 is in disco and later at least.

[Christian Ehrhardt  (paelzer)]

Trying to clean some old issue I've removed the Bionic tasks where this should be working fine so there is no task to be done on that release.

[Utkarsh Gupta (utkarsh)]

Xenial has reached "End of Standard Support" and hence I am marking those tasks as "Won't Fix". Thank you!