[lwip-users] Unusual ARP behavior

[Roger Cover]

Greetings List,

I have encountered an unusual sequence of ARP requests from the lwIP library. I am using the raw API in a Power-PC system with NO_SYS=1. In the attached pcap file, IP 192.168.0.1 is a Windows 7-64 bit computer and IP 192.168.0.175 is my instrument. The post in packet 4 initiates a data set collection. The post in packet 15 initiates a data set transfer. The transfer does not show in the capture as I had UDP packets filtered out. The transfer would normally take about 6.5 seconds, mostly waiting for the collected data to be ready to send.

The first thing I see is that the ARP table entry timed out during the UDP transfer, causing the stack to issue an ARP request at packet 21. The next 3 packets are duplicate ARP requests, as is packet 29.

The host computer software times-out after receiving no UDP packets for 1/2 second and attempts to restart the UDP transfer at packet 31, even though the UDP transfer should be continuing until about time 7.0. There is no reply from the instrument, so a retransmission occurs at packet 32. Between packet 32 and packet 33 (from my other data) the instrument completes a watchdog timer reset (roughly time 10.145).

I am confused about a couple of things here. Why does the stack send 4 duplicate ARP requests in 2 microseconds? Why does it send another ARP request, after those have been answered, 239 microseconds later? Why are no UDP packets passed out of the stack after these 5 ARP requests have been answered? Is there somewhere in the stack that it could reasonably remain for longer than the 1.3 seconds my watchdog timer requires to reset my instrument? I look forward to your reply.

Regards,
Roger W. Cover
Spectral Instruments, Inc.
420 N. Bonita Ave.
Tucson, AZ 85745
Voice: 520-884-8821 ext. 144
FAX: 520-884-8803

[gold...@gmx.de]

Roger Cover wrote:
> I am confused about a couple of things here. Why does the stack send 4 duplicate ARP requests in 2 microseconds?

That's just the way lwIP ARP works: if it does not find a stable entry,
it sends a request. In order to keep it simple, there is no check for
the last request (or to limit the amount of requests).

> Why does it send another ARP request, after those have been answered, 239 microseconds later?

I would guess that at this point, the ARP response packets have not
reached the ARP table yet. I guess the input packets are queued
somewhere, and 239us is not such a long time for an embedded system...

> Why are no UDP packets passed out of the stack after these 5 ARP requests have been answered?

That's a good question. Something seems to block the device between
packets 30 and 35 (it does not respond to TCP SYN, too).

> Is there somewhere in the stack that it could reasonably remain for longer than the 1.3 seconds my watchdog timer requires to reset my instrument?

No, not in the stack itself (unless it's a bug, of course, but that's
unlikely to make it work again later). Sorry I can't help you further
here...
Maybe the lwIP stats can help you?

Simon

_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

[Roger Cover]

Greetings List,

After researching the source code for a while I have determined that lwIP will queue one UDP packet when the ARP table entry for its destination times out, and then drop subsequent UDP packets until the ARP reply is processed (I have ARP_QUEUEING set to 1). My question is: what is the appropriate method for my application to detect that this has happened so it can ensure that no UDP packets are dropped in the stack? I would prefer to have my application suspend its UDP transmissions while the ARP traffic is being resolved.

Regards,
Roger W. Cover
Spectral Instruments, Inc.
420 N. Bonita Ave.
Tucson, AZ 85745
Voice: 520-884-8821 ext. 144
FAX: 520-884-8803

[Kieran Mansley]

On Tue, 2011-03-29 at 08:14 -0700, Roger Cover wrote:
> Greetings List,
>
> After researching the source code for a while I have determined that
> lwIP will queue one UDP packet when the ARP table entry for its
> destination times out, and then drop subsequent UDP packets until the
> ARP reply is processed (I have ARP_QUEUEING set to 1). My question is:
> what is the appropriate method for my application to detect that this
> has happened so it can ensure that no UDP packets are dropped in the
> stack? I would prefer to have my application suspend its UDP
> transmissions while the ARP traffic is being resolved.

I don't think there is an easy way to detect this. UDP is an inherently
unreliable protocol and provides no API to monitor loss. ARP status is
entirely hidden from the application as there is no guarantee that your
application will be running on an Ethernet network.

You could go some way to avoiding the ARP interrupting your
transmissions by making sure there is a valid entry for the destination
before you try and send to it, e.g. by sending a ping and waiting for a
response. You would need to do this periodically in the absence of
traffic from your application as ARP entries will time out.

Kieran

[Roger Cover]

Thank you for the quick reply. I thought that was the case.

Regards,
Roger

[Elad Yosef]

In close matter, I have Peer-To-Peer Ethernet link in my target and
want to increase the ARP tables timeout.
Can it be done easily?

Elad

[Kieran Mansley]

On Tue, 2011-03-29 at 17:47 +0200, Elad Yosef wrote:
> In close matter, I have Peer-To-Peer Ethernet link in my target and
> want to increase the ARP tables timeout.
> Can it be done easily?

>From etharp.c:

/** the time an ARP entry stays valid after its last update,
* for ARP_TMR_INTERVAL = 5000, this is
* (240 * 5) seconds = 20 minutes.
*/
#define ARP_MAXAGE 240

[Simon Goldschmidt]

Roger Cover <rco...@specinst.com> wrote:

> After researching the source code for a while I have determined that lwIP will queue one UDP packet when the ARP table entry for its destination times out, and then drop subsequent UDP packets until the ARP reply is processed (I have ARP_QUEUEING set to 1).

Actually, the code always queued a number of packets, not only one. Now (since 1.4.0RC1 I think) it queues one packet (the latest) if ARP_QUEQUEING is 0 (which is kind of mandatory from the RFC) and a number of packets if it is 1. If it is set to 1, the number of packets queued is defined by MEMP_NUM_ARP_QUEUE, I think. In your case, just set it high enough, depending on your application protocol, the number of simultaneous connections and the expected timeout to receive the ARP response.

Simon