bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22789: 25.1.50; In last master build https connections stop working


From: Lars Ingebrigtsen
Subject: bug#22789: 25.1.50; In last master build https connections stop working
Date: Tue, 01 Mar 2016 11:41:50 +1100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Alain Schneble <a.s@realize.ch> writes:

> Yes that's what I observed as well.  But also that GnuTLS returns -10
> GNUTLS_E_INVALID_SESSION for some of the connections quite early.

In my experience working with this stuff under Linux, if the session
goes invalid, it's because other parts of Emacs has been doing something
with the socket (either reading or (re-)writing bytes that should have
gone to the GnuTLS library).

Could you strace Emacs while it's doing a failed negotiation, and add
some printfs to the handshaking?  If I remember correctly, I discovered
one instance where the trace looked something like

Trying handshake...
write( ... )
EAGAIN...
Done trying
..
write( ... )
Trying handshake...
GNUTLS_E_INVALID_SESSION

And the reason was that Emacs in the polling code decided to try to
retransmit the data (until I made it stop doing that for TLS sockets).

Could there be something similar in the Windows code paths?

>  #ifdef HAVE_GNUTLS
>               /* Continue TLS negotiation. */
>               if (p->gnutls_initstage == GNUTLS_STAGE_HANDSHAKE_TRIED
> -                 && p->is_non_blocking_client)
> +                 && p->is_non_blocking_client
> +                 && (fd_info[p->infd].flags & FILE_CONNECT) == 0)
>                 {
>                   gnutls_try_handshake (p);
>                   p->gnutls_handshakes_tried++;

I think this change makes sense.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





reply via email to

[Prev in Thread] Current Thread [Next in Thread]