Unable to use Stream Compression with eJabberd server because of compression being done after SASL

Smack Smack Dev
1

On XMPP connection and authentication, Smack library do steps in this order :

  1. TLS
  2. SASL
  3. Stream compression (Feature is not listed by stream after SASL. Sending a compress will be ignored (ignoring is intended)
  4. Resource binding

Unfortunately eJabberd does not work with this order. On step 3, juste after sending the compression stanza, server stops sending data to client.

eJabberd supports compression, but in this order :

  1. TLS
  2. Stream compression
  3. SASL
  4. Resource binding

I patched my local checkout of Smack in org\jivesoftware\smack\XMPPConnection.java , in login method: I moved useCompression() before saslAuthentication.authenticate and after it works correctly.

Would it be possible to add to Smack a method to configure when the compression stanza is sent : after or before SASL authentication ?

For Information the opposite request is open on eJabberd support but I am not sure change will be made on this server side :

https://support.process-one.net/browse/EJAB-1382

Thank you.

2

This problem sounds familar. And in fact we have to similar forum posts about this topic:

At that time I was under the impression that the order is not specified, but I may be wrong. If it is and Smack is doing it wrong, then this definetly needs to be fixed. I guess I have to do some specification reading.

Until this question is answered. Could you provide your patch what of changed, so that it can get reviewed? If this fix is trivial as you described and does not come with side effects, it could also get included.

3

Thank you for your answer and sorry for the duplicate.

I search XEPs and found this :

http://xmpp.org/extensions/xep-0170.html#c2s-compress

So it seems Smack is doing in the recommended order.

My patch was only to move useCompression() before saslAuthentication.authenticate in login method, but it may cause problem on other XMPP servers as it is not the order recommended by the XEP-0170.

Maybe a new configuration parameter would be a best option ? or maybe to let the client calls directly the XmppConnection useCompression() method separately of the login method ?

4

No need to feel sorry for the duplicate.

I missed that Smack is actually doing the recommended order. I am not sure if a configuration parameter is the best options. The library should just to the correct thing, which it does, without the user having to configure anything. Even worse if the user has to call the single steps by himself. It should be possible to offload as much business logic as possible to the library, after all, that’s what it’s for.

I think the best is to do nothing on Smack’s side to increase the pressure on ejabber to behave standard compliant. Any “fixing” on Smack’s side would be counter productive.

And I just found that Daniel and you state two conflicting things:

  • Daniel says Smack does Stream Compression after Resource Binding
  • You report that Smack does Stream compression before Resource Binding

Judging from the code, Daniel is correct, since Resource Binding beeing part of the SASL code in Smack (SMACK-454).

Could it be that this is the cause for compression not working with ejabberd?

5

Yes you’re right, this have to be fixed on the server side. I voted for it on eJabberd issue tracker and I will work with folks in my team to submit a patch for this server.

As for the Resource binding I was wrong, Smack does Compression before Resource Binding, but the issue with eJabberd really is the order between SASL and Compression.

Thanks again.

6

OK thanks for clarifying. I hope you are successful with your ejabber patch. If there is anything you need from our side, just ping me.