Modify

Ticket #779 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

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

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:

Description

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.

Change History

comment:1 Changed 4 years ago by 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 ..

comment:2 Changed 4 years ago by mhellwig@…

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

comment:3 Changed 4 years ago by anonymous

comment:4 Changed 4 years ago by 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.

comment:5 Changed 4 years ago by 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."

comment:6 Changed 4 years ago 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 3 years ago by wilmer

  • Component changed from Jabber to BitlBee

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 3 years ago 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 jabber.ccc.de

comment:9 Changed 3 years ago by 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.

comment:10 Changed 3 years ago 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 3 years ago by anonymous

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

comment:12 Changed 3 years ago 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 3 years ago by wilmer

  • Status changed from new to closed
  • Resolution set to fixed

#860.

View

Add a comment

Modify Ticket

Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


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

 
Note: See TracTickets for help on using tickets.