My own dhtproxy node does not work as intended

Hello respected devs,

Thanks for this amazing project, I really love the concept of distributed communication service!

I ran into a problem trying to set up my own dhtproxy server, hopefully I can get some hints as to why this happens.

I have compiled the latest opendht (on Debian buster) according to the instructions on github wiki, and it was successful. Then I ran the dhtproxy node with the following command: dhtnode -b bootstrap.jami.net:4222 --proxyserver 8000 It connects to the public dht network successfully. My android device is able to use this proxy to connect to the dht network. (For testing purpose, I disabled bootscrap and proxylist)

Now the problem is that, the notification mechanism of dhtproxy is not working. From my understanding, when someone sends a message to me or calls me, the dhtproxy should notify me something is up, and my device would go fetch it from the dht network. This works for the official dhtproxy.jami.net, but not for my dhtproxy. When someone calls, it would not connect, unless I use to disconnect/connect toggle at the top right corner, forcing my device to fetch data from the dht network, only then will I be able to receive the call. What am I missing?

Thanks in advance for any help!

changed the description

After reading some information scatted across some sites, I have realized that I need to setup a push gateway together with the dhtproxy in order to get the push notification working.

However in this post it was stated that "It is also possible to use the proxy without push notification. However, it is less reliable because both Android and iOS may stop the app at any time".

For me, even when the app is in the foreground, it still is not able to get any notification from my own dhtproxy. On top of that, I find out in Windows version of Jami, there is also the option to use dhtproxy, there is no push mechanism in place for windows, there must be another way that the dhtproxy can communicate with the client, right?

does the windows client work with your dhtproxy?

For android, the way to use the proxy without push is:

1. disable push notifications in settings (top right, settings, push notifications)
2. enable your proxy.

And it should work directly.

If not, what endpoint are called if you check the network operations? How do you build the proxy too?

Oh, so I have to disable push in order for the direct connection between proxy and android client to work!

That was a bit of a blind spot for me. Thanks for the hint! Much appreciated! Now it works!

As for windows, I thought the proxy worked for windows, since when I used my own proxy, the status became connected, and I could send messages and calls to my phone. Then I tried to disable dhtproxy and bootstrap, it is still able to connect. I have no idea what is going on or what is working. I seem to be able to connect no matter what (on windows).

closed

bootstrap is only used as an entry point. If your jami have stored nodes in cache it will use it

Your explaination makes a lot of sense. The more I understand this project, the more impressed I am about how amazing the idea is, how much freedom the user has. Unfortunately it is not very user friendly, at least not for non tech savvy people.

Side note, this would be an amazing tool to go up against the infamous great firewall. It is a pity that it is IMO not going to become popular.

Also, it would be tremendously helpful if the opendht project could provide static binaries for all major platform including the likes of openwrt, arm machines etc. The ability to easily setup a lot of dhtproxy can become very handy.

Anyway, cheers, I wish you all the best, and wish this project could flourish like a palm tree.

Hey, nice that you're able to run you own dhtproxy. Always hope projects like yunohost can include it someday, or the regular jami clients. https://git.jami.net/savoirfairelinux/ring-client-android/-/issues/517

Oh, so I have to disable push in order for the direct connection between proxy and android client to work!

Wait, maybe don't close this too fast.

I would still like to see this issue considered as/by regular UI issue(s). The confusing setting conditions affect all users.

Trying to think of a solution, maybe enabling a dht-proxy would have to

• auto-disable the corporate push registration of the client (if enabled) and proxy is not registered at the third-party push service,
• and auto-enable to "run in background" (if disabled).

The conditions should allow to have a simple single setting

• use custom dht-proxy: ...
• don't use dht-proxy (p2p mode)

The default for android can be to use dht-proxy (and implicitly to run in background), while playstore versions may allow or even default to use, and thus notify, the corporate push services.

reopened

assigned to @sblin

added SprintIn progress ~149 + 1 deleted label

@terrytw if you are able to build your own opendht (client side, so for your phone), you can try this PR: https://github.com/savoirfairelinux/opendht/pull/551

This will fix the keep alive. Closing a server is detected

removed SprintIn progress label

added 1 deleted label

added SprintTo review label

Thanks for fixing it! I am not quite sure as how to include dht client for an android app.

I think I will wait for the app to update, and then test it.

added SprintDone label and removed SprintTo review label

removed 1 deleted label

You can test with android version >= 5 may (version 296)

Thanks for the fix!

I have done some testing using version 297, it's definitely significantly improved regarding connectivity.

I have spotted some problems though, mainly when switching between wifi and mobile data.

I will continue testing and report back to you guys. Anyway, great work!

But is it related to your dhtproxy?

Also quick question, does the link you are testing use TURN or a relay

I am testing with my own DHTproxy. When I am using wifi, my 2 devices can connect to each other directly since they are in the same local network. When I am using mobile data, my 2 devices are using my custom TURN server to connect to each other. From my understanding there are 2 major parts of communication for Jami clients, first one is to find each other through opendht network and notifying that there is a message or call for the other side, second part is the actual connection that will send the message or call through. I have not had problem with the second part ever since I setup my own TURN server.

The connectivity is definitely improved.

Still got occasional hiccups, not able to reproduce them consistently, maybe or maybe not related to changing from wifi to mobile. Will do more testing.

Ok. For the problem for wifi to mobile, I think it's this scenario: https://git.jami.net/savoirfairelinux/ring-daemon/-/issues/542?

Yes https://git.jami.net/savoirfairelinux/ring-daemon/-/issues/542 is fairly close to what I occasionally encountered, network 0 is wifi, network 1 is mobile, device change from wifi to mobile and to wifi, then calls and messages cannot get through.

removed SprintDone label

During 5 min in fact (until the TURN close the socket). But yeah Jami uses tcp keep alives (30 secs) to detect half-closed connections. However with a TURN in the middle, the keep alive is working because the half closed occurs from the other side.

Ok. So, for now, I will continue to update ring-daemon#542 and I think we can close the issue here, as the proxy is not related (unless proven otherwise with a new scenario).

closed

added severityhigh label