[En-Nut-Discussion] TCP/IP problems with httpd

[Bernd Walter]

On Fri, Jan 14, 2011 at 11:14:11PM +0100, Ulrich Prinz wrote:
> 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.

Sounds like the good old faked ping DOS.
You send an echo request from a faked sender IP, which is directly
connected to the target host, but non existend.
Now the answers stay in queue and further are added until it finally
fiond ou that the host in fact is unreachable.
If you attack fast enough the attacked host finally can get out of
memory.

> 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.

Probably influenced with your PHY problems, but I think this should
be worked around somehow.
FreeBSD has an ICMP bandwidth limit, but since it's working on a
memory beefy host it also has more resources available.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.