@moonlies Did you use an app password for the first account? In this case, the app password would stay valid even when the main password changes.

@rfc2822, may application was moved back to the old server. now all cipherspecs are available again, nothing was changed on the old server ! Only my Nextcloud was first migrated to a newer server, there Nextcloud was updated from 13.0.7 to 14.0.4, the problems occurred. now the Nextcloud has been moved back to the old server. But now it is still Nextcloud 14.0.4 ! Could it be that it’s not the cipherspecs but the old DavDroid has a problem with Nextcloud 14.0.4?

Hello I’m running owncloud 10.0.0.4 on a slow system and requesting a contact sync >450 entries (with pictures). As far as i’m able to judge the client is requesting the whole addressbook and after timeout exception it want to retry a request of 10 entries. At this time the server is still running at 100% cpu duty collecting the previous request. That leads to a bunch of apache instances on server-side which freezes the system for a couple of minutes and the client isn’t getting it’s requests within it’s (too short and unconfigurable) timeout. For reference: setting the timeout to 180sec would very likely fix this problem

@rfc2822 said in Sync stopped working, nothing to go by in terms of debugging: @MadGoose Thanks for sharing your solution! So, your problem was basically firewall settings which were incompatible with the way how Android detects Internet connection, so that synchronization was never started (not only of DAVdroid, but all account types). Well, not quite: DAVDroid synced after a reboot for a certain time - just until i got killed (by the system?). It just was not restarted to continue synchronization. All other apps continued their “synchronization” - but I guess all other apps I use do not rely on the synchronization framework by Android but use other methods to restart after having been killed by the system. But for sure it was no DAVdroid-related problem but the - in my opinion - not too clear documented (well, where could that be found?) behavior of synchronization framework and “internet connectivity detection”. Cheers MG

@rfc2822 No, I can’t browse to the server from any device connected via Internet. On my local LAN the web pages serve up fine , and my Thunderbird calendar on a machine on the LAN will sync to the calendar on the Pi. However, I can ping the server successfully from the internet - both via direct IP address and the sub-domain name. I do have a local DNS server running on another RPi on my LAN - Pi-Hole - to block ads. The Pi-hole logs don’t indicate that traffic to the sub-domain are blocked. But the DNS blocking would be happening from DNS resolution requests from devices that are connected on the LAN, not traffic coming into the LAN.

OH MY … @mwlczk you just cleared several problems with my mobile!! I never found the right pid for the internet connectivity connection! But after allowing pid 1000 Davdroid started to work again (seems like my fw is down intermittently, as it sometimes synced). AND firefox sync started working (it was only logged as Web Session before and was still waiting for email verification…several times…) This should be on the FAQ of AWFALL as well. Thank you again!

I had the same problem with DAVdroid and Posteo and found the cause, so I wanted to share this: I am using LineageOS 14.1 on a GT-i9300 (Samsung Galaxy S3) in Austria, my mobile telecommunications operator is A1. As far as I remember I never edited the APN settings after setting up my phone, so I suspect that the default APN for this operator is wrong (sure it’s possible I edited the settings and can’t remember it…). The active APN was named “live!” and used a Proxy – and I ran into the problem described here. After changing the APN to “A1” (settings with the name of my mobile telecommunications operator and without a Proxy) I can’t reproduce this issue. You can find all APN settings included in LineageOS on GitHub. BTW, thanks for DAVdroid!!

emmmm. I meet this problem again.

@cedricoola Unfortunately not. I am quite certain that the synchronization of the CardDav server only works if you have a proper port forwarding and direct access via a fixed IP address and that this is why I can not access it via app or browser.

2017-11-05 19:35:13 16235 [HttpClient] --> PROPFIND http://192.168.1.100:8008/addressbooks/users/LW/addressbook/ … 2017-11-05 19:35:43 16235 [ui.setup.DavResourceFinder] PROPFIND/OPTIONS on user-given URL failed EXCEPTION java.net.SocketTimeoutException: connect timed out at java.net.PlainSocketImpl.socketConnect(Native Method) The connection to 192.168.1.100:8008 has timed out. This is probably a networking/server problem. You may try to reach the server with your mobile device’s Web browser first.

2017-08-10 16:10:35 4684 [HttpClient] --> END PROPFIND (290-byte body) 2017-08-10 16:11:05 4684 [HttpClient] <-- HTTP FAILED: java.net.SocketTimeoutException: connect timed out 2017-08-10 16:11:05 4684 [ui.setup.DavResourceFinder] PROPFIND/OPTIONS on user-given URL failed EXCEPTION java.net.SocketTimeoutException: connect timed out There was a timeout. This is a connectivity problem. Did you try another network? Can you access the URLs with your browser on the mobile device? Did you try another connection type? Are there any firewalls which could block the access?

@marco said in Cannot add new account: How can I resolve with the mobile data? I mostly use it instead of wifi. It’s not a DAVdroid problem. You can see the proxy in Android settings / Mobile data / Access points (APNs) / your access point / Proxy. If this proxy doesn’t work properly, please contact your provider or just delete the proxy setting (and restart DAVdroid / the system afterwards), if you’re allowed to do so (may be restricted). Same problem as here, for instance: https://forums.bitfire.at/topic/422/certpathvalidatorexception-but-my-domain-is-a-on-ssllabs

@devvv4ever Thanks for the answer ! I’ve adjusted the ciphers the server supports and now it’s working flawlessly Patrick

Thank you, that was the solution. This works best for me, better than auto. ssl_ecdh_curve secp384r1:prime256v1;

Already open again in okhttp: https://github.com/square/okhttp/issues/3308

@MrGutsy It should be possible to set up the account with the working connection (4G) and then sync over WiFi, too.

So the issue indeed seems to be with Android 7 in some way, depending on how you configured your server, I’ll just copy a github comment i accidentally made to the wrong place. I can confirm that the f-droid version was affected, the offending nginx config is this: ssl_ecdh_curve secp384r1; other relevant ssl config lines: ssl_protocols TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers “EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH”; ssl_ecdh_curve secp384r1; ssl_session_cache shared:SSL:50m; ssl_session_timeout 5m; ssl_session_tickets off; ssl_stapling on; ssl_stapling_verify on; So with that option commented out it’s working fine, I’m on 1.6.1.1-ose from f-droid and android 7. Apparently Android 7 supports only up to secp256r1, this was supposedly fixed in 7.1.1. Aside that, a bit of a rant, why are gitlab issues not enabled and instead this forum is used as a bug report tool? I have to create yet another account and wade through 5 google captchas just to write this.

@lllvvv Then I don’t have any idea, except that there must be some connectivity problem. Did you try another connection type (mobile/WiFi)?

@rfc2822 I tried again with the wifi and it works! Thank you very much, this was driving me crazy

Hi @rfc2822, thanks for your reply and the help with this issue. It is working now with only port 4433 forwarded. Here is the solution: As I am forwarding a non-standard port (4433) for SSL/TLS connections to my nextCloud server (which itself is listening on port 443 in my private network), I have to make sure that DAVdroid uses port 4433 aswell. Though DAVdroid was set up like this using the standard URI www.example.com:4433 it did not work because using the short version of the URI and not the one actually pointing to the WebDAV interface (for nextCloud: www.example.com/remote.php/dav) resulted in the well-known URIs kicking in. Unfortunately, I did not change them to forward to port 4433 but kept the standard version of my nginx config. So, the well-known URIs where forwarding to the standard port for SSLL/TLS. And that’s why it worked when I opened port 443 in addition to port 4433. Hope this will be of help for someone who also uses a non-standard port Thanks again and best regards.