[En-Nut-Discussion] Duplicate ACKs with window size = 0

[Stephen Noftall]

Hi Harold

Yes, we are sure... We are looking at the conversation with EtherPeek.
Haven't looked at ethereal. EtherPeek is a very advanced packet sniffer on
windows.

The other side is a Mac, OS-X.  We will try changing the mss.  Basically,
the Mac is sending a 564 byte packet, and then we see up to 20 ACKs coming
back from EtherNut, with a window size of zero. The last ACK shows a window
size non-zero, and then the Mac sends another 564 byte packet and the
process repeats.  Some of these acks are identical - ie: have the same
checksum and sequence number.

We have monitored the Receive thread, and most of the CPU time is being
spent in there. Have a small modification to the thread switcher that adds
time statics to threads if anyone is interested. The reveive thread is very
simple, it just calls NutTcpReceive(), and processes the packet right away,
(just a simple queue input), without holding up anything. So it looks like
the receive thread is being held in NutTcpReceive(), and in there it is
running out of memory, which is causing the multiple ACKs with 0 window
sizes.

Also, we pre-allcoate 10K bytes, and the situation get's much worse. Now,
Ethernut does not send out an ACK, and the Mac re-issues TCP packets, up to
a second later, until the Ethernut sends back an ACK. So it does definitely
look like memory starvation. We might try pre-allocating the netbufs, and
using a pool of them.

Cheers, and thanks for the help!

Stephen Noftall