#779 closed defect (fixed)

Bitlbee hangs on buddy list request when compiled with GnuTLS an connected to

Reported by: anonymous Owned by: wilmer
Priority: normal Milestone:
Component: BitlBee Version: devel
Keywords: Cc:
IRC client+version: Client-independent Operating System: Linux
OS version/distro:


Using bitlbee 3.0.2 and gnutls 2.12.0, bitlbee hangs after requesting the buddy list from the server ( However, Compiled with openssl, everything works fine. Bitlbee runs in ForkDaemon-Mode on Archlinux.

Attachments (1)

Change History (14)

comment:1 Changed at 2011-04-12T08:55:10Z by mhellwig@…

note: the archlinux-bug that discusses this problem is at

I've just tried compiling bitlbee against gnutls, openssl and nss and the only one that works with is openssl. gnutls used to work up until version 2.10.something, with the update to 2.12.whatever it broke ..

comment:2 Changed at 2011-04-12T12:02:16Z by mhellwig@…

note: according to info at the bug is now also visible in debian squeeze.

comment:4 Changed at 2011-04-12T13:40:48Z by anonymous

ok note that at the gnutls bugtracking site (see above, the bit), somebody says something changed in gnutls and now programs have to use it in a different way?

At this point I guess I'll bow out of the proceedings. After all I'm just a humble user.

comment:5 Changed at 2011-04-12T18:03:37Z by anonymous


"gnutls 2.12.0 changed the semantics of gnutls_transport_set_lowat() and the default value is zero."

"Because later versions of gnutls abolish the functionality of using the system call select() to check for gnutls pending data, the function gnutls_record_check_pending() has to be used to achieve the same functionality."

comment:6 Changed at 2011-04-18T12:29:01Z by wilmer

WTF? What are those guys thinking? Thanks for finding that..

This is annoying. I'm not looking forward too much to customizing my event loop code just because those folks like to be different. I'll use the workaround.

comment:7 Changed at 2011-06-12T09:21:07Z by wilmer

Component: JabberBitlBee

Oh yes, so this is fixed with the work-around.

I'll leave it open for a different fix though, since I guess this is not going to work forever.. :-/

comment:8 Changed at 2011-08-22T10:44:09Z by mhellwig@…

note: just tried compiling bitlbee 3.0.3 against new(ish) gnutls, i.e. 3.0.1 and still/again have the "hangs on buddy list request, finally breaks off due to timeout" issue as originally reported. Building against openssl makes it work, at least for

comment:9 Changed at 2011-08-23T05:49:17Z by diopter@…

Compiled against the new gnutls and observing identical behavior to previously, the same as David Orman listed on 4/25/11 at In addition, connecting to both Facebook and GoogleTalk Jabber works correctly with all versions of bitlbee/gnutls I've tried.

For reference the server being contacted that's not working is running OpenFire 3.6.4.

From the GNU bugtracker and looking at the code it seems the issue here is that with the 3.x branch gnutls changed how clients check for remaining encrypted data on the socket, from a "low water mark" select()-based approach to something more asynchronous, requiring the client to poll for new data. At this point, it probably requires a bitlbee patch to correctly handle these situations, assuming it's not somehow a bug specific to OpenFire 3.6.4.

comment:10 Changed at 2011-08-23T07:16:16Z by diopter@…

Just to compare, I decided to install OpenFire 3.7.0 and try bitlbee with both old gnutls, new gnutls and new openssl. All three work perfectly fine, with TLS or SSL on ports 5222 and 5223 respectively.

Looks like this is an OpenFire 3.6.x bug that's already been resolved at this point.

comment:11 Changed at 2011-08-23T07:20:59Z by anonymous

note that doesn't use openfire, it uses ejabberd ("a new enough version" as the admin puts it)

comment:12 Changed at 2011-08-24T17:36:00Z by mhellwig@…

a logfile, since it was requested at the archlinux bug tracker where somebody thought this was "fixed": bitlbee 3.0.3 compiled against gnutls 3.0.1

ssl = true tls = try (same behaviour with tls=false)

<@root> jabber(the_eye@…) - Logging in: Connecting <@root> jabber(the_eye@…) - Logging in: Connected to server, logging in <@root> jabber(the_eye@…) - Logging in: Authentication finished <@root> jabber(the_eye@…) - Logging in: Authenticated, requesting buddy list <timeout after quite 2-3 Minutes wait> <@root> jabber(the_eye@…) - Login error: Connection timeout <@root> jabber(the_eye@…) - Logging in: Signing off..

in contrast with:

ssl = false tls = true

19:17 <@root> jabber(the_eye@…) - Logging in: Connecting 19:17 <@root> jabber(the_eye@…) - Logging in: Connected to server, logging in 19:17 <@root> jabber(the_eye@…) - Login error: Error while reading from server 19:17 <@root> jabber(the_eye@…) - Logging in: Signing off..

so both break.

contrast with bitlbee compiled against openssl where "it just works". (when ssl=true, tls=false. with tls=true, ssl=false I also get the "error while reading from server")

comment:13 Changed at 2011-11-13T15:36:20Z by wilmer

Resolution: fixed
Status: newclosed


Modify Ticket

as closed The owner will remain wilmer.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.