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. [email protected] On Fri, Aug 8, 2014, at 02:03 PM, Michael Wojcik wrote: > > -----Original Message----- > > From: [email protected] [mailto:owner-openssl- > > [email protected]] On Behalf Of Donald J. > > Sent: Friday, 08 August, 2014 15:34 > > To: [email protected] > > 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 List [email protected] > Automated List Manager [email protected] -- http://www.fastmail.fm - Same, same, but different... ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
