TLS short read when closing connection

[breyed]

WebSocket++ reports an error when it acts as a client and connects to a AspNetWebSocket with TLS.

This is the sequence:

1. WebSocket++ connects to AspNetWebSocket.
2. WebSocket++ initiates normal closure.
3. AspNetWebSocket calls CloseAsync (which sends a normal closure acknowledgement).
4. WebSocket++ reports the following messages:

[2013-06-09 19:59:43] [control] Control frame received with opcode 8
[2013-06-09 19:59:43] [error] got TLS short read, killing connection for now
[2013-06-09 19:59:43] [info] asio async_shutdown error: asio.ssl:335544539 (short read)
[2013-06-09 19:59:43] [error] Underlying Transport Error

5. WebSocket++ calls the close handler.
6. WebSocket++ reports the following message:

[2013-06-09 20:02:27] [disconnect] Disconnect close local:[1006,TLS Short Read] remote:[1000]
[2013-06-09 20:09:03] [info] asio async_read_at_least error: asio.ssl:336130329 (decryption failed or bad record mac)
[2013-06-09 20:09:03] [fatal] error in handle_read_frame: Underlying Transport Error (websocketpp.transport:2)

The last two messages only occurred when I sat at a breakpoint for a long time (a couple minutes?) immediately before CloseAsync was called.

Despite the messages, everything seems to work correctly and the fail handler does not get called.

[zaphoyd]

just a note: the fail handler is only called during the opening handshake. Either the open handler or the fail handler will be called. Once the connection has been open (i.e. open handler has been called) the fail will never be called. The close handler should be called on every connection no matter how it closed. There are connection methods that you can use to query the reasons the connection was closed.

The errors you posted seem to indicate that the TLS connection isn't being closed correctly by one of the endpoints. I'll see if I can dig more into what those specific error conditions are.

[RavikumarTulugu]

any updates on this ? i also frequently get this error.

[zaphoyd]

I've done a bit more research into Asio's "short read" read error. Most cases of tls short read are expected and should be ignored.

I've pushed an update that streamlines TLS related error handling. Some highlights:

• TLS short reads that should be ignored are now ignored
• Other TLS errors are now properly reported (rather than reporting as tls short reads or generic pass through)
• Additional information on the info channel about such other TLS errors
• Socket/TLS related shutdown errors that occur after a valid WebSocket close handshake are no longer reported as unclean WebSocket closes. You can still read information about them happening on the info channel if you are interested.

[TechnikEmpire]

Can you reference the diff or just the sources where you applied changes to resolve this problem? Unfortunately the interwebs seems lacking on results for this issue, in fact your thread here comes up #1 result if I use "boost" along with the ec.