I’ve recently been experimenting with the Python pyxmpp implementation and using it to connect to an Openfire server (version 3.6.0a) on my Mac. I’ve modified the “echobot” example program in pyxmpp to support TLS, and I’m able to get through the starttls and sasl steps during login, but the client hangs shortly after that without fully logging in. The CJC command-line client which uses pyxmpp behaves in a similar manner. After some debugging, I was able to track down the problem to the xmpp-bind step in the protocol. I see the following exchange there:
From Echobot to Openfire:
Echobot
From Openfire to Echobot in reply:
echobot@xmpp.timeheart.net/Echobot
Notice the “to” field in the reply. I wouldn’t necessarily expect a “to” value at all in this response, but if there is one it really should be set to the JID of the client. The username field is missing here, though, and the resource field appears to have been populated from the “ID” value assigned by Openfire in the outer stream:stream tag for this session.
Since the JID appears not to be the local client, the pyxmpp code drops this stanza by default, causing the client to hang at this step. If I hack it to ignore the “to” field on IQ packets of type “result”, I can get it to proceed and everything works fine from there. In fact, later IQ results from Openfire have a properly set “to” field of "echobot@xmpp.timeheart.net/Echobot" in that case. It is only this initial xmpp-bind result that has the bad value.
I suspect this might have something to do with the full JID of the client not being established yet, since the final value for the resource field really isn’t set until the bind is complete. However, inserting this other value in the meantime seems like a bad idea.
When I try this same test against Google Talk, I get the following exchange:
From Echobot to Google Talk:
Echobot
From Google Talk to Echobot:
ron.frederick@gmail.com/Echobot5AA8DD6B
Note that in this case, the IQ result for xmpp-bind has no “to” attribute. Some of the later IQ results like the roster do have a “to” attribute, but they are the full JID of the client (including the Google-assigned unique resource value you see above), and so this causes pyxmpp no problem.
While I’ve got a workaround in pyxmpp for this problem for now, this seems to me to be a bug in the Openfire server. Is there something I missed in reading the protocol specs that allows for this kind of response?