[En-Nut-Discussion] TCP/IP Stack crashes

[Hugo Simon]

> If Ethernut is not responding, I'd suggest to check the receiver
> path first. Start in front of
>
>    NutEventWait(&ni->ni_rx_rdy, 2000);
>
> in THREAD(NicRxLanc, arg). Then add an output to NutEtherInput(),
> NutIpInput() and so on. You may use a simple putchar() first to
> minimize the impact of the debug output and add a more advanced
> printf() later.

Hi Harald,

I did this now:

1. activate NUTDEBUG in cfg/os.h (why doesn't it work to enable it in the
configurator)
   With this I found a missing } in event.c, line 284.
2. add some outputs to ethin.c, ipin.c, tcpsm.c

When I start my application now I see tons of messages flooding the
terminal, but it looks logical.
When I ping the Nut and I see it detects a ICMP packet.
When requesting the webpage of the Nut's application it loads ok.

Let's see what the output looks like:

EIIP      means NutEtherInput received an IP packet
IPICMP    means NutIpInput received an ICMP packet
IPTCP     means NutIpInput received a TCP packet
TCPSMRDY1 means NutTcpStateMachine received a packet an posts it to the
statemachine if ((nbp = tcp_in_nbq) == 0)
TCPSMRDY1 means NutTcpStateMachine received a packet an posts it to the
statemachine if ((nbp = tcp_in_nbq) != 0)
SMLACK    means NutTcpSm sends a "late ack"
SMRETR    means NutTcpSm wants a retransmission
SMTIMEOUT means NutTcpSm destroys a socket because of a timeout
SMSYNRECOVER means NutTcpSm recovers from a SYN flood attack
SMSRCV    means NutTcpSm receives a packet
SMNOSOCK  means NutTcpSm finds no socket to a packet


first lets ping the Nut:

EIIP;IPICMP;EIIP;IPICMP;EIIP;IPICMP;EIIP;IPICMP;EIIP;IPICMP;EIIP;IPICMP;EIIP
;
IPTCP;EIIP;IPTCP;EIIP;IPTCP;TCPSMRDY;EIIP;IPTCP;EIIP;

looks allright for me, but I don't know what that TCPSMRDY was.
Now lets request a simple text webpage (the big one would fill two screen
pages of this rubbish):

EIIP;IPTCP;TCPSMRDY1;SMRCV;EIIP;IPTCP;TCPSMRDY1;EIIP;IPTCP;TCPSMRDY2;
SMRCV;SMRCV;EIIP;IPTCP;TCPSMRDY1;EIIP;IPTCP;TCPSMRDY2;SMRCV;SMRCV;EIIP;
IPTCP;TCPSMRDY1;SMRCV;SMSYNRECOVER;EIIP;IPTCP;TCPSMRDY1;EIIP;IPTCP;
TCPSMRDY2;SMRCV;SMRCV;EIIP;IPTCP;TCPSMRDY1;SMRCV;EIIP;IPTCP;TCPSMRDY1;
SMRCV;SMTIMEOUT;SMTIMEOUT;

The page loads ok and the Nut lives through this.
I don't know what this says to me. :-(
Especially I wondered why the received packets after SMRCV where not dumped
by the original NutOS Debug functions.
Is it normal that the process of loading a page will be terminated by a
timeout?

Now lets flood the network with some UDP broadcasts (my MP3 Player streaming
it's display contents):

EIIP;IPBC;IPUDP;EIIP;IPBC;IPUDP;EIIP;IPBC;IPUDP;EIIP;IPBC;IPUDP;EIIP;IPBC;IP
UDP;
EIIP;IPBC;IPUDP;EIIP;IPBC;IPUDP;EIIP;IPBC;IPUDP;EIIP;IPBC;IPUDP;EIIP;IPBC;IP
UDP;
[...]

Looks allright also.

Now the big question:

Do you think these outputs would be helpfull if I get such mysterious crash
of the Nut when it is plugged to our big network?

I think of adding some kind of "performance" counter to NutOS. Let's say we
count up counters for received packets, broadcasts, UDP, TCP, (add some
ideas here). A timer thread copies the values to a safe location every
second or so and then clears the counters. So we can see every second how
much crab was received by the Nut. Maybe we can see if there is a system
overload or something.

BTW: is there an idle task in NutOS? If we also count how often it is called
we have an indicator about the CPU load of the system.

Thank you
Thorsten