lftp does not wait for "221 Goodbye" message before closing control connection

[Stephen Powell]

With "set ftp:use-quit yes" in effect, which is the default value for this option,
lftp will issue the QUIT command to the server in response to an lftp "close"
command. But lftp does not wait for the server to respond with the "221 Goodbye"
message before closing the control connection. Sometimes, the message arrives
before lftp can get the control connection closed, and sometimes it doesn't.
This results in inconsistent debug output. If the server is broken, and doesn't
send the "221 Goodbye" message, a timeout should eventually occur, of course,
and the control connection can then be closed. Or the problem can be circumvented
by using the "set ftp:use-quit no" command. But if you're going to issue the
QUIT command, you really should wait a reasonable amount of time for a response,
for consistency. Failing to wait for a response may also cause problems for the
server, if it does not recover well from an error in sending the 221 message.

[Alexander V. Lukyanov]

Post by Stephen Powell
With "set ftp:use-quit yes" in effect, which is the default value for this option,
lftp will issue the QUIT command to the server in response to an lftp "close"
command. But lftp does not wait for the server to respond with the "221 Goodbye"
message before closing the control connection. Sometimes, the message arrives
before lftp can get the control connection closed, and sometimes it doesn't.
This results in inconsistent debug output. If the server is broken, and doesn't
send the "221 Goodbye" message, a timeout should eventually occur, of course,
and the control connection can then be closed. Or the problem can be circumvented
by using the "set ftp:use-quit no" command. But if you're going to issue the
QUIT command, you really should wait a reasonable amount of time for a response,
for consistency. Failing to wait for a response may also cause problems for the
server, if it does not recover well from an error in sending the 221 message.

As far as I can tell, lftp does not wait for QUIT reply only when it exits.
Is it really necessary to linger at exit to wait for clean connection shutdown?

[Stephen Powell]

Post by Alexander V. Lukyanov
As far as I can tell, lftp does not wait for QUIT reply only when it
exits. Is it really necessary to linger at exit to wait for clean
connection shutdown?

Well, I don't know if "necessary" is the right word; but it is the
expected behavior to wait for a 221 reply to the QUIT command before
closing the control connection. That's what all other FTP clients do.
On the other hand, lftp has a long-standing tradition of being as
asynchronous as possible and as fast as possible, and I respect
that tradition as well.

I propose a compromise. Let's introduce a new "set" variable. Maybe
we could call it ftp:wait-for-goodbye, or something along those lines.
It would be a boolean variable. You could make its default value "no"
for forward compatibility with the current behavior. If set to "yes",
then lftp will wait for a "221 Goodbye." message to be received in
response to the QUIT command before closing the control connection.
What do you think?

[Alexander Lukyanov]

Here is a patch to make lftp wait for QUIT reply at exit. I think to avoid
lingering one can set use-quit no.

Post by Stephen Powell

Post by Alexander V. Lukyanov
As far as I can tell, lftp does not wait for QUIT reply only when it
exits. Is it really necessary to linger at exit to wait for clean
connection shutdown?

Well, I don't know if "necessary" is the right word; but it is the
expected behavior to wait for a 221 reply to the QUIT command before
closing the control connection. That's what all other FTP clients do.
On the other hand, lftp has a long-standing tradition of being as
asynchronous as possible and as fast as possible, and I respect
that tradition as well.
I propose a compromise. Let's introduce a new "set" variable. Maybe
we could call it ftp:wait-for-goodbye, or something along those lines.
It would be a boolean variable. You could make its default value "no"
for forward compatibility with the current behavior. If set to "yes",
then lftp will wait for a "221 Goodbye." message to be received in
response to the QUIT command before closing the control connection.
What do you think?
--
.''`. Stephen Powell
`. `'`
`-
_______________________________________________
lftp mailing list
http://univ.uniyar.ac.ru/mailman/listinfo/lftp

[Stephen Powell]

Here is a patch to make lftp wait for QUIT reply at exit. I think to avoid
lingering one can set use-quit no.

OK. Thanks for the patch. But it does not work as intended. It doesn't
seem to break anything, but neither does it fix anything. I still don't
get the "221 Goodbye." message most of the time. Most of the time, the
control connection gets closed before the 221 message arrives. In order
to get the 221 message consistently, I have to add a delay to the end of
the script. For example,

!sleep 1

This introduces enough delay that the 221 message arrives prior to shutdown.
But this is a kludge. I shouldn't have to do that.

[Alexander Lukyanov]

Can you send me a sample of the script?

Post by Stephen Powell

Here is a patch to make lftp wait for QUIT reply at exit. I think to

avoid

lingering one can set use-quit no.

OK. Thanks for the patch. But it does not work as intended. It doesn't
seem to break anything, but neither does it fix anything. I still don't
get the "221 Goodbye." message most of the time. Most of the time, the
control connection gets closed before the 221 message arrives. In order
to get the 221 message consistently, I have to add a delay to the end of
the script. For example,
!sleep 1
This introduces enough delay that the 221 message arrives prior to shutdown.
But this is a kludge. I shouldn't have to do that.
--
.''`. Stephen Powell
`. `'`
`-
_______________________________________________
lftp mailing list
http://univ.uniyar.ac.ru/mailman/listinfo/lftp

[Alexander Lukyanov]

Ok, I could reproduce the proble you see. For now try to remove the "close"
command from the script.

Post by Alexander Lukyanov
Can you send me a sample of the script?

Post by Stephen Powell

Here is a patch to make lftp wait for QUIT reply at exit. I think to

avoid

lingering one can set use-quit no.

OK. Thanks for the patch. But it does not work as intended. It doesn't
seem to break anything, but neither does it fix anything. I still don't
get the "221 Goodbye." message most of the time. Most of the time, the
control connection gets closed before the 221 message arrives. In order
to get the 221 message consistently, I have to add a delay to the end of
the script. For example,
!sleep 1
This introduces enough delay that the 221 message arrives prior to shutdown.
But this is a kludge. I shouldn't have to do that.
--
.''`. Stephen Powell
`. `'`
`-
_______________________________________________
lftp mailing list
http://univ.uniyar.ac.ru/mailman/listinfo/lftp

--
Alexander.

[Alexander Lukyanov]

Here is an additional patch to wait for QUIT reply after "close" command.

Post by Alexander Lukyanov
Ok, I could reproduce the proble you see. For now try to remove the
"close" command from the script.

Post by Alexander Lukyanov
Can you send me a sample of the script?

Post by Stephen Powell

Here is a patch to make lftp wait for QUIT reply at exit. I think to

avoid

lingering one can set use-quit no.

OK. Thanks for the patch. But it does not work as intended. It doesn't
seem to break anything, but neither does it fix anything. I still don't
get the "221 Goodbye." message most of the time. Most of the time, the
control connection gets closed before the 221 message arrives. In order
to get the 221 message consistently, I have to add a delay to the end of
the script. For example,
!sleep 1
This introduces enough delay that the 221 message arrives prior to shutdown.
But this is a kludge. I shouldn't have to do that.
--
.''`. Stephen Powell
`. `'`
`-
_______________________________________________
lftp mailing list
http://univ.uniyar.ac.ru/mailman/listinfo/lftp

--
Alexander.

--
Alexander.

[Stephen Powell]

Post by Alexander Lukyanov
Here is an additional patch to wait for QUIT reply after "close" command.

OK, now the problem is fixed. But I'm now getting an error message
that I wasn't getting before. The last four lines of debug output are
as follows:

---> QUIT
<--- 221 Goodbye.
**** gnutls_record_recv: The TLS connection was non-properly terminated.
---- Closing control socket

Since this error occurs on a receive, I suspect that this is a server bug
which has existed all along, but which has now been exposed, now that the
client is behaving properly. Still, it might be a good idea to output a
little more information (return codes, reason codes, whatever) about this
error that might help confirm the error as a server bug.

RFC 2246 (TLS 1.0) states, in section 7.2.1 (Closure Alerts), "Each party
is required to send a close_notify alert before closing the write side of
the connection." RFC 4346 (TLS 1.1) adds an additional qualification to
this rule, but otherwise confirms the rule: "Unless some other fatal alert
has been transmitted, each party is required to send a close_notify alert
before closing the write side of the connection." RFC 5246 (TLS 1.2)
retains the wording of RFC 4346. I suspect that the server is closing the
write side of the control connection on its end without sending the
close_notify alert first, and I suspect that that is what is causing the
gnutls_record_recv error on the client. The server in question is vsftpd.
Of course, to avoid errors on the server, lftp is sending a close_notify
alert before closing the write side of the connection on its end, right?

[Alexander V. Lukyanov]

Post by Stephen Powell
Of course, to avoid errors on the server, lftp is sending a close_notify
alert before closing the write side of the connection on its end, right?

I have fixed that, please try http://lftp.yar.ru/ftp/devel/lftp-4.5.5.20140918.tar.gz

[Stephen Powell]

Post by Alexander V. Lukyanov

Post by Stephen Powell
Of course, to avoid errors on the server, lftp is sending a close_notify
alert before closing the write side of the connection on its end, right?

I have fixed that, please try http://lftp.yar.ru/ftp/devel/lftp-4.5.5.20140918.tar.gz

OK, I have tried the development snapshot referenced above.
It doesn't seem to give the server any problems. The last four
lines of debug output on the client side are now as follows:

---> QUIT
<--- 221 Goodbye.
gnutls_record_recv: The TLS connection was non-properly terminated.; assuming EOF
---- Closing control socket

I'm not trying to be picky, but the above error message is
not correctly punctuated. The problem is that the error message
text in gnutls_strerror(res) includes a period at the end.
I might suggest something like this in lftp_ssl.cc:

Log::global->Format(7,"gnutls_record_recv: %s Assuming EOF.\n",gnutls_strerror(res));

This will result in two complete sentences on the same line,
correctly punctuated, as long as both message texts
(GNUTLS_E_UNEXPECTED_PACKET_LENGTH and GNUTLS_E_PREMATURE_TERMINATION)
both have a period at the end. I haven't checked that. I'm not
going to quibble over something like this. You can leave it as-is
if you like. This is just a suggestion.

As to your claim that the new development snapshot of lftp
does indeed send a close_notify alert to the server prior to
closing the control connection when TLS is used, I guess I'll
have to take your word for it. I could not find the word "alert"
anywhere in the source package, and the word "notify" could only be
found in reference to notifying other jobs of some event. Of
course, there are lots of references to "close". Too many.
I can't separate the wheat from the chaff.

For the same reason, though I downloaded the source code
for vsftpd, I could not verify that it does *not* send a
close_notify alert. I'm afraid that my miniscule C/C++
programming skills are not up to the task. I am willing
to file a bug report against vsftpd, but I could easily
get shouted down or ignored as someone who doesn't know
what he's talking about. I'm wondering if it would be better
if you opened the bug report with vsftpd. You do know what
you're talking about. And as the maintainer of a popular FTP
client, you would have a lot more clout with the vsftpd maintainer
than I would. In fact, I wouldn't be surprised if you two already
know each other from working together on bug reports in the past.
What do you think? Would it be better for me to do it? Or would
it be better for you to do it?

I could not find a bug-reporting e-mail address for vsftpd,
or a list server for questions. Apparently, you have to directly
e-mail the maintainer

Chris Evans <***@gmail.com>

And if you're lucky, he may reply. If you two don't know each other,
I would suggest introducing yourself as the upstream maintainer of
lftp in the first sentence. That should increase your chances of
getting a reply.

While we're on the subject, I'm very impressed with both the quality
and speed of service for lftp! Thanks again so much!

[Alexander Lukyanov]

Look for gnutls_bye (gnutls) or SSL_shutdown (openssl) calls. See
https://github.com/lavv17/lftp/commit/fc468dc987cb45bab4a3d31a1e832601bc239774
for the change.

Post by Stephen Powell
As to your claim that the new development snapshot of lftp
does indeed send a close_notify alert to the server prior to
closing the control connection when TLS is used, I guess I'll
have to take your word for it. I could not find the word "alert"
anywhere in the source package, and the word "notify" could only be
found in reference to notifying other jobs of some event. Of
course, there are lots of references to "close". Too many.
I can't separate the wheat from the chaff.

[Stephen Powell]

Post by Stephen Powell
As to your claim that the new development snapshot of lftp
does indeed send a close_notify alert to the server prior to
closing the control connection when TLS is used, I guess I'll
have to take your word for it. I could not find the word "alert"
anywhere in the source package, and the word "notify" could only be
found in reference to notifying other jobs of some event. Of
course, there are lots of references to "close". Too many.
I can't separate the wheat from the chaff.

Look for gnutls_bye (gnutls) or SSL_shutdown (openssl) calls. See
https://github.com/lavv17/lftp/commit/fc468dc987cb45bab4a3d31a1e832601bc239774
for the change.

That's a good tip. vsftpd is written for openssl only (no gnutls); so
I searched for the character string "SSL_shutdown". It occurs only in
reference to data connections, not in reference to the control connection.
But that also led me to the following server options:

-----

strict_ssl_read_eof
If enabled, SSL data uploads are required to terminate via SSL,
not an EOF on the socket. This option is required to be sure
that an attacker did not terminate an upload prematurely with a
faked TCP FIN. Unfortunately, it is not enabled by default
because so few clients get it right. (New in v2.0.7).

Default: NO

strict_ssl_write_shutdown
If enabled, SSL data downloads are required to terminate via
SSL, not an EOF on the socket. This is off by default as I was
unable to find a single FTP client that does this. It is minor.
All it affects is our ability to tell whether the client con‐
firmed full receipt of the file. Even without this option, the
client is able to check the integrity of the download. (New in
v2.0.7).

Default: NO

-----

I tried setting both of these server options to yes and tried my "get" with
lftp again. The last few lines of output in the debug file are now as follows:

---- Got EOF on data connection
---- Closing data socket
<--- 426 Failure writing network stream.
---- received all data but no EOF
---> QUIT
<--- 221 Goodbye.
gnutls_record_recv: The TLS connection was non-properly terminated. Assuming EOF.
---- Closing control socket

(You will note that I have applied a local modification to fix the formatting of
the gnutls_record_recv error message.)

In summary, lftp handles the control connection properly, but not the data connection.
vsftpd handles the data connection properly, but not the control connection. I'll
get to work on the vsftpd people about the control connection. Maybe you could do
something about the data connection?

[Alexander V. Lukyanov]

Post by Stephen Powell
I tried setting both of these server options to yes and tried my "get" with
---- Got EOF on data connection
---- Closing data socket
<--- 426 Failure writing network stream.
---- received all data but no EOF

Please test this change.

--
Alexander.

[Stephen Powell]

Post by Alexander V. Lukyanov

Post by Stephen Powell
I tried setting both of these server options to yes and tried my "get" with
---- Got EOF on data connection
---- Closing data socket
<--- 426 Failure writing network stream.
---- received all data but no EOF

Please test this change.

Yes, the patch worked, for this specific test case. But I am having
a problem connecting to a different server which does not support
TLS. In this case, I'm using lftp interactively instead of via a
script. After issuing the close command, I receive the "221 Goodbye."
response from the server, and an lftp command prompt. But I can't type
anything at the prompt. I type "exit" on the keyboard, but it is not
echoed on the screen. The whole program appears to be hung. Eventually,
after several minutes, I get a "closing idle connection" message and
the exit command shows up on the screen, followed by program termination.
I rather doubt that this last patch is responsible. I think it's something
in how the close command is processed. It has to work in both TLS and
non-TLS environments. It currently seems to have a problem in non-TLS
environments.

[Alexander Lukyanov]

I cannot reproduce it. Please use strace on the lftp process, also use
"pstack PID" on it and send me the output.

Post by Stephen Powell

Post by Alexander V. Lukyanov

Post by Stephen Powell
I tried setting both of these server options to yes and tried my "get"

with

Post by Alexander V. Lukyanov

Post by Stephen Powell
lftp again. The last few lines of output in the debug file are now as
---- Got EOF on data connection
---- Closing data socket
<--- 426 Failure writing network stream.
---- received all data but no EOF

Please test this change.

Yes, the patch worked, for this specific test case. But I am having
a problem connecting to a different server which does not support
TLS. In this case, I'm using lftp interactively instead of via a
script. After issuing the close command, I receive the "221 Goodbye."
response from the server, and an lftp command prompt. But I can't type
anything at the prompt. I type "exit" on the keyboard, but it is not
echoed on the screen. The whole program appears to be hung. Eventually,
after several minutes, I get a "closing idle connection" message and
the exit command shows up on the screen, followed by program termination.
I rather doubt that this last patch is responsible. I think it's something
in how the close command is processed. It has to work in both TLS and
non-TLS environments. It currently seems to have a problem in non-TLS
environments.
--
`. `'`
`-
_______________________________________________
lftp mailing list
http://univ.uniyar.ac.ru/mailman/listinfo/lftp

[Stephen Powell]

Post by Alexander Lukyanov

Post by Stephen Powell
Yes, the patch worked, for this specific test case. But I am having
a problem connecting to a different server which does not support
TLS. In this case, I'm using lftp interactively instead of via a
script. After issuing the close command, I receive the "221 Goodbye."
response from the server, and an lftp command prompt. But I can't type
anything at the prompt. I type "exit" on the keyboard, but it is not
echoed on the screen. The whole program appears to be hung. Eventually,
after several minutes, I get a "closing idle connection" message and
the exit command shows up on the screen, followed by program termination.

I cannot reproduce it. Please use strace on the lftp process, also use
"pstack PID" on it and send me the output.

I can reproduce the problem if I run the lftp command directly at a
shell prompt, but if I run the lftp command under strace, I cannot
reproduce it. How aggravating! Perhaps this is a timing problem, and
running the command under strace introduces just enough delay to eliminate
the problem. Also, I cannot use pstack because pstack is not available
for the machine architecture that I am running on.

[Alexander V. Lukyanov]

Post by Stephen Powell

Post by Alexander Lukyanov
I cannot reproduce it. Please use strace on the lftp process, also use
"pstack PID" on it and send me the output.

I can reproduce the problem if I run the lftp command directly at a
shell prompt, but if I run the lftp command under strace, I cannot
reproduce it. How aggravating! Perhaps this is a timing problem, and
running the command under strace introduces just enough delay to eliminate
the problem. Also, I cannot use pstack because pstack is not available
for the machine architecture that I am running on.

You can use gdb instead of pstack:

$ gdb lftp PID
...attached...
(gdb) bt

[Stephen Powell]

Post by Alexander V. Lukyanov
$ gdb lftp PID
...attached...
(gdb) bt

OK, here's the results from using gdb, but I don't know how useful it is.
There's a lot of ?? labels. As a review, I enter lftp with no options
and get an lftp command prompt. I then enter commands like this

debug 9
open -u xxxxxxxx,yyyyyyyy -p xxxxx non-tls.server.com
get -a filename
close

After issuing the close command, I get the "221 Goodbye." message from
the server echoed back on my lftp console session, but I do not get the
"Closing control connection" message from lftp. A new lftp command prompt
is issued, but the "exit" command which I type at the command prompt is
not echoed to the screen. After three minutes (the default value for
net:idle) the deadlock breaks with "Closing idle connections", the exit
command is processed, and lftp terminates. The gdb back-trace is issued
from another terminal session on the same host.

-----

debian3:~# gdb lftp 2080
GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "s390x-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from lftp...(no debugging symbols found)...done.
Attaching to program: /usr/bin/lftp, process 2080

warning: Could not load shared library symbols for linux-vdso64.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Reading symbols from /lib/s390x-linux-gnu/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/s390x-linux-gnu/libz.so.1
Reading symbols from /usr/lib/s390x-linux-gnu/libgnutls-deb0.so.28...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/s390x-linux-gnu/libgnutls-deb0.so.28
Reading symbols from /lib/s390x-linux-gnu/libreadline.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/s390x-linux-gnu/libreadline.so.6
Reading symbols from /lib/s390x-linux-gnu/libutil.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/s390x-linux-gnu/libutil.so.1
Reading symbols from /lib/s390x-linux-gnu/libtinfo.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/s390x-linux-gnu/libtinfo.so.5
Reading symbols from /lib/s390x-linux-gnu/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/s390x-linux-gnu/libdl.so.2
Reading symbols from /usr/lib/s390x-linux-gnu/libidn.so.11...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/s390x-linux-gnu/libidn.so.11
Reading symbols from /usr/lib/s390x-linux-gnu/libstdc++.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/s390x-linux-gnu/libstdc++.so.6
Reading symbols from /lib/s390x-linux-gnu/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/s390x-linux-gnu/libm.so.6
Reading symbols from /lib/s390x-linux-gnu/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/s390x-linux-gnu/libgcc_s.so.1
Reading symbols from /lib/s390x-linux-gnu/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/s390x-linux-gnu/libc.so.6
Reading symbols from /usr/lib/s390x-linux-gnu/libp11-kit.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/s390x-linux-gnu/libp11-kit.so.0
Reading symbols from /usr/lib/s390x-linux-gnu/libtasn1.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/s390x-linux-gnu/libtasn1.so.6
Reading symbols from /usr/lib/s390x-linux-gnu/libnettle.so.4...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/s390x-linux-gnu/libnettle.so.4
Reading symbols from /usr/lib/s390x-linux-gnu/libhogweed.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/s390x-linux-gnu/libhogweed.so.2
Reading symbols from /usr/lib/s390x-linux-gnu/libgmp.so.10...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/s390x-linux-gnu/libgmp.so.10
Reading symbols from /lib/ld64.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/ld64.so.1
Reading symbols from /usr/lib/s390x-linux-gnu/libffi.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/s390x-linux-gnu/libffi.so.6
Reading symbols from /lib/s390x-linux-gnu/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
Loaded symbols for /lib/s390x-linux-gnu/libpthread.so.0
0x0000000080070796 in ?? ()
(gdb) bt
#0 0x0000000080070796 in ?? ()
#1 0x0000000080055008 in ?? ()
#2 0x0000000080055284 in ?? ()
#3 0x000000008000ddea in ?? ()
#4 0x000003fffd0bc580 in rl_read_key ()
from /lib/s390x-linux-gnu/libreadline.so.6
#5 0x000003fffd09d9fe in readline_internal_char ()
from /lib/s390x-linux-gnu/libreadline.so.6
#6 0x000003fffd09e416 in readline ()
from /lib/s390x-linux-gnu/libreadline.so.6
#7 0x0000000080010010 in ?? ()
#8 0x000000008000b732 in ?? ()
#9 0x0000000080015c54 in ?? ()
#10 0x0000000080055008 in ?? ()
#11 0x0000000080055284 in ?? ()
#12 0x0000000080012a62 in ?? ()
#13 0x00000000800090f4 in ?? ()
#14 0x000003fffcc968ee in __libc_start_main ()
from /lib/s390x-linux-gnu/libc.so.6
#15 0x000000008000a926 in ?? ()
(gdb) quit
A debugging session is active.

Inferior 1 [process 2080] will be detached.

Quit anyway? (y or n) y
Detaching from program: /usr/bin/lftp, process 2080
debian3:~#

-----

[Alexander V. Lukyanov]

Post by Stephen Powell

Post by Alexander V. Lukyanov
$ gdb lftp PID
...attached...
(gdb) bt

OK, here's the results from using gdb, but I don't know how useful it is.
There's a lot of ?? labels. As a review, I enter lftp with no options
and get an lftp command prompt. I then enter commands like this

Fortunately, I could reproduce the bug. It's fixed now in the git repository.
The relevant change: https://github.com/lavv17/lftp/commit/373878e89ce67d10f36291e9c13b39b57ff3a1be

Thanks!

--
Alexander.

[Stephen Powell]

Post by Alexander V. Lukyanov

Post by Stephen Powell
OK, here's the results from using gdb, but I don't know how useful it is.
There's a lot of ?? labels.
...

Fortunately, I could reproduce the bug. It's fixed now in the git repository.
https://github.com/lavv17/lftp/commit/373878e89ce67d10f36291e9c13b39b57ff3a1be

The above fix solves the problem. Thank you. As for the server problem
(not closing the control connection with a close_notify alert when TLS is
used), I have reported the problem to the maintainer, but so far have not
received any reply. Thanks again for your excellent responsiveness to
problems.