lwip-users
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]