Hi everyone.
We just installed Openfire 4.0.2 on our server this morning, and after setting up the first users, clients just get some variation of “Your password is incorrect”. I’ve tested this with unencrypted connections, and it’s still happening, even though I copy and paste the password directly into both the Openfire console and the customer’s client.
I have no idea where to go from here. The server Info logs don’t even seem to produce any output when the client connects.
Have you tried manually typing say ‘test’ as a password into Admin Console and then Spark (or other client you use)?
Thanks for being so thorough and all. I did just try that, and no, same result. Incorrect password.
So, is it Spark? Because Spark usually gives “Invalid username or password” when password is incorrect. Or it could be that username is incorrect.
Hi
I have also big problem with this version.
I read there is an incompatibility with java 7 but I try with java 8 and I have the same pb.
No, it’s not spark. We mostly use Trillian, but I get the same thing in Pidgin.
So, where should I be looking in the server logs for these login errors? It would be nice if the server actually had something to say about this, like for example, that there was a password mismatch with the user found in the database, or that the user wasn’t found, or that the database couldn’t be contacted, or that there was some other kind of technical error that was causing the invalid password when, um, you know, I have the actual password right?
Because yeah, I’m not a raging noob who got his password wrong? I’ve been quite clear on this point so far. You really really really can’t be wrong about your password when you copy and paste it both into the server and the client.
what are you running openfire on? linux or windows? if linux, what distro?
The thing is that it may be a not correct error on the client side and maybe server has nothing to report as no connection is made to it. Copy paste is not always an error proof method as some applications can add additional chars, so manual input is just a way to eliminate such possibility. Anyway, i will try to test it with Pidgin later to see what errors it shows in different situations. Although, starting with Openfire 3.10.2 Pidgin only works in debug mode for me on my test server (hangs otherwise).
pidgin connects fine for me on 4.02 using local accounts and ldap accounts. @Ernie, maybe your antivirus or firewall is causing you an issue? can you telnet to your openfire instance on port 5222 from the workstation trying to connect?
Yes, I’m able to telnet to the server on port 5222. I’m pretty sure it’s not the client, since I’m trying this with two different clients, and also on more than one computer. After all, I’m setting up a server for an entire office full of people. I’m not the only one having this problem.
I’m running Openfire on Linux, Ubuntu 14.04 LTS.
from the openfire admin panel, what version of java does it show? There have been reports of issues with openjdk, and any version of java7 on deb builds is causing issues. If you are running openjdk or java7, please try using oracle jre 8.
Ah. It’s OpenJDK 7. I’ll upgrade it.
Nope. Upgrading to Oracle Java 8 has not solved the problem.
ok…the next thing to check is your encryption info in the admin console
http://localhost:9090/connection-settings-advanced.jsp?connectionType=SOCKET_C2S &connectionMode=plain
some clients require sslv2hello, so look at that.
Also check your cipher suites. might be best to reset this to defaults. some clients…wont connect with a cipher over 128.
Please double check the version of Java reported by Openfire on the admin console’s homepage. Sometimes folks install java 8 and the start script does not use it by default.
Yup! It’s using Java 8 for sure.
In Pidgin, when you copy/enter the password and press OK, does it give you “user@server / disabled Not Authorised” error or something else?
Ugh. I found the problem.
I was replacing ejabberd with Openfire on this server, and ejabberd was still installed.
I discovered the problem by running netstat -nlp |grep java and found this:
root@worker2:/etc/openfire/security# netstat -nlp |grep java
tcp6 0 0 :::9090 :::* LISTEN 32359/java
tcp6 0 0 :::9091 :::* LISTEN 32359/java
tcp6 0 0 :::5229 :::* LISTEN 32359/java
tcp6 0 0 :::5262 :::* LISTEN 32359/java
tcp6 0 0 :::5263 :::* LISTEN 32359/java
tcp6 0 0 :::7443 :::* LISTEN 32359/java
tcp6 0 0 :::5276 :::* LISTEN 32359/java
tcp6 0 0 :::7070 :::* LISTEN 32359/java
Wait, no port 5222 or 5223?
root@worker2:/etc/openfire/security# netstat -nlp |grep 5222
tcp 0 0 0.0.0.0:5222 0.0.0.0:* LISTEN 3153/beam
So because port 5222 was already in use, Openfire couldn’t start the server on that port. I removed ejabberd and restarted Openfire, and now I’m connecting to the right server.
It also helps to search /var/log/openfire/all.log for the string “ERROR”, although it doesn’t exactly say that the socket is already in use.
When I tested this my error_log had
2016.04.14 15:14:03 org.jivesoftware.openfire.spi.MINAConnectionAcceptor[socket_c2s] - Error starting: 5222
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
…snipped…
did yours not have this?