I configured FreeRTOS tCP with two endpoints on same interface. First endpoint has DHCP enabled and second endpoint has IP configured statically. Both endpoints are on different networks. I noticed that when it sends ARP request over first endpoint and it receives a response, FreeRTOS_MatchingEndpoint matches it to the second endpoint. Upon taking a closer look, I noticed that in FreeRTOS_Routing.c at line 922, it copies Sender protocol address to xIPAddressTo and Target protocol address to xIPAddressFrom. And in pxEasyFir function at line 776, we only check xIPAddressTo .
My question is shouldnât we also check xIPAddressFrom in else if condition since we are copying Target protocol address (which is this device address in ARP reply) to xAddressFrom?
The current implementation of pxEasyFit is such that for a particular incoming packet, it gives preference to endpoints based on decreasing order of priority for matching IP address (destination address), matching IPv6 type of the endpoint (if IPv6 enabled), matching MAC address of the endpoint, and if nothing matches, then the IP type (IPv4/v6) of the endpoint.
I believe if there is no match for the destination address, it makes sense to check if the source address is in the same subnet as any of the endpoints as a subcondition with priority lesser than destination address match. If you wish to, please feel free to make this change as a contribution to FreeRTOS+TCP in the form of a Github pull request.
Thank you for the response. I can definitely create a PR for this. However, I tested my changes locally and noticed some side effects. Just to give you some background, my device has two endpoints,
static IP end point on 192.168.151.2 (netmask 255.255.255.0)
DHCP endpoint who ip is dhcp server with a different network id, say 172.17.x.x.
This device communicates with another device and is connected through a switch. It is configured to have static ip of 192.168.151.1 and also has a dhcp address on same network id i.e. 172.17.x.x.
The idea is to use static ip to share private data between these two device and dhcp ip for external comms. I noticed that my device sends an arp request on static IP endpoint to 192.168.151.1, and receives a response successfully which is stored in ARP cache. However, when the other device sends an ARP request using itâs DHCP address to DHCP endpoint on my device, my device gets caught in an infinite loop logging arp miss for 192.168.151.1.
My question is how is the ARP table update managed in this case? Canât FreeRTOS-TCP keep ARP entries for both IP address that are tagged to the same mac address in itâs ARP cache?
Can you share the FreeRTOS+TCP device logs and the wireshark captures from the other device?
Canât FreeRTOS-TCP keep ARP entries for both IP address that are tagged to the same mac address in itâs ARP cache?
ARP caches typically only stores one entry for a given IP address, and if it learns a different MAC address for the same IP, it will overwrite the existing entry with the new information.
I took another look at this and it seems like another change would be to always copy ucSenderProtocolAddress to xAddressFrom and ulTargetProtocolAddress to xAddressTo for both ARP Request and Replies.
Currently, it is different for Request and Reply. It copies ucSenderProtocolAddress to xAddressTo and ulTargetProtocolAddress to xAddressFrom instead for ARP replies. Is there a reason for for doing this since sender should also be considered from address and tagrte should be to address?
If we need to use xAddressFrom correctly, I think this change should be required.
Is there a reason for for doing this since sender should also be considered from address and tagrte should be to address?
I believe since xAddressFrom was not used, this wasnât much of a problem, as the requests are tagged to the right endpoint and replies are anyway processed.