AW: [En-Nut-Discussion] TCP problems

[Oliver Schulz]

Hi Dusan, hi Harald and the LIST!!!

After several month of absence (or years? I can't remeber..) I got an email
from Dusan with an attached capture file describing the problem. Because
once a time a had the whole Nut/NET TCP source code and the according RFCs
in my head, I started to localize the problem.

It's not so hard to figure out what happened. There is a successfull TCP
connection SYN between Nut/OS as a peer. Then the peer send a HTTP GET
packet, which is immediately served by Nut/OS completely (that means all
segments are transmitted and the FIN is sended). Between sending the
packets, Nut/OS doesn't wait for ACKs, b/c the peers receiver window is
large enough to hold the entire stream. (BTW, Nut/OS additionally limits the
number of unack'ed bytes to four maximum segment sizes)

After reading the RFCs, this behaviour is OK, because the FIN packet is
justed queued into the data stream. There is no point in the RFCs that
tells, that sending the FIN must be delayed until all preceeding segments
are ACKnowledged.

So Nut/OS works according to RFC (at least fot that point... :-).
But (and now comes the error in Nut/OS), while exchanging the SYN packets,
the peer requests a MSS (maximum segment size) of 1260 bytes. The first
larger segment sended from Nut/OS (1st segment of HTTP data) is 1460 bytes,
which is obviously to long. The effect on WAN, VPN, PPPoE ... connections
is, that this segment will not be transmitted to the peer, but just
discarded. This explains, why the peer answers with a retransmission of his
last sended ACK packet..

If I'am able to get my development environment working, I try to fix the
error today.

With kind regards,
Oliver.

> -----Ursprüngliche Nachricht-----
> Von: en-nut-discussion-bounces at egnite.de 
> [mailto:en-nut-discussion-bounces at egnite.de] Im Auftrag von 
> Dusan Ferbas
> Gesendet: Dienstag, 7. März 2006 09:40
> An: en-nut-discussion at egnite.de
> Betreff: [En-Nut-Discussion] TCP problems
> 
> Hi Harald,
> 
> add another issue to your list. However this does not cause 
> system crash, it causes unavailability of TCP connection over WAN.
> >After several reports with systems hanging, I'm a little bit 
> alarmed. 
> >Let's see what we have:
> 
> 
> 7. there is no wait for ACK for data sent and FIN packet is 
> sent from Nut/OS (http response) prior to this. A result of 
> this is that client's web browser does nothing because it 
> does not receive anything from Windows TCP stack.
> 
> >Hi,
> >
> >we found a problem with Nut/OS TCP (I think we tried this also with 
> >only most recent 'net' subdirectory, rest of Nut/OS was left 
> untouched) 
> >- if I connect over VPN, let me say 40-100 ms travel time, then I 
> >experience following problem when getting response to http request:
> >Windows SYNs with 32kB window, Win side sends http request, 
> Nut replies 
> >with response and all data packets and sends "immediately" (Ethereal 
> >says
> >0.84 and even 0.004 ms) FIN packet without waiting for ACK 
> from Win side. 
> >As a result of this no file is received on remote VPN side 
> and browser 
> >is waiting ...
> >
> >When captured on local segment Win ACK is send always within 
> that 0.84 
> >interval. For those who are interested, I can send Ethereal 
> capture files.
> >
> >Is Oliver Schulz aware of these things ?
> >
> >
> >Dusan
> 
> 
> Dusan  
> 
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>