search

amitbet / vncproxy

An RFB proxy, written in go that can save and replay FBS files
Other
206 stars 45 forks source link

Problem with websockets/noVNC #6

Closed falzm closed 5 years ago

falzm commented 5 years ago

Hi

I'm facing a similar issue than #4 but since it's a bit different I prefer to open a dedicated issue.

Using vncproxy I'm successfully managing to connect to a proxified local qemu VNC display using noVNC (i.e. it prints the VM display OK), but as soon as I type something into the viewport the connection closes and the proxy prints this error message:

[Error] WriteTo.Consume (ServerUpdater SegmentBytes): problem writing to port: write tcp 172.16.24.134:5001->172.16.24.1:50732: use of closed network connection
[Error] WriteTo.Consume (ServerUpdater SegmentBytes): problem writing to port: write tcp 172.16.24.134:5001->172.16.24.1:50732: use of closed network connection
[Error] ClientConn.MainLoop: error parsing message, write tcp 172.16.24.134:5001->172.16.24.1:50732: use of closed network connection
[Warn ] ClientConn.MainLoop: exiting!

Note that it works OK using the RFB protocol via vncproxy, it looks like it's specific to the websocket protocol. Here is my configuration:

Am I doing something wrong?

amitbet commented 5 years ago

Hi, in order to see the real problem you should change the logger to debug and recompile. To change logevel Change LoglevelWarn to LoglevelDebug in logger/logger.go

I must mention again that i have never tested this with qemu since i don't have such a setup, so if you are willing to debug this issue with me it would be helpful towards adding the support.

On Tue, Oct 16, 2018, 10:54 Marc Falzon notifications@github.com wrote:

Hi

I'm facing a similar issue than #4 https://github.com/amitbet/vncproxy/issues/4 but since it's a bit different I prefer to open a dedicated issue.

Using vncproxy I'm successfully managing to connect to a proxified local qemu VNC display using noVNC (i.e. it prints the VM display OK), but as soon as I type something into the viewport the connection closes and the proxy prints this error message:

[Error] WriteTo.Consume (ServerUpdater SegmentBytes): problem writing to port: write tcp 172.16.24.134:5001->172.16.24.1:50732: use of closed network connection [Error] WriteTo.Consume (ServerUpdater SegmentBytes): problem writing to port: write tcp 172.16.24.134:5001->172.16.24.1:50732: use of closed network connection [Error] ClientConn.MainLoop: error parsing message, write tcp 172.16.24.134:5001->172.16.24.1:50732: use of closed network connection [Warn ] ClientConn.MainLoop: exiting!

Note that it works OK using the RFB protocol via vncproxy, it looks like it's specific to the websocket protocol. Here is my configuration:

  • qemu: qemu-system-x86_64 [...lots of irrelevant options...] -display vnc=127.0.0.1:0
  • proxy (version linux-amd64-v1.02): ./vncproxy -targHost 127.0.0.1 -targPort 5900 -tcpPort 5901 -wsPort 5001
  • noVNC Websockets settings:
    • Host: 172.16.24.134
    • Port: 5001
    • Path:

Am I doing something wrong?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/amitbet/vncproxy/issues/6, or mute the thread https://github.com/notifications/unsubscribe-auth/AC7XAAI3lQq81Mli51zBrwiOiZPVgk8nks5ulZChgaJpZM4Xdxzz .

falzm commented 5 years ago

Here is the debug around the error (complete debug is joined as a file):

[Info ] IServerConn.Handle got ClientMessage: FramebufferUpdateRequest, &{1 0 0 1024 768}
[Debug] ClientUpdater.Consume:(vnc-server-bound) got ClientMessage type=FramebufferUpdateRequest
[Info ] ClientConn.MainLoop: got ServerMessage:FramebufferUpdate
[Debug] WriteTo.Consume (ServerUpdater): got segment type=SegmentMessageStart, object type:0
[Debug] WriteTo.Consume (ServerUpdater): got segment type=SegmentBytes, object type:0
[Debug] WriteTo.Consume (ServerUpdater SegmentBytes): got bytes len=1
[Error] WriteTo.Consume (ServerUpdater SegmentBytes): problem writing to port: write tcp 172.16.24.134:5001->172.16.24.1:51989: use of closed network connection
[Debug] RfbReadHelper.Read: publishing bytes, bytes:[0]
[Debug] WriteTo.Consume (ServerUpdater): got segment type=SegmentBytes, object type:0
[Debug] WriteTo.Consume (ServerUpdater SegmentBytes): got bytes len=1
[Error] WriteTo.Consume (ServerUpdater SegmentBytes): problem writing to port: write tcp 172.16.24.134:5001->172.16.24.1:51989: use of closed network connection
[Error] ClientConn.MainLoop: error parsing message, write tcp 172.16.24.134:5001->172.16.24.1:51989: use of closed network connection
[Warn ] ClientConn.MainLoop: exiting!
[Debug] WriteTo.Consume (ServerUpdater): got segment type=SegmentConnectionClosed, object type:0
[Debug] Recorder.HandleRfbSegment: saving FramebufferUpdate segment
[Debug] Recorder.HandleRfbSegment: writing bytes, len: 1
[Debug] Recorder.HandleRfbSegment: writing bytes, len: 1
falzm commented 5 years ago

Let me know if I can be of any assistance in the debugging process 😉

amitbet commented 5 years ago

this sort of problem usually happens when the server sends something I don't expect and since it doesn't get the answer it requires by the protocol, it closes connection. but it doesn't seem that the essential parts are being logged... this can also be something based on websocket closing due to some firewall or load balancer in the way (implementing A keep alive mechanism can solve that)

I'm trying to create a hyper-v machine with a qemu machine inside it, I got stuck at "booting from cdrom", the qemu vnc works fine trough my proxy at that point, but I guess that's not very impressive ;)

can you elaborate on your setup (network architecture, virtual machines/hardware etc.) ?

I don't really understand the qemu usecase, it seems to me that you should either have a vSphere with some machines on it or work on AWS/GCP/Azure (hypervisor use cases), in which case you don't need QEMU, or have a desktop machine - (local desktop VM usecase) but then, why use a linux as a desktop when you can have a mac/windows?

amitbet commented 5 years ago

Found out you work at exoscale :) so if you are using QEMU as a hypervisor and connecting to the vnc through some network mechanisms, it might be the case that the ping (keepalive) is what's missing and websocket is closed by some middleman for idle time / some other timeout. does it work for some time before it disconnects?

you should try working with it with a local VM (no middlemen) and see if it behaves the same. I don't remember if I had a ping mechanism somewhere in the code, but I did have it in another project that was productized...

falzm commented 5 years ago

I do actually work with a local VM, this is the setup I've described earlier: QEMU installed in a vanilla Ubuntu 18.04 VMware instance, with vncproxy running directly alongside the QEMU VM (so local VNC connection, no middleman); the browser (Firefox 62 on macOS – reproduced with Chrome too) and the noVNC instance are running on the hypervisor.

I highly doubt that it's a timeout issue since the connection gets closed right at the slight key press, even within seconds after it has been established (and if I don't press any key the connection stays up).

amitbet commented 5 years ago

If its a keypress that is making the problem it might be the qemu extended keyboard support.. I'll see if i can make it fail on my end

On Tue, Oct 23, 2018, 09:48 Marc Falzon notifications@github.com wrote:

I do actually work with a local VM, this is the setup I've described earlier: QEMU installed in a vanilly Ubuntu 18.04 VMware instance, with vncproxy running directly alongside the QEMU VM (so local VNC connection, no middleman); the browser (Firefox 62 on macOS – reproduced with Chrome too) and the noVNC instance are running on the hypervisor.

I highly doubt that it's a timeout issue since the connection gets closed right at the slight key press, even within seconds after it has been established (and if I don't press any key the connection stays up).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/amitbet/vncproxy/issues/6#issuecomment-432115997, or mute the thread https://github.com/notifications/unsubscribe-auth/AC7XAA61ZqHlwe4FUUi34HFPip90T3ulks5unrvHgaJpZM4Xdxzz .

falzm commented 5 years ago

Note that it works without problem when I connect noVNC directly to the QEMU VNC-over-Websocket display, without vncproxy.

amitbet commented 5 years ago

When you used a tcp based client (not novnc) what did you use?

On Tue, Oct 23, 2018, 16:48 Marc Falzon notifications@github.com wrote:

Note that it works without problem when I connect noVNC directly to the QEMU VNC-over-Websocket display, without vncproxy.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/amitbet/vncproxy/issues/6#issuecomment-432253411, or mute the thread https://github.com/notifications/unsubscribe-auth/AC7XAM52yerkfpg-V2FUHuSml5Bt4t0Aks5unx4-gaJpZM4Xdxzz .

falzm commented 5 years ago

I use Chicken on macOS. It works fine on plain TCP VNC via vncproxy.

amitbet commented 5 years ago

Chicken is very basic, so i guess it doesn't have support for most qemu extensions, so no special messages come through.

On Tue, Oct 23, 2018, 18:25 Marc Falzon notifications@github.com wrote:

I use Chicken https://github.com/boecko/chicken on macOS. It works fine on plain TCP VNC via vncproxy.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/amitbet/vncproxy/issues/6#issuecomment-432290427, or mute the thread https://github.com/notifications/unsubscribe-auth/AC7XAPapFoSo9VK2OmklfUqgGhEq2JQSks5unzTpgaJpZM4Xdxzz .

falzm commented 5 years ago

Probably, but I don't see the link between Chicken working in TCP and noVNC not working with Websockets via vncproxy (but working without it) 🤔

amitbet commented 5 years ago

It took 3 levels of virtualization (Windows-Ubuntu-QemuUbuntu), but I got it! pull new code and test it, it should now work.

amitbet commented 5 years ago

It was the QemuExtendedKeys as I suspected (messageType 255) so I added support for it.

falzm commented 5 years ago

I confirm it now works, thanks a lot!