First of all I would like to say that I am so thankfull to the +TCP extension to FreeRTOS. It has powered up my projects an runns very CPU performant on my STM32. Well, due to some low RAM problems I diskussed two posibilities to reduce RAM usage by +TCP:

1. Limit the count of connections to 1 by using the reuse socke option: LINK
2. Reduce the MTU size: LINK

Nevertheless I went on inspecting the behavior of +TCP and its inpact to the heap utilisation by printing the xTCPPacket.xEthernetHeader.usFrameType inside the EMAC task in NetworkInterface.c:674. To my suprise I saw, that sometimes there are more than 30 ARP frames per second. For every ARP Frame the EMAC Task allocates some ram sends this frame to the higher level IP-Task which then evaluates the ARP frame and frees the memory. Looking at these large amaout of traffic which is caused only by the adress resolution protocol (ARP) I wonder what is it worth of dealing with my approach number one of limiting the count of connection. My project is running inside a large network with man network peers. Having a closer look to the ARP frames showed that sometimes up to eight ARP-Connection driven by other network peers are done at the same time! So I would like to ask:

1. Is it normal that processing for +TCP to process that much ARP packages?
2. Is it normal that ARP-connections are processed in parallel?
3. Is there any other option of optimizing the RAM usage caused by the adress resolution protocol (ARP) ?

Appendix: Log of the Frametypes: ~~~ xTaskGetTickCount: usFrameType: Time: 49000 FrameType:1544 Time: 49000 FrameType:1544 Time: 49000 FrameType:1544 Time: 49001 FrameType:1544 Time: 49001 FrameType:1544 Time: 49001 FrameType:1544 Time: 49001 FrameType:1544 Time: 49002 FrameType:1544 Time: 49002 FrameType:1544 Time: 49103 FrameType:1544 Time: 49104 FrameType:1544 Time: 49211 FrameType:1544 Time: 49289 FrameType:1544 Time: 49394 FrameType:1544 Time: 49422 FrameType: 8 Time: 49423 FrameType: 8 Time: 49488 FrameType:1544 Time: 49566 FrameType:1544 Time: 49613 FrameType:1544 Time: 49634 FrameType:1544 Time: 49634 FrameType:1544 Time: 49660 FrameType:1544 Time: 49971 FrameType:1544 Time: 49972 FrameType:1544 Time: 49972 FrameType:1544 Time: 49972 FrameType:1544 Time: 49972 FrameType:1544 Time: 49973 FrameType:1544 Time: 49973 FrameType:1544 Time: 49974 FrameType:1544 Time: 49974 FrameType:1544 Time: 49974 FrameType:1544 Time: 49974 FrameType:1544 Time: 49988 FrameType:1544 Time: 49988 FrameType:1544 ~~~

Limit the count of connections to 1 by using the reuse socke option: LINK

Reuse socket ( FREERTOS_SO_REUSE_LISTEN_SOCKET ): A TCP server socket can turn itself into a connected socket. That option is only applicable to TCP, not to ARP or UDP.

• Is it normal that processing for +TCP to process that much ARP packages?

It might happen on a large network. I’m surprised that you don’t also see lots of UDP broadcasting. Did you find out who is sending all those ARP packages? What kind of ARP packages are they?

• Is it normal that ARP-connections are processed in parallel?

ARP is connectionless. In most cases, you will see: Q: Who has IP-address 192.168.x.x ? A: I am 192.168.x.x ? with MAC address y-y-y-y-y-y Beside that, there is the gratuitous ( unsolicited ) ARP message: it only expects an answer from a peer who happens to have the same IP-address. I attach a short PCAP showing the 3 ARP packets: ~arp_requests.pcapng”

• Is there any other option of optimizing the RAM usage caused by the address resolution protocol (ARP) ?

It is a nasty problem. It may force the Network Interface to drop important TCP/UDP packets because all buffers are occupied with ARP packets. It might be useful to do some quick pre-filtering here. Receiving lot of ARP packets may also spoil your ARP table. Suppose you look-up a peer, then after a few seconds, the ARP entry will be re-written by another unsolicited ARP reply. I once had an embedded device in a large LAN. It could hardly function normally because of the frequent UDP broadcasting. We solved it by early filtering. The earlier the better. On remark about TCP and buffer space: have a look at the socket option FREERTOS_SO_WIN_PROPERTIES. It lets you determine the TCP window size and the buffer sizes in both directions. Apply the socket options to the (listening) parent socket: it will be inherited by the connected (child-) socket. If TCP speed is not important, you may consider to define: ~~~

define ipconfigUSETCPWIN 0

~~~ The length of the TCP window will be equal to MSS. This saves a lot of RAM and code.