Re: [lwip-users] arp question

[Leon Woestenberg]

Hello all,

address@hidden wrote:
>[Jim Gibbons wrote:]
>  >Who's right here?  Is it legitimate to glean ethernet source
>  >addresses from incoming IP packets, or should one rely
>  >exclusively on the information presented in ARP replies? 
Good point.

I think this is a left-over from the times that lwIP did not have any
queueing on its outgoing UDP traffic:

An incoming request from a host on the LAN, would add that host to the
ARP table using etharp_ip_input(), so that the first response packet
from lwIP could be resolved to an ARP address right away (and was not lost).

In the current lwIP stack, we have TCP retries (so ARP can resolve
local addresses) and UDP queueing of the first packet to a yet
unresolved IP address.

This means that if lwIP is sending a burst of UDP packets to a yet
unresolved host, the second and later packets can be discarded
right away...

>  >RFCs or my elderly copy of Stevens.  If gleaning is wrong, the
>  >solution is would seem to be as simple as deleting one's calls to
>  >etharp_ip_input.
Yes, that would be safe.

> I'm not sure if gleaning is wrong, but it pollutes the cache
> with ununed entries since higher layers might never use them.
The current etharp.c implementation only updates existing entries,
i.e. does not insert new ones, as follows:

LWIP_DEBUGF(ETHARP_DEBUG | DBG_TRACE, ("etharp_ip_input: updating ETHARP 
table.\n"));
  /* update ARP table */
  /* @todo We could use ETHARP_TRY_HARD if we think we are going to talk
   * back soon (for example, if the destination IP address is ours. */
  update_arp_entry(netif, &(hdr->ip.src), &(hdr->eth.src), 0);


So, if gleaning is wrong, AND we do not allow lwIP to drop UDP packets
this easily, there is work to be done on the multi-packet outgoing
queue.

I already started this work, both had to step back once I noticed that
chaining packets by their pbuf->next pointer is not yet supported in the
TCP core code (segmented queueing for unacked, unsent). It works now
with a single packet only.

Regards,

Leon.