About "No supported sub-auth types!"

[Iñaki Baz Castillo]

Hi, this is what I get when I try to connect to a VNC WebSocket server with the current master branch (note that logs are a bit different and I've added a few more):

noVNC:Websock onopen: server choose "binary" sub-protocol

noVNC:RFB _updateState() | msg: Starting VNC handshake

noVNC:RFB _negotiate_protocol_version() | server ProtocolVersion: 003.008

noVNC:RFB _updateState() | msg: Sent ProtocolVersion: 003.008

noVNC:RFB _negotiate_security() | server security types: 1,16

noVNC:RFB _updateState() | msg: Authenticating using scheme: 16

noVNC:RFB _negotiate_tight_auth() | clientSupportedTypes: {STDVNOAUTH__: 1, STDVVNCAUTH_: 2}

noVNC:RFB _negotiate_tight_auth() | serverSupportedTypes: []

noVNC:Input allKeysUp

noVNC:Websock close()

noVNC:ERROR:RFB _updateState() | msg: No supported sub-auth types!

So basically serverSupportedTypes is an empty array. Is there any explanation for this?

Thanks a lot.

[Joel Martin]

Does the problem happen with the master branch of noVNC without your changes? Also, what VNC server are you using? The server auth types comes from the server, so if it doesn't report any auth types supported by the client, they won't be able to match up and establish a connection.

[Iñaki Baz Castillo]

2015-02-19 23:18 GMT+01:00 Joel Martin <busk...@gmail.com>:
> Does the problem happen with the master branch of noVNC without your
> changes?

Yes:

Server choose sub-protocol: binary
Msg: Starting VNC handshake
<< WebSock.onopen
Server ProtocolVersion: 003.008
Msg: Sent ProtocolVersion: 003.008
Server security types: 1,16
Msg: Authenticating using scheme: 16
>> Keyboard.allKeysUp
<< Keyboard.allKeysUp
Closing WebSocket connection
Msg: No supported sub-auth types!

> Also, what VNC server are you using?

TightVNC: http://www.tightvnc.com/

I cannot yet say which exact version (will know tomorrow).

> The server auth types comes
> from the server, so if it doesn't report any auth types supported by the
> client, they won't be able to match up and establish a connection.

OK, so the server will just report supported auth types that match the
ones suggested by the client (noVNC), am I right? (sorry, I do almost
nothing about the VNC protocol).



Thanks a lot.


--
Iñaki Baz Castillo
<i...@aliax.net>

[Iñaki Baz Castillo]

It seems that the Tight server offers two auth types: 1 (NONE) and 16 (TIGHT).

Then the client chooses 16 (the highest one).

But within the _negotiate_tight_auth() function something fails.

I've added some more logs:

util.js:218 Msg: Starting VNC handshake

websock.js:350 --- WS received data in hex:  0x52 0x46 0x42 0x20 0x30 0x30 0x33 0x2e 0x30 0x30 0x38 0xa

util.js:218  Msg: Sent ProtocolVersion: 003.008

websock.js:350 --- WS received data in hex:  0x2

websock.js:166 --- Websock:rQwait() returns true | [num:2, goback:1]

websock.js:350 --- WS received data in hex:  0x1

websock.js:166 --- Websock:rQwait() returns true | [num:2, goback:1]

websock.js:350 --- WS received data in hex:  0x10

websock.js:170 --- Websock:rQwait() returns false | [num:2, goback:1]

util.js:218  Msg: Authenticating using scheme: 16

websock.js:166 --- Websock:rQwait() returns true | [num:4, goback:undefined]

websock.js:350 --- WS received data in hex:  0x0 0x0 0x0 0x0

websock.js:170 --- Websock:rQwait() returns false | [num:4, goback:undefined]

websock.js:166 --- Websock:rQwait() returns true | [num:4, goback:undefined]

websock.js:350 --- WS received data in hex:  0x0 0x0 0x0 0x0

websock.js:170 --- Websock:rQwait() returns false | [num:4, goback:undefined]

websock.js:170 --- Websock:rQwait() returns false | [num:0, goback:4]

util.js:220  Msg: No supported sub-auth types!

I know that this works if 1 (NONE) is chosen, however I don't know how to enforce noVNC to select 1 instead of 16.

Any tip please?

[Iñaki Baz Castillo]

Some logs improved:

util.js:218  Msg: Starting VNC handshake

websock.js:350 ---ibc: WS received data in hex:  0x52 0x46 0x42 0x20 0x30 0x30 0x33 0x2e 0x30 0x30 0x38 0xa

util.js:218  Msg: Sent ProtocolVersion: 003.008

websock.js:350 ---ibc: WS received data in hex:  0x2

websock.js:166 ---ibc: Websock:rQwait() returns true | [msg:"security type", num:2, goback:1]

websock.js:350 ---ibc: WS received data in hex:  0x1

websock.js:166 ---ibc: Websock:rQwait() returns true | [msg:"security type", num:2, goback:1]

websock.js:350 ---ibc: WS received data in hex:  0x10

websock.js:170 ---ibc: Websock:rQwait() returns false | [msg:"security type", num:2, goback:1]

util.js:218  Msg: Authenticating using scheme: 16

websock.js:166 ---ibc: Websock:rQwait() returns true | [msg:"num tunnels", num:4, goback:undefined]

websock.js:350 ---ibc: WS received data in hex:  0x0 0x0 0x0 0x0

websock.js:170 ---ibc: Websock:rQwait() returns false | [msg:"num tunnels", num:4, goback:undefined]

websock.js:166 ---ibc: Websock:rQwait() returns true | [msg:"sub auth count", num:4, goback:undefined]

websock.js:350 ---ibc: WS received data in hex:  0x0 0x0 0x0 0x0

websock.js:170 ---ibc: Websock:rQwait() returns false | [msg:"sub auth count", num:4, goback:undefined]

websock.js:170 ---ibc: Websock:rQwait() returns false | [msg:"sub auth capabilities", num:0, goback:4]

[Joel Martin]

The auth schemes that noVNC supports is defined in _negotiate_security and _negotiate_authentication and is based on what noVNC actually supports. The auth scheme is the highest numbered scheme that is supported by both client and server. That part is working though. It seems like the server is lying though because it appears from your logs to be telling the client that it supports tight authentication, but then sends an empty list of sub-auth types to the client. So the client is correctly saying that the server doesn't support any sub-auth types with the auth type that they agreed on, so negotiation stops. Can you connect to this same VNC server with a regular native VNC client?

[Iñaki Baz Castillo]

2015-02-20 15:32 GMT+01:00 Joel Martin <busk...@gmail.com>:
> The auth schemes that noVNC supports is defined in _negotiate_security and
> _negotiate_authentication and is based on what noVNC actually supports. The
> auth scheme is the highest numbered scheme that is supported by both client
> and server. That part is working though. It seems like the server is lying
> though because it appears from your logs to be telling the client that it
> supports tight authentication, but then sends an empty list of sub-auth
> types to the client. So the client is correctly saying that the server
> doesn't support any sub-auth types with the auth type that they agreed on,
> so negotiation stops. Can you connect to this same VNC server with a regular
> native VNC client?

Thanks a lot, I will try on next week.

[Iñaki Baz Castillo]

Sorry for the late response. Indeed the server is buggy. It is a
"customization" of the TightVNC server and yes, it's buggy.