We are seeing an issue with the generation of presence updates in some federated scenarios, where the local Openfire domain is a substring of the external domain, e.g. when federating with a subdomain, xmpp.org <> ext.xmpp.org.
Deployment details
Issue occurs on Openfire 4.7.5
Issue persists after upgrading to Openfire 5.0.3
Windows x64 installation using .exe installer
XMPP client: Spark 2.9.4 and 3.0.2
Steps
User in the local domain adds a contact from the external domain.
Contact is successfully added in the local user’s client, and is visible in the Openfire admin portal when viewing the user’s roster (with subscription=‘both’).
Initial presence probes/updates are successful - both users see the correct initial presence.
Inbound presence updates from the federated user are handled correctly and shown in the local user’s client.
Issue
Outbound presence updates are not sent to the federated user when the local user changes their presence.
Openfire logs do not indicate any errors, or any attempts to send updates to the federated user.
I have attached a file showing the logs from the time when the local user changes their presence. These are the only logs for several seconds in either direction.
In this setup, two XMPP domains are involved, that are expected to communicate with each-other through regular XMPP server-to-server connections (federation).
Both XMPP domain names share a common part (one appears to be a ‘subdomain’ of the other).
This would be somewhat of an unusual setup.
Openfire, historically, was implemented with an implicit assumption that an XMPP address that appears to be a subdomain of the XMPP domain of the Openfire server relates to a (server-sided) XMPP component. In your example, that wouldn’t be the case, if I understand things correctly.
Can/have you verified that this problem does not occur when the XMPP domain names involved do not share a common part?
Assuming all of my assumptions are correct: I don’t think the way that you’re deploying Openfire is necessarily wrong (from an XMPP specification perspective), but I wonder how easy it would be to address this issue in Openfire’s code, given that it is incompatible with an (arguably incorrect) assumption made by Openfire developers as long ago as two decades, maybe. If you can avoid this particular configuration, that may be the most pragmatic way to work around the issue. Otherwise, some significant work may be required.
Yes, your summary of the issue is correct. To clarify, this also seems to occur even when Openfire’s XMPP domain is any simple substring of the external domain, it doesn’t have to be a subdomain necessarily. For example, we see the same issue with an Openfire XMPP domain like xmpp.org and an external domain like otherxmpp.org. Also, the issue affects presence but does not affect messaging.
We have verified (using the same deployment) that the problem does not occur when the external domain does not contain Openfire’s XMPP domain.
For context, we offer an XMPP protocol bridge service which communicates with Openfire over server-to-server connections. Our customers often use a root domain name as their Openfire XMPP domain, e.g. company.com, so routing to our service is much simpler using a subdomain. The alternative is that they buy/configure another root domain name just for this routing.
A JIRA issue has now been created for this presence update problem: OF-3166.
Although this scenario is relatively uncommon, resolving it may require substantial changes under the hood. If you need a faster solution or hands-on guidance, contacting one of the Ignite Realtime professional support partners can be helpful: Service Providers. Full disclosure: I am listed on that page myself.