Re: [lwip-users] ACK Seq number problem with FIN ACK

[address@hidden]

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
>
>
>