You can clone with
I'm using XmppFramework to connect with ejabberd server 2.1.11 on Ubuntu (Linux 32 bits).
Client side : IOS 5. Xcode 4.3.2. MacOS 10.7.4.
The negotiation process stops at the second negotiation (renegotiation) line 3037 (XMPPStream.m ).
The log show:
2012-07-19 12:00:06:468 XMPPStream[49107:3e0b] RECV: <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">bm9uY2U9IjIxNTYzMTM4ODEiLHFvcD0iYXV0aCIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M=</challenge>
2012-07-19 12:00:06:468 XMPPStream[49107:3e0b] SEND: <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">dXNlcm5hbWU9Imt3ZWluZXIxIixyZWFsbT0iMjAzLjIwNS4xMC4xMjciLG5vbmNlPSIyMTU2MzEzODgxIixjbm9uY2U9Ijg1RUU5MTczLTQ0RTEtNDNDMS1CNzFBLTY3OEE5NTQ2MjU1MiIsbmM9MDAwMDAwMDEscW9wPWF1dGgsZGlnZXN0LXVyaT0ieG1wcC8yMDMuMjA1LjEwLjEyNyIscmVzcG9uc2U9NzMwZWZjNzUxOWIwNzNiNDEzMGU0NjFjMmVmMjliNmIsY2hhcnNldD11dGYtOA==</response>
2012-07-19 12:00:06:502 XMPPStream[49107:4603] RECV: <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">cnNwYXV0aD00YzRjMDk4ZGJhYjk2NmNiMTg3MzVhOTMyYTZhMDkxYw==</challenge>
2012-07-19 12:00:06:502 XMPPStream[49107:4603] SEND: <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>
2012-07-19 12:00:06:854 XMPPStream[49107:4603] RECV: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>
2012-07-19 12:00:06:854 XMPPStream[49107:4603] SEND: <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' to='xxx.xxx.xxx.xxx'>
// Now we start our negotiation over again...
// I added this line
[asyncSocket readDataWithTimeout:TIMEOUT_XMPP_READ_STREAM tag:TAG_XMPP_READ_STREAM];
Yesh, I also had that problem. I had to revert back to my old version!
this solution worked for me
Worked for me, too.
Yes this fixes the problem that I was having.
I confirm as well that this solved my problem
First time trying out XMPPFramework and had this problem. This snipped fixed the problem for me. Thanks. :)
It seems clear that this is an issue for several people. It's also clear that the proposed solution seems to solve the problem. However, I'm having trouble wrapping my head around the root cause of the problem. I'm investigating when and where [asyncSocket readData...] is called, and don't quite understand why this is needed. According to my (obviously incorrect) understanding, it's getting called in all the right places, and at all the right times.
I'd like to merge this change into master, but I fear this bug is specific to a particular server configuration or xmpp authentication flow. Thus the patch may fix one problem, but cause another (for different configurations / authentications).
Could someone possibly comment out the fix listed above, and then post a full SEND/RECV log from start to hang.
Also, is there anything else unique about the xmppStream configuration? (Using oldSchoolSecureConnect, etc.)
Issue reproduced... Investigating now.
Bug fix for issue #81 - framework stops receiving responses in renego…
Closing the issue. Please let me know if you still have issues after the change.
I don't know if is is related but some extensions start working when the stream call their didAuthenticate methods, what about if the connection is secured?
This fixed my issue as well. Thanks!