Re: TLS problem: gnutls-e-again

[Magnus Henoch <magnus.henoch@gmail.com>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Magnus Henoch <magnus.henoch@gmail.com> 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) magnus.henoch@gmail.com: 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