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 with.
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 d...@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="d...@dave.cridland.net/tablet" to="coun c...@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="coun...@muc.xmpp.org" from="d...@dave.cridland.net/tablet" type="get" id="U75gpvwLTKvv0L+2mc8FzJZr2Rwsnox8xFnAquYztIg8cM/A8eTBv8Qn1CT7ddI58zY"><query xmlns="http://jabber.org/protocol/disco#info";></query></iq> 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='d...@dave.cridland.net/tablet' from='member...@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 id='U75gpvwLTKvv0L+2mc8FzJZr2Rwsnox8xFnAquYztIg8cM/A8eTBv8Qn1CT7ddI58zY' type='result' to='d...@dave.cridland.net/tablet' from='coun...@muc.xmpp.org'><query xmlns='http://jabber.org/protocol/disco#info'><identity type='text' name='council' category='conference'/><feature var='http://jabber.org/protocol/muc'/><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' var='FORM_TYPE'><value>http://jabber.org/protocol/muc#roominfo</value></field><field type='text-single' label='Description' var='muc#roominfo_description'><value></value></field><field type='text-single' label='Number of occupants' var='muc#roominfo_occupants'><value>18</value></field></x></query></iq> 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. Dave. _______________________________________________ JDev mailing list Info: https://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
