Ask Your Question

How can communication continue even after RST,ACK (ECONNABORTED)?

asked 2021-10-07 12:21:43 +0000


I'm troubleshooting an issue with our application's ftp client, which are having timeout issues on the FTP control channel while transferring large files. We have tried to setup a keep-alive mechanism which sends NOOP messages on the control channel periodically, but this seem to cause other issues with FTP servers that ignores messages on the control channel while there is an active transfer on the data channel.

We know that FileZilla manages to upload these large files, so what I did was to monitor traffic using WireShark while uploading a file using FileZilla. The results are a bit strange:

After 1 hour of transfer the server sends a RST,ACK message, closing the control channel. I can even see in FileZilla that it says: "Disconnected from server: ECONNABORTED - Connection aborted". There is no response from the client on this message though. Then about 1 hour later when the transfer finishes it reads the 226 Transfer complete message from the server - on the same control channel, without reconnecting. How does it manage to do that?

You can also see that FileZilla seem to use SO_KEEPALIVE to keep the control channel active during the transfer, and not the NOOP method.

Excerpt from Wireshark, filtering on port 21:

67  38.382093   xxxxxxxxx   FTP 60  Request: PASV
68  38.403053   xxxxxxxxx   FTP 107 Response: 227 Entering Passive Mode (xxxxxxxxx).
69  38.403466   xxxxxxxxx   FTP 69  Request: STOR test.bin
70  38.424603   xxxxxxxxx   FTP 96  Response: 150 Opening BINARY mode data connection.
71  38.465021   xxxxxxxxx   TCP 54  58981 → 21 [ACK] Seq=118 Ack=408 Win=262144 Len=0


84  3627.210719   xxxxxxxxx   TCP 55  [TCP Keep-Alive] 59549 → 21 [ACK] Seq=168 Ack=823
85  3627.231802 xxxxxxxxx   TCP 66  [TCP Keep-Alive ACK] 21 → 59549 [ACK] Seq=823 Ack=169


86  3634.081473 xxxxxxxxx   TCP 60  21 → 59549 [RST, ACK] Seq=823 Ack=169 Win=0 Len=0
[FileZilla: Disconnected from server: ECONNABORTED - Connection aborted]

87  3638.504643   xxxxxxxxx   TCP 55  [TCP Keep-Alive] 58981 → 21 [ACK] Seq=117 Ack=408
88  3638.525476 xxxxxxxxx   TCP 66  [TCP Keep-Alive ACK] 21 → 58981 [ACK] Seq=408 Ack=118


95  6478.177713 xxxxxxxxx   FTP 78  Response: 226 Transfer complete.
96  6478.206762   xxxxxxxxx   FTP 60  Request: PASV
97  6478.227939 xxxxxxxxx   FTP 107 Response: 227 Entering Passive Mode (xxxxxxxxx).
98  6478.228310   xxxxxxxxx   FTP 60  Request: LIST
99  6478.249480 xxxxxxxxx   FTP 96  Response: 150 Opening BINARY mode data connection.
100 6478.267052 xxxxxxxxx   FTP 78  Response: 226 Transfer complete.
edit retag flag offensive close merge delete


Your excerpt does not show enough data to draw a conclusion.
Either upload the pcap so we can take a look or add a column showing the value and/or the TCP src/dst ports.

The TCP RST closes the session on port 59549, but not the session on port 58981.

André gravatar imageAndré ( 2021-10-07 20:48:52 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2021-10-11 07:02:14 +0000

hugo.vanderkooij gravatar image

I know some firewalls delete a connection from the connection table by default after 3600 seconds of inactivity. Be it that does not happen with RST packets. They will only show up after you try to use the connection after being silent that long.

Changing the timeout on the firewall helps a bit but not in all cases. But if you change the TCP keep alive from the default 7200 seconds to 900 seconds then all trouble went away.

So that is basically what I recommend as default change to any file transfer or database server.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2021-10-07 12:21:43 +0000

Seen: 40 times

Last updated: Oct 11