Login/Authentication only on third or fourth attempt?

Openfire Openfire Support
1

Hi all,

I’'ve installed 3.1.1 a couple of weeks back.

Now, I face some weird authentication / login problem. When I haven’'t used the server (pure dev-environment for a bot-network) for some time, the first couple of login attempts simply fail.

Details:

version = 3.1.1 download on jivesoftware,

server = Linux mysrv 2.6.15-26-k7 #1 SMP PREEMPT Fri Jul 7 20:10:15 UTC 2006 i686 GNU/Linux (this is ubuntu dapper)

userdb = integrated (no ldap configured)

mysql = mysqld Ver 4.1.15-Debian_1ubuntu5-log for pc-linux-gnu on i486 (Source distribution)

Serversettings detail:

xmpp.auth.anonymous is false

xmpp.client.tls.policy is required

no proxy used/defined

xmpp.server.permission = whitelist

xmpp.server.session.idle = 900000

xmpp.server.socket.active = false

xmpp.server.tls.enabled = true

xmpp.session.conflict-limit = 3

xmpp.socket.ssl.active = true

java version “1.5.0_06”

Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)

Java HotSpot™ Client VM (build 1.5.0_06-b05, mixed mode, sharing)

Clients used to connect: psi 0.10-2ubuntu2, gajim 0.10.1-0ubuntu1, libnet-jabber-perl 2.0.2 and libnet-xmpp-perl 1.0-1 as well as latest xmpp svn

Btw: Once a connection has been made by one of the clients lately (have no exact time frame for this yet) the next will connect just fine.

I get the following in the logs:

START debug.log:

]

Certificate Extensions: 5

: ObjectId: 1.2.34.56 Criticality=false

SubjectAlternativeName [

DNSName: mysrv.de, Other-Name: Unrecognized ObjectIdentifier: 1.2.3.4.5.6.7.8.9]

: ObjectId: 1.2.34.56 Criticality=false

KeyUsage [

DigitalSignature

Key_Encipherment

]

: ObjectId: 1.2.34.56 Criticality=false

ExtendedKeyUsages [

: ObjectId: 1.2.3.4.5.6.7.8.9 Criticality=false

AuthorityInfoAccess [

[accessMethod: 1.2.3.4.5.6.7.8.9

accessLocation: URIName: http://ocsp.cacert.org]

]

: ObjectId: 1.2.34.56 Criticality=true

BasicConstraints:[

CA:false

PathLen: undefined

]

Algorithm:

Signature:

END debug.log

After which I’'m successfully authorized (no sasl, just tls or ssl, oh yes: does that on both 5222 and 5223)!

(Last error doesn’‘t seem to come up in relation to the “bug”, as LDAP isn’'t onfigured at all, i wonder why it does instantiate the obj…??)

Besides that, nothing in admin-log (except proabably unrelated):

08:57:29.157 ERROR! [SunJsseListener0-1] uk.ltd.getahead.dwr.util.CommonsLoggingOutput.error(CommonsLoggingOutput.java:7 5) >40> Line=19 The content of element type “dwr” must match “(init?,allow?,signatures?)”.

and many

21:54:29.448 WARN!! [Update Manager] org.apache.commons.httpclient.HttpMethodBase.getResponseBody(HttpMethodBase.jav a:676) >04> Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.

I have only now enabled the audit-log and will report back on that if there’'s something suspicious going on there.

Also, if I can figure out when exactly i can and when i can’‘t login, i’‘ll let you know. The client side of things mostly just says: connected to the server, waiting, waiting, waiting, i’‘m out. But I’'m trying to debug that a little further.

Oh: myserv.de is the replacement for a FQDN, i’'m using a cacert.org certified and fully ascerted cert…

Ona sidenote. a reverse lookup on mysrv.de does end up with another (uglier…) name.

rest is working just great!! Thanks to all for the software, the philosophy, the help ))

Cheers

2

almost forgot: sometimes, it does help (speed up things) if instead of logging in with a presence type of “available” i choose “away” or “brb” or whatever. In general, the next attempt if not that same will prevail though i cannot tell if this is really connected to the issue or if it’'s just luck…

3

Hi there,

did some more debugging. Regarding gajim the information was wrong. Looks like i had the order messed up.

  1. i try psi:

START

END

  1. i launch gajim:

START

END

  1. i retry psi and voila:

START

END

So, question remains, why is that so? Both clients definitely go about things differently, gajim negotiates and uses sasl and logs in fine (all the time, i’'ve rechecked), while psi sometimes works, sometimes not. And even without gajim “in between”, it does work after about 3-6… tries.

Thing is with sasl, i can’‘t really try in psi as i thought unchecking the “Allow plaintext login” in the config would do exactly that (or tls, so…), and with perl’‘s net::xmpp there’‘s still that bug around line 1770 of Protocol.pm which doesn’'t allow sasl-logins right now. So it might have sth. to do with sasl.

But what’'s the thing with psi being able to sometimes do it, sometimes not?

Anyone experiencing sth. similar?

4

I HAVE THE SAME PROBLEM

but when i change the user group by other group the problem disappear,

but if change it new to initial group the problem persist

you can resolve it?

You can help me?