[asterisk-bugs] [JIRA] (ASTERISK-28257) res_http_websocket: PING / PONG opcodes break data reception

[Jeremy Lainé (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-28257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremy Lainé updated ASTERISK-28257:
------------------------------------

    Attachment: mix-ping-and-fragmented-data.py

The `mix-ping-and-fragmented-data.py` script talks to Asterisk's echo websocket handler. It sends a fragmented message consisting of 10 fragments of 1000 bytes. In the middle of the fragmented message it sends a PING opcode to trigger the bug. This script requires the very latest `websockets` code:

pip install -e 'git+https://github.com/aaugustin/websockets.git#egg=websockets'


> res_http_websocket: PING / PONG opcodes break data reception
> ------------------------------------------------------------
>
>                 Key: ASTERISK-28257
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28257
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_http_websocket
>    Affects Versions: 16.1.1
>            Reporter: Jeremy Lainé
>         Attachments: mix-ping-and-fragmented-data.py
>
>
> Currently, PING / PONG opcodes are handled together with data reception. At a high level the logic looks like:
> - retrieve frame header
> - retrieve frame payload and apply unmasking
> - (reply to PING and stop here ONLY if replying fails)
> - (handle CLOSE opcode and stop here)
> - put payload into a re-assembly buffer and return it to the caller
> When data and PING / PONG opcodes and data are received consecutively, Asterisk behaves properly. However RFC 6455 specifies that control opcodes (PING / PONG / CLOSE) can be received in the middle of a fragmented message. In this case, Asterisk's logic breaks down, resulting in a truncated message being received.
> My suggestion to fix this is to align the behavior with the new CLOSE handling code and return immediately, without exposing the payload to the caller.



--
This message was sent by Atlassian JIRA
(v6.2#6252)