Sending the following stanza will cause a client disconnection:
Where ‘proxy.example.com’ is the built-in openfire socks5 proxy. The error (from the openfire logs) is:
2007.09.19 11:24:38 org.jivesoftware.openfire.IQRouter.handle(IQRouter.java:341) Could not route packet
java.lang.IllegalArgumentException: Illegal JID:
at org.xmpp.packet.JID.init(JID.java:384)
at org.xmpp.packet.JID.(JID.java:219)
at org.jivesoftware.openfire.filetransfer.proxy.FileTransferProxy.handleIQ(FileTra nsferProxy.java:126)
at org.jivesoftware.openfire.filetransfer.proxy.FileTransferProxy.process(FileTran sferProxy.java:349)
Adding a ‘from’ attribute (regardless of whether that from attribute is correct) to the iq stanza prevents the disconnect. However, there is still a violation of rfc3920, section 9.2.3: ‘An entity that receives an IQ request of type “get” or “set” MUST reply with an IQ response of type “result” or “error” (the response MUST preserve the ‘id’ attribute of the request).’. Openfire does not respond at all.
Thanks for the bug report. I filed http://www.igniterealtime.org/issues/browse/JM-1125 and checked in a fix for it. BTW, the problem in your packet is that the activate element has no text in it. That is triggering an exception that at the end ends up closing your connection.
I think you’re mistaken; even with the activate tag removed entirely, the error still occurs. While on the other hand adding a bogus ‘from’ attribute to the iq tag prevents the disconnect, even leaving the empty activate tag.
In the XEP-0065: SOCKS5 Bytestreams you can see in the section 4.9 an example where activate specifies the JID of the other party. And in the section 6.1 you see that activate has to be present. Anyway, I agree that section 4.9 does not explicitly say that it MUST contain a JID but you can infer it from the context.
Thank you for the pointer; the text “including an <activate/> element whose XML character data specifies the full JID of the Target.” does indeed imply that it’s a must.
I assume the fix you commited was to make openfire return an error for those cases, rather than simply dropping the connection?
That’s correct. The problem that you found was in fact about how Openfire deals with internal errors while processing IQ packets of any type. The server will now return an IQ of type error instead of closing the connection.