Issue authenticating when using gsasl 1.6.0

Bug #737229 reported by Eric Schnnoebelen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Jabberd
Confirmed
Medium
Unassigned

Bug Description

Using Jabberd2 2.2.13, built on NetBSD/alpha 5.0, with the gsasl 1.6.0 SASL library, jabberd/c2s hangs when a client attempts to connect.

Running with gsasl 1.1, all works as expected.

Revision history for this message
Eric Schnnoebelen (eric-cirr) wrote :
Revision history for this message
Tomasz Sterna (smoku) wrote :

Please run c2s in debug mode -D to see the nature of the problem.

Changed in jabberd2:
status: New → Incomplete
Revision history for this message
Eric Schnnoebelen (eric-cirr) wrote :

My apologies, I should have included that.

I have attached two copies of ``c2s -D'' output. One from gsasl 1.1, which works correctly, and one from gsasl 1.6.0, which fails to complete authentication.

Revision history for this message
Eric Schnnoebelen (eric-cirr) wrote :
Revision history for this message
Tomasz Sterna (smoku) wrote :

Actually there is nothing wrong with attached log of gsasl 1.6.0.

There was a success on SASL authentication and then your client instead reopening the stream, disconnected out of blue:
[...]
sx (sx.c:199) finished resetting stream state
sx (server.c:237) doing server init for sx 8
sx (server.c:252) waiting for stream header
sx (server.c:255) tag 8 event 0 data 0x0
Fri Mar 18 09:57:41 2011 c2s.c:35 want read
sx (io.c:383) tag 8 event 0 data 0x0
Fri Mar 18 09:57:41 2011 c2s.c:35 want read
Fri Mar 18 09:58:14 2011 c2s.c:525 read action on fd 8 <-- here jabberd wants stream header
sx (io.c:498) 8 state change from 0 to 6 <-- and here your client broke connection
sx (io.c:499) tag 8 event 7 data 0x0
Fri Mar 18 09:58:14 2011 c2s.c:544 close action on fd 8
Fri Mar 18 09:58:14 2011 [notice] [8] [192.67.63.19, port=54834] disconnect jid=unbound, packets: 0

Could you try any other client than Psi?

Revision history for this message
Daniel Bahrdt (daniel-launchpad-net) wrote :

Hi,
I'm also having this problem and I just don't find a way around it,apart from disabling sasl-auth.
Kopete works with old-style-ssl if I specify the server manually as server.funroll-loops.de.
Pidgin works with old-style-ssl, but not with starttls (invalid response from server).
The fqdn of the host is server.funroll-loops.de.
Log-File with pidgin-2.9: http://public.funroll-loops.de/jd2.log

The important config parts:
c2s:
<local>
<id realm='funroll-loops.de'
        pemfile='/etc/ssl/services/funroll-loops_jabber.pem'
        register-enable='true'
        verify-mode='0'
        password-change='true'
    >funroll-loops.de</id>
    <id realm='funroll-loops.de' pemfile='/etc/ssl/services/funroll-loops_jabber.pem' register-enable='true' verify-mode='0' password-change='true' require-starttls='mu'
    >server.funroll-loops.de</id>

</local>

<mechanisms>

      <traditional>
        <digest/>
      </traditional>

      <sasl>
        <digest-md5/>
      </sasl>

    </mechanisms>

    <ssl-mechanisms>
      <traditional>
        <plain/>
        <digest/>
      </traditional>

      <sasl>
        <plain/>
        <digest-md5/>
      </sasl>

    </ssl-mechanisms>

Revision history for this message
Tomasz Sterna (smoku) wrote :

According to http://<email address hidden>/msg01710.html this is a client bug, that it does not properly handle end of SASL negotiation.
This message also includes workaround.

Changed in jabberd2:
importance: Undecided → Medium
status: Incomplete → Invalid
Revision history for this message
Tomasz Sterna (smoku) wrote :

Reopening as this is workaroundable as Bug 899284 demonstrates.

Changed in jabberd2:
status: Invalid → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.