SASL Issue When Trying to Connect to Openfire Server

Openfire Openfire Support
1

Morning,

I have been trying to recover my chat services that were powered by Openfire since last night. I am running on the latest PCLinuxOS(KDE4.4). We’re also using MySQL for the data. We installed the Openfire3.6.4 package off this site other than the PCLOS port. To connect to it. Im using PSI. The issue is that it keeps getting this error:

There was an error communicating with the server.
Details: Authentication error: No appropriate mechanism available for given security settings (e.g. SASL library too weak, or plaintext authentication not enabled)

This is the 1st time I ever encountered this error. So, I assumed it was that I did’nt have certain packages installed. Thus went through the PCLOS package manager installing alot of sasl related pakages. Still no change. I still get this error whether I try connecting to the server with or without encryption enabled.

2

Over 55 views and still no one knows anything on this issue?

My lead developer is thinking maybe MySQL is the issue. Would anyone have any insight to add to that? As, I searched this place myself and could not find anything close enough to what we are experiencing.

3

What do the logs say? Also you may try enabling debug mode from the Admin Console. Did you generate the security certificates?

4

From our logs, this is the only exception…

2010.06.18 17:46:22 SASLAuthentication: SaslException

javax.security.sasl.SaslException: DIGEST-MD5: digest response format violation. Mismatched URI: xmpp/phyer.net; expecting: xmpp/127.0.0.1

at com.sun.security.sasl.digest.DigestMD5Server.validateClientResponse(DigestMD5Se rver.java:531)

at com.sun.security.sasl.digest.DigestMD5Server.evaluateResponse(DigestMD5Server.j ava:226)

at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java :296)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:165)

at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:133)

at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.common.IoFilterAdapter.messageReceived(IoFilterAdapter.java:80)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)

at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:185)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)

at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 886)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)

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

So it looks like we might have a config problem. I’ll try and fix it.

Nathan

5

looks like an /etc/hosts issue. why does phyer.net resolve to 127.0.0.1? On hosts that run openfire, an entry in the hosts file must match the actual ip addr, e.g. if not thru dns lookup.

6

That was changed to the actual domain it should have been.

When my lead dev installed everything. He accidentally left the domain field in the initial setup blank. To be safe we went ahead and did a full reinstallation. And this time I made sure to put in the domain.

Unfortunately, it still has’nt resolved the issue. We are still getting the SASL authentication issue. Something has dawned on the the dev guys that maybe MySQL might be the culprit. Could that be an actual possibility? We never had this issue before when we originally ran the service using the embedded database months ago. And if so, what can we do at this point to fix it?

Update:

I should have added in that the client I was trying to use was PSI. I just tried using JWChat. A web based client I normally use to test out configurations. And it had an option that allows you to totally get around connecting with ssl. Unlike PSI. It worked! I was able to connect. But now Im stumped as to what we can do about this.

7

Issue Ressolved!

8

This is to update the community that the issue ressolved itself. Well, with a bit of help.

heres the deal:

Apparently PCLinux2010(KDE4.4) did not have all the needed SASL & PLAIN packages installed by default like previous versions. So, even after I installed all that stuff on the server. I still could not connect. Yet, I could see other people connecting fine! So, I pondered it more and realized it was a “client side” issue. So, I installed all those packages on my desktop. But STILL could not connect! So, upon a reboot. Everything works perfectly now as it should.

So the resolution was to install SASL packages off the PCLOS repo for the client PC and reboot everything! Now with this issue ressolved. This post has come to an end.

Thank You