websocket binary message splitting
Categories
(Core :: Networking: WebSockets, defect)
Tracking
()
People
(Reporter: nick, Unassigned)
Details
Attachments
(1 file)
|
196.72 KB,
application/x-compressed-tar
|
Details |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0
Steps to reproduce:
Firefox 75.0 on Linux/x64.
When sending a rapid series (every 10ms) of 2048 byte binary websocket messages, about 1% of the messages are split into two messages. The problem is sporadic and seems to be worse while other UI stuff is happening in FF. Smaller packet sizes lead to fewer incidents, and slower rates (50ms) practically eliminate it.
Actual results:
I've confirmed using wireshark that this is happening on the sending side ... where a message is split there are two TCP packets sent, each with a WebSocket header and the FIN bit set. The amount split off the end is always 16, 24, 32 or 48 bytes and those bytes are transmitted correctly, but as a separate message.
I've included a file 'captured_packets.txt' in the attached tarball which is the dump of a good message and the two packets of a split message. There's also a small bit of javascript code to demo the problem (in www) and a minimal websocket server (in src).
Also interesting: normally the packets alternate between masked and unmasked packets, but in this case both the split message and the unsplit message before it are unmasked.
Expected results:
This shouldn't happen at all: where a message is split across two WebSocket frames the FIN bit should be used to let the receiver know what's going on. The same code on Chrome doesn't have this problem either.
I grabbed the source code and I'm having a look at how to get MOZ_LOG to log stuff and also trying to understand the code, but figured I'd raise this now just to make a start on it ...
|
||
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Comment 2•5 years ago
|
||
Sounds like a low-level websockets issue. Valentin do you know this area, or can you suggest who to contact?
I think Michal might know.
|
||
Comment 4•5 years ago
|
||
Resetting severity to default of --.
|
||
Comment 5•5 years ago
|
||
(In reply to Nick Moore from comment #0)
I've confirmed using wireshark that this is happening on the sending side ... where a message is split there are two TCP packets sent, each with a WebSocket header and the FIN bit set. The amount split off the end is always 16, 24, 32 or 48 bytes and those bytes are transmitted correctly, but as a separate message.
I've included a file 'captured_packets.txt' in the attached tarball which is the dump of a good message and the two packets of a split message. There's also a small bit of javascript code to demo the problem (in www) and a minimal websocket server (in src).
I can't find packets from captured_packets.txt in captured_packets.pcapng. Packet 3147 is ACK and not a websocket frame. Anyway, all packets listed in captured_packets.txt are frames sent by the server to Firefox. It's obviously a bug in libwebsockets and not in Firefox.
|
Reporter | |
Comment 6•5 years ago
|
||
Oh gawd, you're right: I got the packet capture exactly backwards and those are the packets coming back out of the libwebsockets server. Which is somehow splitting them up incorrectly. Which explains why I couldn't see any problems when logging the packet writes in Firefox. Who knows why it didn't occur in Chrome, maybe just luck or timing.
Thanks & apologies for wasting your time :-(.
Description
•