[En-Nut-Discussion] Http server - TCP state machine fix

[Damian Slee]

Hi all,
Further to my email yesterday regarding occasionally SYN ACK not being
received, I have traced that;

- every SYN sent by the PC is received by ethernut

- every SYN received in listening state has a SYN ACK generated.

- NutIpOutput does Not fail in NutTcpOutput. So it should be passed all
the way down to NicOutput()

So it must be lost somewhere between NicOutput and received by the PC.
This would be similar to the lost FIN of Dusan Ferbas findings.  I put
my money on it being lost by NicOutput/Realtek somewhere.

--------------------
Moving on.  I found that in tcpsm.c;
- after a SYN is received, SYN ACK sent, switch to SYN RECEIVED state.
Ok

- SYN ACK disappears.  Not so ok.

- PC sends another SYN, after timeout of 3 and 6 seconds.  Ok

- Ethernut receives these SYNs in SYN RECEIVED STATE.

** the problem in NutTcpStateSynReceived() **

- this "without ACK" check is done before the Reject SYNs check.
Therefore the Reject SYNs code will Never execute, cause the first
handshake SYN from the PC doesn't have an ACK.   Needs to be Swapped
around.  Result, a RST is sent imediately back to the PC, re-sync, page
loads immediately. 

Should the same change apply to NutTcpStateFinWait1(),
NutTcpStateFinWait2(), NutTcpStateCloseWait(), NutTcpStateClosing(), and
NutTcpStateLastAck() ??


    /*
     * Silently discard segments without ACK.
     */
    if ((flags & TH_ACK) == 0) {
        NutNetBufFree(nb);
        return;
    }
...
   /*
     * Reject SYNs.
     */
    if (flags & TH_SYN) {
/* this code never executes, because of return above */
        NutTcpReject(nb);
        return;
    }



damian