Our organization has a huge domain structure with multiple subdomains and we need s2s-connections between XMPP servers. But there is a problem. When I try to send message from user1@domain.com to user2@subdomain.domain.com JM-server ‘‘domain.com’’ doesn’‘t perform neither s2s-connection nor dns lookups ( I can see it in tcpdump output ). Instead it tries to deliver it locally. I think, this is because JM-server interpret ‘‘subdomain’’ as a service (like ‘‘conference’’ or ‘‘search’’). I saw some threads about this problem, but I didn’'t find the solution. Is there a workaround ?
PS. JM nightly build 2005-07-21. All dns records ok.
PPS. Actually, you do not need another subdomain XMMP server to reproduce this bug
THANK YOU! I have finally found somebody else with my problem! I am having the exact same problem as you, but you explained it much better than I did. I, too, noticed that messages seemed to be destined to the local server rather than the remote server. Upon disconnecting and reconnecting the client (Psi), all the messages I had sent to the remote server suddenly appear, all of which having the source and destination of the local user. What Zenith said above makes perfect sense, and it describes my problem perfectly. Any help provided would be most appreciated. Developers? Anyone? Thanks!
I’‘d like to add. SMTP protocol has a similar problem, but every SMTP-server has a configuration option which defines local delivery domain (’‘mydestination’’ option in Postfix or ‘‘local-host-name’’ file in Sendmail). Also I read ejabberd documentation briefly and found an option ‘‘hosts’’ which defines domains for serving, but I don’‘t know exact meaning of this option because I didn’'t use ejabberd
When completing this same test, I do not receive a 404 reply. However, using Ethereal, I do notice DNS lookups being made by the Jive server. I am going to install the most recent build of Jive on two servers and test more using this method. Does anyone else have any ideas that might be of some help?
Yeah, apparently they do like to ignore us. I personally think not being able to connect to another Jabber server is a rather critical problem, and it makes it rather diffuicult to use the S2S communication feature, but oh well…
I have this problem too. I use last available source (jive_messenger_src_2005-07-25.zip) and I found the location of problem in file src/java/org/jivesoftware/messenger/spi/RoutingTableImpl.java (86):
if (!node.getDomain().contains(serverName)) {
// Authenticate this hostname with the remote server so that the remote server can
If the domain part of destination contains server name as substring, server doesn’‘t authentificate destination and s2s service doesn’‘t work. It’‘s incorrect code because it don’'t work with subdomains, and not only, for example foo.com and foo.com.ru.
I solve the problem with hack, and it isn’'t right solution, but it is work right.
if (!node.getDomain().contains(serverName) || node.getDomain().contains(“subdomain.name”))
I hope it helps the developers to solve this problem more correctly.
First of all I apologize for not replying before but we have been very busy adding other new features to JM for the upcoming release. This problem has been fixed so you can try again with the next nightly build. BTW, the new nightly build includes also some performance improvements.
Update: I have installed the most recent build of Jive (2005-07-27), and the problem seems to have been corrected, mostly. I am using Psi 0.9.3 to connect to two Jive servers simultaneously, and I am experiencing a small bug with the status of remote contacts. From what I can tell, the remote contacts of one server work appropriately, where the remote contacts on the other server always indicate offline. The determining factor is the order in which the servers are connected. If I connect to ServerA first, then the remote contact on ServerA (to ServerB) works, where the remote contact on ServerB (to ServerA) indicates offline. At this point, if I reconnect to ServerA, both remote contacts indicate online. The same conditions apply to other users running on separate instances of Psi. Regardless of the status of the remote contacts, all message communication works perfectly. Thanks again for the help.