opcodes are incorrect

[tdhsmith]

My connections seem to have incorrectly flagged opcodes/frame types. All of the outgoing frames are marked TEXT (opcode 0x1) and all the incoming frames are marked CONTINUATION (opcode 0x0), regardless of ground truth.

Here are the same 4 frames, shown first in the socket monitor and then in wireshark:


As seen in the right column, their true values are TEXT, TEXT, TEXT, BINARY, which was confirmed by dissection as well.

I understand it is likely an underlying issue and not one with this package itself, but I wanted to file the issue while I was dealing with it to investigate later. (Would this again be stemming from the SDK or from something closer to FF internals?)

[tdhsmith]

Actually I'm just realizing the inaccuracies are a bit larger than that:

• all frames are marked as having maskBit=true when they aren't (in my case messages from the server are being sent unmasked)
• disconnect frame is displayed as raw text with the reason code appended to the front. For example �ëonly text frames are supported, where the gibberish 0x03eb on the front should be parsed as reason code=1003.

(I don't have the capability right now to modify my stack to send true continuation frames with finBit=0, so I can't verify if the finBit is parsing correctly or not.)

[eliihen]

Yeah, the entire frame, including the metadata like opcode, comes from the Firefox API we're using to read websockets. We pretty much only map that to a string. I can't really give any info on the Firefox API because I haven't been that deep.

Let's try pinging @bakulf, he seems knowledgeable on the matter.

[bakulf]

Can I have a testcase? I would like to test it locally. @esphen, thanks.

[tdhsmith]

Here's a quick demonstration server in NodeJS, if that helps. Sorry for the messy code; threw it together on lunch break.

https://gist.github.com/tdhsmith/8e71aba02c684f549cdec05761e6e87b

You'll need to install ws first. Run the server with node server.js then browse to http://localhost:3000/ and the browser and client will each send a variety of frame types.

Here's what I see:

Server

-> TEXT         (0x1); MASKED
-> BINARY       (0x2); MASKED
<- BINARY       (0x2); unmasked
<- PING         (0x9); unmasked
<- PONG         (0xA); unmasked
<- TEXT         (0x1); unmasked
<- CONTINUATION (0x0); unmasked
<- CLOSE        (0x8)
-> PONG         (0xA); MASKED
-> CLOSE        (0x8)

(note that the ordering of the last few is off slightly due to when I'm calling the log commands relative to the actual message queue)

WireShark

Raw capture file is available in the gist above.

websocket-monitor