Timeout when XMMP server sends "iq-auth" twice
Hi,
The XMPP server I use sends sometime the following stanza twice in a row:
2017-07-11 06:30:58,175 IN : <stream:features xmlns:stream="http://etherx.jabber.org/streams"><auth xmlns="http://jabber.org/features/iq-auth"/><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>SCRAM-SHA-1</mechanism><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism></mechanisms><ver xmlns="urn:xmpp:features:rosterver"/><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression></stream:features>
When it occurs the resulting sequence is:
2017-07-11 06:30:58,190 OUT: <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="SCRAM-SHA-1">biwsbj0xMjM0NS0xMjM0NS0xMjM0NS0xMjM0NS0xNSxyPUVieXF3V3dSTXBUQUw0NCtBN29MSUE9PQ==</auth>
2017-07-11 06:30:58,249 IN : <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">cj1FYnlxd1d3Uk1wVEFMNDQrQTdvTElBPT1yQ2U4YTF0d0JjYlRDV3IzUklITyxzPVFPUElzNlZCbmt1WFVRPT0saT00MDk2</challenge>
2017-07-11 06:30:58,264 OUT: <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">Yz1iaXdzLHI9RWJ5cXdXd1JNcFRBTDQ0K0E3b0xJQT09ckNlOGExdHdCY2JUQ1dyM1JJSE8scD1ZM1d3c3YzVVoyaE5FQ3NCNEN3TTRxK09CMkk9</response>
2017-07-11 06:30:58,309 IN : <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl">dj1YN2ErZlR5b3JCdjlUaXB2R2RReUorakhuV289</success>
2017-07-11 06:30:58,312 OUT: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing" version="1.0" to="unreg-product.int.connect2.opentouch.com" xml:lang="en-US"></open>
2017-07-11 06:30:58,352 IN : <open xmlns='urn:ietf:params:xml:ns:xmpp-framing' from='unreg-product.int.connect2.opentouch.com' id='c6916879-0da0-493a-8fa7-6b61afd3a93d' version='1.0' xml:lang='en' />
2017-07-11 06:30:58,353 IN : <stream:features xmlns:stream="http://etherx.jabber.org/streams"><csi xmlns="urn:xmpp:csi:0"/><ver xmlns="urn:xmpp:features:rosterver"/><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features>
2017-07-11 06:31:18,189 OUT: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" version="1.0"></close>
2017-07-11 06:31:18,191 IN : <close xmlns='urn:ietf:params:xml:ns:xmpp-framing' />
And rocks.xmpp.core.session.NoResponseException: Timeout while waiting on resource binding feature. is thrown.
Before asking the server to fix the issue (which is a very tedious process...) I would like to be sure that the behavior of Babbler is the right one, and as I'm not proficient enough in XMPP I would appreciate your help...
Thanks,
Jacques
Comments (7)
-
repo owner -
reporter Unfortunately, or fortunately, I was wrong regarding how fast the issue will be fixed on server side. Actually I already got a patch and the fix seems, so far, OK. Anyway I'll follow your instructions and I'll let you know if I get something.
-
reporter Trying with another XMPP server instance (not fixed yet), I got several "Timeout while waiting on resource binding feature" but nothing coming from the "xmppClient.addSessionStatusListener"
-
repo owner Does the server send the <bind/> feature? Exceptions during login are special, maybe they don't show up in the listener (although I thought they would). However, you should get the exception from the login method then (throws).
-
repo owner Do you have more information here? There's some custom stuff involved here, xmlns="ale:cloudconnect:ftr", after which the session is closed, maybe due to an error or intentionally. Afterwards a new login is made.
I'd also be happy if you could provide a pull request, because I don't have the environment to test with your custom extensions.
-
reporter I'm sorry but now all the XMPP servers are patched and I can't reproduce the issue anymore. May I suggest to close this issue?
-
repo owner - changed status to closed
- Log in to comment
Hi Jacques,
Babbler is sending a <close/> and I am not sure why.
Could you please do something similar to this (before connecting/login): xmppClient.addSessionStatusListener(e -> {
if (e.getThrowable() != null) { e.getThrowable().printStacktrace(); } } });
And see, if it prints something?
— Christian