> Simon Josefsson <[EMAIL PROTECTED]> wrote: >I suspect the error handling here is simply sub-optimal, and that you >aren't doing anything wrong.
>Creating a self-test inside GnuTLS tests/ that trigger this situation >would help. Having that self-test would help us test what kind of >errors really should be returned in this situation, and how to return >them. I can't commit to work on this now, so I added the following to >doc/TODO: >- Investigate why failed client authentication results in weird error > messages. See http://permalink.gmane.org/gmane.network.gnutls.general/875 >If you or others wants to work on it, you are very welcome to do so. >/Simon Hi. I did some investigating and can report a little more detail. I began with replacing the underlying push function, send(), with a variant, send_msg_nosignal(), in order to avoid the nagging SIGPIPE that is being thrown when send() is called against a broken connection. Unless you catch SIGPIPE (or ignore it), the app. just exits with -141 (Unknown error) when gnutls pushes against a broken connection. #ifdef HAVE_MSG_NOSIGNAL static ssize_t _send_msg_nosignal (gnutls_transport_ptr_t ptr, const void *buf, size_t buflen) { ssize_t ret = send ( (int)ptr, buf, buflen, MSG_NOSIGNAL); /* Here I can look at the actual error. On Linux I am seeing EPIPE. Other unices probably return ENOTCONN. */ ... return ret; } #endif and elsewhere in my code I issue this statement as I am setting up the tls session: #ifdef HAVE_MSG_NOSIGNAL gnutls_transport_set_push_function (tls->session, _send_msg_nosignal); #endif The error that is causing gnutls to issue GNUTLS_E_PUSH_ERROR in my variant above is that send() is returning EPIPE. I tried replacing the EPIPE with ENOTCONN, just to see if gnutls "behaved better" on this error. I still get GNUTLS_E_PUSH_ERROR. That seems to explain the reason for the GNUTLS_E_PUSH_ERROR client-side errors when the server breaks off, and vice versa. Perhaps the other error I see, GNUTLS_E_UNEXPECTED_PACKET_LENGTH, when a peer breaks off may be due to some unread TLS bytes in the tcp buffers? I suppose, for now, the way to proceed is simply to treat GNUTLS_E_PUSH_ERROR GNUTLS_E_UNEXPECTED_PACKET_LENGTH as "acceptable" errors that may occur during the handshake, indicating that the peer broke off because it doesn't like our certificate, or that we failed to send one when required to do so. Phil
pgpTBkUcZheAG.pgp
Description: PGP signature
_______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
