Re: [lwip-users] ARP ETHARP_TRY_HARD

[Leon Woestenberg]

Hello Paul,

On Wed, 2004-12-01 at 11:44, Paul C wrote:
> I think that those changes fix all the issues I found. With for_us = 1
> I had seen arp replies when a gratuious arp was sent to 0.0.0.0
> they seem to have gone with that last dhcp_arp_reply() change. 
> I'll rebuild with a fresh cvs checkout, and make sure.
> 
> I do have a problem with ARP_QUEUEING in previous versions on LWIP
> there was only one packet queued on the ARP now it seems that it is
> possible to continuously add packets to the queue. This is good when
>
Yes, I have adapted the pbuf code in such ways that a "pbuf queue"
consists of multiple "pbuf chains".

The last pbuf of a pbuf chain has a next pointer to the next pbuf chain.

This is documented in the head of pbuf.c.

I have never received much feedback on this feature, so either it works
or either it has not been tested much.

> there is a reply to the arp but if the ip address does not exist then
> it is possible to exhaust memory buffers. What I would like is a 

Yes, with the ARP pending timeout being anywhere near 5 to 10 seconds,
all packets sent to a single IP address end up on the same queue.

The good case would be when the IP address is available and an ARP
response comes in almost directly (which results in the queue being
sent right away), the worst case when the target IP does not exist
(and the queue lives for 5 to 10 seconds).

> new error value ERR_ARP_PENDING so that if a packet is not sent but
> an Arp request instead (the packet is either lost or queued) the return
> value is not ERR_OK but ERR_ARP_PENDING or ERR_ARP_SENT. That way I 
>
I would suggest ERR_QUEUED (to accomodate other types of link layers
in the future).

> dont keep mindlessly sending packets to a non existant ip address. 
> Any comment?
> 
We could limit the number of packets per queue and reply with
ERR_QUEUE_FULL.

Also I thought of remembering entries that got no answer (tagging them
ETHARP_UNREACHABLE) and exploit this to let let senders know directly
the destination IP address is not on the network. (So we can return
ERR_UNREACHABLEs.)

ETHARP_UNREACHABLE is the same state as ETHARP_PENDING (i.e. we still
retry ARP requests) but it is entered when ETHARP_PENDING has timed
out.