Re: [lwip-devel] etharp.c updating

[address@hidden]

Leon Woestenberg wrote:
> Yes, I have a mix up, sorry. However, that brings me to this question:
>
> Why do we endetharp_ip_input() with
> etharp_ip_input(ETHARP_FLAG_FIND_ONLY), of which the return value is
> further ignored?
>
> etharp_ip_input(struct netif *netif, struct pbuf *p)
> {
>    <...>
>    update_arp_entry(netif,&iphdr_src,&(ethhdr->src), ETHARP_FLAG_FIND_ONLY);
> }
>
> Thus the complete function etharp_ip_input() is now a NO-OP since that change.
No, it's not. It resets the ctime of an already known entry to zero. 
Only if the address is not yet listed, no new entry is created: new 
entries are only created for incoming ARP packets, not for incoming IP 
packets. This also means that for ETHARP_TRUST_IP_MAC==1, entries won't 
time out when they are in use (through IP traffic).
> It used to update ARP entries on incoming IP packets.
That's what it does, still.
> This is
> perfectly valid, maybe not RFC, but the IP entry has already been
> "verified" through ARP before.
Yes, it's perfectly valid but not RFC. This is why we have code for it 
which is disabled by default (through ETHARP_TRUST_IP_MAC's default 
value of 0).
> If we drop etharp_ip_input() we must otherwise make sure actively used
> ARP entries are not timed out, by sending ARP requests for them. If we
> do not, ARP entries will time out and be removed in lwIP, and pcb will
> every so many seconds have a few seconds "drop-out".
That's correct. For ETHARP_TRUST_IP_MAC==0, I think it's a good idea to 
re-request the arp entry shortly before it would expire. I think I  
didn't observe this in my tests because we have turned on ARP queueing 
for our products.

I've created a bug entry for this: 
https://savannah.nongnu.org/bugs/index.php?33551

Simon