FreeRTOS / FreeRTOS-Plus-TCP

FreeRTOS-Plus-TCP library repository. +TCP files only. Submoduled into https://github.com/FreeRTOS/FreeRTOS and various other repos.
MIT License
125 stars 149 forks source link

[BUG] Allocation failure in `prvCreateSectors` is silently ignored, causing unexpected packet send failures later on #1149

Closed hlef closed 2 weeks ago

hlef commented 1 month ago

Describe the bug When the allocation of xTCPSegments in prvCreateSectors fails (here), an error code is returned. However this error code is ignored by the caller vTCPWindowCreate (here - see the explicit void cast). The result is a network stack that seems to correctly initialize, but fails to send packets through FreeRTOS_send later on.

We are encountering this issue in a setting where the network stack is initialized late, and not enough memory is available to satisfy the relatively large allocation in prvCreateSectors.

This is a very tricky issue to debug, because not all packets are impacted by this allocation failure. In our case, we perform a TLS handshake: the TCP handshake goes through, but the TLS client hello does not send because of this problem.

Target Any, AFAIK this is not a target-specific bug.

Host Same.

To Reproduce

Expected behavior The failure of prvCreateSectors should be noticed by vTCPWindowCreate, and further propagated up the call stack. This should ultimately result in the network stack failing to initialize.

Screenshots N/A.

Wireshark logs In Wireshark, we observe that the TCP handshake goes through, but the client hello packet of our TLS handshake is not sent.

Additional context N/A.

tony-josi-aws commented 1 month ago

Hi @hlef,

Thanks for reporting this issue. Please let us know if you prefer us to make a PR or if you prefer to create one since you have already figured out the cause of this bug.

hlef commented 1 month ago

Hi @tony-josi-aws I would prefer if you could handle the PR as this may take a while to reach the top of my TODO list :slightly_smiling_face:

tony-josi-aws commented 2 weeks ago

@hlef

Closing this ticket as PR #1152 should fix this issue.