lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] etharp.c updating


From: Leon Woestenberg
Subject: Re: [lwip-devel] etharp.c updating
Date: Mon, 13 Jun 2011 01:49:21 +0200

Hello Simon, Kieran,

On Sun, Jun 12, 2011 at 11:27 PM, Simon Goldschmidt <address@hidden> wrote:
>
> I think you might have been looking at the wrong function there:
> etharp_ip_input handles incoming IP packets, whereas the lines you cited 
> comment about incoming ARP packets. These are handled in etharp_arp_input.
>
> Normally, etharp_ip_input is not used at all, since it is regarded the 
> minimum anti-spoof level to not update the ARP cache on incoming non-ARP 
> packets. Also, doing so would have significant performance drawbacks.
>
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.


It used to update ARP entries on incoming IP packets. This is
perfectly valid, maybe not RFC, but the IP entry has already been
"verified" through ARP before.

This means once a connection with a remote host is established and
active we keep it's ARP entry up to date.

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".

Regards,
-- 
Leon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]