[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: |
David Empson |
Subject: |
Re: [lwip-users] ACK Seq number problem with FIN ACK |
Date: |
Tue, 13 Nov 2007 10:58:11 +1300 |
Simon Goldschmidt <address@hidden> wrote:
first, thank you for helping me with this!
You're welcome.
It looks like it is just the end part of the sequence which is the problem,
so let's cut it back to your original summary (corrected for the ACK at the
beginning):
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+ACK (1/1) ->
// 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)
// HTTP 501 error response (202 bytes)
<- DATA (1/101)
<- FIN+ACK (203/101)
// lwIP has received everything
ACK (102/204) ->
// 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.
David Empson schrieb:
Simon Goldschmidt <address@hidden> wrote:
// 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.
OK, I misunderstood how the outgoing sequence number field behaved in this
ACK packet. It looks right. Windows uses exactly the same packet to
acknowledge a FIN from the other station, incrementing both its outgoing
sequence number (one past the nominal sequence number of FIN) and the
acknowledgement sequence number (one past the nominal sequence number of the
other station's FIN).
As far as I can tell, LWIP is behaving correctly.
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)?
That seems likely.
Another possibility is a buggy router or firewall of some kind between you
and gmx.de. I ran into a similar sort of problem once with a friend's mail
server when we accessed it over the Internet from some networks and with
some client software. I forget the precise details, but it went something
like this:
The evidence pointed to there being a firewall with stateful packet
inspection between one particular network and the server. We weren't able to
repeat the problem from another network (which had a different route to the
server). It only happened with one particular mail client (that we found).
Careful observation of the packets revealed that this particular mail client
was causing the TCP connection to terminate in a slightly different way. I
forget exactly what it was, but I think it was sending a FIN+ACK packet
which acknowledged the last data received from the server, whereas other
clients were sending a separate ACK to acknowledge the last data, followed
by a FIN all by itself.
At the server end, what we received was an ACK packet which acknowledged the
data, but no FIN. This was probably due to a bug in the firewall. The server
didn't think the connection was closed. The client also didn't think the
connection was closed since its FIN hadn't been acknowledged, so it retried
the FIN (as expected).
The firewall in the middle had received the original FIN, and used it to
close its record of the connection. When a retried FIN arrived, it was
discarded by the firewall, because there was no longer a valid connection
which matched it.
End result: unclosed connection at both the server and client, until both
ends timed out.
The firewall could have also caused this problem if it did send a FIN to the
server but that packet was lost. It would have forgotten the connection and
ignored FIN retries by the client.
It sounds like you are seeing almost exactly the same problem here. The
server to client direction of the connection has been closed correctly, but
the client to server direction has not, and retried FIN packets are being
ignored. The correct behaviour at the server would be to resend an
acknowledgement (as long as the repeated FIN arrived within a short time of
the connection being closed), so the FIN packets must be getting discarded
before they reach the server.