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

Feature/compile config delay sending 226 #63

Conversation

bjuulp
Copy link
Contributor

@bjuulp bjuulp commented Nov 8, 2023

An FTP client implementation has been
observed to close the data connection
as soon as it receives the 226 status
code - even though it hasn't received
all data, yet. To improve interoper
with such buggy clients, sending of
the 226 status code can now be delayed
a bit. The optional delay is controlled
by means of preprocessor define that
can be set from the cmake command
line through a cmake cache variable.

A signed-unsigned conversion was making the
PASV command sometimes report signed numbers.
This was detected by the Windows firewall as
a problematice connection and it therefore
terminated the connection.
An FTP client implementation has been
observed to close the data connection
as soon as it receives the 226 status
code - even though it hasn't received
all data, yet. To improve interoper
with such buggy clients, sending of
the 226 status code can now be delayed
a bit. The optional delay is controlled
by means of preprocessor define that
can be set from the cmake command
line through a cmake cache variable.
Comment on lines 1317 to 1322
{
asio::error_code ec;
data_socket->shutdown(asio::socket_base::shutdown_both, ec);
data_socket->close(ec);
}

Copy link
Member

@FlorianReimold FlorianReimold Nov 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bjuulp: This must always be executed, right? I think the current implementation does not close the data socket at all, after sending a file...

My old implementation did close the socket, but the new memory-mapped file implementation does not use the writeDataToSocket function anymore, which would close the socket. So I think this bug was introduced with the memory-mapped file implementation. Funny, that curl doesn't complain about that.

Edit: Ah, I think the shared-pointer goes out of scope and the destructor closes the socket, which saved us. I still think we should explicitly shutdown the connection properly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I'll add that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've now tested what happens if I explicitly close the socket and set the delay to 0. This still triggers the bug in the old lwftp implementation. So, the only thing I've done in the latest commit is to move the explicit connection closure so that it is done irrespective of the presence or absence of the delay.

The data socket is now also closed
explicitly after file fetch in the
case where sending of code 226 is
not delayed.
me->sendFtpMessage(FtpReplyCode::CLOSING_DATA_CONNECTION, "Done");
// Close Data Socket properly
{
asio::error_code ec;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you fix the "ec hides previous declaration" warning here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually. Where is that warning coming from? That is, why did you see it? I didn't see that in my builds.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The warning came from Visual Studio 2022. It wasn't a problem in this case, but hiding variables can also be unintentional, so I like to keep the project as warning-free as possible.

@FlorianReimold FlorianReimold merged commit 48d52be into eclipse-ecal:master Nov 10, 2023
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants