Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with mdns server and now with websocket server too (IDFGH-5259) #7027

Closed
baldhead69 opened this issue May 16, 2021 · 61 comments
Closed
Labels
Awaiting Response awaiting a response from the author Resolution: Done Issue is done internally Status: Done Issue is done internally

Comments

@baldhead69
Copy link

Hi,

My mdns server and websocket server were working properly for a long time.
I ended up putting the project aside for few months because i am waiting for the launch of the esp32-s3 modules.

When i came back to the project i decided to do some tests, and the mdns server was behaving strangely.
Using wireshark i saw that the mdns server sent the ad for about 6 times and stopped(after manual reset).
The first 4 times every 1 seconds and the last 2 times every 2 seconds and stopped.
I configured mdns on menuconfig so that it would send the notification to the network every 1 second.

During this period we moved to an new internet provider and also to a new wifi router.
I thought the problem could be the new wifi router, but i haven't been able to find the problem yet.

So i decided to update the esp-idf.
I updated to v4.4-dev-1254-g639e7ad49.

After esp-idf update the mdns problem still persists.
And now the websocket server also bugged.

Using the idf.py monitor, i can see that websocket server start ok, but when i connect to the server through my android application, the following message appears:
W (00:00:08.807) httpd_ws: httpd_ws_get_frame_type: Failed to read header byte (socket FD invalid), closing socket now
W (00:00:08.816) httpd_ws: httpd_ws_get_frame_type: Failed to read header byte (socket FD invalid), closing socket now

Before the update of the esp idf, the websocket server worked ok, including "ESP-IDF Release v4.2.1".

Some suggestion on how to resolve the mdns server and now the websocket server bug ?

Note: i changed the httpd priority from "config.httpd.task_priority = tskIDLE_PRIORITY + 5" to "config.httpd.task_priority = configMAX_PRIORITIES".

@david-cermak

Thank's.

@espressif-bot espressif-bot added the Status: Opened Issue is new label May 16, 2021
@github-actions github-actions bot changed the title Issues with mdns server and now with websocket server too Issues with mdns server and now with websocket server too (IDFGH-5259) May 16, 2021
@david-cermak
Copy link
Collaborator

Hi @baldhead69

Could you please share more details:

  • About your application: is it based on some example? how is the ws_transport handled? Does it use TLS?
  • Share debug logs

The above warnings tell us, that an error occurred during tcp receive, enabling debug log would tell us, what kind of error it was (probably some kind of disconnection). Or maybe there already was an error on the warn level:

ESP_LOGW(TAG, LOG_FMT("error in %s : %d"), ctx, errno);

Cannot help much without more information, as now this looks to me like you've changed your network configuration, your project stopped working, so you switched to v4.4-dev which didn't help so raised this issue.

If your project is based on some of the httpd-ws examples in IDF, very unlikely there'd be a regression, as they are continuously tested in the CI. We have some pending fixed to httpd-ws, but nothing that would cause interrupted connections.

@baldhead69
Copy link
Author

baldhead69 commented May 19, 2021

Hi @david-cermak ,

I already uninstalled the v4.4-dev-1254-g639e7ad49.
I installed v4.2.1 now.

I dont switch the esp-idf versions on my computer.
I always need to edit my enviroment variables to esp-idf to work.

@baldhead69
Copy link
Author

Hi @david-cermak ,

Follow the attached responses:

Hi @baldhead69

Could you please share more details:

  • About your application: is it based on some example? how is the ws_transport handled? Does it use TLS?
    Yes, it use TLS.
  • Share debug logs

The above warnings tell us, that an error occurred during tcp receive, enabling debug log would tell us, what kind of error it was (probably some kind of disconnection). Or maybe there already was an error on the warn level:
The received data was all corrupted.

ESP_LOGW(TAG, LOG_FMT("error in %s : %d"), ctx, errno);

Cannot help much without more information, as now this looks to me like you've changed your network configuration, your project stopped working, so you switched to v4.4-dev which didn't help so raised this issue.
In version v4.2.1 the websocket server are OK.

If your project is based on some of the httpd-ws examples in IDF, very unlikely there'd be a regression, as they are continuously tested in the CI. We have some pending fixed to httpd-ws, but nothing that would cause interrupted connections.
The received data was all corrupted.

@david-cermak
Copy link
Collaborator

With the little info you've provided, we could only guess that the TLS handshake completed successfully and you're getting corrupted received data. No idea about the application, so assuming that you've registered a ws_handler() that getting the data, which are not exactly the ws-transport data, but something else. (this is strange, because previously you've reported interruption of the received data: : Failed to read header byte (socket FD invalid), closing socket now )

Listing the commits between v4.2.1...v4.4-dev-1254 I would fortune my guess to this one:

  • a1d5cfc example: Identify the callback whether is hanshake or frame-receive by req->method

Now the uri handler gets called immediately after the handshake. In the handler we can identify that this was the handshake by checking req->method as it is still a GET from the first part of the handshake the client has sent. On a normal websocket-frame-receive (when normally a websocket uriHandler gets called) this field is set to 0 Closes #6597

Could you please try to check for the req->method in your ws-handler and make sure the received data are not part of the WS handshake?

 static esp_err_t ws_handler(httpd_req_t *req)
 {
+    if (req->method == HTTP_GET) {
+        ESP_LOGI(TAG, "Handshake done, the new connection was opened");
+        return ESP_OK;
+    }
     ...
}

@baldhead69
Copy link
Author

Hi @david-cermak,

I dont have v4.4-dev-1254-g639e7ad49 installed anymore in my computer, only v4.2.1.

In v4.2.1 the websocket are working "perfectly" and in v4.4-dev-1254-g639e7ad49 the data was corrupted.

I dont change my cell phone app with both versions of esp-idf tests, so i suppose the bug is in the version v4.4-dev-1254-g639e7ad49.

I had the two problems in v4.4-dev-1254-g639e7ad49:
W (00:00:08.807) httpd_ws: httpd_ws_get_frame_type: Failed to read header byte (socket FD invalid), closing socket now
W (00:00:08.816) httpd_ws: httpd_ws_get_frame_type: Failed to read header byte (socket FD invalid), closing socket now

and

corruped data in websocket payload too.

@david-cermak
Copy link
Collaborator

suppose the bug is in the version v4.4-dev-1254

Yes, there could indeed be a bug in the latest IDF, but to find it, we would need your help. We have many applications which work perfectly on the latest v4.4-dev, and you seem to have one that fails (and used to work on v4.2!). Could you please share some portions of your app or at least a minimum project that could be used to reproduce the issue?

@Alvin1Zhang
Copy link
Collaborator

@baldhead69 Thanks for reporting. Would you please help share if any updates for this issue? Thanks.

@Alvin1Zhang Alvin1Zhang added the Awaiting Response awaiting a response from the author label Jul 14, 2021
@Alvin1Zhang
Copy link
Collaborator

@baldhead69 Thanks for reporting. Would you please help share if any updates for this issue? Thanks.

@baldhead69
Copy link
Author

Hi @Alvin1Zhang ,

Apparently all is working in v4.2.1 and not working in version v4.4-dev-1254-g639e7ad49.

When will esp32-s3 be made available to the general public ?

Could you provide me with samples of development boards with esp32-s3 ?

Thank's.

@david-cermak
Copy link
Collaborator

Apparently all is working in v4.2.1 and not working in version v4.4-dev-1254-g639e7ad49.

@baldhead69 Could you please share more details and a small portion of your application code to reproduce the issue as asked in #7027 (comment) ?

@Alvin1Zhang
Copy link
Collaborator

Thanks for reporting and sorry for late reply, regarding ESP32-S3 sample boards, please contact https://www.espressif.com/en/contact-us/get-samples, thanks.

@baldhead69
Copy link
Author

Hi @Alvin1Zhang ,

I send a "sales questions".

Thank's.

@david-cermak
Copy link
Collaborator

@baldhead69 Could you please share more details on this issue? The title says:

Issues with mdns server and now with websocket server too

but no mdns problem has been reported and the websocket server seems to work correctly on my end.

@baldhead69
Copy link
Author

Hi @david-cermak ,

What you need ?

Full project ?

I can sent to a private email.

@david-cermak
Copy link
Collaborator

@baldhead69 Just the piece of code that sets the https server up in websocket mode, if that's enough to reproduce the problem. I'd believe it would be about 20 lines of code calling the http-server API. This could be shared here.

It would be also great to remove the mdns part from the issue title, not only to keep reporting clean, but also for sake of other users who might search for the "open" issues.

I can sent to a private email.

That might be helpful, too, but let's try with the snippet first. If you're willing to share the project via email, you can send it to my git address (present in any of my commits ), e.g.:

cd esp-idf
git fetch
git show dbbf21 | grep Author

@baldhead69
Copy link
Author

baldhead69 commented Jul 27, 2021

@david-cermak

static httpd_handle_t server = NULL;

static void start_webSocket_secure_server()
{    
    httpd_ssl_config_t config = HTTPD_SSL_CONFIG_DEFAULT();    // Considerar usar wolfssl lib, pois usa menos memoria ram(metade da lib mbedTls). 

    config.httpd.core_id = PRO_CPU_NUM;
    config.httpd.max_open_sockets = open_sockets_max;  // 5
    config.httpd.task_priority =  tskIDLE_PRIORITY + 5;  // tskIDLE_PRIORITY + 20;  
    //config.httpd.open_fn = opened_socket_handler;
    config.httpd.close_fn = closed_socket_handler;
    //config.transport_mode = HTTPD_SSL_TRANSPORT_INSECURE;    // da para testar com ws://192.168.0.8/ 
    config.httpd.lru_purge_enable = false;    // The lib limits to "max_open_sockets" openned sockets, but closes one socket and opens another if "lru_purge_enable = true".  

#if enable_ws_Keep_Alive
    //UBaseType_t keepAliveTaskPriority = config.httpd.task_priority + 1;    
    UBaseType_t keepAliveTaskPriority = tskIDLE_PRIORITY + 4;
#endif

    ESP_LOGI(TAG, "Starting WebSocket Secure Server");


       
    extern const unsigned char cacert_pem_start[] asm("_binary_cacert_pem_start");
    extern const unsigned char cacert_pem_end[]   asm("_binary_cacert_pem_end");
    config.cacert_pem = cacert_pem_start;
    config.cacert_len = cacert_pem_end - cacert_pem_start;

    extern const unsigned char prvtkey_pem_start[] asm("_binary_prvtkey_pem_start");
    extern const unsigned char prvtkey_pem_end[]   asm("_binary_prvtkey_pem_end");
    config.prvtkey_pem = prvtkey_pem_start;
    config.prvtkey_len = prvtkey_pem_end - prvtkey_pem_start;


    esp_err_t ret = httpd_ssl_start(&server, &config);
    
    if ( ret != ESP_OK )
    {
        ESP_LOGE(TAG, "Failed to start the server!");
        printf("\nError->httpd_ssl_start: %d\n", ret);
        return;
    }
    			
    printf("\nserver = %p\n\n", server );


    // URI handler for websocket client(s) message reception.
    static const httpd_uri_t get_clients_message =
    {
        .uri       = "/",  
        .method    = HTTP_GET,
        .handler   = get_clients_message_handler,
        .user_ctx  = NULL,
        .is_websocket = true
    };
    httpd_register_uri_handler(server, &get_clients_message);
   
    
#if enable_ws_Keep_Alive
    ret = ESP_FAIL;
    ret = ws_init_keep_alive_task( 1000, ws_clients_list.max_list_size, 30, keepAliveTaskPriority, server );

    if ( ret != ESP_OK )
    {
        printf("\nError->init_Ws_Keep_Alive_Task: %d\n", ret);     
        return;
    }
#endif
}

@david-cermak
Copy link
Collaborator

@baldhead69 Thanks for sharing the code. I've been testing it and found no issues. But I used this *very simple handler as your get_clients_message_handler():

static esp_err_t get_clients_message_handler(httpd_req_t *req)
{
    if (req->method == HTTP_GET) {
        ESP_LOGI(TAG, "Handshake done, the new connection was opened");
        return ESP_OK;
    }
    httpd_ws_frame_t ws_pkt;
    uint8_t *buf = NULL;
    memset(&ws_pkt, 0, sizeof(httpd_ws_frame_t));

    // First receive the full ws message
    /* Set max_len = 0 to get the frame len */
    esp_err_t ret = httpd_ws_recv_frame(req, &ws_pkt, 0);
    if (ret != ESP_OK) {
        ESP_LOGE(TAG, "httpd_ws_recv_frame failed to get frame len with %d", ret);
        return ret;
    }
    ESP_LOGI(TAG, "frame len is %d", ws_pkt.len);
    if (ws_pkt.len) {
        /* ws_pkt.len + 1 is for NULL termination as we are expecting a string */
        buf = calloc(1, ws_pkt.len + 1);
        if (buf == NULL) {
            ESP_LOGE(TAG, "Failed to calloc memory for buf");
            return ESP_ERR_NO_MEM;
        }
        ws_pkt.payload = buf;
        /* Set max_len = ws_pkt.len to get the frame payload */
        ret = httpd_ws_recv_frame(req, &ws_pkt, ws_pkt.len);
        if (ret != ESP_OK) {
            ESP_LOGE(TAG, "httpd_ws_recv_frame failed with %d", ret);
            free(buf);
            return ret;
        }
    }
    if (ws_pkt.type == HTTPD_WS_TYPE_TEXT) {
        ESP_LOGI(TAG, "Received packet with message: %s", ws_pkt.payload);
        ret = httpd_ws_send_frame(req, &ws_pkt);
        if (ret != ESP_OK) {
            ESP_LOGE(TAG, "httpd_ws_send_frame failed with %d", ret);
        }
        ESP_LOGI(TAG, "ws_handler: httpd_handle_t=%p, sockfd=%d, client_info:%d", req->handle,
                 httpd_req_to_sockfd(req), httpd_ws_get_fd_info(req->handle, httpd_req_to_sockfd(req)));
        free(buf);
        return ret;
    }
    free(buf);
    return ESP_OK;
}

Could you please share your ws handler, too? How do you use the httpd_ws_recv_frame() API? There were some changes to allow dynamic payload reception, but the old way should still be supported.

@baldhead69
Copy link
Author

Hi @david-cermak ,

I sent you an email.

@baldhead69
Copy link
Author

baldhead69 commented Jul 28, 2021

Hi @david-cermak ,

The mdns stop of sending multicast packets after some time after esp32 turning on(some hours).

Edit:
i entered the list of connected and disconnected devices in the router and i verified that the esp32 was disconnected.
Maybe a wifi config issue.
I think esp32 tries to connect to router 5 times and stops.
I need to configure the wifi correctly(robustly) yet.

Do you have a open source robust wifi config to me use in esp32 ?

Thank's.

@david-cermak
Copy link
Collaborator

Hi @baldhead69

Thanks for sharing the project. I've made it compilable supplying some missing symbols (like the list of clients and the array of function pointers). And was able to reproduce an issue (not sure though if that was the issue you reported).
I was able to fix it quickly supplying a payload pointer:

static esp_err_t get_clients_message_handler(httpd_req_t *req)
{
+    ws_pkt.payload = buf;
    esp_err_t ret = httpd_ws_recv_frame(req, &ws_pkt, sizeof(buf));  // sizeof(buf) = 128 bytes

    if (ret != ESP_OK)
    {
#if webSocketDebug
        printf( "\nhttpd_ws_recv_frame failed with: %d code.\n", ret );
#endif
        return ret;
    }

After this change the project seemed to work correctly, didn't run the custom functions, but got the expected reply over ws transport: Given **it !!!

As mentioned earlier, there might be some minor inconsistencies of using the ws api between releases, but this was actually present on v4.2 as well:

https://github.com/espressif/esp-idf/blob/release/v4.2/examples/protocols/http_server/ws_echo_server/main/ws_echo_server.c#L73

Just a note, that if I understand your project correctly, you're implementing manually what has been implemented in this example on v4.3 and later, including a keep-alive module (it might be easier, as safer, too, to migrate to this type of project)

https://github.com/espressif/esp-idf/tree/release/v4.3/examples/protocols/https_server/wss_server


As for the mdns, we've been reported an issue with avahi #7124 causing the mdns library to stop responding (only with avahi and only after the TTL expires), but this is fixed already and backported to all release branches.

@baldhead69
Copy link
Author

@david-cermak,

I don't think you reproduced the problem correctly.

The "ws_pkt.payload = buf;" i initialize into another function.

@baldhead69
Copy link
Author

@david-cermak ,

With regards to Mdns, i checked again that esp32 was not sending the multicast packet to the network and i checked in the router list that esp32 was connected.

@baldhead69
Copy link
Author

@david-cermak

I installed de esp-idf version: v4.4-dev-2359-g58022f859, and the websocket bug yet exist.

static esp_err_t get_clients_message_handler(httpd_req_t *req)
{      
    esp_err_t ret = httpd_ws_recv_frame(req, &ws_pkt, sizeof(buf));  // sizeof(buf) = 128 bytes 
   
    printf( "\nhttpd_ws_recv_frame ret: %d code.\n", ret );
    int fd = httpd_req_to_sockfd(req);
    printf("Packet Socket: %d\n", fd );
    
    printf("Packet type: %d\n", ws_pkt.type);

    switch ( ws_pkt.type ) 
    {
        case HTTPD_WS_TYPE_CONTINUE:  printf("Packet type:   CONTINUE");   break;
        case HTTPD_WS_TYPE_TEXT:            printf("Packet type:   TEXT");             break;   
        case HTTPD_WS_TYPE_BINARY:        printf("Packet type:   BINARY");        break;
        case HTTPD_WS_TYPE_CLOSE:          printf("Packet type:   CLOSE");          break;
        case HTTPD_WS_TYPE_PING:            printf("Packet type:   PING");            break;
        case HTTPD_WS_TYPE_PONG:          printf("Packet type:   PONG");           break;
                                            default:          printf("Packet type:   UNKNOWN");  break;
    }
    
    printf("\n");

    ws_pkt.payload[ws_pkt.len] = '\0';    // printf("Got packet with message: %s\n", frame->payload);

    printf("Packet lenght: %d\n", ws_pkt.len);
    
    
    if( ws_pkt.type == HTTPD_WS_TYPE_TEXT )
    {
        printf("Packet messag: %s\n", ws_pkt.payload);    
    }
    else if( ws_pkt.type == HTTPD_WS_TYPE_BINARY )
    {
        printf("Packet messag BIN:\n");
        
        for( int i = 0 ; i < ws_pkt.len ; i++ )
        {        
            printf("buf[%d] = %u\n", i, ws_pkt.payload[i] );
        }
    }
    else
    {
        printf("\n\nPAYLOAD:\n\n");

        for( uint32_t i = 0 ; i < ws_pkt.len ; i++ )
        {
            printf("ws_pkt.payload[%u] = %u\n", i, ws_pkt.payload[i] );   
        }
        
        printf("\n\n");
    }    
     
    return ESP_OK;
   }

httpd_ws_recv_frame ret: 0 code.
Packet Socket: 55
Packet type: 0
Packet type:   CONTINUE
Packet lenght: 2


PAYLOAD:

ws_pkt.payload[0] = 50
ws_pkt.payload[1] = 0



httpd_ws_recv_frame ret: 0 code.
Packet Socket: 55
Packet type: 0
Packet type:   CONTINUE
Packet lenght: 2


PAYLOAD:

ws_pkt.payload[0] = 0
ws_pkt.payload[1] = 239

@baldhead69
Copy link
Author

Some suggestion ????

@baldhead69
Copy link
Author

@Alvin1Zhang

@Alvin1Zhang
Copy link
Collaborator

@baldhead69 Thanks for sharing updates, sorry for replying late, we are still investigate this issue, will update once we have any progress. Thanks.

@david-cermak
Copy link
Collaborator

I disabled the entire application.Theoretically, if the problem was the application, the websocket server should work, but it still has the same problem.

Remove rather than disable, but we already did this exercise and found no issue. These kind of problems are very hard to find and decide whether the culprit is the user part or the IDF part. Therefore we usually ask users to provide a minimal, reproducible example (i believe I asked for that in the very first reply).

After esp32 hard reset by me, the server takes about 5 to 10 seconds to boot.

This is weird, but very unlikely has any connection to the issue you're reporting. Is it the http server which takes that long to start? Checked the code you shared and didn't see any such delay.
Again, it's very hard to judge where the problem lies, so I'd suggest breaking your project down to smaller pieces to see if you reproduce the init problem separately.

If i don't send any data for the server, when the connection open, the server shows incoming data that does not exist.

I haven't noticed any received data when the connection stayed open with no data sent when testing your project. The wireshark log should reveal if any data are coming or not. Might your clients pinging the server, perhaps?


As mentioned above, we still wanted to follow these three points:

  1. git bisect
  2. debug mem-corruption
  3. wireshark log

Of course (repeating myself again), a minimal reproducible example would be very helpful

@baldhead69
Copy link
Author

baldhead69 commented Aug 20, 2021

If i don't send any data for the server, when the connection open, the server shows incoming data that does not exist.

I haven't noticed any received data when the connection stayed open with no data sent when testing your project. The >wireshark log should reveal if any data are coming or not. Might your clients pinging the server, perhaps?

In my android app i disabled the ping to test.
Javascript running on chrome dont send ping to server, because client websocket lib in browser dont have support for this.
As far as i know the websocket browser lib only responds with pongs(in background) to the pings sent by the server, but my server it's not sending ping to client/s.
And another thing, if the client pings the server, this ping was not supposed to show up in the uri handler.

Of course (repeating myself again), a minimal reproducible example would be very helpful

I just need to test with the wifi initialization implemented in esp-idf examples.
After this test i will send a email to you with a minimum reproducible code.

@baldhead69
Copy link
Author

If i don't send any data for the server, when the connection open, the server shows incoming data that does not exist.

I (00:00:36.589) WSS_SERVER: Opened Socket Function:
I (00:00:36.590) WSS_SERVER: hd = 0x3ffd51b0
I (00:00:36.591) WSS_SERVER: Opened socket = 55
I (00:00:36.597) WSS_SERVER: info: 1
I (00:00:36.602) WSS_SERVER: Opened WebSocket = 55
I (00:00:36.609) WSS_SERVER: open_connection: 55
I (00:00:36.615) WSS_SERVER: <LOG INIT>
I (00:00:36.619) WSS_SERVER: <LOG INIT>
I (00:00:36.624) CLIENTS LIST: ***************** Lista *******************
I (00:00:36.632) CLIENTS LIST: Connected wsClients: 1
I (00:00:36.639) CLIENTS LIST: fd_list[0] = 55
I (00:00:36.645) CLIENTS LIST: fd_list[1] = no_socket
I (00:00:36.652) CLIENTS LIST: fd_list[2] = no_socket
I (00:00:36.659) CLIENTS LIST: fd_list[3] = no_socket
I (00:00:36.665) CLIENTS LIST: fd_list[4] = no_socket
I (00:00:36.672) CLIENTS LIST: ********************************************
I (00:00:36.680) WSS_SERVER: </LOG END>
I (00:00:36.684) WSS_SERVER: </LOG END>
I (00:00:37.299) MY_APP: MALLOC_CAP_INTERNAL = 202879
I (00:00:37.299) MY_APP: MALLOC_CAP_SPIRAM = 4132439

W (00:00:41.693) httpd_txrx: httpd_sock_err: error in recv : 11
W (00:00:41.693) httpd_ws: httpd_ws_recv_frame: Failed to receive the second byte
I (00:00:41.697) WSS_SERVER: httpd_ws_recv_frame ret: -1 code.
I (00:00:41.704) WSS_SERVER: Packet Socket: 55
I (00:00:41.710) WSS_SERVER: Packet type: 0
I (00:00:41.716) WSS_SERVER: Packet type:   CONTINUE
I (00:00:41.723) WSS_SERVER: Packet lenght: 0
I (00:00:41.729) WSS_SERVER: PAYLOAD:
I (00:00:42.299) MY_APP: MALLOC_CAP_INTERNAL = 203035
I (00:00:42.299) MY_APP: MALLOC_CAP_SPIRAM = 4132439

Today i tested with ESP32-PICO-DevKitM-2 board and the problem persists.

@baldhead69
Copy link
Author

baldhead69 commented Aug 20, 2021

Hi @david-cermak

I sent "a minimal reproducible example code" to your email.

Even me using the wifi example code from esp-idf the problem persists.

I used the hotspot of my notebook too, created by windows to eliminate the access point variable and the problem persists.

@david-cermak
Copy link
Collaborator

@baldhead69 Thanks for sharing the project! Finally, I was able to reproduce the issue!

The problem is that the ws handler is also called upon http-get method, so that we misread the second byte of the WS protocol manually in the handler and read the first one instead. That's why the packet types and lengths were wrong.
This functionality was introduced in

You can fix it in your code adding this condition:

https://github.com/espressif/esp-idf/blob/master/examples/protocols/http_server/ws_echo_server/main/ws_echo_server.c#L70-L73

in your handler.

Sorry I haven't noticed you're also missing this condition in the first version you supplied, but that was largely incomplete so I filled the missing parts myself.


Also, please re-read my second post in this issue back from May

#7027 (comment)

where I guessed that this had been the very problem!

@baldhead69
Copy link
Author

baldhead69 commented Aug 20, 2021

@baldhead69 Thanks for sharing the project! Finally, I was able to reproduce the issue!

The problem is that the ws handler is also called upon http-get method, so that we misread the second byte of the WS protocol manually in the handler and read the first one instead. That's why the packet types and lengths were wrong.
This functionality was introduced in

I think this new feature is bad( commit a1d5cfc ). My suggestion is much better, however, the espressif team never wanted to apply it.

I think that when the server call the uri handler for the first time, the handshake is already finished, am I right ?
Considering i'm correct, i already used a "hello" code from my websocket client to communicate the server when the connection was open(very first message) and added the websocket client to the list of connected websocket clients(#5602 (comment) #5602 (comment)).

"Thanks baldhead. I appreciate your good work. It help a lot!"
https://www.esp32.com/viewtopic.php?f=13&t=16501

I opened this feature request a 3 days ago, but i've been asking for this solution for a long time(more than one year) and i think my idea also solves the issue #6597 besides my idea being a lot less workaround.

My feature request: #7431

You can fix it in your code adding this condition:

https://github.com/espressif/esp-idf/blob/master/examples/protocols/http_server/ws_echo_server/main/ws_echo_server.c#L70-L73

in your handler.

Sorry I haven't noticed you're also missing this condition in the first version you supplied, but that was largely incomplete so I filled the missing parts myself.

Also, please re-read my second post in this issue back from May

#7027 (comment)

where I guessed that this had been the very problem!

I tested the proposed "solution".

With local variables the "solution" works.

static esp_err_t get_clients_message_handler(httpd_req_t *req)
{
    httpd_ws_frame_t pkt;
    uint8_t bu[128] = { 0 };

    memset(&pkt, 0, sizeof(httpd_ws_frame_t));
    pkt.payload = bu;  
}

With static global variables the "solution" dont works.

static uint8_t buf[128] = { 0 };
static httpd_ws_frame_t ws_pkt;

static uint8_t state_buf[128] = { 0 };
static httpd_ws_frame_t ws_server_state_pkt;

static void init_frame_variables()
{    
    // Receiver and transmitter frame
    memset(&ws_pkt, 0, sizeof(httpd_ws_frame_t));
    ws_pkt.payload = buf;

    // Transmitter only frame
    memset(&ws_server_state_pkt, 0, sizeof(httpd_ws_frame_t));
    ws_server_state_pkt.payload = state_buf;
    ws_server_state_pkt.final = true;   
    ws_server_state_pkt.type = HTTPD_WS_TYPE_BINARY;
}

Why the first call to uri handler(when websocket client open connection) are of type "req->method == HTTP_GET" ?

Why the other calls to uri handler are of type "req->method == HTTP_DELETE" ?

@david-cermak
Copy link
Collaborator

Hi @baldhead69

Here's the complete diff of your project to make it working

diff -u components/communication/my_wss_server/src/webSocket_server.c
@@ -122,6 +122,11 @@
     return ESP_OK;
 */
 
+    if (req->method == HTTP_GET) {
+        return ESP_OK;
+    }
+    ws_pkt.payload = buf;
+    ws_pkt.len = 0;
 
     esp_err_t ret = httpd_ws_recv_frame(req, &ws_pkt, sizeof(buf));  // sizeof(buf) = 128 bytes

As for the feature requests, they are evaluated by component owner's team based on customer requests, if we have more customers, more likely the feature will be implemented (You know my opinion (and reasoning) on your suggestion of calling open_fd() after the handshake).

I have to admit, though, that the changes to cause your problems are breaking and should must not have been made between minor releases, no matter how experimental the ws-server feature is. Let me apologize for the inconvenience, we always try to pay particular attention to anything that may break existing application, but this changeset slipped through the net, sorry for that.

@baldhead69
Copy link
Author

baldhead69 commented Aug 22, 2021

Hi @david-cermak ,

So i assume this approach is correct for adding a websocket client to a list, right ?
"add_ws_client_to_list(sockfd)"

At the beginning of uri handler:

if( req->method == HTTP_GET )
{
    ESP_LOGI(WSS_SERVER_TAG, LOG_USER("Handshake done, the new connection was opened"));        
    int sockfd = httpd_req_to_sockfd(req);
    ESP_LOGI(WSS_SERVER_TAG, LOG_USER("Handshake Socket: %d"), sockfd); 
    add_ws_client_to_list(sockfd);
    printf("\n");    
    return ESP_OK;
}

Here the closed socket it was supposed to be websocket("HTTPD_WS_CLIENT_WEBSOCKET"), but it is returning 1
"HTTPD_WS_CLIENT_HTTP".
Unless this function "httpd_ws_get_fd_info( )" is only valid after the handshake and before the socket closes.

// typedef void (*httpd_close_func_t)(httpd_handle_t hd, int sockfd);

static void closed_socket_handler(httpd_handle_t hd, int sockfd)
{    
    ESP_LOGI( WSS_SERVER_TAG, LOG_USER("Closed socket Function:") );
    ESP_LOGI( WSS_SERVER_TAG, LOG_USER("hd = %p"), hd );
    ESP_LOGI( WSS_SERVER_TAG, LOG_USER("Closed socket = %d"), sockfd );
        
    // if( sockfd == websocket_Socket )
    httpd_ws_client_info_t info = httpd_ws_get_fd_info(hd, sockfd);
 
    ESP_LOGI(WSS_SERVER_TAG, LOG_USER("info: %d"), info );

    if( info != HTTPD_WS_CLIENT_WEBSOCKET )
        return;

    remove_ws_client_from_list(sockfd);
}

@david-cermak
Copy link
Collaborator

@baldhead69 Unfortunately none of these is possible if you wanted to keep the list of ws clients only. I would suggest listing all clients and sorting the ws clients out only if any action (pinging, sending async messages) needed.

  • the URI handler is called before the handshake for the ws clients, but also for standard http clients, so the condition above is true also if a common http request takes place with the same uri.
  • httpd_ws_get_fd_info() returns the ws type only if
    • ws handshake is completed
    • and at the same time the connection is not being closed

https://github.com/espressif/esp-idf/blob/master/components/esp_http_server/src/httpd_ws.c#L479

The latter is mostly true if your clients close the connection in a clean way (sending CLOSE frame) which most clients do.

Please understand that the ws server support in IDF is very simple. It's not a full featured websocket server, just a httpd that understands ws frames and some of the heavy-lifting is left for the user code.

@baldhead69
Copy link
Author

baldhead69 commented Aug 24, 2021

Hi @david-cermak ,

I followed the example code"https://github.com/espressif/esp-idf/blob/master/examples/protocols/http_server/ws_echo_server/main/ws_echo_server.c".

Partially code of function "static esp_err_t echo_handler(httpd_req_t *req)".

The ws_pkt.len are returning buggy values.

I (00:03:10.493) esp_https_server: performing session handshake
I (00:03:12.016) TAG: Handshake done, the new connection was opened
I (00:03:12.044) TAG: frame len is 1
I (00:03:15.503) TAG: frame len is 2
I (00:03:20.116) TAG: frame len is 5
I (00:03:20.118) TAG: frame len is 4
W (00:03:23.494) httpd_ws: httpd_ws_recv_frame: WS frame is not properly masked.
E (00:03:23.494) TAG: httpd_ws_recv_frame failed to get frame len with ESP_ERR_INVALID_STATE
I (00:03:23.500) WSS_SERVER: Closed socket handler:

I am using binary frame "HTTPD_WS_TYPE_BINARY".

static esp_err_t get_clients_message_handler(httpd_req_t *req)
{   
    if (req->method == HTTP_GET)
    {
        ESP_LOGI("TAG", "Handshake done, the new connection was opened");
        return ESP_OK;
    }

    httpd_ws_frame_t ws_pkt;    
    memset(&ws_pkt, 0, sizeof(httpd_ws_frame_t));
    
    /* Set max_len = 0 to get the frame len */
    esp_err_t ret = httpd_ws_recv_frame(req, &ws_pkt, 0);
    if (ret != ESP_OK) {
        ESP_LOGE("TAG", "httpd_ws_recv_frame failed to get frame len with %s", esp_err_to_name(ret));
        return ret;
    }

    ESP_LOGI("TAG", "frame len is %d", ws_pkt.len);

    return ESP_OK;    
}

@baldhead69
Copy link
Author

baldhead69 commented Aug 24, 2021

@david-cermak ,

As a suggestion could have a function that returns the payload size directly like for example:

static esp_err_t websocket_uri_handler( httpd_req_t *req )
{   
    if (req->method == HTTP_GET)
    {
        ESP_LOGI("TAG", "Handshake done, the new connection was opened");
        return ESP_OK;
    }

    size_t payload_size = httpd_ws_get_payload_size(req); 
}

@david-cermak
Copy link
Collaborator

@baldhead69 The original API works good, but you have to read the payload after checking the length. The same way it's outlined in the example. Otherwise next payload check reads the actual payload data from the network and reads incorrectly.

  // read length
  httpd_ws_recv_frame(req, &ws_pkt, 0); 
  // log length
  ESP_LOGI( WSS_SERVER_TAG, LOG_USER("length: %d"), ws_pkt.len );
  // read payload
  httpd_ws_recv_frame(req, &ws_pkt, ws_pkt.len);  // provided sizeof(buf) > ws_pkt.len

@baldhead69
Copy link
Author

@david-cermak

Except the first payload packet that has payload lenght 1 the rest of the payloads lenght is 4.
In addition, an error occurs after some receptions.

@david-cermak
Copy link
Collaborator

Hi @baldhead69

I wonder if you're really asking support questions or just randomly shuffle the lines in your handler to post a log proving that it doesn't work.
Please understand that GitHub issues are mainly used to track bugs in ESP-IDF and thus we rely on submitters to create clean and meaningful reports and keep the conversation to the point.
This helps the IDF support team and our community to handle issues smoothly and pays back to all users when searching for active or older issues, bugs and corresponding fixing commits.
What do you think about this report, what would anyone think when reading through this issue? Especially when experiencing trouble with mDNS or the WS server, or both?

About your query on the binary frames and "The ws_pkt.len returning buggy values" :
Here's the complete diff to make your snippet working:

diff -u components/communication/my_wss_server/src/webSocket_server.c
@@ -73,8 +73,6 @@
         ESP_LOGE("TAG", "httpd_ws_recv_frame failed to get frame len with %s", esp_err_to_name(ret));
         return ret;
     }
-    ws_pkt.payload = buf;
-    httpd_ws_recv_frame(req, &ws_pkt, sizeof(buf));
     ESP_LOGI("TAG", "frame len is %d", ws_pkt.len);
 
     return ESP_OK;

As mentioned above, the websocket support in httpd is very simple and we have to read the data continuously in the user handler (need to read the payload and set the ws_pkt.payload).

To my understanding, there are no issues with websocket server nor in mnds.
There are some incompatibilities between the v4.3 and current master, though.
I'd suggest updating the documentation on how to correctly write a handler. Since there's no real documentation of this feature, besides this Websocket server section and reference to the project and code, I will add a paragraph to the ws echo example
highlighting the need for checking the request method and setting a valid length and payload in the httpd_ws_frame_t before reading frames.

@baldhead69
Copy link
Author

baldhead69 commented Aug 25, 2021

@david-cermak

I commented about the payload size because i decided to do some experiments (learning) with dynamic allocation of the httpd_ws_frame_t structure and payload buffer.

I call a function that allocate the httpd_ws_frame_t and payload buffer and return a httpd_ws_frame_t pointer.

The freed allocated memory show in example.

Example:

static esp_err_t get_clients_message_handler(httpd_req_t *req)
{
    ESP_LOGI(WSS_SERVER_TAG, LOG_USER("URI HANDLER:"));
    ESP_LOGI(WSS_SERVER_TAG, LOG_USER("req->method = %d\n"), req->method);

    if( req->method == HTTP_GET )
    {
        ESP_LOGI(WSS_SERVER_TAG, LOG_USER("Handshake done, the new connection was opened"));        
        int sockfd = httpd_req_to_sockfd(req);
        ESP_LOGI(WSS_SERVER_TAG, LOG_USER("Handshake Socket: %d\n"), sockfd);         
        return ESP_OK;
    }
	
    httpd_ws_frame_t ws_pkt;    
    memset(&ws_pkt, 0, sizeof(httpd_ws_frame_t));
           
    // Set max_len = 0 to get the frame len
    esp_err_t ret = httpd_ws_recv_frame(req, &ws_pkt, 0);
    if (ret != ESP_OK)
    {
        ESP_LOGE(WSS_SERVER_TAG, "httpd_ws_recv_frame failed to get frame len with: %s\n", esp_err_to_name(ret));
        return ret;
    }
    
    ESP_LOGI(WSS_SERVER_TAG, LOG_USER("frame len is: %d\n"), ws_pkt.len);
    if( ws_pkt.len == 0 )
    {
        ESP_LOGE(WSS_SERVER_TAG, "ws_pkt.len == 0\n");
        return ESP_FAIL;
    }

    // Does not exist.
    // size_t payload_size = httpd_ws_recv_frame_payload_size(req);
    // ret = allocate_ws_frame_memory(payload_size, &ws_frame_mem);

    httpd_ws_frame_t* ws_frame_mem = NULL;
    
    ret = allocate_ws_frame_memory(ws_pkt.len, &ws_frame_mem);
    if( ret != ESP_OK )
    {
        ESP_LOGE(WSS_SERVER_TAG, "allocate_ws_frame_memory ERROR: %s\n", esp_err_to_name(ret));
        return ret;
    }

    ESP_LOGI(WSS_SERVER_TAG, LOG_USER("ws_frame_mem: %p"), ws_frame_mem);
    ESP_LOGI(WSS_SERVER_TAG, LOG_USER("ws_frame_mem->payload: %p\n"), ws_frame_mem->payload);

    ret = free_ws_frame_memory( &ws_frame_mem );
    if( ret != ESP_OK )
    {
        ESP_LOGE(WSS_SERVER_TAG, "free_ws_frame_memory ERROR: %s\n", esp_err_to_name(ret));
        return ret;
    }
    
    return ESP_OK;  
}


// This function is more interesting for sending packets than for receiving packets ?!
// inline maybe
static esp_err_t allocate_ws_frame_memory(size_t buf_size, httpd_ws_frame_t** allocated_ws_frame_memory)
{
    if( buf_size == 0 ) 
        return ESP_FAIL;

    *allocated_ws_frame_memory = calloc(1, sizeof(httpd_ws_frame_t));  
    if(*allocated_ws_frame_memory == NULL)
        return ESP_ERR_NO_MEM; 

    uint8_t* buf = calloc(buf_size, sizeof(uint8_t)); 
    if (buf == NULL)    
    { 
        free(*allocated_ws_frame_memory);       
        return ESP_ERR_NO_MEM; 
    } 

    (*allocated_ws_frame_memory)->fragmented = false;     
    (*allocated_ws_frame_memory)->final = true;  
    (*allocated_ws_frame_memory)->payload = buf; 
    (*allocated_ws_frame_memory)->len = buf_size;
    (*allocated_ws_frame_memory)->type = HTTPD_WS_TYPE_BINARY;

    ESP_LOGI(WSS_SERVER_TAG, LOG_USER("*allocated_ws_frame_memory: %p"), *allocated_ws_frame_memory); 
    ESP_LOGI(WSS_SERVER_TAG, LOG_USER("buf: %p"), buf);
    ESP_LOGI(WSS_SERVER_TAG, LOG_USER("(*allocated_ws_frame_memory)->payload: %p\n"), (*allocated_ws_frame_memory)->payload); 
    return ESP_OK; 
}


static esp_err_t free_ws_frame_memory(httpd_ws_frame_t** allocated_ws_frame_memory)
{
    if( (*allocated_ws_frame_memory == NULL) || (*allocated_ws_frame_memory)->payload == NULL )
        return ESP_FAIL;

    free( (*allocated_ws_frame_memory)->payload );
    (*allocated_ws_frame_memory)->payload = NULL;

    free( *allocated_ws_frame_memory );
    *allocated_ws_frame_memory = NULL;

    return ESP_OK;        
}

@espressif-bot espressif-bot added Status: In Progress Work is in progress and removed Status: Opened Issue is new labels Aug 26, 2021
@baldhead69
Copy link
Author

baldhead69 commented Aug 27, 2021

Hi @david-cermak

I discovered this option in "handle_ws_control_frames" in esp_http_server.h file.
/**
* Flag indicating that control frames (PING, PONG, CLOSE) are also passed to the handler
* This is used if a custom processing of the control frames is needed
*/
bool handle_ws_control_frames;

I enabled "handle_ws_control_frames" to receive PING frames from websockets clients.
The URI handler is being called when i get a ping from the websocket client, but an error occurs.

W (00:00:41.021) httpd_ws: httpd_ws_recv_frame: Failed to receive the second byte
I (00:00:41.021) WSS_SERVER: httpd_ws_recv_frame failed with: ESP_FAIL

What am i doing wrong ?

URI handler register:

    static const httpd_uri_t get_clients_message =
    {
        .uri       = "/ws",  
        .method    = HTTP_GET,
        .handler   = get_clients_message_handler,                
        .is_websocket = true,
        .handle_ws_control_frames = true,
        .user_ctx  = NULL,
        .supported_subprotocol = NULL
    };

URI HANDLER:

static uint8_t buf[64] = { 0 };
static httpd_ws_frame_t ws_pkt;

static esp_err_t get_clients_message_handler(httpd_req_t *req)
{       
    ESP_LOGI(WSS_SERVER_TAG, "URI HANDLER:");
    ESP_LOGI(WSS_SERVER_TAG, "req->method = %d\n", req->method);

    if( req->method == HTTP_GET )
    {
        ESP_LOGI(WSS_SERVER_TAG, "Handshake done, the new connection was opened");        
        int sockfd = httpd_req_to_sockfd(req);
        ESP_LOGI(WSS_SERVER_TAG, "Handshake Socket: %d\n", sockfd);        
        return ESP_OK;
    }

    memset(&ws_pkt, 0, sizeof(httpd_ws_frame_t));
    ws_pkt.payload = buf;
 
    // This function return ESP_FAIL. 
    esp_err_t ret = httpd_ws_recv_frame(req, &ws_pkt, sizeof(buf));   
    if( ret != ESP_OK )
    {   
        ESP_LOGI(WSS_SERVER_TAG, "httpd_ws_recv_frame failed with: %s\n", esp_err_to_name(ret));
        return ret;
    }
         
    if( ws_pkt.type == HTTPD_WS_TYPE_PING )
    {
        int sock = httpd_req_to_sockfd(req);
        ESP_LOGI(WSS_SERVER_TAG, "HTTPD_WS_TYPE_PING: %d\n", sock);        
        return ESP_OK;
    }
    return ESP_OK;
}

I tried the code below, based on "static esp_err_t ws_handler(httpd_req_t *req)" from "https://github.com/espressif/esp-idf/blob/master/examples/protocols/https_server/wss_server/main/wss_server_example.c",
But no luck.

I (00:00:12.750) esp_https_server: performing session handshake
I (00:00:14.725) WSS_SERVER: Handshake done, the new connection was opened
W (00:00:44.871) httpd_ws: httpd_ws_recv_frame: Failed to receive the second byte
E (00:00:44.871) WSS_SERVER: httpd_ws_recv_frame failed to get frame len with -1

URI HANDLER CODE:

static esp_err_t get_clients_message_handler(httpd_req_t *req)
{
    if (req->method == HTTP_GET) 
    {
        ESP_LOGI(WSS_SERVER_TAG, "Handshake done, the new connection was opened");
        return ESP_OK;
    }
    httpd_ws_frame_t ws_pkt1;
    uint8_t *buf = NULL;
    memset(&ws_pkt1, 0, sizeof(httpd_ws_frame_t));

    // First receive the full ws message
    /* Set max_len = 0 to get the frame len */
    esp_err_t ret = httpd_ws_recv_frame(req, &ws_pkt1, 0);
    if (ret != ESP_OK)
    {
        ESP_LOGE(WSS_SERVER_TAG, "httpd_ws_recv_frame failed to get frame len with %d", ret);
        return ret;
    }
    ESP_LOGI(WSS_SERVER_TAG, "frame len is %d", ws_pkt1.len);
    if (ws_pkt1.len)
    {
        /* ws_pkt.len + 1 is for NULL termination as we are expecting a string */
        buf = calloc(1, ws_pkt1.len + 1);
        if (buf == NULL)
        {
            ESP_LOGE(WSS_SERVER_TAG, "Failed to calloc memory for buf");
            return ESP_ERR_NO_MEM;
        }
        ws_pkt1.payload = buf;
        /* Set max_len = ws_pkt.len to get the frame payload */
        ret = httpd_ws_recv_frame(req, &ws_pkt1, ws_pkt1.len);
        if (ret != ESP_OK) 
        {
            ESP_LOGE(WSS_SERVER_TAG, "httpd_ws_recv_frame failed with %d", ret);
            free(buf);
            return ret;
        }
    }
    // If it was a PING
    if (ws_pkt1.type == HTTPD_WS_TYPE_PING)
    {
        ESP_LOGD(WSS_SERVER_TAG, "Received PING message");
        free(buf);
        int sockfd = httpd_req_to_sockfd(req); 
        ESP_LOGI(WSS_SERVER_TAG, "SOCKFD: %d", sockfd);        
        return ESP_OK;
    }    
    // If it was a BINARY message
    else if (ws_pkt1.type == HTTPD_WS_TYPE_BINARY)
    {
        int sock = httpd_req_to_sockfd(req);
        ESP_LOGI(WSS_SERVER_TAG, "HTTPD_WS_TYPE_BINARY: %d", sock);
        free(buf);
        return ESP_OK;
    }
    free(buf);
    return ESP_OK;
}

Maybe the problem is that the client ping has no message at all, ie, payload size is zero ?!

I am using OKHTTP client library.

@baldhead69
Copy link
Author

Hi @david-cermak ,

Can you help me solve the question about ping ?

The dynamic memory allocation for httpd_ws_frame_t and the payload buffer, at first i won't use.

Thank's.

@baldhead69
Copy link
Author

baldhead69 commented Aug 28, 2021

@david-cermak ,

I took two tests(using ws and not wss):

  • Send ping with payload and send ping without payload.

First test: Send ping with payload.

The websocket ping control frame call uri handler:

I (00:00:28.062) WSS_SERVER: Handshake done, the new connection was opened
I (00:00:28.070) WSS_SERVER: Handshake Socket: 55

I (00:00:28.162) WSS_SERVER: URI HANDLER:
I (00:00:28.166) WSS_SERVER: req->method = 0

W (00:00:28.172) httpd_txrx: httpd_sock_err: error in recv : 104
W (00:00:28.178) httpd_ws: httpd_ws_recv_frame: Failed to receive the second byte
I (00:00:28.186) WSS_SERVER: httpd_ws_recv_frame failed with: ESP_FAIL

JMeter_WS_PING_WITH_PAYLOAD
WebSocket Ping With Payload

Second test: Send ping without payload.

The websocket ping control frame call uri handler:

I (00:00:57.224) WSS_SERVER: Handshake done, the new connection was opened
I (00:00:57.233) WSS_SERVER: Handshake Socket: 55

I (00:00:57.325) WSS_SERVER: URI HANDLER:
I (00:00:57.328) WSS_SERVER: req->method = 0

W (00:00:57.382) httpd_ws: httpd_ws_recv_frame: Failed to receive the second byte
I (00:00:57.382) WSS_SERVER: httpd_ws_recv_frame failed with: ESP_FAIL

JMeter_WS_PING_WITHOUT_PAYLOAD
WebSocket Ping Without Payload

@baldhead69
Copy link
Author

@david-cermak ,

I already took the opportunity to test the websocket close control frame.

The websocket close control frame dont call uri handler:

I (00:00:23.257) WSS_SERVER: URI HANDLER:
I (00:00:23.258) WSS_SERVER: req->method = 1

I (00:00:23.258) WSS_SERVER: Handshake done, the new connection was opened
I (00:00:23.267) WSS_SERVER: Handshake Socket: 55

I (00:00:23.359) WSS_SERVER: Closed socket handler:
I (00:00:23.363) WSS_SERVER: hd = 0x3ffd5348
I (00:00:23.369) WSS_SERVER: Closed socket = 55

WebSocket Close Frame

@david-cermak
Copy link
Collaborator

@baldhead69 Please be kind to us and create a separate issue for the control frames. We will close this one, once we update the docs.

There might be some bugs in processing of ping frames with no payload, and passing the close frame to the handler. It is unrelated to this issue.

@baldhead69
Copy link
Author

baldhead69 commented Aug 30, 2021

@david-cermak

@baldhead69 Please be kind to us and create a separate issue for the control frames. We will close this one, once we update the docs.

OK, i will open a new issue.
Openned: #7493

There might be some bugs in processing of ping frames with no payload, and passing the close frame to the handler. It is unrelated to this issue.

There are some bugs in processing of ping frames with payload too.
I tested it with and without payload

@espressif-bot espressif-bot added Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally Resolution: Done Issue is done internally and removed Status: In Progress Work is in progress Resolution: NA Issue resolution is unavailable labels Sep 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting Response awaiting a response from the author Resolution: Done Issue is done internally Status: Done Issue is done internally
Projects
None yet
Development

No branches or pull requests

4 participants