No connection to XMPP channels

[slickriptide]

Context:

It looks like discovery is broken somehow.

This is the important part:

PC is asking for a list of registered services, and Openfire is replying back saying... not found. So PC can't locate the MUC service. This is what the reply is supposed to look like:

Then PC would go through the list and query each item to discover which one is the MUC service. Excerpt:

But for whatever reason your Openfire install is saying there aren't any services available. That doesn't look right; pubsub is built in so that should at least be listed. Is Pidgin able to see the MUC service / any rooms?

Just to make things interesting, I'm getting not-quite-the-same behavior using an entirely different XMPP server (Prosody).

Debug Log:

PCC INFO:  Client is now fully initialized and ready!
xmpp DEBUG SRV lookup failed.
xmpp DEBUG Using alternate domain <NULL>, port 0
xmpp DEBUG sock_connect to www5.cjhunter.com:5222 returned 1168
xmpp DEBUG attempting to connect to www5.cjhunter.com
xmpp DEBUG connection successful
conn DEBUG SENT: <?xml version="1.0"?><stream:stream to="www5.cjhunter.com" xml:lang="en" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams">
xmpp DEBUG RECV: <stream:stream version='1.0' from='www5.cjhunter.com' id='6392724b-3df8-45ed-b207-935a2f3a399f' http://www.w3.org/XML/1998/namespace lang='en'>
xmpp DEBUG RECV: <features xmlns="http://etherx.jabber.org/streams"><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>SCRAM-SHA-1</mechanism><mechanism>DIGEST-MD5</mechanism></mechanisms><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/><register xmlns="http://jabber.org/features/iq-register"/></features>
conn DEBUG SENT: <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
xmpp DEBUG RECV: <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
xmpp DEBUG handle proceedtls called for proceed
xmpp DEBUG proceeding with TLS
conn DEBUG SENT: <?xml version="1.0"?><stream:stream to="www5.cjhunter.com" xml:lang="en" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams">
xmpp DEBUG RECV: <stream:stream version='1.0' from='www5.cjhunter.com' id='f9e522f7-bd2f-4961-ac03-8ba01281daa0' http://www.w3.org/XML/1998/namespace lang='en'>
xmpp DEBUG RECV: <features xmlns="http://etherx.jabber.org/streams"><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>SCRAM-SHA-1</mechanism><mechanism>DIGEST-MD5</mechanism></mechanisms><register xmlns="http://jabber.org/features/iq-register"/></features>
conn DEBUG SENT: <auth mechanism="SCRAM-SHA-1" xmlns="urn:ietf:params:xml:ns:xmpp-sasl">biwsbj1zbGlja3JpcHRpZGUscj1WWXdBQU1jVnZGa0FBQUFB</auth>
xmpp DEBUG RECV: <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">cj1WWXdBQU1jVnZGa0FBQUFBZWY1YjNkZTMtMDJiZC00YjJlLWFlZDItMzk4MWNjNDc3NWM3LHM9TkdFeE5UWmxOalF0TkRSbU5pMDBPVEF4TFdFek1qVXRObVZqTUdGbE9XWmtNR1psLGk9NDA5Ng==</challenge>
xmpp DEBUG handle SCRAM-SHA-1 (challenge) called for challenge
conn DEBUG SENT: <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">Yz1iaXdzLHI9Vll3QUFNY1Z2RmtBQUFBQWVmNWIzZGUzLTAyYmQtNGIyZS1hZWQyLTM5ODFjYzQ3NzVjNyxwPWZjNGlvRVlVYlFhVmxKbXZ2RVA1RnFyb1dLTT0=</response>
xmpp DEBUG RECV: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl">dj1wcVNxNGJ0TVVodlgzTW9ZbVdFZXk3SjEyL009</success>
xmpp DEBUG handle SCRAM-SHA-1 (challenge) called for success
xmpp DEBUG SASL SCRAM-SHA-1 auth successful
conn DEBUG SENT: <?xml version="1.0"?><stream:stream to="www5.cjhunter.com" xml:lang="en" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams">
xmpp DEBUG RECV: <stream:stream version='1.0' from='www5.cjhunter.com' id='b9361dd1-c84e-429f-af5d-659f0dfa32c2' http://www.w3.org/XML/1998/namespace lang='en'>
xmpp DEBUG Reopened stream successfully.
xmpp DEBUG RECV: <features xmlns="http://etherx.jabber.org/streams"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><required/></bind><session xmlns="urn:ietf:params:xml:ns:xmpp-session"><optional/></session><c hash="sha-1" xmlns="http://jabber.org/protocol/caps" node="http://prosody.im" ver="ZBWApSGFMsTZkuVThHtyU5xv1Mk="/><ver xmlns="urn:xmpp:features:rosterver"/></features>
conn DEBUG SENT: <iq id="_xmpp_bind1" type="set"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><required/><resource>Artiste</resource></bind></iq>
xmpp DEBUG RECV: <iq id="_xmpp_bind1" type="result"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>slickriptide@www5.cjhunter.com/Artiste</jid></bind></iq>
xmpp DEBUG Bind successful.
conn DEBUG SENT: <iq id="_xmpp_session1" type="set"><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></iq>
xmpp DEBUG RECV: <iq id="_xmpp_session1" to="slickriptide@www5.cjhunter.com/Artiste" type="result"/>
xmpp DEBUG Session establishment successful.
INFO:  XMPP Connected
conn DEBUG SENT: <presence><pc jid="slickriptide@www5.cjhunter.com/Artiste" xmlns="pc:presence" version="Release-1.0.13" protocol="7"/><character class="Class_Controller" badgetitle="AtlasParkTour3" xmlns="pc:character" oldcostume="p33cj2+wrhaDUq/K5Jw0xXivmow=" map="maps/City_Zones/City_01_01/City_01_01.txt" costume="p33cj2+wrhaDUq/K5Jw0xXivmow=" origin="Science" name="Artiste"/></presence>
conn DEBUG SENT: <iq id="00000002-19e33102" type="get"><query xmlns="http://jabber.org/protocol/disco#info"/></iq>
conn DEBUG SENT: <iq id="00000003-19e33102" type="get"><query xmlns="http://jabber.org/protocol/disco#items"/></iq>
conn DEBUG SENT: <iq id="roster_req1" type="get"><query xmlns="jabber:iq:roster"/></iq>
xmpp DEBUG RECV: <presence from="slickriptide@www5.cjhunter.com/Artiste"><pc jid="slickriptide@www5.cjhunter.com/Artiste" xmlns="pc:presence" version="Release-1.0.13" protocol="7"/><character class="Class_Controller" xmlns="pc:character" badgetitle="AtlasParkTour3" oldcostume="p33cj2+wrhaDUq/K5Jw0xXivmow=" map="maps/City_Zones/City_01_01/City_01_01.txt" costume="p33cj2+wrhaDUq/K5Jw0xXivmow=" origin="Science" name="Artiste"/></presence>
xmpp DEBUG RECV: <presence to="slickriptide@www5.cjhunter.com/Artiste" from="slickriptide@www5.cjhunter.com/7509ab46-dd48-4772-ad56-3d5f38d68bf0"><priority>1</priority><c hash="sha-1" xmlns="http://jabber.org/protocol/caps" node="http://pidgin.im/" ver="I22W7CegORwdbnu0ZiQwGpxr0Go="/><x xmlns="vcard-temp:x:update"><photo/></x><delay xmlns="urn:xmpp:delay" stamp="2017-09-15T17:54:10Z" from="www5.cjhunter.com"/></presence>
xmpp DEBUG RECV: <iq id="00000002-19e33102" to="slickriptide@www5.cjhunter.com/Artiste" type="result" from="slickriptide@www5.cjhunter.com"><query xmlns="http://jabber.org/protocol/disco#info"><identity category="account" type="registered"/><identity category="pubsub" type="pep"/><feature var="http://jabber.org/protocol/pubsub#publish"/></query></iq>
xmpp DEBUG RECV: <iq id="00000003-19e33102" to="slickriptide@www5.cjhunter.com/Artiste" type="result" from="slickriptide@www5.cjhunter.com"><query xmlns="http://jabber.org/protocol/disco#items"/></iq>
xmpp DEBUG RECV: <iq id="roster_req1" to="slickriptide@www5.cjhunter.com/Artiste" type="result"><query xmlns="jabber:iq:roster" ver="1"/></iq>
DEBUG: Unhandled cmd_num 97

Prosody is returning an empty items list instead of returning a 404 error. The end result for Paragon Chat is the same.

Why? I have no idea. I can't come up with any rationale why a firewall would interfere in this system and in any case, this all happening inside a network segment where everybody has permission to do whatever they want. There shouldn't be any firewall rules interfering even if it was possible. A XMPP server shouldn't have to make any external connections to know the list of services it has available.

[slickriptide]

The current workaround for this issue is to use /xmpp_set_muc_service to explicitly set the MUC connection and then /mapmove to any map.

Hey, whatever works; though I'd certainly like to figure out just what's going on with the service discovery. Prosody assures me that my XMPP server includes discovery as one of its loaded modules and Openfire just includes it as base feature of the server.

[Codewalker]

I found the issue. Paragon Chat is sending the discovery iq without a 'to' attribute. The original XMPP Core spec (RFC 3920) states that the server should take the appropriate action if it recognizes the request namespace, implying that this iq is 'to' the server itself.

RFC 6120 adds some explicit rules for this scenario -- an iq without a 'to' attribute is assumed to be to the user's entity (username@server.tld). This has important consequences for disco#items, because it means that the server responds to this request with the items that belong to the user, not to the server.

Openfire 4.1.0 and later changes its behavior from the old spec to the newer one. I suspect Prosody's behavior is derived from RFC6120 also.

Specifically, it's this commit:

https://github.com/igniterealtime/Openfire/commit/95f40ab7a64f7d90481476598c6a4d69c601515a

which references these issues:

https://issues.igniterealtime.org/browse/OF-872
https://issues.igniterealtime.org/browse/OF-462

I've reproduced the issue by updating my local test openfire instance to 4.1.5, and tested a fix that explicitly addresses the discovery 'to' the server itself. That will ensure it works properly with either version of the spec. It'll be in the pipeline for release soonish.

[slickriptide]

Groovy. I'm always happy when a mysterious systems problem turns out to have a logical explanation.