Skip to content
This repository

fail to connect to qemu using tightPNG (illegal basic compression) #41

Closed
sleepingpig opened this Issue December 28, 2010 · 14 comments

4 participants

sleepingpig Joel Martin meong-congkok Corentin Chary
sleepingpig

fail to connect to qemu
Hi, I tried to connect to the vnc server of qemu like:
./qemu -boot d -cdrom ~/windowsXP.iso -m 100M -vnc :5
run noVNC like:
./utils/launch.sh --vnc 127.0.0.1:5905
browse the web:
http://ubuntu:6080/vnc.html?host=ubuntu&port=6081
But got the following error message:
"Illegal basic compression received, ctl: 80"

In fact, the problem isn't quite stable when using firefox, sometimes it will be stuck at
"Authentication OK"
OR
"Sent ProtocolVersion: 003.008"
When using Chrome, the result is always "Illegal basic compression received, ctl: 80"

Environment:
Ubuntu 10.10
firefox 3.6.13
chrome 8.0.552.224
qemu 0.13.0

p.s. Connecting to qemu works fine when using Vinagre

Thank you!

sleepingpig

Hello,
I found that changing the version of qemu from 0.13.0 to 0.12.5 will fix the problem.
Maybe I should report this problem to the qemu team later.
Thanks.

Joel Martin
Owner

What you are running into is a bug in an experimental feature that I co-developed with a QEMU summer of code student. It's a new VNC encoding optimized for browser based VNC clients (i.e. noVNC) called tightVNC.

The tightVNC encoding is similar to the tight encoding, but rather than using zlib compressed data which is very slow to decode in JavaScript, it uses PNG compressed data instead.

The bug is that if QEMU is built with tight support but not tightPNG suppot, noVNC will ask for tightVNC, but QEMU will respond with the tight encoding. I will mention it to the developer. Did you build QEMU yourself or are you using a binary version?

You can try this workaround to noVNC to disable tightPNG:

--- a/include/rfb.js
+++ b/include/rfb.js
@@ -44,7 +44,7 @@ var that           = {},         // Public API interface
     // In preference order
     encodings      = [
         ['COPYRECT',         0x01 ],
-        ['TIGHT_PNG',        -260 ],
+        //['TIGHT_PNG',        -260 ],
         ['HEXTILE',          0x05 ],
         ['RRE',              0x02 ],
         ['RAW',              0x00 ],
sleepingpig

Thank you.
After applying the patch, it works on Ubuntu! (both firefox and chrome)
However, it still doesn't work when using firefox 3.6.13 on Windows XP.
(But works when using chrome)
I got the message "Server disconnected" at client, and
27: got client connection from xxx.xxx.xxx.xxx
27: forking handler process
27: Sending flash policy response
27: No connection after handshake
at server.

Environment:
Windows XP service pack3 x32
firefox 3.6.13

By the way, I built QEMU myself on Ubuntu 10.10 with default configuration.

Joel Martin
Owner

If you rebuild QEMU using the --enable-vnc-png (and re-enable it in noVNC), you should be able to use the higher performance tightPNG protocol properly.

On to your second problem:

When using firefox-3.6 the Flash WebSockets emulator is loaded and used (firefox 3.6 has no built-in WebSockets support). This output:

27: Sending flash policy response
27: No connection after handshake

is normal output when using the flash WebSockets emulator (it's responding to a Flash network security policy request). But for some reason the emulator is not making a connection after policy response is received. Can you try shift-reloading the page a couple times and see if it clears up (Flash is temperamental at times).

If that doesn't work, can you try following the troubleshooting info at the bottom of the README (https://github.com/kanaka/noVNC) and post the output you get from the firebug console?

sleepingpig

Hi, I tried to reload the page several times, and also try to restart the browser, but the problem still exists. (I have also tried to recompile qemu with vnc-png enabled and re-enable the tightPNG in noVNC)

Here is the console output of firebug:

>> RFB.constructor
>> Canvas.init
Browser: gecko 19
Canvas supports imageData
Using Canvas createImageData
Prefering javascript operations
Data URI scheme cursor supported
<< Canvas.init
Using web-socket-js flash bridge
    util.js (line 71)
New state 'loaded', was 'disconnected'. Msg: noVNC ready: WebSockets emulation, createImageData rendering
    util.js (line 71)
<< RFB.constructor
New state 'connect', was 'loaded'.
    util.js (line 71)
>> RFB.init_ws
connecting to ws://xxx.xxx.xxx.xxx:6081/
<< RFB.init_ws
[WebSocket] cannot connect to Web Socket server at ws://xxx.xxx.xxx.xxx:6081/ (SecurityError) make sure the server is running and Flash socket policy file is correctly placed
    [Break On This Error] console.error(decodeURIComponent(message));
    web_socket.js (line 379)
>> WebSocket.onclose
New state 'failed', was 'connect'. Msg: Server disconnected
    [Break On This Error] case 'error': Util.Error = function (msg) { console.error(msg); };
    util.js (line 72)
Clearing connect timer
<< WebSocket.onclose
New state 'failed', was 'failed'.
    util.js (line 71)

Hope this would help. If more information is needed, please just tell me. :)

Joel Martin
Owner

Messages prefixed with "[WebSocket]" come from the Flash emulator. The type of error indicates something went wrong with the security policy request (or Flash doesn't like the response). What version of Flash are you running? You can find this out in most browsers by navigating to "about:plugins".

sleepingpig

Sorry for my late response.
My firefox now use Shockwave Flash 10.1 r102. And I have tried this on both windows XP and 7, and the results are the same.
Thank you.

sleepingpig

Hi,
today I test this problem again, and amazingly found that it works! It seems that the flash player and firefox doesn't have big update recently since the version numbers are the same.
I don't know why. (Maybe there was some minor updates?)
Anyway, there's no problem now. Thank you.

Joel Martin kanaka reopened this July 06, 2011
Joel Martin
Owner
kanaka commented July 06, 2011

This bug still exists in qemu 0.14.1 and in the master git tree. I have filed the following bug against QEMU:

https://bugs.launchpad.net/qemu/+bug/806656

I'm re-opening this bug to track the QEMU bug.

meong-congkok
  • ['TIGHT_PNG', -260 ],
  • //['TIGHT_PNG', -260 ],

It works.

Joel Martin
Owner
kanaka commented May 17, 2012

I submitted a patch to the mailing list (May 16 at 6:00PM CDT): http://lists.nongnu.org/archive/html/qemu-devel/2012-05/msg02373.html

I'll close this once the patch is pulled in upstream.

For future reference here is the process for qemu patch submission:

Joel Martin
Owner
kanaka commented May 17, 2012

#145 was a dupe of this issue.

Corentin Chary

Please resend to qemu-trivial (http://wiki.qemu.org/Contribute/TrivialPatches). That may speed-up things. (CC agraf, aligori and me). (I don't have any commit access, else I would have merged your patch).

Thanks

Joel Martin
Owner

It just got added to the trivial-patches tree: stefanha/qemu@281f9f3

Marking as closed.

Joel Martin kanaka closed this October 15, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.