This was to netware 6.5 with all current patches
The client did not wait for ACKnowledgment segments from the server's TCP for the sent data and it did not send an SSL Closure Alert before it initiated closure of the TCP connection, but it immediately initiated closure of the TCP transport with the last data segment.
Packet trace shows this to be true. One work around is to lower the buffer to 500 from 4096. But that's to slow on large files. Can this be fixed?
Here's more if it helps as someone else gave to me ....
You can find the SSL version 3.0 protocol specification at http://wp.netscape.com/eng/ssl3/draft302.txt.
The SSL version 3.0 protocol specification reads the following about Close Alerts,
"5.4.1 Closure alerts
The client and the server must share knowledge that the connection
is ending in order to avoid a truncation attack. Either party may
initiate the exchange of closing messages.
close_notify This message notifies the recipient that the
sender will not send any more messages on this
connection. The session becomes unresumable if
any connection is terminated without proper
close_notify messages with level equal to
warning.
Either party may initiate a close by sending a close_notify alert.
Any data received after a closure alert is ignored.
Each party is required to send a close_notify alert before closing
the write side of the connection. It is required that the other
party respond with a close_notify alert of its own and close down
the connection immediately, discarding any pending writes. It is
not required for the initiator of the close to wait for the
responding close_notify alert before closing the read side of the
connection.
NB: It is assumed that closing a connection reliably delivers
pending data before destroying the transport."
In case of uploading a file, the FTP client is the write side of the connection. Because the FTP client did not send a close_notify alert before it closed the transport connection and because the specification reads that each party is required to send a close_notify alert before closing the write side of the connection and that the close_notify is to avoid a truncation attack, I think the client is causing the problem in this case.