Bring websockifiy.c up to date to support HyBi/IETF 6455 version of protocol about websockify HOT 29 CLOSED

Debug of noVNC:

[WebSocket] protocol doesn't match: 'undefined' != 'base64'
__error(message="%5BWebSocket%5D%20proto...ined'%20!%3D%20'base64'")web_socket.js (Zeile 303)
message = "%5BWebSocket%5D%20proto...ined'%20!%3D%20'base64'"
[Bei diesem Fehler anhalten] console.error(decodeURIComponent(message));

from websockify.

The websockify clients in other/ are in varying stages of being out of date. In particular the C and Node versions don't support the HyBi (IETF 6455) version of the WebSocket protocol. You are using a browser without native WebSockets support which means the Flash fallback for WebSockets is being used and that version only supports the newer protocol.

I recommend trying to get the python version working (that's the one I support and test). I don't have the time (or motivation) to bring the other versions up to date and they are mostly just for developer reference anyhow. There is somebody working on creating a version of websockify using libwebsockets: novnc/noVNC#108

I also take patches ;-)

from websockify.

thanks for the update.
the python version is working half, if i connect from remote (not per a local net) its taking around 5-10 sec in idle (buggy hostname to ip request?) but the easy workaround is set the timeout higher, then it works.
the python version is not working at all on winblows, thats why i tested the C version.
i just put two websockify's on a linux box (one for the linux and one for the winblows box) and now this problem is gone too :)

from websockify.

I assume you are talking about the connection timeout in noVNC? Can you post what websockify shows at the point after you have clicked connect, but before the connection actually happens? E.g. I'm wanting to know whether the delay is happening somewhere in websockify and is therefore fixable for the type of situation you are running into. Thanks.

from websockify.

no i didnt talk about that, i was talking about an delay if i connect remotly, it hangs for 5-10 seconds (no output form noVNC nor from websockify (python)). i guess its because websockify makes a ip to hostname lookup and times out after 5-10 seconds, there is no CPU usage of noVNC nor websockify.

from websockify.

If there is no output from websockify then what makes you think the delay is in websockify. It gives output when it receives a new connection before it has done any processing for it.

from websockify.

because i sniffed the traffic between, noVNC sends the requests (cant actually say which one, websockets are new for me and i dont have the pcap file anymore) and websockifiy idles for 5-10 sec. i tested it before remote with a pc from a friend and he had the 5-10 seconds delay too.

greetings

from websockify.

Perhaps you are observing the Flash policy request prior to the actual connection from noVNC. If your firewall is completely dropping (instead of doing a RESET/reject) requests to port 843 (the first port Flash tries to access) then it will likely have to timeout before it asks again on the real port for the Flash policy.

Another thing to test is with a browser that has real WebSocket support rather than using the Flash fallback (Chrome and recetn firefoxes).

from websockify.

i tested it on my friends pc with chrome.
the droping would explain the hang, why does it first try to connect over port 843? im going to sniff it and report back later.

from websockify.

got it, it trys to connect to port 843 2 times, each one with a timeout of 6 seconds.

from websockify.

The Flash policy request first attempts 843 because this is a privileged port and if the administrator of the server wants to restricts incoming Flash connections then they can run a policy server on port 843. Flash will then proceed to ask for a policy from the actual target port, but Flash must wait for 843 in case the policy on 843 overrides a policy returned on the target port. You should be able to get fast response by rejecting connections to 843 on your server (or the firewall in front of it) rather than just dropping the connections (which is often the default for firewalls these days).

I'm closing since this doesn't appear to be a problem with noVNC or websockify.

from websockify.

Or rather, I'll keep it open to track bringing websockify.c up to date if I (or somebody) else decides to tackle that.

from websockify.

I've been working on this issue and have an implementation which is at least partially working with hybi. I've been developing this for use with noVNC and another socket I need for a project. With the noVNC source, the C websockify version now works with Firefox 9, iPad and HP Touchpad web browsers. Opera still doesn't work, so there is room for improvement (although for my purposes, Opera isn't important, the mobile browsers are).

One caveat is that I am developing this for Windows CE, so we probably shouldn't just plop my code into the repository. The forking process has been replaced with Windows threading, and WSA is being used for sockets. I haven't been using preprocessor directives in the code as much as I should have, and the new hybi code will probably need some adjustments to work on Linux. For this I apologize.

Kanaka, I would be willing to submit these changes to you or someone else who could then decide what to integrate and merge with the source repository. The Windows CE compatibility relies on some other files which I don't feel comfortable providing--if there is a demand for this I could probably accommodate for this. Also, for the sha1 in the handshake I used 3rd party C code because the Windows CE library was too complicated for me to bother. I would be willing to provide this as well; it comes with some form of open-source license. Let me know how you want to handle this.

from websockify.

@dew111, I would certainly be interested in seeing the code. Can you do it as a github fork of my repo so that it is easy to view/comment/pull/merge?

from websockify.

I uploaded my versions of websocket.c, websockify.c and websocket.h in my own fork. It can be found at: https://github.com/dew111/websockify/tree/master/other

Although the C code might not be too popular, for embedded systems it's pretty handy. Even though there is a C# version for Windows which would probably work on CE without too much trouble, the system I'm developing on really can't afford that performance penalty.

from websockify.

@dew111, I didn't end up using much of your code, but you did motivate me to just get this done. So HyBi/IETF 6455 is now pushed in the C version. It probably won't build for you on Windows but it builds and works well (Chrome 15, Firefox 9) for me on Linux.

from websockify.

3 problems:

1; it cant read the ssl cert file (its working without ssl):

root@THINKPAD:/usr/local/bin/noVNC# /usr/local/bin/noVNC/utils/C/websockify --cert self.pem --ssl-only 5800 localhost:5900
Usage: [options] [source_addr:]source_port target_addr:target_port

  --verbose|-v       verbose messages and per frame traffic
  --daemon|-D        become a daemon (background process)
  --cert CERT        SSL certificate file
  --key KEY          SSL key file (if separate from cert)
  --ssl-only         disallow non-encrypted connections

SSL only and cert file '/usr/local/bin/noVNC/self.pem' not found
root@THINKPAD:/usr/local/bin/noVNC# ls -al self.pem 
-rw-r--r-- 1 root root 2095 2012-01-08 08:07 self.pem

2; the makefile isnt up to date:

cc -fPIC   -c -o websockify.o websockify.c
cc -fPIC   -c -o websocket.o websocket.c
cc  websockify.o websocket.o -lssl -lcrypto -lresolv -o websockify
make: *** No rule to make target `wswrapper.so', needed by `all'.  Stop.

3; wswrapper.so is missing and there is no way to build it.

from websockify.

@K1773R, generating an SSL cert is described at the top of websockify.c. I've also added the information to the README. I've also removed the remaining references to wswrapper in the Makefile (which addresses both 2 and 3).

from websockify.

dude im not retarded ;)
the cert works with the python version but not with the c version!
2nd and 3d problem solved now, ty!
take a look @ my first problem and read the whole post, there u see that the file exists and is readable!

from websockify.

@K1773R, so right, my apologies. I missed your ls. This was a problem with the --ssl-only option and I've fixed that now.

from websockify.

still not fully fixed, now this happens if you connect with ssl:

  0: got client connection from 127.0.0.1
  0: forking handler process
  0: non-SSL connection disallowed
  0: No connection after handshake
  0: handler exit

websockify still works without ssl, looks like the cert is readed wrong and so de decrypting failed? if you need a pcap just tell me ;)

from websockify.

@K1773R, that "non-SSL connection disallowed" indicates to me that noVNC is attempting to make a non-encrypted WebSocket connection. Make sure "encrypt" is selected from the settings menu.

Note that the WebSocket connection encryption is separate from the page itself (e.g. just because you use HTTPS to load noVNC, doesn't mean the WebSocket connection itself will be encrypted).

I just pushed a change to make the default WebSocket encryption setting match the mode of the page. Note that since noVNC settings are saved in cookies, this will only affect first load. If you have already loaded the page, then the encrypt setting will be whatever you last set it to.

from websockify.

it was selected, i always select "Encrypt" from the options and you dont have to tell me basics ;)

EDIT/UPDATE:

root@THINKPAD:/usr/local/bin/noVNC# /usr/local/bin/noVNC/utils/C/websockify --cert self.pem 5800 localhost:5900
Waiting for connections on :5800
  0: got client connection from 127.0.0.1
  0: forking handler process
  0: using plain (not SSL) socket
  0: using protocol HyBi/IETF 6455 13
  0: connecting to: localhost:5900
  0: empty frame
  0: client sent orderly close frame
  0: handler exit

sry i did copy the wrong one before ;)

from websockify.

@K1773R, I'm not sure then. It's definitely working for me with the latest websockify and with noVNC encrypt turned on. If I use --ssl-only and disabled the encrypt setting I get exactly the same messages from websockify as you posted.

It's possible that there is some disconnect between the UI setting and the actual URI that's being used. You could try instrumenting the connect() function in include/rfb.js to print the actual URI that's being used. It should be prefixed with "wss://" if it's encrypted.

from websockify.

i did edit my post just one or two minutes before ;)

from websockify.

i did check it again, if you connect with encrypted then websockify dosnt recognize that its encrypted with SSL (as u see above), therefore the connection fails!

from websockify.

I tested with the latest nightly build of Chromium (Chrome 18) and ran into other issues with SSL frames from the client. In Chrome 15 I always received whole frames from the client and so the code was simplistic (even in Chrome 18, non-SSL frames appear to arrive whole). I've removed the assumption in the C code and have buffering of HyBi frames now. I'm able to use SSL with Chrome 18 now. I've pushed those fixes.

It probably won't fix the failure to detect SSL, but there is a chance it will. If not we'll have to instrument your code a bit more to track this down. Let me know what you find with the latest that I pushed.

from websockify.

sry i was busy, i tested it and it works now without problems :) ty alot!

from websockify.

Great!

from websockify.