Connections close with reason: PROTOCOL_ERROR(1002): RSV bit(s) incorrectly set.}

[glassfishrobot]

Some connections close with that reason (RSV bit(s) incorrectly set), and I see them trying to reconnect with no success.

At the same time, many users report daily that they can't connect to the websocket server, most of them from non-windows OS (mainly Chromium OS).

The clients connect to the server using HTML5's Js Websocket library.

I can't reproduce the problem as it works in all my devices (Windows, Android and iOS).

What are the RSV bits? And why they may be "incorrectly set"? What can I do to track the root of the problem?

Thanks.

Environment

Debian 7.5

Affected Versions

[1.14]

[glassfishrobot]

• Issue Imported From: https://github.com/tyrus-project/tyrus/issues/607
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @pavelbucek

[glassfishrobot]

@glassfishrobot Commented Reported by soylomass

[glassfishrobot]

@glassfishrobot Commented soylomass said: The users with that problem open a connection, and it's closed almost immediately:

New connection with client: 3e909765-87e5-42bb-a845-217a047f47cf ... Close connection for client:

{3e909765-87e5-42bb-a845-217a047f47cf}

REASON

{PROTOCOL_ERROR(1002): RSV bit(s) incorrectly set.}

[glassfishrobot]

@glassfishrobot Commented @pavelbucek said: ad RSV bits: see https://tools.ietf.org/html/rfc6455#section-5.2

5.2\.  Base Framing Protocol

   This wire format for the data transfer part is described by the ABNF
   [RFC5234] given in detail in this section.  (Note that, unlike in
   other sections of this document, the ABNF in this section is
   operating on groups of bits.  The length of each group of bits is
   indicated in a comment.  When encoded on the wire, the most
   significant bit is the leftmost in the ABNF).  A high-level overview
   of the framing is given in the following figure.  In a case of
   conflict between the figure below and the ABNF specified later in
   this section, the figure is authoritative.

      0   1   2   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
     |N|V|V|V|       |S|             |   (if payload len==126/127)   |
     | |1|2|3|       |K|             |               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |               |Masking-key, if MASK set to 1  |
     +-------------------------------+-------------------------------+
     | Masking-key (continued)       |          Payload Data         |
     +-------------------------------- - - - - - - - - - - - - - - - +
     :     Payload Data continued ...:
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |     Payload Data continued ...|
     +---------------------------------------------------------------+

   ...

   RSV1, RSV2, RSV3:  1 bit each

      MUST be 0 unless an extension is negotiated that defines meanings
      for non-zero values.  If a nonzero value is received and none of
      the negotiated extensions defines the meaning of such a nonzero
      value, the receiving endpoint MUST _Fail the WebSocket
      Connection_.

I just checked Tyrus code and there is only single place where RSV (rsv1) bit is set - in PerMessageDeflate extension. Aren't you using that by any chance? If no, there might be something fishy in Chromium OS, I would go for tcp dump and see whether you really see any RSV bits set to anything else than 0.

Anyway, Tyrus server passes Autobahn tests suite (http://autobahn.ws/testsuite/), which covers RSV bits, so I highly doubt that this issue is originating from Tyrus...

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA TYRUS-430

[glomarch]

This bug still exists when use org.glassfish.tyrus.client.ClientManager to start websocket client. Other javax.websocket based client, such as org.java_websocket.client.WebSocketClient does not have such problem. The ClientManager is connected to javax.websocket endpoint running on Tomcat9 websocket server implementation.