Skip to content
This repository

The framework stops receiving responses in Renegotiate of XMPPStream.h #81

Closed
cuongthai opened this Issue · 11 comments

8 participants

Thai Ly Cuong Robbie Hanson jonasman bassrock Sascha Fröhlich halfsoft mdx1984 tjg184
Thai Ly Cuong
  • Background:
    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.

  • Bug Description:
    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'>
  • My suggestion:
if (shouldRenegotiate){
  // Now we start our negotiation over again...
  [self sendOpeningNegotiation];
  // I added this line
  [asyncSocket readDataWithTimeout:TIMEOUT_XMPP_READ_STREAM tag:TAG_XMPP_READ_STREAM];
}
jonasman

Yesh, I also had that problem. I had to revert back to my old version!

bassrock

this solution worked for me

Sascha Fröhlich

Worked for me, too.

halfsoft

Yes this fixes the problem that I was having.

jonasman

I confirm as well that this solved my problem

mdx1984

First time trying out XMPPFramework and had this problem. This snipped fixed the problem for me. Thanks. :)

Robbie Hanson
Owner

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.)

Robbie Hanson
Owner

Issue reproduced... Investigating now.

Robbie Hanson
Owner

Closing the issue. Please let me know if you still have issues after the change.

Robbie Hanson robbiehanson closed this
jonasman

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?

Exemple:
XMPPvCardAvatarModule

tjg184

This fixed my issue as well. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.