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

[Oliver Schulz]

Hi Damian,

regarding your found bug in NutTcpStateSynReceived (and perhaps in
NutTcpStateFinWait1(), NutTcpStateFinWait2(), NutTcpStateCloseWait(),
NutTcpStateClosing() and NutTcpStateLastAck()), I have to take some time to
look again at these big tcp state machine to be sure not to add some more
side effects...

But on the first look, I would say you're right.

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 09:14
> An: Ethernut User Chat (English)
> Betreff: RE: [En-Nut-Discussion] Http server - TCP state machine fix
> 
> 
> Hi Oliver,
> I'm using the new driver with this problem.  Tho I think it 
> occurs in the old as well.
> Maybe there is another busy bit check or something needed.
> 
> Do you agree with my NutTcpStateSynReceived() fix?
> 
> Anyone,
> How does a call to NutTcpReject(), return it to a listening state?
> If there a FIN or something sent from the other end when they 
> receive the RST?
> 
> Thanks,
> 
> damian
> 
> -----Original Message-----
> From: Oliver Schulz [mailto:Oliver.Schulz at bong.de] 
> Sent: Wednesday, 25 February 2004 3:48 PM
> To: Ethernut User Chat (English)
> Subject: AW: [En-Nut-Discussion] Http server - TCP state machine fix
> 
> 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.
> 
[snip]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2852 bytes
Desc: not available
URL: <http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040225/230fa018/attachment-0001.bin>