powered by Jive Software

Spark login issues

Many of my Spark users are having problems logging in. Usually the first two times they try logging in they are presented with an error: Invalid Username or Password.

The third time they are successful.

Seems to only be happening with versions 1.1.2.5 and 1.1.3

My iChat users are not having this problem.

Any ideas?

The DNSLookup that is happening by default might be failing. To test out the connection more, go to the “advanced” settings in the login dialog, uncheck the auto-discovery and put in the explicit settings. This should work, as well as a side benefit of logging in much quicker.

Cheers,

Derek

Is there any server side changes that I can make to alleviate problem for my users?

Hi gmurob,

What is the domain you are having your users connecting to and what is the domin setting in your server? I just want to make sure these match up.

-Derek

That’'s a good point. Is it okay if the XMPP domain is different from the hostname/domain of the machine? Any problems you can think of?

I had similar problems today and found that explicitly specifying the settings on the advanced tab cured the problem.

However, if I changed the userid then the login would fail again even tho the settings were still set in the advanced tab, unless i went back to the advanced tab and actually clicked through the fields and clicked OK.

Hi OldAndGrey,

Could you clarify what you mean by this issue? Just want to make sure I file the correct bug

Thanks,

Derek

I’'m still having problems with some of my users.

My XMPP domain is: acme.com

Hostname (returned via unix commandline): asdf.acme.com

Hostname (reported on wildfire web interface): acme.com

Users have configured asdf.acme.com as the host. Nothing configured under the advanced tab.

Should this work???

Hi,

I think that Spark and some other clients accept the xmpp.domain that Wifi sends them. So after or during login they switch to acme.com. I have no idea which IP address will be used anyhow.

Does the DNS server returns the same IP address for both domains?

Why did you set the xmpp.domain to acme.com in the web interface? Wifi itself does not store the xmpp.domain in the database but if you are using s2s and have cross-server rosters changing it may cause trouble.

LG

The only dns record is for jabber.acme.com. There is no DNS record for acme.com.

I set the xmpp.domain to acme.com to keep jabber ids shorter (in the case that people need to manually add others to their buddy list).

Are there any special DNS entries that might fix this issue without adding an A record for acme.com?

Would adding an A record for acme.com help?

Might it be wiser to transition my users and JIDS to jabber.acme.com? How hard is that?

Message was edited by: gmurob

I’‘m now very confused. =) Spark has the worst problems logging into my -local- servers. (that are accessible via my internal network) And yeah, it can interact with jabber.org just fine. I’‘ve tried various iterations of specifying the server directly, using ip addresses instead of hostnames, auto-detect and not auto-detect. Different jids. Judging from the debug logs (i’‘ve been working on a sparkplug so I’‘ve been watching the debug output), it looks like there’‘s some sort of ssl error? I don’‘t know enough about what I’'m looking at here to tell. =) Anyway, hopefully this is helpful.

java.net.SocketException: Socket closed

at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)

at java.net.SocketOutputStream.write(SocketOutputStream.java:136)

at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)

at sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404)

at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)

at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)

at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)

at java.io.BufferedWriter.flush(BufferedWriter.java:230)

at org.jivesoftware.smack.util.ObservableWriter.flush(ObservableWriter.java:48)

at org.jivesoftware.smack.PacketWriter.writePackets(PacketWriter.java:242)

at org.jivesoftware.smack.PacketWriter.access$000(PacketWriter.java:36)

at org.jivesoftware.smack.PacketWriter$1.run(PacketWriter.java:70)

javax.net.ssl.SSLProtocolException: java.io.IOException: subject key, Unknown key spec: Invalid RSA modulus size.

at com.sun.net.ssl.internal.ssl.HandshakeMessage$CertificateMsg.(DashoA12275)

at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA12275)

at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA12275)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA12275)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA12275)

at org.jivesoftware.smack.XMPPConnection.proceedTLSReceived(XMPPConnection.java:11 18)

at org.jivesoftware.smack.PacketReader.parsePackets(PacketReader.java:322)

at org.jivesoftware.smack.PacketReader.access$000(PacketReader.java:43)

at org.jivesoftware.smack.PacketReader$1.run(PacketReader.java:63)

Caused by: java.security.cert.CertificateParsingException: java.io.IOException: subject key, Unknown key spec: Invalid RSA modulus size.

at sun.security.x509.X509CertInfo.(X509CertInfo.java:155)

at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1679)

at sun.security.x509.X509CertImpl.(X509CertImpl.java:173)

at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:90 )

at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.ja va:389)

… 10 more

Caused by: java.io.IOException: subject key, Unknown key spec: Invalid RSA modulus size.

at sun.security.x509.X509Key.parse(X509Key.java:155)

at sun.security.x509.CertificateX509Key.(CertificateX509Key.java:58)

at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:706)

at sun.security.x509.X509CertInfo.(X509CertInfo.java:153)

… 14 more

java.lang.NullPointerException

at org.jivesoftware.smack.SASLAuthentication.send(SASLAuthentication.java:405)

at org.jivesoftware.smack.sasl.SASLMechanism.authenticate(SASLMechanism.java:68)

at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java: 190)

at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:426)

at com.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:586)

at com.jivesoftware.LoginDialog$LoginPanel.access$400(LoginDialog.java:179)

at com.jivesoftware.LoginDialog$3.construct(LoginDialog.java:492)

at com.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:121)

at java.lang.Thread.run(Thread.java:552)

No response from the server.:

at org.jivesoftware.smack.NonSASLAuthentication.authenticate(NonSASLAuthentication .java:58)

at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java: 223)

at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:426)

at com.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:586)

at com.jivesoftware.LoginDialog$LoginPanel.access$400(LoginDialog.java:179)

at com.jivesoftware.LoginDialog$3.construct(LoginDialog.java:492)

at com.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:121)

at java.lang.Thread.run(Thread.java:552)

situation - I couldnt log in with correct user id and password

Changed settings on advanced tab and was able to log in

Tried to log in using a different userid and correct password - failed

Checked settings in advanced tab - still set

Clicked through the option in advanced tab

Tried to log in - success

logged out

try to log in using first userid - failed

click through settings on advanced tab

log in - success

etc…

Oddly enough, that scenario wasn’'t working for me, so i may be having a different problem from you all.

I’'m still having the same issues…

Twice they get an “incorrect username/password error”. Then they are able to connect.

Debugging on the client side shows:

Message was edited by: gmurob

Interesting . . . that means conflict. (409 does) Sounds like either wildfire thinks that the resource you are logging in as is still claimed, or Spark is trying to auth twice as the same resource so the second time it really -is- already claimed.

I’'ve never seen a client make use of bind before. =) Interesting. Psi does this:

Okay… I think I found the culprit…

Under Conflict Policy I had “Assign Kick Value” set to 2.

Now I changed it to:

“Always kick”.

Seems to be working.

Where is this conflict policy item located? I want to try and change mine!

It’‘s in the left column of the Wildfire configuration web interface. It’'s under Resource Policy. =)