android
android copied to clipboard
Uploads fail with "Connection error" even though connection works (TLS1.3 broken for uploads, TLS1.2 OK)
Steps to reproduce
- Open Nextcloud
- Head to "Uploads"
- Tap a file with "Connection" error
Expected behaviour
- The file correctly uploads
Actual behaviour
- The upload fails with "Connection error"
- I can correctly use the Android app to navigate the server and I can use my browser too. The "Connection Error" only happens on uploads.
Can you reproduce this problem on https://try.nextcloud.com?
- No, can't reproduce
Environment data
Android version: 11
Device model: Pixel 4a 5G
Stock or customized system: Stock
Nextcloud app version: 3.16.0 RC2
Nextcloud server version: 21.0.0 (PHP8)
Reverse proxy: haproxy+nginx
NB: my server only serves TLS 1.3 and requires SNI (the joys of having only IPv4 in this day and age)
Logs
Web server error log
No errors in log
Nextcloud log (data/nextcloud.log) (Android app log)
2021-03-21T20:02:28.924+0100;V;UploadsStorageManager;getUploads() got 0 rows from page 1, 9 rows total so far, last ID 1
2021-03-21T20:02:28.924+0100;V;UploadsStorageManager;getUploads() returning 9 (9) rows after reading 2 pages
2021-03-21T20:02:30.062+0100;E;UploadFileOperation;Upload of /storage/emulated/0/DCIM/Camera/PXL_20210319_092551675.jpg to /InstantUpload/Camera/PXL_20210319_092551675.jpg: No network connection
2021-03-21T20:02:30.062+0100;D;UploadsStorageManager;updateDatabaseUploadResult uploadResult: RemoteOperationResult(mSuccess=false, mHttpCode=-1, mHttpPhrase=null, mException=null, mCode=NO_NETWORK_CONNECTION, message=null, getLogMessage=No network connection) upload: com.owncloud.android.operations.UploadFileOperation@92c9df
2021-03-21T20:02:30.069+0100;V;UploadsStorageManager;Updating /storage/emulated/0/DCIM/Camera/PXL_20210319_092551675.jpg with status:UPLOAD_FAILED and result:NETWORK_CONNECTION (old:/storage/emulated/0/DCIM/Camera/PXL_20210319_092551675.jpg status:UPLOAD_IN_PROGRESS result:-1)
2021-03-21T20:02:30.070+0100;V;UploadsStorageManager;Updating /storage/emulated/0/DCIM/Camera/PXL_20210319_092551675.jpg with status=UPLOAD_FAILED
2021-03-21T20:02:30.075+0100;D;UploadsStorageManager;updateUpload returns with: 1 for file: /storage/emulated/0/DCIM/Camera/PXL_20210319_092551675.jpg
2021-03-21T20:02:30.075+0100;D;UploadsStorageManager;notifyObserversNow
2021-03-21T20:02:30.076+0100;D;FileUploader;NotifyUploadResult with resultCode: NO_NETWORK_CONNECTION
2021-03-21T20:02:30.081+0100;D;FileUploader;Stopping command after id 4
2021-03-21T20:02:30.081+0100;D;UploadListAdapter;loadUploadItemsFromDb
2021-03-21T20:02:30.083+0100;D;UploadsStorageManager;QUERY: status==0 OR last_result==9 OR last_result==13 OR last_result==11 OR last_result==14 AND account_name== ? ROWID: -1
2021-03-21T20:02:30.086+0100;V;UploadsStorageManager;getUploads() got 0 rows from page 0, 0 rows total so far, last ID -1
2021-03-21T20:02:30.086+0100;V;UploadsStorageManager;getUploads() returning 0 (0) rows after reading 1 pages
2021-03-21T20:02:30.088+0100;D;UploadsStorageManager;QUERY: status==1 AND last_result<>9 AND last_result<>13 AND last_result<>11 AND last_result<>14 AND account_name== ? ROWID: -1
2021-03-21T20:02:30.090+0100;V;UploadsStorageManager;getUploads() got 3 rows from page 0, 3 rows total so far, last ID 9
2021-03-21T20:02:30.090+0100;D;UploadsStorageManager;QUERY: (status==1 AND last_result<>9 AND last_result<>13 AND last_result<>11 AND last_result<>14 AND account_name== ?) AND _id < ? ROWID: 9
2021-03-21T20:02:30.093+0100;V;UploadsStorageManager;getUploads() got 0 rows from page 1, 3 rows total so far, last ID 9
2021-03-21T20:02:30.093+0100;V;UploadsStorageManager;getUploads() returning 3 (3) rows after reading 2 pages
2021-03-21T20:02:30.094+0100;D;UploadsStorageManager;QUERY: status==2 AND account_name== ? ROWID: -1
2021-03-21T20:02:30.097+0100;V;UploadsStorageManager;getUploads() got 9 rows from page 0, 9 rows total so far, last ID 1
2021-03-21T20:02:30.097+0100;D;UploadsStorageManager;QUERY: (status==2 AND account_name== ?) AND _id < ? ROWID: 1
2021-03-21T20:02:30.099+0100;V;UploadsStorageManager;getUploads() got 0 rows from page 1, 9 rows total so far, last ID 1
2021-03-21T20:02:30.099+0100;V;UploadsStorageManager;getUploads() returning 9 (9) rows after reading 2 pages
NOTE: Be super sure to remove sensitive data like passwords, note that everybody can look here! You can use the Issue Template application to prefill some of the required information: https://apps.nextcloud.com/apps/issuetemplate
Network trace
# tcpdump -tttnei bge0 port https
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bge0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:00:00.000000 78:81:02:2e:5c:d4 > 98:f2:b3:e6:4d:54, ethertype IPv4 (0x0800), length 74: 151.80.43.167.64842 > 192.168.1.100.443: Flags [S], seq 3460956079, win 65535, options [mss 1240,sackOK,TS val 58825446 ecr 0,nop,wscale 8], length 0
00:00:00.000091 98:f2:b3:e6:4d:54 > 78:81:02:2e:5c:d4, ethertype IPv4 (0x0800), length 74: 192.168.1.100.443 > 151.80.43.167.64842: Flags [S.], seq 1199358745, ack 3460956080, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 3924191486 ecr 58825446], length 0
00:00:00.030865 78:81:02:2e:5c:d4 > 98:f2:b3:e6:4d:54, ethertype IPv4 (0x0800), length 66: 151.80.43.167.64842 > 192.168.1.100.443: Flags [.], ack 1, win 256, options [nop,nop,TS val 58825492 ecr 3924191486], length 0
00:00:00.001818 78:81:02:2e:5c:d4 > 98:f2:b3:e6:4d:54, ethertype IPv4 (0x0800), length 243: 151.80.43.167.64842 > 192.168.1.100.443: Flags [P.], seq 1:178, ack 1, win 256, options [nop,nop,TS val 58825494 ecr 3924191486], length 177
00:00:00.000771 98:f2:b3:e6:4d:54 > 78:81:02:2e:5c:d4, ethertype IPv4 (0x0800), length 73: 192.168.1.100.443 > 151.80.43.167.64842: Flags [P.], seq 1:8, ack 178, win 1027, options [nop,nop,TS val 3924191518 ecr 58825494], length 7
00:00:00.000015 98:f2:b3:e6:4d:54 > 78:81:02:2e:5c:d4, ethertype IPv4 (0x0800), length 66: 192.168.1.100.443 > 151.80.43.167.64842: Flags [F.], seq 8, ack 178, win 1027, options [nop,nop,TS val 3924191519 ecr 58825494], length 0
00:00:00.029404 78:81:02:2e:5c:d4 > 98:f2:b3:e6:4d:54, ethertype IPv4 (0x0800), length 66: 151.80.43.167.64842 > 192.168.1.100.443: Flags [.], ack 8, win 256, options [nop,nop,TS val 58825524 ecr 3924191518], length 0
00:00:00.003012 78:81:02:2e:5c:d4 > 98:f2:b3:e6:4d:54, ethertype IPv4 (0x0800), length 66: 151.80.43.167.64842 > 192.168.1.100.443: Flags [F.], seq 178, ack 9, win 256, options [nop,nop,TS val 58825527 ecr 3924191519], length 0
00:00:00.000082 98:f2:b3:e6:4d:54 > 78:81:02:2e:5c:d4, ethertype IPv4 (0x0800), length 66: 192.168.1.100.443 > 151.80.43.167.64842: Flags [.], ack 179, win 1026, options [nop,nop,TS val 3924191552 ecr 58825527], length 0
00:00:05.222193 98:f2:b3:e6:4d:54 > 78:81:02:2e:5c:d4, ethertype IPv4 (0x0800), length 129: 192.168.1.100.443 > 151.80.43.167.52761: Flags [P.], seq 3743102473:3743102536, ack 2447182969, win 1035, options [nop,nop,TS val 1426787209 ecr 1365080257], length 63
00:00:00.000038 98:f2:b3:e6:4d:54 > 78:81:02:2e:5c:d4, ethertype IPv4 (0x0800), length 66: 192.168.1.100.443 > 151.80.43.167.52761: Flags [F.], seq 63, ack 1, win 1035, options [nop,nop,TS val 1426787209 ecr 1365080257], length 0
00:00:00.025787 78:81:02:2e:5c:d4 > 98:f2:b3:e6:4d:54, ethertype IPv4 (0x0800), length 66: 151.80.43.167.52761 > 192.168.1.100.443: Flags [.], ack 63, win 502, options [nop,nop,TS val 1365260264 ecr 1426787209], length 0
00:00:00.000058 78:81:02:2e:5c:d4 > 98:f2:b3:e6:4d:54, ethertype IPv4 (0x0800), length 66: 151.80.43.167.52761 > 192.168.1.100.443: Flags [F.], seq 1, ack 64, win 502, options [nop,nop,TS val 1365260265 ecr 1426787209], length 0
00:00:00.000042 98:f2:b3:e6:4d:54 > 78:81:02:2e:5c:d4, ethertype IPv4 (0x0800), length 66: 192.168.1.100.443 > 151.80.43.167.52761: Flags [.], ack 2, win 1035, options [nop,nop,TS val 1426787235 ecr 1365260265], length 0
Is this happening for all uploads, also manual ones? What kind of wifi/mobile data/server/proxy setup do you have?
It happens for all uploads: auto-backup, addressbook uploads, and manual uploads.
I use a WiFi connection with a 0.0.0.0/0 Wireguard VPN through my dedicated server. (https://play.google.com/store/apps/details?id=com.wireguard.android)
It used to work though, so that's weird (but I can't tell if it was a Nextcloud beta update that broke it or an Android 11 update).
My networking setup looks like this:
My phone can successfully browse the Nextcloud instance but it can't upload files. I have even confirmed that I can browse to newly created files & folders (1. don't touch phone 2. use browser to create a dummy file on the server 3. use the phone to browse to that file 4. use the phone to remove that file). I can't see any reason for the uploads failing.
haproxy is used to do SNI redirection (because I only have one IPv4), see this article. Bypassing haproxy did not change the behavior (using a direct PAT: rdr pass on $ext_if inet proto tcp from any to $ext_if port https -> $nextcloud_s4 port https
).
digraph network {
bgcolor=transparent
subgraph cluster_castle {
label="NAS @ home";
haproxy [shape=rectangle];
"nextcloud on nginx" [shape=rectangle];
postgresql [shape=rectangle];
}
"wg server" [shape=rectangle];
phone -> "wg server" [label="encapsulated"]
"wg server" -> haproxy -> "nextcloud on nginx" [label="https"]
"nextcloud on nginx" -> postgresql [label="pgsql"]
}
I think I am experiencing the same issue. All of my automatic updates were in "waiting for free wifi", so I set my home wifi to "treat as free" and when tapping the waiting uploads they are moved to "failed". Any further tap displays a very short progress bar, then its back again to "Verbindungsfehler" (connection error). Browsing the server in the app as well as in Chrome works flawlessly. The uploads worked until mid-February, but i'm afraid I dont know which version was still working. Currently, it's 3.15.1 .
I'd be happy to troubleshoot, just give me a hint where to start or what to look for...?
I downgraded from the beta client to the default version (3.16.0), the same issue started happening today :disappointed:
I had the same issue till today with
- Pixel 4a
- Android 11
- App version 3.16.0
- Server version 21.0.1
In my case, it was because I only allowed TLS version 1.3 in my server nginx config. See https://github.com/nextcloud/android/issues/8355 Adding version 1.2, as described, fixed the problem for me.
@codemonkey1988 this is weird. My Nextcloud app can actually navigate inside the server. Only uploads are broken.
@moviuro same for me. I was able to browse my server using the app but uploads were failing with the message "connection error" The android app log gave me the hint, that the SSL handshake was failing for the upload, so I tried adding TLS 1.2 (and because I saw that issue in the list before)
@codemonkey1988 I had the same issue. I allowed TLS1.2 also again and now uploads are working again. Thanks!
Same issue here, Pixel 4 XL (stock, Android 11) TLS 1.3 only server Last upload worked on the 06.05. getting "connection error" when trying to upload a file Browsing the existing files, creating folders works without problems
So the TLS issue hit me twice recently. First I was failing to upload from my old android phone, as described above. So did a manual download to PC and uploaded from there. Then I lost several hours of my life fighting the dreaded login loop on my new phone. Even tried it on a random android tablet. Kept giving auth errors and not much else going wrong. Downgraded to TLS1.2. Login works. Uploads work.
Same here. I have a HAProxy (version 1.8.27 with OpenSSL 1.1.1i) in front of my Nextcloud instance. I have the reverse proxy configured so that it only accepts TLS 1.3 and this used to work without issues. As reported by others in this thread, the photo auto uploads in Android suddenly stopped working. The browsing and downloading of files still worked. Other Android apps that use Nextcloud like Deck or Joplin also continued to work.
I removed no-tlsv12
from the advanced SSL options in HAproxy and the auto upload started working again.
@stefanthoss are you running the latest patch release of the Android app: 3.16.1 released 1st June?
Nextcloud Android 3.16.1 on Pixel 4a 5G running Android S (beta); TLS 1.3 only 21.0.2 Nextcloud server running on FreeBSD 12.x with PHP 8.0, the issue is still here.
@AndyScherzinger please re-open that issue. Using TLS 1.3 or 1.2 shouldn't matter, and nothing makes me believe it's been fixed.
Nextcloud Android 3.16.1 on Pixel 4a 5G running Android S (beta); TLS 1.3 only 21.0.2 Nextcloud server running on FreeBSD 12.x with PHP 8.0, the issue is still here.
@AndyScherzinger please re-open that issue. Using TLS 1.3 or 1.2 shouldn't matter, and nothing makes me believe it's been fixed.
Second that. Verified Google Store Version (updated just now), re-trying uploads immediately show "connection error".
re-opened and pinging @tobiasKaminsky
I've been seeing the odd image auto upload not working for a while now - but tonight my SO was uploading some videos manually at home and noticed the same issue.
Been scratching my head over this one all evening. I also use Wireguard on my Samsung S10 - but in my case the problem seem to stem from using Wifi. 3/4G with or without WG works fine.
The Dev app with its Log feature shows me "No network connection" for the "E UploadFileOperation". Going down from TLS1.3 to 1.2 doesn't seem to make any difference. No hits (HEADs, PUTs) on the nginx access.log
I should add that browsing and downloading works fine. PCs works too.
On my end though, I can confirm that:
- TLS 1.3 only = always Connection error
- TLS 1.3 & 1.2 = no Connection error
Enabling/disabling WireGuard did not change the behavior.
After some more careful grepping through my reverse proxies' spaghetti of configs I've found I missed one 'ssl_protocols' line. In other words, yeah - TLS1.2 works :o) my bad.
Using TLS 1.3 or 1.2 shouldn't matter, and nothing makes me believe it's been fixed.
@moviuro see https://github.com/nextcloud/android-library/pull/621/files that is what has changed with 3.16.1 and what should actually work and fallback 1.3->1.2->... So you second post means the client always falls back to 1.2
what should actually work and fallback 1.3->1.2->...
Yes, I can confirm that if nginx only exposes TLS1.3 (ssl_protocols TLSv1.3;
), the client (3.16.1) fails uploading. (Just tested it again this morning)
If needed, I can create an account on my Nextcloud instance for testers. (@tobiasKaminsky ? @AndyScherzinger ?) I idle on libera.chat (RIP freenode) and my email is: nickname @ google's popular mail service.
Probably rather @tobiasKaminsky but is is afk till next week and yes a test account might be helpful but he might be better answering that questions.
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
@stefanthoss are you running the latest patch release of the Android app: 3.16.1 released 1st June?
I just confirmed that this issue still exists with the Nextcloud Android App 3.16.1. I also upgraded my server's OpenSSL library to 1.1.1k. As soon as I add no-tlsv12
to the HAProxy config, the Android App complains with a Connection Error
for auto uploads.
I can confirm the behavior mentioned by forestEagle: Uploads on 4G running fine, but on wifi it says "Connection error"; Enabling TLS 1.2 also fixes the issue --> why is wifi more restricted, than mobile internet? Is wifi treated as metered connection or something?
Setup: NginX with TLS1.3 only; Android App 3.16.1; Xiaomi Smartphone; Wireguard doesn't seem to have any impact
Seems like a fix is coming with https://github.com/nextcloud/android-library/pull/645, different parts of the Android codebase use different TLS implementations in the current version.
Hopefully nextcloud/android-library#645, will do the trick, from my experience I'd agree seems to be an incompatibility with TLSv1.3.
Server: apache running Nextcloud 21.0.3.1 Client: Nextcloud for Android 3.16.1 TLS Config: TLSv1.3 only
Doing a packet capture I can see:
Instant Upload
-
Client:
TLSv1.2 Client Hello
-
Server:
Alert (Level: Fatal, Description: Protocol Version)
Other Actions
e.g. refreshing a folder
-
Client:
TLSv1.3 Client Hello
, -
Server:
Server Hello, Change Cipher Spec, Application Data
-
Client::
Change Cipher Spec, Application Data
- ...data transfer...
\o/ I just want to thank everyone who figured this out! After fighting with auto-upload for more than a day, I had almost given up on my plans to maybe start actually using NC after evaluation.
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
Not stale, just waiting: fixed version not yet released