[lwip-users] Ats.: Fast ARP reply causes queueing problem in etharp_query function

[Darius Babrauskas]

I have same problem in 1.21 LWIP version.
SNTP using udp connection, which not guaranteed that your SNTP request will be 
delivered to time server. But, if I remember, LWIP not respond error, if your 
sntp packet dropped, because in arp table no information about your destination 
MAC.
Second sntp request must get respond, because first request sended arp request.
LWIP have OPTION (it add some additional code), which can your request udp 
packet, add to special queue. After LWIP get ARP respond, this packet is sent 
from queue and you must get your sntp respond.
If you this option enabled, but problem still same. Then, possible, your arp 
respond not correctly delivered for LWIP. ARP respond must treated in LWIP 
thread. 

________________________________________
Siuntėjas: address@hidden address@hidden Dave Harper address@hidden vardu
Išsiųsta: 2013 m. vasario 25 d. 18:56
Kam: address@hidden
Tema: [lwip-users] Fast ARP reply causes queueing problem in etharp_query       
function

I am running lwIP along with FreeRTOS on an embedded microcontroller
that does periodic checks to a GPS based timeserver located in the same
room.  Thus the timeserver is able to quickly respond to an ARP request
(measurements show a consistant range of 740us to 750us). The first
timeserver check is performed as the system starts up so this causes an
ARP request to be sent.  In the etharp_query() function, this situation
is detected, an ARP request is sent and the IP packet is queued for
later transmission.  Unfortunately, sending the ARP request first and
THEN queueing the IP packet seems to open up a potential timing
problem.  What I'm seeing is that occasionally between the time the the
ARP request is sent and the time the IP packet is actually queued, there
is an interruption of execution in etharp_query.  Before etharp_query()
gets to execute again, the timserver is able to respond with the ARP
reply and this triggers input processing.  As part of the input
processing update_arp_entry() is called which is where queued packets
are sent.  Unfortunately, it finds nothing queued at this point so it
simply returns.  Eventually etharp_query() resumes execution and queues
the IP packet but at this point it is too late.

One of my debugging tools is a logic analyzer I use to trace the path of
execution.   This is done by embedding a macro that writes a unique
value to an I/O port where it is then captured by the logic analyzer.
What I found was the more macros I embedded to try and trace down the
source of the problem, the worse it became (I was effectively delaying
code execution and giving the timeserver more time to respond).  By the
time I finally figured out what was happening my SNTP request was
succeeding only about 10% of the time.

I decided to try reversing the order of operations in etharp_query -
queue the IP packet first and then send the ARP request.  What I found
was that the SNTP request succeeded every time.  Unfortunately I don't
have enough of a grasp of full lwIP operation to know if I've only
appeared to fix a problem but in reality simply opened up other areas
for failure.  I am running an older version of lwIP (1.3) but I checked
the latest 1.41 release and etharp_query() operates essentially the same.

Can anyone please weigh in on this?

Thanks,
Dave Harper

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users