[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] ARP code question

From: Eric Koldeweij
Subject: Re: [lwip-devel] ARP code question
Date: Wed, 13 Oct 2021 21:57:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0


LWIP should send out ARP requests well before the cache times out. In all the LWIP implementations I have made I see that happening, without fail. I suggest to check if your timers are configured and running correctly and that, if appropriate for your implementation, sys_check_timeouts() is called regularly.

A gratuitous ARP is not a request, it's an unsolicited announcement of a hosts's own IP/MAC combination, which receivers may use to update their caches. Since it's not a request no response is allowed on reception of such a packet (especially since it is a broadcast packet). LWIP can be configured to send out gratuitous ARP announcements and it looks like you have that enabled. I have not checked this but I think on reception of a gratuitous ARP LWIP will update the ARP cache entry. Someone please correct me if I'm wrong on this :-)

Good luck in finding the root cause!


On 10/13/21 8:32 PM, Bill Auerbach wrote:
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 
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 

Best regards,

lwip-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]