[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