FreeRTOS+TCP and ARP handling

we have an application where a STM32H7 will stream out data via UDP to a remote host. The remote host will trigger the stream once, and may then passively listen.

I’ve seen that, in the current version of FreeRTOS+TCP V2.4.0, mayor reworks were done in the ARP source code. We had some problems in older versions, where UDP packets were converted to ARPs. I found a workaround by calling the following API function before sending out data, which worked fine:

xARPWaitResolution(xDestinationAddress.sin_addr, 10)

We don’t use the zero-copy driver and hand over the payload to the stack with


Now, it seems like this works fine, until the device send more than a couple thousand messages. I’ve investigated this further, and counted the number of FreeRTOS_sendto() calls, which seemed correct. Also no error return codes.
Observing this with Wireshark showed, that in fact no packets arrived on my network card (some were swallowed).

I then proceeded to write a script which timestamps the incoming packets, and counts them. With a rate of 10 packets per second, this is what I got after initiating the data burst:

packets/s:10.008807750820722 total packets:100
packets/s:10.03774190958002 total packets:200
packets/s:9.993703966501105 total packets:300
packets/s:10.003801444548929 total packets:400
packets/s:9.99750062484379 total packets:500
packets/s:10.012615896028995 total packets:600
packets/s:10.001500225033755 total packets:700
packets/s:9.980139522350523 total packets:800
packets/s:9.99980000399992 total packets:900
packets/s:10.01401962747847 total packets:1000
packets/s:10.002600676175806 total packets:1100
packets/s:9.963434196498849 total packets:1200
packets/s:10.066843843118306 total packets:1300
packets/s:10.04490070615652 total packets:1400
packets/s:10.023354415788788 total packets:1500
packets/s:9.942532164091551 total packets:1600
packets/s:9.99910008099271 total packets:1700
packets/s:9.96541999262559 total packets:1800
packets/s:9.987515605493133 total packets:1900
packets/s:9.989910190707386 total packets:2000
packets/s:9.981534161800669 total packets:2100
packets/s:10.026268824319718 total packets:2200
packets/s:9.981036031540073 total packets:2300
packets/s:10.009509033581903 total packets:2400
packets/s:10.058136026231619 total packets:2500
packets/s:9.996801023672425 total packets:2600
packets/s:9.983527180152748 total packets:2700
packets/s:9.986617931971159 total packets:2800
packets/s:10.001400196027443 total packets:2900
packets/s:10.043185698503565 total packets:3000
packets/s:10.014922234128852 total packets:3100
packets/s:9.99980000399992 total packets:3200
!!!Missing packets!!! delta:0.199928 total packets:3267
packets/s:9.913652090293542 total packets:3300
packets/s:10.067958721369243 total packets:3400
packets/s:9.99920006399488 total packets:3500
packets/s:10.017229634972152 total packets:3600
packets/s:9.984623679533518 total packets:3700
packets/s:10.067147876335156 total packets:3800
packets/s:10.009709418135591 total packets:3900
!!!Missing packets!!! delta:0.199903 total packets:3947
packets/s:9.96551930321089 total packets:4000
packets/s:9.976057462090981 total packets:4100
packets/s:9.934827531394056 total packets:4200
packets/s:9.99970000899973 total packets:4300
packets/s:10.050554288068987 total packets:4400
packets/s:9.99980000399992 total packets:4500
packets/s:9.984424298094972 total packets:4600
packets/s:9.99970000899973 total packets:4700
packets/s:10.077699059750678 total packets:4800
packets/s:10.03693592420106 total packets:4900
packets/s:9.999600015999361 total packets:5000
packets/s:10.03854802441375 total packets:5100
packets/s:10.033209924851258 total packets:5200
packets/s:10.019939679963127 total packets:5300
packets/s:9.951833127662114 total packets:5400
packets/s:9.98332784250302 total packets:5500
packets/s:10.018132820404933 total packets:5600
packets/s:10.005903483055002 total packets:5700
packets/s:9.977749618351076 total packets:5800

The value of delta is basically the measured time between the reception of two packets.

I also removed the xARPWaitResolution() call, since it looks like the the ARP cache handling is now improved. However this did not change the behavior.

I’m running out of ideas where to debug or what to change. Does anyone maybe have any suggestions or hints what the cause of the problem might be?

Thanks a lot for your advice!

The STM32 has a static IP configuration in the network.
The payload is 250 bytes in length and does not change.

Here is a Wireshark trace, with no filters enabled:

The STM32 (IP looses one frame between frame number 152 and 153 (one additional frame reception timestamp should be in between those, with 11:19:07:30XXXX)

If I understand correctly - you are wanting to send a stream of UDP packets, but not all the packets are placed onto the wire. Is that correct? If so, it’s not clear what ARP has to do with that, or if the ARP messages in your Wireshark image are relevant as you say the packet gets lost before the ARP shown in the image.

Do you check the return value of FreeRTOS_sendto()? If it can’t obtain a buffer after whatever timeout you specify it will give up and return 0.

Thanks for your reply. Yes, that seems to be the case.
I just suspected ARP to be the problem, since we already had issues with “swallowed” UDP packets in this context.
I only checked negative return values of the sendto-function, I will try and investigate this further with your suggestion.