Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data connection is not always closed on control disconnect #15

steakboy7000 opened this issue Jul 7, 2019 · 1 comment


Copy link

@steakboy7000 steakboy7000 commented Jul 7, 2019

When an upload has been started (i.e. STOR has been executed and its first response has been sent) but no data has yet been transmitted, closing the control connection will not close the data connection.
The file will remain as 0 bytes as long as the data connection isn't closed on the peer end.
This happens regardless of whether port or pasv was used.

The data connection will be closed whenever any data arrives as glftpd will then realize that the control connection is gone.
This causes troubles for example during FXP when the other site runs out of credits and the STOR (successful) was executed before the RETR (unsuccessful). The only way to stop the transfer is then to close the data connection on the other site.

Sending ABOR will not work either in this case, since ABOR for some reason only triggers when data is received on the data connection, so as long as no data is received the ABOR will hang. This is in itself another bug.


This comment has been minimized.

Copy link

@glftpd glftpd commented Nov 14, 2019

I guess you are mixing a few things together. Can you please poke Hujer on efnet #glftpd ?

I will try to look at ABOR if i have time but im somewhat confused about the other things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.