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

[Oliver Schulz]

Hi Damian,

some days ago, I tried to figure out why NutConnect sometimes get stucked.
The reason was that the whole software stuff, including the realtek driver, reported success for sending the initial SYN TCP packet, but this packet was definitely not put on the LAN. 

My bugfix was, to use the retransmission timer for NutConnect, because the next packet was then transmitted correctly.
But I didn't this testing again with the new driver from Bengan.

While testing, I noticed a strange behaviour: If you put a 'NutDelay(1)' somewhere in NicPutPacket, everything seems to be ok then (except the performance, of course :-)....

So long,
Oliver.

> -----Ursprüngliche Nachricht-----
> Von: en-nut-discussion-bounces at egnite.de
> [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Damian Slee
> Gesendet: Mittwoch, 25. Februar 2004 08:40
> An: Ethernut User Chat (English)
> Betreff: RE: [En-Nut-Discussion] Http server - TCP state machine fix
> 
> 
> NicPutPacket() is definitely writing out the SYN ACK packet that is
> lost, so must be realtek or LAN loosing it.  Will try crossover LAN
> cable tomorrow, ethernut direct to PC NIC.  Eliminate any network
> switches etc...
>  
> 
> -----Original Message-----
> From: Damian Slee 
> Sent: Wednesday, 25 February 2004 2:44 PM
> To: Ethernut User Chat (English)
> Subject: RE: [En-Nut-Discussion] Http server - TCP state machine fix
> 
> 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
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
> 
> 
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>