Verification Error on self-hosted Kontalk server

Hi, I recently set up the Kontalk server on and Ubuntu 18 server. I manually set the server domain and IP as required on a compiled Kontalk Android client so as to test the server. The client connects during verification but returns an error ‘verification code refused’ with tge 123456 codeas set up with the dummy provider. I’ve tried changing the code, using my nexmo credentials but the error still persists. Anybody?

2019-06-12 09:45:52.409 24769-23764/org.kontalk.debug W/AbstractXMPPConnection: Connection KontalkConnection[not-authenticated] (11) closed with error
    org.jivesoftware.smack.SmackException: Parser got END_DOCUMENT event. This could happen e.g. if the server closed the connection without sending a closing stream element
        at org.kontalk.client.smack.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1344)
        at org.kontalk.client.smack.XMPPTCPConnection$PacketReader.access$900(XMPPTCPConnection.java:1081)
        at org.kontalk.client.smack.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:1098)
        at java.lang.Thread.run(Thread.java:764)

org.jivesoftware.smack.SmackException$NotConnectedException: The connection KontalkConnection[not-authenticated] (11) is no longer connected while waiting for response with StanzaIdFilter: id=Seav3-21
        at org.jivesoftware.smack.StanzaCollector.nextResultOrThrow(StanzaCollector.java:263)
        at org.jivesoftware.smack.StanzaCollector.nextResultOrThrow(StanzaCollector.java:219)
        at org.kontalk.service.registration.RegistrationService.onChallengeRequest(RegistrationService.java:987)
        at java.lang.reflect.Method.invoke(Native Method)
        at org.greenrobot.eventbus.EventBus.invokeSubscriber(EventBus.java:507)
        at org.greenrobot.eventbus.EventBus.invokeSubscriber(EventBus.java:501)
        at org.greenrobot.eventbus.AsyncPoster.run(AsyncPoster.java:46)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)

Hello and welcome!

Weird, it seems the kyotocabinet library made the JVM crash :open_mouth:
Debugging this will be hard… and I chose to use containers so the environment would 100% certain :roll_eyes:

So, I guess you’re using the xmppserver-docker repository without changes to the Dockerfiles.
What’s your version of Docker?

Hey there,

So, I guess you’re using the xmppserver-docker repository without changes to the Dockerfiles .
What’s your version of Docker?

Yep, no changes whatsoever.
I’m using Docker version 18.09.6, build 481bc77156.
I further tried setting up the server on my local machine (same host environment as the server), the instance doesn’t crash but only allows a single registration on rebuild/restart, the subsequent registrations return the 'Verification code refused" error.
Here is p ofart the server logs

On a debian server I get an error similar to this
A more powerful instance doesn’t really help in my case.

I’ve opened an issue. I’ll try to investigate using an Ubuntu VM, but these kind of issues are really weird and very hard to debug - in simple terms, I can’t spend too much time on them, sorry.

In the meantime, could you try on Debian with the same configuration? Just to exclude any misconfiguration. Thanks!

Okay, thanks for that. So how do I Bypass the ‘connection refused’ error with the debian server?
Similar to this

That’s because the server probably didn’t start yet. What does the server log says?

Hi @daniele_athome

After some debugging I finally found “weird” solutions to both errors.

As you had earlier pointed out, the ‘verification issue’ was brought about by a fatal dockerd crash which in turn kills and restarts the server. This seems to be an issue unique to virtualized hardware droplets running Ubuntu 18.* (at least in my case). Switching to Debian 9 resolved the issue.

On the other hand, the ‘connection refused error’ by instances installed on both remote servers and select local machines is caused by a ‘freeze/delay’ on the XMPP container as it tries to generate gpg keys before the service ports are readied. This creates an impression to the client that the server is yet to start/has failed. As you mention here:

Freshly created virtualized hardware droplets will most certainly have very low entropy which is a bottleneck for the desired cryptographic randomness required to generate gpg keys. The command below can be used to check the system entropy on linux distros.

cat /proc/sys/kernel/random/entropy_avail

Any value above 3000 should work. If you get a 38 like me :grin:, you’ll need an entropy boost. My solutionwas rng tools and havege, however, I’m not sure it’s the best idea considering a process involving encryption parameters should not be guided/‘helped’ so to say.

With that the server works like charm. I can make a point of sharing my documentation on setup if it helps.

I however have two more queries @daniele_athome

  1. At what point does the android application encrypt the messages, is it before saving them to the phone’s database or after? In other words is it [text]>encrypt>save>send or [text]>save>encrypt>send ?

  2. I tried testing the compiled app on an Infinix phone running android 7 and got a looping X509Certificate error on logcat when passing the dummy verification code. It however works perfectly with the beta.kontalk.net server. Could this be an undoing of not generating my own SSL? If so, will Letsencrypt suffice or do I actually need a commercial provide.

Keen to hear from you.
Thank you.

I forgot to tell you that you can always create your own GPG key for the server on another machine and then transfer it to the server. In a production environment it’s the recommended way to do that - also because that’s the key your clients’ keys will be signed with, so it can’t change.

Encryption is done at sending time, so the local database is not encrypted.

Using Let’s Encrypt should work (we use it). Alternatively, a quick workaround is to check “Accept any SSL certificate” (under preferences > Network) in the Android app if you know what you’re doing :angel:

‘Accept any SSL certificate’ doesn’t do the trick either. My concern was if it was just a simple failure due to the default certificate then wouldn’t the app just display the authentication error toast instead of crashing during code verification? I’ll keep trying different options though.

Noted. Thanks a lot.
You’ve been very helpful.

Can I see the app log please?