The FTP client is a batch mainframe process which
must get return code zero, or someone gets called
in the middle of the night. I have been working
with IBM support which claims that the server should
return a Fin before Rst. So I will probably turn this
problem over to our PC server group.
I don't really understand why in the successful sequence,
the client sends Ack PSh and waits to receive the
Ack Fin before sending the close_notify. But in the
failing sequence the client sends Ack Psh, then
immediately sends lose_notify without any waiting.
If the server is closing its connection after sending the
close_notify, it probably wouldn't send the Ack Fin in
the successful sequence?
I guess IBM is saying the server should send Ack Fin,
wait for Ack from client, and server then would send
the AckRst?
--
Donald J.
dona...@4email.net
On Fri, Aug 8, 2014, at 02:03 PM, Michael Wojcik wrote:
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Donald J.
Sent: Friday, 08 August, 2014 15:34
To: openssl-users@openssl.org
Subject: RST after close_notify
I have an issue with an FTP client issuing a DIR command to a Windows
FTP server.
A normal packet trace is shown in sequence 1 below. An Ack Fin is
received
from the Windows FTP server and the DIR command completes successfully.
Both of your traces below show an RST in the final packet, not a FIN.
In the 2nd sequence, each side exchanges close_notify, but no Fin
flags are set.
Windows FTP server ends with an Ack Rst. After receiving the Reset
packet,
the FTP client issues a connection reset' message and sets an error
code.
Is that the correct thing to do?
Are you questioning the server's behavior, or the client's?
Probably what happened is the server sent its close_notify and then
closed its end of the connection without waiting for the client's
close_notify response. See Eric Rescorla's /SSL and TLS/ book, 8.10, for
further discussion. This is unfriendly behavior by the server, in my
opinion, but common enough for Rescorla to discuss it.
It's also possible the server did an abortive close, which would be the
Wrong Thing to do, but the former case is more likely. And in any event,
your client couldn't distinguish between the two. (And what would you do
about it anyway? If someone else's server behaves badly, you have to deal
with it in some fashion.)
How the client handles receiving a RST (generally manifests as a return
code of -1 from send or recv, with errno set to ECONNRESET [1]; with
OpenSSL you should get SSL_ERROR_SYSCALL and check errno) is a matter of
taste. Often you do want to report that the connection was reset. In this
case, though, since a reset is not unexpected AND you know you've
received all the data from the server - you got its close_notify - it's
better to silently ignore it.
In short, the logic should be something like this:
if RST-received
if we were trying to send data
check for a close_notify from the peer
end-if
if close_notify not already recevied from peer
treat as failure
end-if
close socket and clean up
end-if
[1] This assumes the application, if it's running in a POSIX environment,
has set the disposition of the SIGPIPE signal to ignore. SIGPIPE is a
kluge for applications that don't check the result of the write/send
family of system calls. Any well-written application should ignore it.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
--
http://www.fastmail.fm - Same, same, but different...
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
