FreeRTOS-Plus-TCP V4.0.0
FreeRTOS_IP.c#L1830
/* The IP-header type is copied to a special reserved location a few bytes before the message
* starts. In the case of IPv6, this value is never actually used and the line below can safely be removed
* with no ill effects. We only store it to help with debugging. */
pxNetworkBuffer->pucEthernetBuffer[ 0 - ( BaseType_t ) ipIP_TYPE_OFFSET ] = pxIPHeader_IPv6->ucVersionTrafficClass;
In my case, my NetworkEndPoint pxNext was overwritten.
— enviroment —
Arm Cortex-M4
arm-gnu-toolchain 12.3.1
There is space left at the beginning of each network buffer’s packet storage area to store some metadata, such as a pointer back to the network buffer structure and IP version info [please refer: ipconfigBUFFER_PADDING].
In the line referred in the question, the IP version info (IPv4 or v6) is stored in that left out space from the beginning of the network buffer, so that memory belongs to the network packet and shouldn’t be overwriting any other locations. When the pxUDPPayloadBuffer_to_NetworkBuffer function is called this stored info is reused to get back the network buffer from the UDP payload buffer.
The change in the value of pxNext you see should be something else. pxNext is set to NULL if its the last endpoint in the endpoint list. Also where is your xNetEndPointLocal variable stored?
When using BufferAllocation_1.c, pxGetNetworkBufferWithDescriptor does not pad the metadata area.
In the case of BufferAllocation_1.c the ethernet buffers are statically allocated by the network interface of the particular interface you are using.
During the xNetworkBuffersInitialise(), the call to vNetworkInterfaceAllocateRAMToBuffers will create aligned (aligment specific to each device) and padded buffers. [Example definition of vNetworkInterfaceAllocateRAMToBuffers for STM32F4xx]
