FreeRTOS+TCP-MULTI library update to v2.3.2

Hi,
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 (https://github.com/htibosch/FreeRTOS-Plus-TCP-multi)

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

C:\Users\e1347354\Desktop\myProject\build/…/lib/FreeRTOS+TCP-
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
Prince

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.

Thanks
Prince

@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.

Thanks
Prince

Hi,

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 - 192.168.2.5 and 192.168.2.1. 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),
Aniruddha

Hi @kanherea

  1. In the last snapshot (3) the system IP( Computer IP address) is 192.168.2.1 and 192.168.2.5 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

Thanks
Prince

Hi

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 )

{

case ipARP_REQUEST:

vARPProcessPacketRequest( pxARPFrame, pxTargetEndPoint, ulSenderProtocolAddress );

eReturn = eReturnEthernetFrame;

break;

case ipARP_REPLY:

vARPProcessPacketReply( pxARPFrame, pxTargetEndPoint, ulSenderProtocolAddress );

break;

default:

/ Invalid. /

break;

}

}

Thanks
Prince

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

C:\users\hein>ping 192.168.2.114

Pinging 192.168.2.114 with 32 bytes of data:
Reply from 192.168.2.114: bytes=32 time<1ms TTL=64
Reply from 192.168.2.114: 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 192.168.1.5 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 192.168.2.5

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==192.168.2.5 || arp”.

1 Like

@htibosch
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…
PCAPFile.zip (13.7 KB)

Thanks
Prince

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

Thanks
Prince

@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:

macinit.BroadcastFramesReception = ETH_BROADCASTFRAMESRECEPTION_ENABLE;

Are broadcast packets allowed in your LAN, will they be forwarded? How is the 192.168.2.1 host connected to the 192.168.2.5 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:

@htibosch

  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 192.168.2.1 host is connected to 192.168.2.5 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.

Thanks
Prince

Thank you for trying this, almost good.
Could you send a UDP packet to the broadcast address 192.168.2.255 in stead of 192.168.2.5?
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.

Thanks