- What steps will reproduce the problem? 1. Try to send a message to a user at a different server that uses the s2s dialback mechanism to verify s2s connections. *2.* *3.* - What is the expected output? mod_s2s debug sending: <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' from='prosody' id='bfa48f94-3297-4183-90fb-271fb99fa1b2' xmlns:db='jabber:server:dialback' to='nitro' xmlns='jabber:server'> s2sin7ff352ef0720 debug Received[s2sin_unauthed]: <verify id='4158ec458e8a4070c8818fb424a96151' xmlns='jabber:server:dialback' to='prosody' from='nitro'> s2sin7ff352ef0720 debug verifying that dialback key is ours... s2sin7ff352ef0720 debug verified dialback key... it is valid mod_s2s debug sending: <db:verify id='4158ec458e8a4070c8818fb424a96151' type='valid' to='nitro' from='prosody'> s2sout7ff352ee44b0 debug Received[s2sout_unauthed]: <result xmlns='jabber:server:dialback' type='valid' to='prosody' from='nitro'> - What do you see instead? mod_s2s debug sending: <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' from='nitro' id='1d441585-65a5-40cf-9231-60d1001e7273' xmlns:db='jabber:server:dialback' to='prosody' xmlns='jabber:server'> s2sin7f7fe8ef0a30 debug Received[s2sin_unauthed]: <verify id='18280dec684f92c570826ce528595df2' xmlns='jabber:server:dialback' to='nitro' from='nitro'> stanzarouter warn Unhandled s2sin_unauthed stream element or stanza: verify; xmlns=jabber:server:dialback: <verify id='18280dec684f92c570826ce528595df2' xmlns='jabber:server:dialback' to='nitro' from='nitro'>566a48067b5b01674f07bbd7236790a60a41c739fec3cb462b44325ea399cbe5</verify> s2sin7f7fe8ef0a30 debug Disconnecting (unknown host)[s2sin_unauthed], <stream:error> is: unsupported-stanza-type mod_s2s debug sending: <stream:error> - What version of the product are you using? On what operating system? hg trunk on Mac OSX. - Please provide any additional information below. This is the culprit since the message is coming from and going to the same server. <verify id='18280dec684f92c570826ce528595df2' xmlns='jabber:server:dialback' to='nitro' from='nitro'> Please see attached patch for a trivial fix.

• s2s_open_session.patch

Hi, thanks for the report and patch! Were both servers running Prosody? If so, both trunk? If not, what was the other server?

• owner MattJ

I wrote the server on the other side. I'm opening with a <stream from='nitro' to='prosody> and was expecting <stream from='prosody' to='nitro'> but get both to and from set to nitro. Am I doing something wrong or is this a bug in prosody?

> Am I doing something wrong or is this a bug in prosody? I'm not sure enough to say either way yet. We've had no reports of similar issues from other people running trunk. But then this code has changed recently, and a missed bug is plausible. Perhaps you could get a packet capture? Either using Wireshark if it's local, or if you're on a server something like this should do with tcpdump: tcpdump -i eth0 -s0 -w s2s_dialback.pcap tcp port 5280

I included the output from Prosody in the original bug report. You can see the to and from attributes of the opening <stream/> that Prosody sends out, with and without the patch. Is this not sufficient?

Ok, I possibly shouldn't be coding so late... but you've convinced me Prosody is misbehaving here. I really can't explain how it continued to work with other servers as-is. I suspect it's because they (including Prosody) are tolerant of servers that (incorrectly) omit to/from on stream headers (Google, Openfire, and some old ejabberds among them), meaning they pay more attention to the host they believe the stream is connected to than what the remote host says it is. I've pushed a fix in df3c78221f26, where I opted to make to/from explicitly specified in all calls to open_stream(), instead of incorrectly inferring them when omitted. Thanks!

• tags Status-Fixed