Re: [lwip-devel] ARP code question

[Bill Auerbach]

Hi Simon (and others),

>Re-requesting ARP is expected, but should not stall the connection:
>the re-request phase is done before the ARP entry times out. Plus it
>is done as unicast (in contrast to the broadcast which is done when
>the address is not known). You should see such re-requests every couple
>of minutes, as the default ARP timeouts is 5 minutes if I remember correctly.

Here what I see when studying this more.  When the ARP time expires, nothing
happens yet.  When lwIP receives a TCP packet, the ARP req is sent at that time.
What I don't know is if the receive callback was delayed, or was on time but
the tcp_output was delayed.  But this is where there is consistently a delay
from the normal receive/response timing when ARP hasn't timed out and a req
is pending. It's like the "need to send ARP" should be noted and done when TCP
slow timer expires, not tied to sending a response back.  Or, sending the 
request
and not waiting for a response if that is what's happening.

I also noticed that sometimes WireShark will show "gratuitous ARP" sent to the
PC (Windows 10) and there is no response.  Is this the correct behavior or was
this optimized since Windows sees that it has this mapping it doesn't need to
to respond? I do not see this on lwIP devices but only on other devices.  So why
aren't lwIP's ARPs called out as "gratuitous"?

I have added etharp_add_static_entry calls to our code.  I still think timing 
of the
TCP stream is being effected by ARP requests issued on the 5 minute timeout.

Maybe we in a small percentage of users that use lwIP with TCP in a real-
time application with real-time expectations for TCP responses and packet 
handing.

Best regards,
Bill