websocket client decided to send first a FIN then a continuation, which is not allowed?! (IDFGH-11736)

[0xFEEDC0DE64]

Answers checklist.

• I have read the documentation for esp-protocols components and the issue is not addressed there.
• I have updated my esp-protocols branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

What component are you using? If you choose Other, provide details in More Information.

esp_websocket_client

component version

modem-v1.0.5

IDF version.

v5.3-dev-1043-g8c9e29898f

More Information.

websocket client unexpectatly sends first a FIN text message, then a continuation, which causese my websocket server to kick out esp32 connections.
I have added a few log statements to esp-protocols to follow this:

I (107646) CMDHANDLER: connected! socketIdentifier=cloud                             
I (107646) websocket_client: esp_websocket_client_send_with_exact_opcode() opcode=129 len=223                                                                              
I (107646) transport_ws: esp_transport_ws_send_raw() opcode=129 len=223              
I (107656) transport_ws: _ws_write() opcode=129 len=223                              
I (107666) websocket_client: esp_websocket_client_send_with_exact_opcode() esp_transport_ws_send_raw() returned 223                                                        
I (107686) CMDHANDLER: executing command type=hello socketIdentifier=cloud is_secured=true                                                                                 
I (107686) CMDHANDLER: skip=0                                                        
W (107706) CMDHANDLER: scan overflowed                                               
I (107706) websocket_client: esp_websocket_client_send_with_exact_opcode() opcode=129 len=2435                                                                             
I (107706) transport_ws: esp_transport_ws_send_raw() opcode=129 len=1024             
I (107716) transport_ws: _ws_write() opcode=129 len=1024                             
I (107726) websocket_client: esp_websocket_client_send_with_exact_opcode() esp_transport_ws_send_raw() returned 1024                                                       
I (107736) transport_ws: esp_transport_ws_send_raw() opcode=0 len=1024               
I (107736) transport_ws: _ws_write() opcode=0 len=1024                               
I (107746) websocket_client: esp_websocket_client_send_with_exact_opcode() esp_transport_ws_send_raw() returned 1024                                                       
I (107756) transport_ws: esp_tr[0;port_w3_sen) rsw_) rp_oum=_ les=387ncorrect size o;32mIe dump66) tra 2p9r41w5: _0m_write() opcode=0 len=387                              
I (107766) websocket_client: esp_websocket_client_send_with_exact_opcode() esp_transport_ws_send_raw() returned 387                                                        
E (107786) transport_base: poll_read select error 104, errno = Connection reset by peer, fd = 57                                                                           
E (107786) websocket_client: esp_transport_read() failed with -1, transport_error=ESP_OK, tls_error_code=0, tls_flags=0, errno=119                                         
W (107806) CLOUD: WEBSOCKET_EVENTS event_id=WEBSOCKET_EVENT_ERROR esp_transport_read() failed with -1, transport_error=ESP_OK, tls_error_code=0, tls_flags=0, errno=119    
E (107816) websocket_client: Error receive data                                      
I (107826) websocket_client: Reconnect after 10000 ms 

the first message succeeds as it has len=223 (which is <1024), the second message fails (which is >1024 and needs to be buffered in continue packets)

please revert to the old behaviour again, this feature was working for the past years without problems.

we are using esp-protocols as submodule which contains esp modem and esp websocket client for us. we only wanted to update esp_modem but for some reason both are stuck together in a monorepo, now we are facing this websocket issue

[0xFEEDC0DE64]

[gabsuren]

@0xFEEDC0DE64 thank you for rising an issue.
The esp_websocket_client_send_**with_exact**_opcode is a newly introduced API, and it maintains compatibility with previous versions of the WebSocket client. Have you previously used esp_websocket_client_send_with_opcode maybe? If so, please note that this API remains unchanged

[0xFEEDC0DE64]

I havent touched the rest of our code, just updated the esp-protocols, is it possible for existing API to keep its functionality and create new apis with different behaviours? especially since the websocket code still splits up messages, but does it incorrectly now

[0xFEEDC0DE64]

I tried to fix the api here:
#461

[david-cermak]

seems like a regression from fae80e2

esp_websocket_client_send_with_opcode()newly adds a FIN flag in here:

esp-protocols/components/esp_websocket_client/esp_websocket_client.c

Line 1230 in a6845f4

ret = esp_websocket_client_send_with_exact_opcode(client, opcode | WS_TRANSPORT_OPCODES_FIN, data, len, timeout);