Error: no handler for opcode 7

[binarykitchen]

Seeing this error + stack trace when using websocket-stream v3.3.3

Error: no handler for opcode 7
at Receiver.error (/var/www/videomail/production/source/node_modules/ws/lib/Receiver.js:321:18)
at Receiver.processPacket (/var/www/videomail/production/source/node_modules/ws/lib/Receiver.js:242:43)
at Receiver.add (/var/www/videomail/production/source/node_modules/ws/lib/Receiver.js:103:24)
at TLSSocket.realHandler (/var/www/videomail/production/source/node_modules/ws/lib/WebSocket.js:825:20)
at emitOne (events.js:96:13)
at TLSSocket.emit (events.js:188:7)
at readableAddChunk (_stream_readable.js:177:18)
at TLSSocket.Readable.push (_stream_readable.js:135:10)
at TLSWrap.onread (net.js:542:20) 

Any clues what this can be?

[lpinca]

You are receiving invalid frames. Opcodes 0x03-0x07 are reserved so you get an error.

[binarykitchen]

hmmm, weird, how can i debug best what's invalid about them? are there any specs saying that opcode 7 exactly means?

i am using them for a heavily used API and am thinking of DOS attacks or other hack attempts. hence very curious here ...

[lpinca]

The spec doesn't say much, it only says that those opcodes are reserved for further non-control frames, see https://tools.ietf.org/html/rfc6455#section-5.

[binarykitchen]

Thanks for the link. Chapter 5.8 Extensibility also says they can be used for more capabilities.

How would you debug this best? Really curious here about their contents.

[lpinca]

Yeah but the extension must be negotiated first. ws only support permessage-deflate and afaik that extension does not use those reserved opcodes.

[binarykitchen]

Hmmm, thanks. And what about the other question, how can I investigate + debug this best?

[lpinca]

What do you mean with "debug"? I'm not sure if this is done on purpose or it is the result of a faulty client. What you can do is log as much as you can when you get this error.

[binarykitchen]

Can't say if on purpose or faulty.

Log as much as I can? I already do but not much on the websocket level. Do you think it would be possible to wrap more information in errors thrown from Receiver.error?

For example I am curious who the sender is. What the recent buffer contents were. And so on.

[lpinca]

You can get some valuable info about the sender when you get the error as the upgradeReq is still there, for example:

ws.on('error', (err) => {
  if (err.message === 'no handler for opcode 7') {
    console.log(ws.upgradeReq.connection.remoteAddress);
    // or check the headers if you are behind a reverse proxy
  }
});

The buffer contents is simply discarded when you get the error, you may be able to read it but you have to monkey patch the Receiver.

[lpinca]

Closing this, please comment if needed.

[AshleyScirra]

This also appears to be occasionally crashing a node server we run in production.

Ideally the server will not crash if somebody sends it something invalid. This is a pretty nasty DOS vector. Shouldn't the server handle this reliably by default?

[lpinca]

@AshleyScirra it will not crash if you add, and you should, an error listener to your WebSocket objects.

[lpinca]

Throwing on not handled errors is default Node.js behavior.