[Feature Request] Suggest FreeRTOS+TCP stack to have a function for users to manually add a static ARP table。

[hangeV]

It is recommended to add a function for users to manually add static ARP tables to FreeRTOS-TCPIP. This way, even if the underlying layer does not use Ethernet, there is no need to modify the ARP source code when using PPPOS.

[htibosch]

@hangeV, thank you for creating this "issue". I think more people have missed the possibility to manually add entries.

Looking at a Linux example:

    add arp -ip 10.102.29.6 -mac 00:24:e8:73:ca:ec -ifnum 1/1

Translating to FreeRTOS+TCP: in the current mainline, where only IPv4 is implemented, along with a single "interface", I would think of this new function:

BaseType_t xARPAddStaticAddress( uint32_t ulIPAddress, MACAddress_t * pxMACAddress );

In the new IPv6_integration branch, we need to know the endpoint ("interface"), and also IPv6 addresses can be stored. These will be passed to the ND cache in FreeRTOS_ND.c.

When the endpoint is unknown, it may be passed as NULL. The function will look it up.

BaseType_t xARPAddStaticAddress_IPv4( uint32_t ulIPAddress,
                                      MACAddress_t * pxMACAddress,
                                      NetworkEndPoint_t * pxTargetEndPoint );

BaseType_t xARPAddStaticAddress_IPv6( IPv6_Address_t * pxIPAddress,
                                      MACAddress_t * pxMACAddress,
                                      NetworkEndPoint_t * pxTargetEndPoint );

I know that ARP has nothing to do with IPv6 addresses, but I like the function names for the symmetry.

Please shoot!

[htibosch]

Or maybe the following:

/* ARP add static address. */
BaseType_t xARPAddStaticAddress( uint32_t ulIPAddress,
                                 MACAddress_t * pxMACAddress,
                                 NetworkEndPoint_t * pxTargetEndPoint );

/* ND add static address. */
BaseType_t xNDAddStaticAddress( IPv6_Address_t * pxIPAddress,
                                MACAddress_t * pxMACAddress,
                                NetworkEndPoint_t * pxTargetEndPoint );

ARP stands for Address Resolution Protocol. ND stands for Neighbour Discovery.

[johnrhen]

Thanks for submitting this request - we'll put the manual addition of static ARP tables into our input queue.

[shubnil]

Hi @hangeV,

Thanks for the feature request. We would like to understand more on the use case that you are looking for.

In my opinion, the physical(or underlying layer) can be either EThernet, PPPOS or any other custom tunnel, the FreeRTOS+TCP stack need not be aware of the same. The underlying layer can call the add/delete functions of the ARP/DNS entries as per their own dynamic/static learning.

This kind of "manual addition of entries" makes more sense when we have a Bridging and Routing functionalities supported. In those schenario, this is very useful to create/delete custom routing entries to support NAT, VLAN or any other custom routing.

This is same as adding or deleting Bridge FDB entries as supported in Linux and Windows. We have brain-stormed this many times, but as FreeRTOS does not support Bridging and Routing as of now, it did not make much sense to add the same. Infact, this might increase the risks of corrupting the dynamically learnt table entries of FreeRTOS and hence impacting the usual behavior. However, we are open to better understand your use case and re-look at it.

Thanks, Shub

[hangeV]

你好@hangeV,

感谢您的功能请求。 我们想更多地了解您正在寻找的用例。

在我看来，物理（或底层）可以是 EThernet、PPPOS 或任何其他自定义隧道，FreeRTOS+TCP 堆栈不需要意识到这一点。底层可以根据自己的动态/静态学习调用ARP/DNS表项的增加/删除函数。

当我们支持桥接和路由功能时，这种“手动添加条目”更有意义。在那些场景中，这对于创建/删除自定义路由条目以支持 NAT、VLAN 或任何其他自定义路由非常有用。

这与在 Linux 和 Windows 中支持的添加或删除 Bridge FDB 条目相同。 我们对此进行了多次头脑风暴，但由于 FreeRTOS 目前不支持桥接和路由，因此添加它们没有多大意义。事实上，这可能会增加破坏 FreeRTOS 的动态学习表条目的风险，从而影响通常的行为。 但是，我们愿意更好地了解您的用例并重新审视它。

谢谢， 舒布

当TCPIP协议栈的链路层不使用以太网，而是使用PPPOS的时候是不存在MAC地址的。 但是交给协议栈的是带MAC的以太网数据包，协议栈发送的也是带MAC的数据包。 所以我目前这是这么用的： 如果有一个手动添加ARP的函数我就不需要修改eARPGetCacheEntry()函数了。

[shubnil]

Hi @hangeV, Thanks for clarifying. One option is to have an API for manually creating a static ARP entry. This also means that we add an extra field for ARP entries and classify the entries as either static or dynamic. In normal flow, we can choose to match only for dynamic entries , however we can have an option to find an entry based on type either static/dynamic/both. Will this type of model be helpful for your use case.

[shubnil]

HI @hangeV, Gentle Reminder. Please suggest if the above proposed solution meets your use case.