DTLS memory leak of 1 packet on each connection about netxduo HOT 14 CLOSED

Thanks for reporting this issue. I've created an internal tracking work item - we'll try to replicate your problem and let you know if we have any questions.

from netxduo.

It appears there may be an issue in the documentation - after a successful call to nx_secure_dtls_session_receive(), you need to release the packet that is returned. The sample code in the document is missing that call.

It's not immediately clear from your report if this will fix the specific issue you are seeing but it definitely would lead to a packet leak. See the following code with the added call to release the packet:

    /* Check for received application data. */
    if(receive_flag)
    {
        /* We have received data over a previously-established DTLS session.
           Mutex handling omitted for clarity. */
        status = nx_secure_dtls_session_receive(receive_dtls_session, &receive_packet,
        NX_IP_PERIODIC_RATE);


        /* Process received data… */
        status = nx_packet_data_extract_offset(receive_packet, 0, receive_buffer, 100,
             &bytes);
        /* Display the Client request data. */
       receive_buffer[bytes] = 0;
       printf("Received data: %s\n", receive_buffer);

/************* Add the following line ***************/
status = nx_packet_release(receive_packet);

        /* Prepare and send response to client. */
        status = nx_secure_dtls_packet_allocate(receive_dtls_session, &packet_pool,
            &send_packet, NX_IP_PERIODIC_RATE);


       /* Populate the packet with our response data. */
       nx_packet_data_append(send_packet, response_data, response_data_length,
            &pool_0, NX_WAIT_FOREVER);

        /* Send response to client. */
        status = nx_secure_dtls_server_session_send(receive_dtls_session,send_packet);
    }

from netxduo.

Thanks @tstapko.

Yes, there is also a memory leak here, but I already found and fix it before post this issue.

I think there is an other memory leak during handshake, because the memory appear even without receiving or sending any datas.

Below the pool stats :

Before a DTLS client connect :
IP Free TCP : 15 min - 18 now/ 22

When client is connected (but doesn't send any datas)
IP Free TCP : 13 min - 17 now/ 22

After client disconnect
IP Free TCP : 13 min - 17 now/ 22

Note : If I connect again, the value "now" decrease by now after each connexion.

If I add an osDelay(10); in nx_secure_tls_packet_release() before it calls nx_packet_release(), the memory leak disappear :

UINT nx_secure_dtls_packet_release_delayed(NX_PACKET *packet_ptr);
#define nx_secure_tls_packet_release nx_secure_dtls_packet_release_delayed

/**
 * ******************************************************************************
 *  Function Name: nx_secure_dtls_packet_release_delayed()
 * *******************************************************************************
 */
UINT nx_secure_dtls_packet_release_delayed(NX_PACKET *packet_ptr)
{
    osDelay(10);
    return nx_packet_release(packet_ptr);
}

After adding delay, the pool stats becomes : (memory leak is fixed)

Before a DTLS client connect :
IP Free TCP : 16 min - 18 now/ 22

When client is connected (but doesn't send any datas)
IP Free TCP : 13 min - 18 now/ 22

After client disconnect
IP Free TCP : 13 min - 18 now/ 22

from netxduo.

I cannot reproduce the problem. Can you share more details about your environments? Such as which platform is used and which network driver is used.

Can you set a breakpoint on nx_packet_release.c:114 to see if there are any failed attempts to release the packets?

from netxduo.

Yes.
It is on an STM32F4, the driver is from ST : https://github.com/STMicroelectronics/x-cube-azrtos-f4

For the breakpoint : Yes, when I open the connection the break point fire.

from netxduo.

Just a note : nx_secure_dtls_server_session_start() is called in dtls_server_thread and not in IP/driver thread (callback), can it cause issue ?

from netxduo.

@yanwucai Instead of adding a osDelay(10) to each call to nx_secure_tls_packet_release(), I try to find the calls where they are needed.
I found that adding a delay here is all that is needed to solve the memory leak :

As your first hunch, it seems that the problem is related to the ethernet driver.

Note : on the STM32F4 driver, DMA is used to send packets, and an IT is generated when the packet is sent.

Any ideas to solve this issue properly?

from netxduo.

It won't cause issue if nx_secure_dtls_server_session_start() is called in dtls_server_thread.

Does the IP thread have higher priority than the DTLS server thread?

from netxduo.

Moving the delay here at the end of handshake also solve the leak issue.

It seems that calling _nx_secure_dtls_retransmit_queue_flush() before all packet were sent (or while a packet is sent) cause the memory leak.

from netxduo.

Does the IP thread have higher priority than the DTLS server thread?

I tried both, without osDelay() the memory leak appear.
Is their any recommandation for DTLS tread priority ?

from netxduo.

@yanwucai, I think I found the issue, but I don't know how to fix it properly :

On STM32F4 driver :

• DMA is used to transfer packet. (So IP/Driver thread doesn't wait the end of transfert)
• An IT fire at the end of DMA transfert and set the flag NX_DRIVER_DEFERRED_PACKET_TRANSMITTED.
  It causes IP/Driver execution, which call _nx_packet_transmit_release() where nx_packet_queue_next is set to NX_DRIVER_TX_DONE as below :

• When nx_packet_queue_next is set to NX_DRIVER_TX_DONE, calling _nx_secure_dtls_retransmit_queue_flush() will release the buffer.
  

But in my case, _nx_secure_dtls_retransmit_queue_flush() is certainly called BEFORE the end of transfert, so nx_packet_queue_next is NOT set to NX_DRIVER_TX_DONE yet and packet isn't released....

It also explain why the delay solve this issue.

Is their a way to wait all packets be sent before calling _nx_secure_dtls_retransmit_queue_flush() at the end of the DTLS handshake ? (Instead of the osDelay(10))

from netxduo.

Can you replace Line 94 - 96 in nx_secure_dtls_retransmit_queue_flush.c with the following lines and see if it can solve the issue?

    while (packet_ptr &&
           (packet_ptr != (NX_PACKET *)NX_PACKET_ENQUEUED))

from netxduo.

Thanks for this reply, I will test on the board beginning of next week

from netxduo.

@yanwucai : your fix works perfectly, thanks.

from netxduo.