[En-Nut-Discussion] TCP/IP problems with httpd
Ulrich Prinz
uprinz2 at netscape.net
Fri Jan 14 23:14:11 CET 2011
Hi!
So we are now with three people checking the stack. Thanks to my
colleague Daniel, we found a thing. We don't have a soluting, but I'll
try to describe exactly how it comes to long time unanswered pings if
not any other TCP/UDP/FTP access is happening from/to the same host.
If icmpin.c NutIcmpReflect() is requested to echo a packet, it issues
this echo. The called routine checks if there is an ARP cache entry for
the target and if so, the echo packet takes its way.
If there is no ARP entry for the target, cause it is the very first
packet ever sent to the host, or cause the ARP cache entry aged out, the
called function from icmpin issues an ARP request.
This ARP request is handled by icmpout and is sent through the line, and
the host answers the packet. Unfortunately the icmpin routine is waiting
for the initial echo packet to be sent and the ARP request answer is
staying in the input buffer, never retrieved by icmpin.
There are timeout mechanisms working in the background, as this blocking
situation sometimes recoveres after some minutes.
The described bug doesn't appear very often as most times a system is
busy with transferring anything useful but icmp. Other protocols check
the ARP cache too and request a new address if the desired is missing,
but while their stacks are blocked until the response comes in, icmp is
free and working.
The problem was difficult to find as you have to meet the situation
where 1st, the ARP cache entry aged, and an icmp echo was answered right
before a TCP response was sent.
The higher the icmp traffic is, the higher the chance to hit the bug.
Best regards
Ulrich
More information about the En-Nut-Discussion
mailing list