Server-to-server communication and xmpp.domain

Michael_Redinger · November 11, 2007, 11:29am

Hi,

I am re-posting a previous question as (1) the title was misleading and (2) the actual problem description was hidden somewhere deep down in a comment.

I am having trouble with server-to-server communication when using our domain name as xmpp.domain (instead of the hostname of the Openfire server):

I have two Jabber clients (both Spark), two servers and two accounts (one on each server).

On client C1, I am logged in as user U1 on server S1.

On client C2, I am logged in as user U2 on server U2.

On server S1, the XMPP domain is set to mydomain.com (instead of S1.mydomain.com). However, our DNS server is configured properly sothat this should work (see below).

Now as user U2, I try to add the user U1 to my roster. User U1 gets a popup which asks whether he wants to allow this. User U1 co

nfirms this.

However, now user U2 does not get a popup in return (that asks him if he wants to allow being added by U1). The status of the newly created roster entry is still “pending”.

On server U1 I get the following error messages in the log files:

2007.11.08 15:43:33 Failed to route packet to JID: U2@S2.mydomain.com packet:

2007.11.08 15:43:33 Failed to route packet to JID: U2@S2.mydomain.com packet:

2007.11.08 15:43:33 Failed to route packet to JID: U2@S2.mydomain.com packet:

<status>Available</status>

</presence>

I then changed the XMPP domain on server S1 to S1.mydomain.com.

Now everthing worked fine: As soon as user U1 allows being added to the roster, the user U2 also gets a popup message asking if h

e wants to allow being added to the other user’s roster.

So this seems to be a problem with my XMPP domain.

However, I would have expected that S2 (who has to do the lookup and find out that U1@mydomain.com is actually located on S1) shows some errors - at least if it is a DNS problem.

I do not think it is a firewalling problem: The firewall ports are configured correctly (I can connect to 5222 and 5269). Also, i

t works as soon as I change the XMPP domain.

I think I have configured DNS correctly: I have added the IN SRV entries (_jabber, _xmpp-server, _xmpp-client) to our nameservers. Querying the nameservers works fine:

$ dig @nameserver jabber.tcp.mydomain.com any +short

0 0 5269 S1.mydomain.com.

$ dig @nameserver xmpp-server.tcp.mydomain.com any +short

0 0 5269 S1.mydomain.com.

$ dig @nameserver xmpp-client.tcp.mydomain.com any +short

0 0 5222 S1.mydomain.com.

Any idea what the problem is here?

Thanks,

Michael

LG1 · November 11, 2007, 6:23pm

Hi Michael,

I assume that there is a problem how Openfire compares JID’s and there is an open issue for this.

I try to describe your problems in one sentence: s2s between foo.example.com and bar.example.com as xmpp.domains works fine. And s2s between completely different xmpp.domains also works fine. But there is a problem with s2s when using “foo.example.com” and “example.com” as xmpp.domain, isn’t it?

LG

Michael_Redinger · November 13, 2007, 9:59am

Yes, exactly!

I somehow missed that in bug database. Do you know the issue number?

Thanks,

Michael

LG1 · November 13, 2007, 1:32pm

Hi Michael,

I came across JM-419 but this is not the problem you have, so I guess that there is no such issue.

Maybe JM-711 helps you, it allows to specify the remote server IP for a given host name.

I wonder which server has this problem, is it possible for you to enable debugging on both servers and then trying to create a s2s connection? The servers should log something like “OS - Trying to connect to example.com:5269 (DNS lookup: example.com:5269 )” to the debug log. You should then disable debug log again.

LG

Rob_Alexander · December 6, 2007, 8:13pm

LG,

We at WGU have this same issue with server wgu.edu not being able to talk to mychat.wgu.edu. It worked fine with Openfire 3.3.3, but broke once we upgraded to 3.4.1. Jive support says there was some code modification in 3.4 that is making our wgu.edu think mychat.wgu.edu should be a service on itself rather than a different server. The two issues you referenced do appear to be likely to resolve this issue, but I don’t know when they’ll be fixed.

Rob

Rob_Alexander · December 6, 2007, 11:45pm

Here is an e-mail conversation I had this afternoon with Jive regarding this issue:

Original Message-----

From: Scott

Sent: Thursday, December 06, 2007 3:43 PM

To: Rob Alexander

Subject: RE: server to server communication problem

Hi Rob,

I just finished talking with the developer. They are currently in the process of releasing 3.4.2 and so the fix for this issue cannot be included in that release.

The next release will be out in 3 weeks. The bug reports that you had sent in your previous email are different issues than what you are seeing so I have logged a new bug concerning this issue specifically (http://www.igniterealtime.org/issues/browse/JM-1203).

The development team will need to do an assessment of the impact of this change and how much effort it will take. At the moment, installers are the highest priority for the 3.4.3 release.

thanks,

Scott

Original Message -

From: Rob Alexander

To: Gato

Cc: Scott

Subject: RE: server to server communication problem

Gato,

Thanks for your reply. I just got off the phone with Scott in support, and he said he would get together with his manager and you in the next hour or so to see if you could commit to making Openfire 3.4.2 attempt to use the s2s logic if the service isn’t found on the same server.

I look forward to hearing your answer, in hopes that we won’t have to rename our wgu.edu server tonight.

Thank you,

Rob

Original Message-----

From: Gato

Sent: Thursday, December 06, 2007 2:55 PM

To: Rob Alexander

Cc: Scott

Subject: RE: server to server communication problem

Hey Rob,

I guess that you are looking into JM-419 and JM-711 as a way to solve the s2s issue between ‘mychat.wgu.edu’ and ‘wgu.edu’. Unfortunately, none of them will solve the s2s issue you were seeing. Both of those Jira issues affect the s2s logic and in your case based on the XMPP domains that you are using the s2s logic is not used.

The server ‘wgu.edu’ is assuming that ‘mychat.wgu.edu’ is a service running in the same server thus a s2s connection is never attempted.

Openfire assume that services (provided by components) are of the form .[domain]. So in this case ‘wgu.edu’ assumes that ‘mychat.wgu.edu’ is an service and not a remote server.

Regards,

– Gato