Bitlbee hangs on buddy list request when compiled with GnuTLS an connected to jabber.ccc.de

[anonymous]

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

[mhellwig@…]

note: the archlinux-bug that discusses this problem is at ​https://bugs.archlinux.org/task/23678

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

[mhellwig@…]

note: according to info at ​http://web.jabber.ccc.de/?p=273 the bug is now also visible in debian squeeze.

[anonymous]

possible solution at ​https://savannah.gnu.org/support/index.php?107660

[anonymous]

ok note that at the gnutls bugtracking site (see above, the savannah.gnu.org 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.

[anonymous]

On ​https://savannah.gnu.org/support/index.php?107660:

"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."

[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.

[wilmer]

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.. :-/

[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 jabber.ccc.de

[diopter@…]

Compiled against the new gnutls and observing identical behavior to previously, the same as David Orman listed on 4/25/11 at ​https://bugs.archlinux.org/task/23678. 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.

[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.

[anonymous]

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

[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")

[wilmer]

#860.

[anonymous]

​GPS Tracking Orang, ​Klinik Hipnoterapi Surabaya, ​Vertical Blind Jakarta