17

If a Windows server has several thousand ports open in LAST_ACK state (as shown by netstat), what could this mean? Is it because one endpoint is waiting for the other to respond?

Nick Bolton
  • 5,126
  • 12
  • 54
  • 62

4 Answers4

12

The last_ack state (if I recall my TCP stack correctly) is the state when you have received your FIN message to close the connection from your neighbour, but you still need to flush and shut down your connection. You send the final FIN yourself and wait for an ACK.

Typically hanging in last_ack means your application keeps a socket open even when the the other end has finished sending data. This can happen for multiple reasons. There might be a firewall or other load balancer which loses last ACK from the client, and leaves you stuck in the last_ack state. If the connections are not timed out after a few minutes (10 or so) you probably have a bug.

Have a look at the state diagram at http://tangentsoft.net/wskfaq/articles/debugging-tcp.html

pehrs
  • 8,789
  • 1
  • 30
  • 46
6

LAST_ACK means your end has received a FIN from the peer, sent an ACK, sent a FIN, and is waiting for the final ACK from the peer. At this point there is nothing further the application can do: the socket is closed. The application may even have exited. From here on it is up to TCP to resend the FIN until it gets the final ACK, or time out doing so. Not much you can do as an admin except investigate the network.

user207421
  • 1,010
  • 6
  • 16
4

LAST_ACK is the last state right before closing the down the TCP connection.

Imo
  • 841
  • 5
  • 7
  • 2
    Thanks, what can cause a port to hang in this state? – Nick Bolton Mar 31 '10 at 15:22
  • Is this an IIS webserver (or other service) you're seeing this on, or, your own application? – Imo Mar 31 '10 at 15:39
  • The application implements the "Cook Computing" XML-RPC client (from Asp.Net, run through IIS), and is talking to a Java XML-RPC server. – Nick Bolton Mar 31 '10 at 16:08
  • 1
    It's the final stages of the TCP conversation with the client. Your software looks to close() the TCP session and sends a LAST_ACK to the client. The client then should send back an acknowledgement that the LAST_ACK was received. I agree with pehrs in that client (maybe firewall) may not have acknowledged it or the packet may have been lost... these are the two most likely cases. – Imo Apr 01 '10 at 18:08
  • 2
    It doesn't 'send a LAST_ACK to the client'. It sends a FIN and is presently waiting for an ACK, having already received a FIN and sent an ACK. It's the last state *after* closing the connection. – user207421 Jun 17 '14 at 05:33
0

I believe that @lmo is correct in saying that it's "the last state right before closing down the TCP connection," but in addition to this, based on my reading of the wikipedia page, it's worth noting that this is not part of the "Active Close" mechanism that (in my understanding) is the ending of most well-behaved connections, but rather part of the "Passive Close" sequence, which is presumably associated with Bad Stuff Happening.

(FWIW, I'm languages, not networks. I'd be happy for clarification from a networks person.)

John Clements
  • 171
  • 1
  • 7
  • 1
    He is not correct in saying that, and there is nothing bad about a passive close. It just means the peer closed before you did. – user207421 Feb 15 '19 at 23:27