[lwip-users] Re: [lwip] RE:[lwip-members] improved Ethernet ARP on my web site, seeking testers

[Paul Sheer]

> 
> For example, of any ARP request to us, the source IP would not enter the
> cache.

this should not matter -

the only reason a host would want to make an ARP request is
to send us an IP packet immediately afterward. This forthcomming
IP packet would cause an update.

> Furthermore, foreign ARP traffic (between two other hosts) was
> ignored as well.

same argument applies

> This situation occurs when an ARP entry is going from PENDING to STABLE
> by means of an incoming ARP request to us.

which basically never happens.

an ARP request in PENDING would have just sent a request
packet and would be about to receive a reply. It would be
a huge coincedence for the same remote host to want to do
an ARP lookup at exactly the same time.

> If this occurs, we must both
> reply with ARP, as well as send the queued packet.
> 

> The current implementation could NOT do both, and the packet would still
> be on the queue.


> Furthermore, the code did not cater for queued packets
> in STABLE entries.

which is also quite rare - it only happens when an ARP
request gets lost. so its sufficient for is to let it get
lost and just get retransmitted by the higher levels.

> I have not examined whether this caused memory leaks
> in the old implementation but my guess is it does.

it doesn't in my tree - its been checked with a leak tracer

> > the biggest problem with the previous ARP code was that it
> > did not create new entries for arbitrary IP packets. Hence
> >
> I understand what you mean. However, the ARP cache is referenced for
> outgoing
> IP packets only, and should be optimized towards that usage.
> 
> Updating on arbitrary IP packets would indeed keep more entries more
> up-to-date, but we must not destructively overwrite heavily used
> ARP entries.

huh? if a host is talking directly to you, should you not
use that TCP traffic to refresh your ARP entry for that host?

> 
> > if you'd ping a LwIP host, you never got an immediate
> > reply. Instead you got an ARP request back, and then a
> > ping reply later.
> >
> >This ARP request is theoretically unnecessary because the
> >ping request contains the ethernet hardware address. I think
> >most IP stacks work this way.
> >
> This behaviour is now correct, like you described.

I have not looked, but I hope the reason for
its correctness is that LwIP gets the hwaddr from
the incomming ICMP packet.

> Dynamic vs. static resource allocation is always a delicate
> topic in embedded design. I think static works best for
> most of us. In case of many hosts, a dynamically resizing
> cache might indeed be beneficial.

making it "dynamic" is a trivial change - i simply
don't look through the whole array if most of it is empty.
i.e. keep an index of the last valid array entry.

> 
> ARP cache sorting is in the plans, but not high-priority.
> Reserving entry #0 for the default gateway can be easily
> implemented, and might be worthwhile.

the ARP cache needs to be a hash table - which is complex.
i think anything less is not solving any kind of real problem.

i personally don't think the code warrants any more changes
that the ones i sent you.

-paul

Paul Sheer Consulting IT Services . . Tel . . . +27 (0)21 6869634
Email . . . address@hidden . . . . Work  . . +27 (0)21 6503467
Linux  development,  cryptography,  embedded,  support,  training
http://www.icon.co.za/~psheer . . . . . . http://rute.2038bug.com
L I N U X . . . . . . . . . . . .  The Choice of a GNU Generation


[This message was sent through the lwip discussion list.]