Tested this morning with 126.96.36.199 and nginx 1.11.0. Works like a charm. Thanks a lot :slight_smile:
iCloud account setup fails unless using alternate base url
twisteroidambassador last edited by devvv4ever
I was trying to setup contacts sync with an iCloud account (with an email address ending in @icloud.com). Followed the instructions on the “tested service” page, tried both not using a base url and using a base of
https://icloud.com, neither would complete the setup. I then tried to use the base url
https://contacts.icloud.com, and this time setup completed successfully, and my contacts were synced. (The account did not show calendars at all, which is to be expected, I guess.)
The full debug info generated by the app is here:
Looking at the logs, I think there may be several problems:
Both the PROPFIND request and GET /.well-known/ request to
icloud.comreceived a 301 redirect to
www.icloud.com, and the subsequent redirected request failed. Does this mean
icloud.comno longer supports these discovery methods, and thus isn’t suitable as a base url anymore?
The DNS SRV discovery also failed, with
EXCEPTION java.lang.ArrayIndexOutOfBoundsException: length=0; index=0. Strangely, when I run
dig srv _carddavs._tcp.icloud.comstraight on the device (in TermUX), it returns an answer just fine:
_carddavs._tcp.icloud.com. 3600 IN SRV 0 0 443 contacts.icloud.com.
Now this could just be my unusual network setup, since I run a proxy server on device and then set it as the global proxy (
settings set global http_proxyover adb), but the problem persists after I undo this global proxy setting.
The DNS SRV discovery also failed, with EXCEPTION java.lang.ArrayIndexOutOfBoundsException: length=0; index=0.
Yes, this is the problem. The CardDAV server is normally detected over DNS SRV. Unfortunately, if this doesn’t work correctly, you have to set it up with contacts.icloud.com.
@rfc2822 I guess then the question becomes, why couldn’t the app complete DNS SRV discovery when a manual lookup succeeds?
@twisteroidambassador Did you run dig on the mobile phone?
Ah, I have just seen in the debug info that there are no DNS servers for your connection:
☒ tun0 - [ Transports: WIFI|VPN Capabilities: INTERNET NOT_RESTRICTED TRUSTED VALIDATED NOT_ROAMING FOREGROUND NOT_CONGESTED NOT_SUSPENDED LinkUpBandwidth>=1048576Kbps LinkDnBandwidth>=1048576Kbps] - DNS: <- !!!!!! ☐ wlan0 - [ Transports: WIFI Capabilities: NOT_METERED INTERNET NOT_RESTRICTED TRUSTED NOT_VPN VALIDATED NOT_ROAMING FOREGROUND NOT_CONGESTED NOT_SUSPENDED LinkUpBandwidth>=1048576Kbps LinkDnBandwidth>=1048576Kbps SignalStrength: -46] - DNS: 240e:3b1:300a:8750::1, 192.168.31.1 ☐ rmnet_data1 - [ Transports: CELLULAR Capabilities: SUPL INTERNET NOT_RESTRICTED TRUSTED NOT_VPN VALIDATED NOT_ROAMING NOT_CONGESTED NOT_SUSPENDED LinkUpBandwidth>=15000Kbps LinkDnBandwidth>=30000Kbps Specifier: <3>] - DNS: 188.8.131.52, 184.108.40.206 ☐ rmnet_data2 - [ Transports: CELLULAR Capabilities: IMS NOT_METERED TRUSTED NOT_VPN VALIDATED NOT_ROAMING FOREGROUND NOT_CONGESTED NOT_SUSPENDED LinkUpBandwidth>=15000Kbps LinkDnBandwidth>=30000Kbps Specifier: <3>] - DNS:
So I guess the problem is that DAVx5 can’t tell dnsjava any DNS servers, so dnsjava can’t do the lookup, so it fails.
I’ll see whether the list of DNS servers is stacked (so that the WiFi DNS should be tried after the VPN DNS or something like that). However this could have security implications.
Do you know whether it’s correct that there are no DNS servers for your VPN connection? Which type of VPN is it?
@rfc2822 For my particular circumstances, not having DNS servers set on the VPN is correct. This is a
tincconnection that I use to access some private servers, so it only has routes to some specific subnets, and it’s not my default gateway.
I did run
digdirectly on device, and it used the DNS server on my WiFi network if I remember correctly. Now I wonder how the Android system pick its DNS servers.
@twisteroidambassador Just for information: dnsjava 3.x uses the same method as DAVx⁵, so if more DNS than those from
ConnectivityManager.getActiveNetwork()shall be used, we could submit a patch there too.
This is a tinc connection that I use to access some private servers, so it only has routes to some specific subnets, and it’s not my default gateway.
I see; as I understand it, the plain WiFi should then be “active” too, i.e. its DNS servers would also be used. So the question is, why is it not “active”… maybe we’d have to iterate through all networks and query an “active” flag or something like that.
Since Android 10, there’s a new DnsResolver API which can be used. We will have a look at that.
@twisteroidambassador Can I send an APK that uses a proof-of-concept DnsResolver solution to see whether it’s working for your use case?
Should work with 4.1-alpha.3 which uses the new DnsResolver API. Can you please test? I can send an APK if required (but you’d have to reinstall because we can’t sign with the FDroid key).
@rfc2822 Sure, I’ll be happy to test this.
@twisteroidambassador I have sent a link to the APK.
@rfc2822 This version worked right away with username + password, without adding a base URL. Thanks!
@twisteroidambassador Thanks for the report and testing. So the new resolver will be included in the next version