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

[David Empson]

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.

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

> // 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 
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).

> // 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, 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, and/or the ACK with 
the wrong sequence number (102) might have caused further confusion.