Re: [lwip-users] Etharp Mystery

[Leon Woestenberg]

Hello Paul,

formerly ARP more or less worked this way.

 
> In etharp.c find_entry() find entry will always (try to) add an ARP entry even
> when it is not required (flags == 0).
>
Correct.

> Here is my patch. It should probably return
> something other than ERR_MEM perhaps ERR_RTE or ERR_ARG?
>
The implementation is correct, ARP is ALWAYS required to update
the ARP cache, and always add entries when possible.

Setting "ETHARP_CREATE" just means that lwIP tries harder to actually
create an ARP entry in case the cache is full and in use.

It is there to more or less force ARP to recycle an active entry in the
cache, as we think the new entry is more important than an older entry.
There could be several reasons for thinking that.

In other words, NOT setting ETHARP_CREATE might still create an ARP
entry, and that is intended behaviour.

Maybe I should call it "ETHARP_RECYCLE" or "ETHARP_TRY_HARDER" or
"ETHARP_REPLACE". I will 

We recycle older entries (see line 264 in etharp.c) as follows:

  /* b) choose the least destructive entry to recycle:
   * 1) empty entry
   * 2) oldest stable entry
   * 3) oldest pending entry without queued packets
   * 4) oldest pending entry without queued packets
   */ 

> The dhcp.c code may need to be updated as the etharp_query(..)
> call in it uses a NULL pbuf which means that the etharp_query will not
> set the ETHARP_CREATE flag. Should etharp_query() always set
> ETHARP_CREATE? 
>
Yes, this is a good point and will make DHCP behave more robust in the
corner cases where the DHCP server gives away an address already in use.
 
> Finally in etharp_ip_input should the update_arp_entry have the
> create flag set to zero? Or set to CREATE only if the destination is
> our ip address?
>
There is no real way of telling beforehand if we should try harder to
replace an active entry, but again a good point; I will remove it there.

Please review the code after these changes are committed (in an hour or
so).

Regards,

Leon Woestenberg.