search

novnc / noVNC

VNC client web application
https://novnc.com
Other
11.68k stars 2.31k forks source link

Problems using libwebsockets proxy #108

Closed abligh closed 12 years ago

abligh commented 12 years ago

I have written code to proxy novnc using libwebsockets, and am having difficulty debugging a failure to connect. My code may have bugs (though I can't immediately see where), so I am really looking for a debugging pointer. This is with novnc git head as of about 2 minutes ago (commit 06a9ef0c6cd90746210f62d72b6bf8f0dcab9491).

What I see is the websocket negotiate fine, tcpdump shows what I believe is a sensible RFB packet with websocket encapsulation showing 2 byte header including 12 byte length + "RFB 003.008" + newline, but novnc does not appear to pick it up, and sends no reply.

novnc console output in firebug shows:

New state 'connect', was 'loaded'. util.js (line 71)

RFB.connect util.js (line 69) connecting to ws://127.0.01:8080/ util.js (line 70) << RFB.connect util.js (line 69) WebSock.onopen util.js (line 69) Server chose sub-protocol: base64 util.js (line 70) New state 'ProtocolVersion', was 'connect'. Msg: Starting VNC handshake util.js (line 71) Clearing connect timer util.js (line 69) << WebSock.onopen

The content of the TCP packet sent from proxy to client is a binary frame under the v8 spec (i.e. a LWS_WS_OPCODE_07__BINARY_FRAME in libwebproxy terms), with the following bytes: 82:0c:52:46:42:20:30:30:33:2e:30:30:38:0a (the last 12 bytes being "RFB 003.008" + newline).

(note I have disabled deflate to make things easier to read; the same happens with deflate enabled).

But the JS client never appears to receive this and certainly does not send a reply. It appears to work with wsproxy.

Any ideas how to debug this further?

kanaka commented 12 years ago

@abligh, sorry for the slow reply. I recently started a new job and haven't had any time to give attention to noVNC/websockify issues.

Unless you are using a very new version of Chrome, setting binary frame type won't work (I believe firefox just closes the connection if it receives it).

In addition, the include/websock.js lib currently doesn't support javascript binary data types (this is on my long term TODO list). But it is able to send binary data by base64 encoding/decoding the data (as indicated by the sub-protocol of 'base64' in the headers).

So you will need to base64 encode the payload and then send it as a text type frame. You'll need to base64 decode on received data. Also note that you should key off the 'base64' sub-protocol type. At some point in the future I will add direct binary data type functionality and then the sub-protocol value will be 'binary' in which case you should not base64 encode/decode and just send and receive raw binary frames.

If you are still working on this and come up with a good working implementation I wouldn't mind including it in the tree since it should be much smaller and simpler than the current C version that implements the entire WebSocket functionality too.

For now I'm closing the issue but feel free to continue posting questions here or in a new issue.

abligh commented 12 years ago

Joel,

--On 15 December 2011 13:07:16 -0800 Joel Martin reply@reply.github.com wrote:

@abligh, sorry for the slow reply. I recently started a new job and haven't had any time to give attention to noVNC/websockify issues.

No problem.

Unless you are using a very new version of Chrome, setting binary frame type won't work (I believe firefox just closes the connection if it receives it).

In addition, the include/websock.js lib currently doesn't support javascript binary data types (this is on my long term TODO list). But it is able to send binary data by base64 encoding/decoding the data (as indicated by the sub-protocol of 'base64' in the headers).

Indeed, it connects to an endpoint with a 'base64' protocol unconditionally (so I discovered), and expects base64 encoded data.

So you will need to base64 encode the payload and then send it as a text type frame. You'll need to base64 decode on received data. Also note that you should key off the 'base64' sub-protocol type. At some point in the future I will add direct binary data type functionality and then the sub-protocol value will be 'binary' in which case you should not base64 encode/decode and just send and receive raw binary frames.

Yes. I have this working now.

The main problem turned out to be libwebsockets had an obscure bug in its base64 implementation, which never got tickled processing headers etc. because the number of bytes converted was always a multiple of 4.

If you are still working on this and come up with a good working implementation I wouldn't mind including it in the tree since it should be much smaller and simpler than the current C version that implements the entire WebSocket functionality too.

I am still working on it.

It's pretty trivial to do (once you know the above) with libwebsockets for a single proxied connection. What is harder to do is support multiple asynchronous connections without ever blocking (you end up using pthreads), give protection against malicious users, and avoid forking. This has made what would otherwise be all of a couple of hundred lines into a bit of a monster, which in my case is non-portable (well, I have made no effort to achieve portability from Linux anyway).

What I might try to do is create an example in C of a simple compatible binary proxy that just does a fork() for every incoming connection.

I will ping the websockets guys to put my fix to their base64 routines into the library, as without that, nothing works. Happy to post that patch here too if that helps.

Alex Bligh

kanaka commented 12 years ago

Any progress?

abligh commented 12 years ago

Joel,

--On 23 December 2011 09:36:30 -0800 Joel Martin reply@reply.github.com wrote:

Any progress?

On the simple C proxy using libwebsockets? Not had time to look at it yet. It's one of the many things I am hoping to look at between Christmas and going back to work in the new year. However, it requires Andy Green to fix libwebsockets up, which he hasn't done yet - I will send him a third ping.

Alex

Reply to this email directly or view it on GitHub: https://github.com/kanaka/noVNC/issues/108#issuecomment-3262913

Alex Bligh

kanaka commented 12 years ago

k, thanks for the update.

abligh commented 12 years ago

Joel,

I decided to do this a different way, and write a websocket proxy module for apache, based on the apache-websocket module. This mostly works. See: http://blog.alex.org.uk/2012/02/16/using-apache-websocket-to-proxy-tcp-conne ction/

I've been fiddling around with making the tcp handling a little more efficient, adding internal authentication etc. (not in the tarball on the site), but as far as I can tell it works - well enough that I can get confused between my VMware Fusion window on my Mac and Chrome running novnc.

It's apache licensed. I have offered it to the apache-websocket maintainer. I have debian packaged versions here if that's interesting.

Alex

--On 15 December 2011 13:07:16 -0800 Joel Martin reply@reply.github.com wrote:

@abligh, sorry for the slow reply. I recently started a new job and haven't had any time to give attention to noVNC/websockify issues.

Unless you are using a very new version of Chrome, setting binary frame type won't work (I believe firefox just closes the connection if it receives it).

In addition, the include/websock.js lib currently doesn't support javascript binary data types (this is on my long term TODO list). But it is able to send binary data by base64 encoding/decoding the data (as indicated by the sub-protocol of 'base64' in the headers).

So you will need to base64 encode the payload and then send it as a text type frame. You'll need to base64 decode on received data. Also note that you should key off the 'base64' sub-protocol type. At some point in the future I will add direct binary data type functionality and then the sub-protocol value will be 'binary' in which case you should not base64 encode/decode and just send and receive raw binary frames.

If you are still working on this and come up with a good working implementation I wouldn't mind including it in the tree since it should be much smaller and simpler than the current C version that implements the entire WebSocket functionality too.

For now I'm closing the issue but feel free to continue posting questions here or in a new issue.

Reply to this email directly or view it on GitHub: https://github.com/kanaka/noVNC/issues/108#issuecomment-3169007

Alex Bligh

kanaka commented 12 years ago

@abligh, I linked to your post and tarball on the websockify Feature Matrix. Care to push your sources into a github repo? I would rather link to that than to a tarball if possible.

Thanks.

abligh commented 12 years ago

@kanaka

Joel,

I'd love to - the sensible git repo would be self.disconnect's one for apache-websocket itself, as you can't use it without that. I've asked him/her to put it up there; if that doesn't happen I'll either put it on github or git.alex.org.uk.

Alex

--On 24 February 2012 10:06:20 -0800 Joel Martin reply@reply.github.com wrote:

@abligh, I linked to your post and tarball on the websockify Feature Matrix. Care to push your sources into a github repo? I would rather link to that than to a tarball if possible.

Thanks.

Reply to this email directly or view it on GitHub: https://github.com/kanaka/noVNC/issues/108#issuecomment-4161852

Alex Bligh