powered by Jive Software

Races in 4.0rc1

Hi

Trying out XMPP for the first time, with 4.0rc1, operating against an ejabberd 2.10 host.

I’ve come up against problems with connecting. Firstly :

XMPPConnection connection = new XMPPTCPConnection(config);

connection.connect();

connection.login(“user”, “password1”);

Was bombing on the connection due to “No non-anonymous SASL connection modes” type error.

This is because the all-important message[1] containing the supported SASL modes has not arrived by the time login() is executed. I can’t tell if that’s because the server is slow, or that the pause is in sending the outbound queued message. Either way, it’s a race condition, and inserting

Thread.sleep(30000);

between connect and login fixes it, ugly though that may be.

Secondly, I seemed to have to disable TLS with

config.setSecurityMode(ConnectionConfiguration.SecurityMode.disabled);

If I don’t, then by the time we get to SASLMechanism:170 “sc.hasInitialResponse()”, the answer is ‘no’, and we end up sending ‘null’ as authenticationText (Which unsurprisingly doesn’t work).

tls start and proceed messages have been exchanged [2], so I don’t know why it’s the case that it’s not happy in that route.

[1]

<?xml version='1.0'?>

stream:featuresSCRAM-SHA-1ANONYMOUSDIGEST-MD5PLAIN</m echanism><register xmlns='http://jabber.org/features/iq-register’/></stream:features>

[2]

This is because the all-important message[1] containing the supported SASL modes has not arrived by the time login() is executed.

Thanks fore reporting! SMACK-558

Secondly, I seemed to have to disable TLS with

config.setSecurityMode(ConnectionConfiguration.SecurityMode.disabled);

If I don’t, then by the time we get to SASLMechanism:170 “sc.hasInitialResponse()”, the answer is ‘no’,

Could you elaborate that a bit more? How does an enabled TLS affect the SASL authentication? Or in different words: Why is the answer ‘no’ if you don’t set SecurityMode.disabled?

While SMACK-558 sure is a valid as there is a missing synchronization point in Smack (and I also believe your second report to be valid to, i just need some more info about it, to see the problem) I wonder why you are the first to report those. Are you using a heavy latency connection to your xmpp server? Or some kind of mobile/GSM connection?

Ok I found a race in packetReader where wait() would timeout, the connectionId would have been set, but features where possibly not yet parsed. I will commit the patch soon in an extra branch. Are you able to build Smack from sources and test it? That would be great. The code can be found here: https://github.com/Flowdalic/Smack

I’ll try building from source.

Re: the TLS - what I see in the debug window is

Send:

<stream:stream to=“192.168.111.28” xmlns=“jabber:client” xmlns:stream=“http://etherx.jabber.org/streams” version=“1.0”>

</stream:stream>

– long pause –

<stream:stream to=“mycompany.com” xmlns=“jabber:client” xmlns:stream=“http://etherx.jabber.org/streams” version=“1.0”>

Recv:

<?xml version='1.0'?>

– long pause –

<?xml version='1.0'?>

stream:featuresSCRAM-SHA-1ANONYMOUSDIGEST-MD5PLAIN</m echanism><register xmlns='http://jabber.org/features/iq-register’/></stream:features>

Then @ SASLMechanism.java:170, sc.hasInitialResponse() == false.

I’ll try the latest repo version. FWIW, server is ejabberd 2.10/ubuntu.

It appears that TLS failes. Did you configure Smack with a SSLContext that accepts your servers certificate?

No … I’m not sure the TLS part is even a bug, but I was surprised it failed the way that it did.

I tried building from git, but it just bombs out with a load of incomplete javadoc that I don’t care about (not being a gradle user I haven’t got the knowledge to fix that).

I tried building from git, but it just bombs out with a load of incomplete javadoc that I don’t care about (not being a gradle user I haven’t got the knowledge to fix that).
If you show us some output from the gradle build, we may be able to help.