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
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
