Re: [lwip-devel] etharp.c updating

[Bill Auerbach]

Hi Leon,

>Are you using the trusted IP packet for ARP updates option?

If you mean how do I define ETHARP_TRUST_IP_MAC, it's a 1.

>What if your ARP entry runs out? You'ld certainly be looking at at
>least the ARP latency plus the TCP retransmission latency for a lost
>packet (if queueing is off).

That's a good question. I didn't look for it to happen.  Except where I had
to learn the internals to pick up speed, lwIP is a black box to me. Where I
looked for speed improvements is at the lowest most often called routines. I
would only know of problems if reported by product end users.  And if this
affected their usage of the product only, say, one a month, I'm sure I'd
never hear about it.  Also, the symptom would be the same as occurs due to
their equipment and mechanical issues making detecting this all but
impossible to pinpoint.

>Thus worst case, queueing is off, and a TCP packet is lost. I'm
>measuring 1 second drop-outs if the ARP cache has to be repruned in
>combination with packet loss and TCP retransmit.

A 1 second drop-out would affect users if it happened during a run (as
opposed to be connected but idle).  But they would likely think that their
equipment or operators caused it and not tell us.

I'm happy to test this.  All of our systems send constant UDP "here I am"
messages or TCP status messages once per second unless that information is
folded into other outbound replies.  So if there is constant communication
would I still see the ARP timeout?

Thanks,
Bill