[jdev] Debugging Info for Prosody and Conversations (And why I missed Council).

Dave Cridland dave at cridland.net
Thu Dec 14 10:32:30 UTC 2017

Hi folks,

So I missed the Council meeting last night despite managing to arrange
both WiFi and an entire meeting room with the client I was working

Luckily, between my server and muc.xmpp.org there's a Metre instance
which does traffic enforcement (to increase security), and also logs
everything in plaintext (to remove any security again...).

So here is a tale of two servers, a chatroom, a weird MITM thing, and a client.

Dramatis Personae:

My client: Conversations, Google Play version, on an Android Tablet.
(The tablet has a hardware keyboard, in case you wonder, so it's
fairly practical for this kind of thing). The jid is
dwd at dave.cridland.net/tablet - I deliberately use a fixed resource
string here because it makes debugging much easier.

My server: Openfire 4.2.0 (4.2.1 is out, of course, but I've been a
bit busy). Jid is dave.cridland.net of course.

Metre: Github master. Metre (tries to be) notable for enforcing
security and doing a lot of piggybacking. Metre doesn't have its own
jid. Poor Metre. Instead it pretends to the world it is hosting
dave.cridland.net, and pretends to dave.cridland.net that it hosts the
entire world. Perhaps it does, and everything else is an illusion. It
would explain so much.

muc.xmpp.org: Prosody MUC internal component.

xmpp.org: Prosody IM (same server instance as muc.xmpp.org).

On Tuesday morning at 10:02, my client decides to leave the council
MUC. I have no idea why it's chosen to do this, possibly it's trying
to force a resynchronization:

DEBUG 2017-12-12T10:02:29 /home/dwd/src/Metre/src/xmlstream.cc:95 : NS320 - Got
[96] : <presence type="unavailable" from="dwd at dave.cridland.net/tablet" to="coun
cil at muc.xmpp.org/dwd"/>

It then sends a disco#info query:

DEBUG 2017-12-12T10:02:29 /home/dwd/src/Metre/src/netsession.cc:115 :
NS195 - Send: <iq to="council at muc.xmpp.org"
from="dwd at dave.cridland.net/tablet" type="get"

It will never get a reply to these stanzas. (Cue dramatic music).

Shortly before, on Tuesday morning at 10:01 UTC, xmpp.org connected to
Metre. There's the usual TLS and SASL exchange (Metre trusts the CA
xmpp.org uses and validates the cert), and then this curious traffic:

DEBUG 2017-12-12T10:01:01 /home/dwd/src/Metre/src/xmlstream.cc:95 : NS575 - Got
[297] : <?xml version='1.0'?><stream:stream xmlns:db='jabber:server:dialback' xm
lns:stream='http://etherx.jabber.org/streams' version='1.0' from='xmpp.org' to='
dave.cridland.net' xml:lang='en' xmlns='jabber:server'><presence type='unavailab
le' to='dwd at dave.cridland.net/tablet' from='memberbot at xmpp.org'/>

Note the pipelining of the stanza with the stream open. I don't think
that's wrong, as such, but it's worthy of note. Metre will handle this
fine, returning stream features and then processing the stanza (by
forwarding it through). I'm pretty sure the new session and presence
is in response to Conversations coming online and causing a probe,

But the next traffic it receives is this:

DEBUG 2017-12-12T10:02:29 /home/dwd/src/Metre/src/xmlstream.cc:95 :
NS575 - Got [855] : <iq
type='result' to='dwd at dave.cridland.net/tablet'
from='council at muc.xmpp.org'><query
xmlns='http://jabber.org/protocol/disco#info'><identity type='text'
name='council' category='conference'/><feature
var='muc_unsecured'/><feature var='muc_unmoderated'/><feature
var='muc_open'/><feature var='muc_persistent'/><feature
var='muc_public'/><feature var='muc_semianonymous'/><x type='result'
xmlns='jabber:x:data'><field type='hidden'
type='text-single' label='Description'
type='text-single' label='Number of occupants'

This is a disco#info response to my client's query, but it's come back
on a connection which is only authorized for xmpp.org, and not
muc.xmpp.org. Metre does the only thing it reasonably can:

DEBUG 2017-12-12T10:02:29 /home/dwd/src/Metre/src/netsession.cc:115 :
NS575 - Send: <stream:error><not-authorized
xmlns="urn:ietf:params:xml:ns:xmpp-streams"><text>Not authorized to
perform that action</text></not-authorized></stream:error>

This pattern will repeat constantly:

Prosody establishes an S2S session for xmpp.org.
Conversations leaves a chatroom it has not joined.
Conversations issues a disco#info request.
Prosody responds over the xmpp.org session.
Metre drops the stanza (and session).

Conversations isn't doing anything wrong here, but the pattern it has
chosen is very brittle, and there's no feedback in the UI to see
anything went wrong. Gajim's pattern seems more robust, and results in
a joined chatroom consistently (though with occasional desync issues).
The feedback on whether you're joined is pretty good, nonetheless, and
of course Gajim has the debugging tools if things do go really wrong.


More information about the JDev mailing list