On 2012-05-22 at 09:47 +0200, Nikos Mavrogiannopoulos wrote: > On Tue, May 22, 2012 at 8:48 AM, Janne Snabb <[email protected]> wrote: > > Maybe you were unconsicously planning to file a bug about the misleading > > EOF handling? :) I think we both wasted several hours of debugging time > > because of that. > > If a new error code can not be introduced due to API compatibility > > reasons, the debug output should at least clearly indicate what happened > > (instead of "ASSERT: somefunction(): NNN"). > > Hello, > I don't really understand what you mean here. Is there an issue in > gnutls we can somehow improve?
When we were tracking down the NSS interop issue, we were both led a little astray by one error return. <gnutls/gnutls.h> says: #define GNUTLS_E_UNEXPECTED_PACKET_LENGTH -9 /* GNUTLS_A_RECORD_OVERFLOW */ The error message was "A TLS packet with unexpected length was received." The problem is that *no* TLS packet was received. Instead, there was an EOF condition. (Okay, sure there's a TCP RST involved, but that's not TLS). I spent a bit of time looking for the extra packet, and not seeing it in ssltap/etc this is what led me to initially wonder if there was stale data being left behind from a previous packet to GnuTLS. If it can be accomplished without real interoperability issues, a separate error code for EOF would really help with diagnosis. Thanks, -Phil _______________________________________________ Help-gnutls mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-gnutls
