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
_______________________________________________
lwip-devel mailing list
lwip-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel