I’m having some an issue with a first time setup of Openfire. I have successfully installed and configured the server. I am still having some problems. I am using Pidgin as my xmpp client. I can successfully connect the to openfire server. But when I try to authorize/subscribe to other use accounts on that server, I get the follow error in the openfire logs:
==> error.log <==
2009.01.30 22:47:51 [org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSes sion(LocalOutgoingServerSession.java:258)] Error trying to connect to remote server: hydrian(DNS lookup: hydrian:5269)
java.net.UnknownHostException: hydrian
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSess ion(LocalOutgoingServerSession.java:253)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain (LocalOutgoingServerSession.java:144)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:239)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:216)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
==> warn.log <==
2009.01.30 22:47:51 Error returning error to sender. Original packet:
org.jivesoftware.openfire.PacketException: Cannot route packet of type IQ or Presence to bare JID:
at org.jivesoftware.openfire.spi.RoutingTableImpl.routePacket(RoutingTableImpl.jav a:217)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.return ErrorToSender(OutgoingSessionPromise.java:285)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:219)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
It looks like openfire is trying to do a DNS lookup on the username. I have seen this error before on the mailling list but it was concerning server2server connection, not client2server connections like this. I know my pidgin clients are configured correctly as I have used them with other XMPP servers without issue.I also setup the additional dns name for the server:
xmpp.tygerclan.local
pubsub.xmpp.tygerclan.local
conference.xmpp.tygerclan.local
All of these resolve to the same and only openfire server.
In XMPP addresses are of the form username@domain/resource. A full JID includes the 3 parts that I just mentioned while a bare JID includes only the first two (i.e. username@domain). When you only have one piece then it is considered a domain. Having said that, in your example you have a client sending a packet to the address ‘hydrian’ so to the server that means that that is the address of an XMPP server and not a client. Therefore a s2s connection will be used for delivering that packet. From what you are saying in your server you have an account whose username is hydrian. In that case your client should add to its roster the following address hydrian@xmpp.tygerclan.local. The server will then analyze that address and realize that it belongs to the local server and in particular to a user account.
I believe this is a bug with Openfire, but I can’t find the jira ticket at the moment
Openfire will suck in these bad JIDs and commit them to the database either in the user’s roster or MUC admin tables. It then will break the admin console since it can’t deal with these invalid JIDs in the display.
I understand that there are 3 parts to the XMPP account information. Pidgin also sets a default resource of “Home” if you do not manually set one. I don’t know if it is openfire’s fault of not reading it or pidgin’s fault for not sending it. I also tried changing the default resource to “Tygerclan” to see if it was a default resource issue. The change did help or change anything .
Make sure your openfire server has a server name that is fully qualified (i.e. xmpp.tygerclan.local), and that the xmpp.domain system property uses the same value. If this requires a change you may need to generate new certificates in the openfire admin site. If it still does not work after this I would question your settings in pidgin.
As for the firewall issue, it is unlikely. The openfire server is sitting on my firewall server, but my firewall server does accept all internal traffic normally and I haven’t ever had a problem with it in past. All of my testing so far has only been internal network testing. I haven’t open up the server to the outside world yet.
Using the Openfire Admin Console, look at your System Properties and find the entry “xmpp.domain” In your case this should read either xmpp.tygerclan.local or tygerclan.local. As Todd said, you need a DNS entry for xmpp.tygerclan.local and then point your client to xmpp.tygerclan.local.
I am not sure what all you folks are driving at with the xmpp.domain setting. Openfire does not assume anything about the domain of the subscription packet. It is incorrectly assuming that the JID is a remote server.
Pidgin also should not be sending invalid JIDs to the server, nor should openfire store them.
I did set both parameters in the past and it didn’t help. I did do a reinstallation of openfire at one point so I do not know if both parameters are still set at the moment. I will check when I get home later.
The point we are driving at is too many people take the lazy incorrect approach to setting up their servers. They do not give their servers a proper FQDN when setting up. They hope DNS can compensate, and then need help when it can’t. So in short:
The openfire server name should be a FQDN that is in your DNS (i.e. xmpp.domain.com)
The xmpp.domain should match this FQDN
The self signed certificates should match this FQDN
The ports for communication need to be open in both directions
I have verified that the xmpp.fqdn and xmpp.domain are both set to xmpp.tygerclan.local. I also must mention that I am having some issue with ssl certificates but I don’t think that would effect this. I so allow unencrypted connections.
