Account failure: status unknown
I had to reinstall twice, because after some time (or maybe after force-closing the ring app) the account did not connect properly anymore.
The account was created for testing purposes, without registering a user name and with an empty password.
After the error occured there was an "!" next to the account in the menu. When checking the account details, disabling and re-enabling the account shortly displayed Ring-Account connecting, and then unknown.
Possibly related?: https://tuleap.ring.cx/plugins/tracker/?aid=893
Activity
This issue https://tuleap.ring.cx/plugins/tracker/?aid=1488 made me think maybe the problem is the account is really not known in the connected dht node?
And if there can be such dht outages, maybe this can also be the explanation when text-through-dht is not working in one direction, but establishing local calls between the devices is still possible?
https://git.ring.cx/savoirfairelinux/ring-project/issues/432#note_8035Edited by Ring Thing
Which version?
Ring or SIP account?
If it's the F-Droid version there is still the bug where your account stay disconnected when you wake up the device. (fixed on the latest release by https://git.ring.cx/savoirfairelinux/ring-client-android/commit/4576a58fbc0285ac6a50867c7ca6091d652f0ccf)
added ~141 S - Major priority2 labels
@ringthing Please fill the bug report form:
Bug report form
Describe your environment
Please specify the following:
- Ring version:
- Device model:
- Android version:
- What build you are using: [ring.cx | F-droid | Play Store | App store | your own (please specify commit id + ring daemon version or commit id)...]
Steps to reproduce
- Can you reproduce the bug: [at will | occasionally | not at all]
- Steps: 1. 2. ...
- Actual result:
- Expected result:
Additional information
Hello, and thank you, ring look's as it is becoming marvelous.
It occured yesterday, installation was done from F-Droid some time ago. I think a new version was installed today, because the google push messaging option is not shown in the advanced options any more.
Version is now: 20180501
Reproducing
After retrying to create a new ring test account (without name registration) today, I noticed that the dht proxy option was disabled by default. Which seemed strange to me for the android version, so I enabled it, and immediately the account went into the unknown state. Fortunately, after disabling the proxy the status changed to online again.
Do I recall it correctly that default for matching local and published... has also changed to yes (checked)?
I had hoped the dht proxy option would allow using ring on mobile properly. What could be the problem with it?
Ok, when the f-droid version does not wake up is the status supposed to stay "offline", or is it the same "unknown" that I see with proxy enabled?
The (preset) proxy is: dhtproxy.ring.cx
Is there a workaround to get the account back online, when it does not wake up? I havn't noticed this yet in any way, after suspending.
There are two phones with Ring installed behind the same router, both immediately get into the unknown state when enabling the dht proxy.
Further observations (current f-droid version, proxy disabled):
- Only one phone I see waking up with connection failure. The other says online
- Presence status is not well reflected on other side.
- When both phones are on (not suspended and account setting says online), calls are sometimes signalled and can connect even if other is shown as offline. But many times calling attempts just fail silently after a while.
- Calling a suspended phone seems never able to wake it up. (This worked the first day before the update (IIRC proxy was enabled by default) until the unknown state came eventually.)
Troubleshooting Problems:
-
The option to allow using mobile networks is also gone with the current f-droid version? :( I can't test if it works across different networks.(Is in general settings, not account settings.)
Edited by Ring ThingI see advanced options about local and published ports... and many reports and advice of SIP failing with multiple devices behind NATs, e.g. https://teamhelp.sipgate.co.uk/hc/en-gb/articles/204133972-Local-Port-Selection-and-Using-Multiple-VoIP-phones.
That seems quite a blocker for a mobile ring app, any voip actually, and isn't all this making even more sense to enable a solution like IAX2? https://www.voip-info.org/iax/
Edited by Ring ThingI was now able to test with the "play" version on one phone, and to enable using the mobile network.
I saw identical behavior with both versions (play and f-droid): The dht proxy setting worked on the mobile net but caused the unknown state in the wifi network.
What do you advice?
Edited by Ring Thing-
Still can't understand the proxy problem. Several devices are connected at this time and it's up since last Friday. I'll try to reproduce.
Presence: known bug. I don't think it's solved (maybe with the latest bump of OpenDHT but not sure)
Connecting problem: Fixed by https://git.ring.cx/savoirfairelinux/ring-daemon/commit/a2207056f028c259f21aeca89d76e771e5bec57b (2 weeks ago, so still not on the FDroid)
Calling a suspended phone: Normal if it's F-Droid because there is no push system for now.
-
Ok we just tried with @pduchemin the FDroid version switching between the proxy and the local node, and switching the connectivity (3 or 4g, wifi). There is no failure, so if you have any reproduce step.
However, you need to check that mobile connectivity is allowed, otherwise, you'll get an unknown status on mobile network.
Edited by Pierre DucheminThanks for the hints, I was able to find out now that at a different wifi network the proxy can be enabled without a problem (just as on mobile).
So, it seems the router here is connecting or filtering a little differently than others. Now, how may this be debugged? You'd need some logging I guess.
Just check that you can access dhtproxy.ring.cx on port 80. You can also try from a computer on the same network.
If you feel like you can build a debug version of Ring for Android, logs might help, otherwise the logs from the release version are not very useful.
This issue is not related to Ring but to your network. If you find where this come from, let us know, but there may be nothing to fix in Ring.
Even if, in the end, Ring is really not able to work through the NAT router here, it would be very much helpful to find out what's causing this. Then Ring could also print a much better error message that can point the user to the required solution.
I could verify that dhtproxy.ring.cx can be reached even from the network where Ring gets into the unknown state as soon as enabling it. In the browser the response looks like usage statistics. In both networks the access is not possible using https/ssl (NB: Wouldn't that be better?).
Is there any further signaling communication required beyond the http connection to the proxy? Could there be a problem with MTU, packet sizes, or similar?
Found https://git.ring.cx/savoirfairelinux/ring-client-gnome/issues/662
Does Ring contact the dht proxy also using UDP, unlike the browser using TCP?
On the other hand, it looks as if running the dht node on the phone is working (more or less, but with messages not coming through if one phone was suspended). Could it be that there is only an isolated local dht network, consisting only of the two phones in the LAN?
Couldn't find any network stats in the app.
-
@ringthing Yeap OpenDHT uses UDP to work. If it's not available on your router, sure it will not work. But without the proxy too.
I was having this problem as well. In varietate concordia - 20180712 Android 6.0.1 LineageOS 13.0
There is a refresh icon that does nothing. I have disabled/re-enabled the account and it will still show "Unknown" in red. My only "workaround" is to hard close the app and then re-open it. It has happened twice now.
I wonder if that was also the cause of messages stopping being sent gnome-ring. It was fine for awhile one night then out of the blue, they just stopped sending. I could still receive FROM android though. Actually, that sounds like a separate and old issue that I thought was handled before. It's working again though... for now.
If we assume, the cause is due to the router not being open for UDP, the question remains why the client enters the unknown state in proxy mode (that uses TCP as I learned in #517). Could this come from some check? Maybe ICE, that is not making the full error status available?
Hi there,
There have been a lot of improvements this past few days namely the upgrade of openDHt. Could you check if this still happens on your end ?
Edited by Mohamed FenjiroBecause the router environment has changed, unfortunately I can't test the behaviour with restricted UDP connectivity anymore.
The most problematic thing was, I think, that there was no proper error message that mentioned the actual problem and hints to the solution.
Something like "can't connect to host X on port Y using UDP". If that has not been added, I think the issue is still valid.
Having seen ring/jami connectivity problems in some situations that may be router dependent let to a heads up when I found this as part of another projects roadmap:
- Wrapping a TCP tunnel around the UDP-based RPC2/SFTP communication protocol between clients and servers. This avoids many problems with firewalls some of which like to treat all UDP as DNS traffic and lose the port forwarding once 'the reply packet' has been passed back. https://github.com/cmusatyalab/coda/issues/55#issuecomment-410312635
Sounds like this could possibly explain some of the trouble.
mentioned in issue #920 (closed)
-
Jami will not support a non UDP network without proxy. For the proxy it was ree-written several times, so I close as it should be solved nowadays
Edited by Sébastien Blin added severityhigh label
