[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TLS problem: gnutls-e-again
From: |
Magnus Henoch |
Subject: |
Re: TLS problem: gnutls-e-again |
Date: |
Sat, 05 Mar 2016 19:05:25 +0000 |
Lars Magne Ingebrigtsen <address@hidden> writes:
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?
The symbol gnutls-e-again was returned from gnutls-boot, inside
gnutls-negotiate. It then called gnutls-errorp on it, which
returned t, and thus an error was signalled.
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?
That fixes the problem. Thanks!
Regards,
Magnus