[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] ACK Seq number problem with FIN ACK
From: |
address@hidden |
Subject: |
Re: [lwip-users] ACK Seq number problem with FIN ACK |
Date: |
Mon, 12 Nov 2007 19:21:17 +0100 |
User-agent: |
Thunderbird 2.0.0.6 (Windows/20070728) |
Hi,
first, thank you for helping me with this!
David Empson schrieb:
Simon Goldschmidt <address@hidden> wrote:
Seems what I saw was a little different. I'll describe it with
a "packet trace" (seqno/ackno in brackets):
lwip www.gmx.de:80
--------------------------------
SYN (0/x) ->
<- SYN+ACK (0/1)
// now, lwIP sends 100 bytes of data the server doesn't understand
DATA (1/1) ->
Shouldn't that DATA packet also have the ACK flag set (or is that just a
transcription error)?
The three way handshake doesn't appear to have completed correctly by this
point without either a separate ACK or an ACK piggybacked on DATA.
Just my error, of course there is an ACK included, so the handshake is
completed correctly.
// and closes the connection
FIN+ACK (101/1) ->
// here comes the difference: on my local network, ackno is 102!
// however, www.gmx.de doesn't seem to have received the FIN+ACK packet...
<- ACK (1/101)
That could just be a timing/implementation difference. www.gmx.de may have
sent the ACK as soon as it received the DATA, so it hasn't seen the FIN+ACK
yet.
That was my thought, also.
// HTTP 501 error response (202 bytes)
<- DATA (1/101)
<- FIN+ACK (203/101)
// lwIP has received everything
ACK (102/204) ->
Why has this ACK incremented the sequence number? It should be 101/204, and
From what I've seen from my pc (windows + local embedded router /
windows + internet host), this is correct: FIN consumes one sequence number.
I suppose it could be FIN+ACK (101/204) unless there are timer issues
relating to resending the FIN (I'm not familiar enough with those details).
I guess lwIP just doesn't check for the ACK number here. It could detect
the ACK for the FIN it sent is missing and retransmit the FIN in this
frame, I suppose.
// then, after 2.8 seconds, the TCP timer retransmits FIN+ACK
FIN+ACK (101/204)
// and so on (FIN+ACK) until the pcb is finally closed.
So this is a little different than what Paul wrote: the internet server
never seems to receive the FIN+ACK.
Can anyone explain this? Maybe the retransmitted FINs should have their
seqno
updated?
No, they are supposed to have the same sequence number. The FIN counts as a
data byte in the sequence numbers,
Which would be the reason for ACKing with seqno = 102, not 101?
and it is that byte which has not been
acknowledged.
If the transcript is accurate, I expect lwip not sending an ACK along with
the initial data may have confused the internet server,
That was my fault :-(
and/or the ACK with
the wrong sequence number (102) might have caused further confusion.
And that should be OK, I think.
It all points to an error in the server: I just incidentally traced my
(windows-) email client receiving mails from pop.gmx.de and noticed the
same thing. So maybe gmx.de has a general TCP misbehaviour? Maybe to
suppress the danger of half open connections (SYN-flooding)?
Simon
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users