[Top][All Lists]

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

Re: TLS problem: gnutls-e-again

From: Lars Magne Ingebrigtsen
Subject: Re: TLS problem: gnutls-e-again
Date: Sat, 05 Mar 2016 17:04:52 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Magnus Henoch <address@hidden> writes:

> Connecting to xmpp.l.google.com:5222...
> gnutls.el: (err=[gnutls-e-again] Resource temporarily unavailable, try again.)
> boot: (:priority NORMAL :hostname gmail.com :loglevel 0 :min-prime-bits nil
> :trustfiles (/opt/local/share/curl/curl-ca-bundle.crt) :crlfiles nil :keylist 
> nil
> :verify-flags nil :verify-error (:hostname . t) :callbacks nil)
> address@hidden: connection lost: ‘STARTTLS negotiation failed:
> GnuTLS error: #<process jabber>, gnutls-e-again’
> Unfortunately, my attempts at creating a self-contained test case have failed
> so far... What jabber.el does, is that it opens an asynchronous network
> connection (:nowait t), performs XMPP feature negotiation in cleartext, and
> then attempts to do STARTTLS using gnutls-negotiate.

On non-blocking sockets, gnutls-boot no longer waits for the connection
to complete.  But if you try to talk to it before it's completed, it
should block the communication until that has happened, so what function
is it that gets that return value?

Anyway, there should be a way to specify that you want TLS negotiation
to complete even on non-blocking sockets, so I've now added this to the
trunk.  It should probably fix your use case, too.

Could you try updating from git and running jabberd again?

(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]