FreeRTOS+TCP-MULTI library update to v2.3.2

I am facing issue while updating the FreeRTOS+TCP-Multi from 160112 release library to v2.3.2. here is the link from where i downloaded the zip (

While updating it gives me linking error.
for eg:-
Linking CXX executable SCM-E-MODBUS-STM32.elf

Multi/source/FreeRTOS_Sockets.c:2251: undefined reference to `xApplicationGetRandomNumber’.

Similar to this there are other FreeeRTOS files which give the same error while linking.
I want to know that is there a case where i am not considering backward compatiblity with the previous version.

Thanks and Regards

Any function that starts “Application” is something the application writer is supposed to provide - a callback. In this case it is calling back to the application to give the opportunity for the application to generate a true random number if the hardware is capable of doing so - if the hardware has a TRNG.

First of all, the official location of the FreeRTOS+TCP library is here, and the IPv6/multi branch can be found here.

You will find several clones on Github like mine, but those are all running more or less behind.

Beside these 2 locations there are LTS releases ( Long Term Support ).

When I google the missing function xApplicationGetRandomNumber(), it brings to Working Example for FreeRTOS+TCP and STM32F7. It describes well what the function should do.

The following function ( “application hook” ) probably also lacks some description:

/* Create an initial sequence number (ISN), to be used for a TCP connection
 * between two IP-addresses / port numbers.
 * In most cases it will be sufficient to call xApplicationGetRandomNumber.
uint32_t ulApplicationGetNextSequenceNumber( uint32_t ulSourceAddress,
                                             uint16_t usSourcePort,
                                             uint32_t ulDestinationAddress,
                                             uint16_t usDestinationPort );

It is asking for a random an initial sequence number. In the simplest case you just return a random number that you obtained by calling xApplicationGetRandomNumber().

I have written documentation about these functions but apparently it is still “in the pipeline”.

As per your suggestion. I have implemented the xApplicationGetRandomNumber callback function and the linking problem is been solved.


@htibosch Thanks for informing about the official location of FreeRTOS+TCP library. I have replaced it with the current lib in use and after implementation of xApplicationGetRandomNumber this issue undefined reference to `xApplicationGetRandomNumber’. is resolved.



I have compiled the new library and observed the ping over TCP using ethernet.
Following is the snapshot of wireshark.

  1. This is the tarffic observed when there is no ping check done from cmd terminal.

  2. This is the traffic observed when ping is checked from cmd.

  3. This is the ping I have observed after the integration of new FreeRTOS+TCP-Multi library. The ping is getting lost in between after every few sec and it goes on.

Is the observed ping pattern due to new FreeRTOS+TCP-Multi library integration ?

Thanks and Regards
Prince Tripathi

Hello @Prince,

In the last snapshot (3) that you have attached, I am seeing 2 IP addresses - and And both of them seem to be being pinged. That is something unusual.

Looking at the snapshot (2) - I am seeing that ARP is not being resolved for quite some time (frames 20-37). Can you put a breakpoint in your code and try to look what happens when an ARP request is received by the FreeRTOS+TCP stack? The ping starts back again after there is gratuitous ARP after ~10s (frames 38 & 39).

There are many things which can cause an ARP packet to be discarded. You can check that by stepping through the code.

Let me know if that helps (and works),

Hi @kanherea

  1. In the last snapshot (3) the system IP( Computer IP address) is and is the static IP address of the device we need to check. So only device IP address is getting pinged.
  2. Sure, I will put a break point in code and look for the reason for packet discard and let you know



I have debugged through the ARP code and put a break point in the following function

eFrameProcessingResult_t eARPProcessPacket( NetworkBufferDescriptor_t * pxNetworkBuffer )

inside the loop where operation related to ARP_REQUEST and ARP_REPLY is decided.
But the code is not getting break at inside this loop. So is this the problem related to ARP.

if( ( pxTargetEndPoint != NULL ) && ( pxTargetEndPoint->bits.bEndPointUp != pdFALSE_UNSIGNED ) )


switch( pxARPHeader->usOperation )



vARPProcessPacketRequest( pxARPFrame, pxTargetEndPoint, ulSenderProtocolAddress );

eReturn = eReturnEthernetFrame;


case ipARP_REPLY:

vARPProcessPacketReply( pxARPFrame, pxTargetEndPoint, ulSenderProtocolAddress );



/ Invalid. /





When I unplug a FreeRTOS+TCP device from my LAN, ping will complain like this:


Pinging with 32 bytes of data:
Reply from bytes=32 time<1ms TTL=64
Reply from bytes=32 time<1ms TTL=64
Request timed out.  // Unplugged the network cable here
Request timed out.
Request timed out.
Request timed out.

When your ping says that “Destination Host unreachable”, I think that you should inspect the network setup, and especially the routing.
I found a good explanation about ping here.

It is also worth checking if the the IP address is unique in your LAN. A while ago there was a post with a similar complaint, saying that ping was answered only for a short while.
Please have a look here.

@Prince, could you do a test, make the following define in your FreeRTOSIPConfig.h:

#define arpGRATUITOUS_ARP_PERIOD    ( pdMS_TO_TICKS( 1000U ) )

and then run continuous ping test:

ping -n 1000

With the define, +TCP will emit a gratuitous ARP request every second. I am curious if it changes the ping behaviour.

If possible, it would also be helpful if you can make a PCAP and attach that in a ZIP file.
Before saving the PCAP file, you can apply a filter like “ip.addr== || arp”.

1 Like

I have test the code by making
define arpGRATUITOUS_ARP_PERIOD ( pdMS_TO_TICKS( 1000U ) )

And run continuous ping test,

  1. The result was that instead of showing the “Destination Host unreachable” it gives a ping time above 1000ms after every few ping and hence continues the same behaviour. Following is the screenshot of the command prompt.

  1. Also i have seen the packets on wireshark. Following is the attcahed PCAP file observed

Processing: PCAPFile.pcap… (13.7 KB)


  1. The IP address and are my device IP address and and is the IP Address of local system from where i am pinging the device. These IP address are fine.


@Prince, thanks for doing the experiment and for attaching the PCAP file. I think that we have come closer to the cause. I think that the device does not receive, or does not allow broadcast packets, i.e. packets that have the ff:ff:ff:ff:ff:ff MAC-address as the destination.
And so it does not receive broadcasted ARP packets.

Are you using an original driver, found on Github?

Are you working with an STM32? Which part exactly? ( I think of STM32 because you mentioned “CXX executable SCM-E-MODBUS-STM32.elf” ).

If it is an STM32, you might want to look for the field BroadcastFramesReception as here:


Are broadcast packets allowed in your LAN, will they be forwarded? How is the host connected to the device? A straight cable? Or a switch, or a router?

Can you send a test UDP broadcast packet ( e.g. with packetsender? ) Does that packet arrive at your device?

Here is an example of how I just sent a test UDP packet:


  1. I have checked the driver file its updated and
    macinit.BroadcastFramesReception = ETH_BROADCASTFRAMESRECEPTION_ENABLE;
    is also enabled.

  2. And broadcast packets are allowed in the LAN . The connection between host is connected to device with a straight cable there is no switch or router in between.

  3. I have tried sending the TCP broadcast packet from packet sender and the log shows that the request is been arrive at device.


Thank you for trying this, almost good.
Could you send a UDP packet to the broadcast address in stead of
And then I would be curious if your device receives this packet.

Yes I will have to change the configuration as i was working on TCP/IP. I will perform that test and will let you know the result.