Re: TLS problem: gnutls-e-again

[Magnus Henoch]

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