Running into GarminSdkError::0 when trying to sync Nextcloud

[ashrude]

I'm running Music v1.8.1 and SubMusic 2.8 on an Epix 2
SubMusic settings:
API backend: Ampache API
Server Address: https://cloud.[domain].[tld]/apps/music/ampache

When I go into "more", and "Test Server", it says "Inlog OK No podcasts"
Then when I try to sync, after searching for a wifi network it displays "GarminSdkError::0". The only playlist I have selected has five songs. It's also correctly pulling the list of playlists and songs in playlists.

I'm also using a LetsEncrypt certificate on my server, and nextcloud is behind Nginx Proxy Manager

[memen45]

Thanks for your feedback. Can you check the ciphers you enabled on your webserver? See #42
Will try the same version shortly, have to charge my watch first.

[villovil]

I am having the same issue on a Forerunner 265
I have Airsonic server version 10.6.2-RELEASE
I am also using a valid LetsEncrypt cert

API Backend: Subsonic API

When I have no playlist selected for offline sync the "Sync" is successful. I guess it grabs the available playlists. However once I select either if my 2 "testing" playlist with less than 12 songs and try to sync again, I get "GarminSdkError::0" displayed on the screen

[memen45]

Could you try different number of songs on the playlist (zero songs too) and maybe narrow it down to a particular song? I have seen certain characters in the metadata cause this error as well, for example the copyright ©️ symbol.

Otherwise you could also send me a personal email (in the Garmin Connect IQ store, then Contact developer option) with some temporary login details so I can test with your server instance.

[villovil]

Thanks for your quick response.
I have sent the access to my server via Connect IQ store.

With regards to manipulating the playlist, I think I have done all sorts of changes since I assumed it might be a naming issue. However, none of that seems to help.

[memen45]

Do you have redirect in place? Found an issue where the redirect is not followed here.

I will take a look as soon as I get home. I forgot my windows boot drive and the simulator doesn't work on Linux unfortunately.

[villovil]

I wouldn't call it a redirect. It's just that the Airsonic container is sitting behind an Apache reverse proxy... I think in this day and age this kind of setup is pretty standard.
I appreciate your attention looking into this🙏🏽

[yura1106]

I'm facing a similar issue with my Forerunner 255s Music.
My setup includes NextCloud behind Traefik in Kubernetes, and I also use TrueChart in TrueNAS Scale.
The connection to NextCloud and fetching of playlists, podcasts, and tracks are functioning properly. However, there seems to be an issue with syncing songs.
Can you suggest any solution, please?
Thank you for your time and effort in investigating this matter.

[villovil]

I'm facing a similar issue with my Forerunner 255s Music. My setup includes NextCloud behind Traefik in Kubernetes, and I also use TrueChart in TrueNAS Scale. The connection to NextCloud and fetching of playlists, podcasts, and tracks are functioning properly. However, there seems to be an issue with syncing songs. Can you suggest any solution, please? Thank you for your time and effort in investigating this matter.

I am wondering if maybe some stuff changed with Garmin recently and broke the add-on. I shared credentials to my Airsonic server with the dev to try see if the error can be reproduced. Hopefully a way forward can be found... I'd really like to be able to us my own music and not have to subscript to Spotify Premium or the other services.

[memen45]

Unfortunately, it will take longer. Currently, I am unable to see crash reports, run the simulator, or anything. The Garmin dev tools were not streamlined, but now completely broken. Waiting for an update on their side :(

[villovil]

Unfortunately, it will take longer. Currently, I am unable to see crash reports, run the simulator, or anything. The Garmin dev tools were not streamlined, but now completely broken. Waiting for an update on their side :(

Is it possible to install an older version of the app to see if the error is also present there? (I don't even know if this sort of thing is possible with IQ)

[tsipizic]

are there any news regarding that? I can confirm my server has TLSv1.2 enabled and the required ciphers. I see requests on the server during the test but no requests or errors during the sync

[memen45]

are there any news regarding that? I can confirm my server has TLSv1.2 enabled and the required ciphers. I see requests on the server during the test but no requests or errors during the sync

Could you share the device and firmware version of your watch?

[tsipizic]

are there any news regarding that? I can confirm my server has TLSv1.2 enabled and the required ciphers. I see requests on the server during the test but no requests or errors during the sync

Could you share the device and firmware version of your watch?

Garmin Fenix 7 17.28

[memen45]

The firmware version might be broken. I have received more reports (Fenix 7 Pro Solar and Epix2 devices) for this firmware version 17.28 with the issue. Also for other music apps. There is a beta program, which let you update to version 18.12, but it seems like the issue is not fixed yet by Garmin. The bug report is acknowledged by Garmin, but no ETA or additional details are given.

Did you check if there is any request at all coming from the watch, or just the request log on your server side? The HTTPS certificates issue will probably not arrive in your server logs, as it is part of negotiation before the actual connection is made, and thus if it fails, the request has not been sent yet.

I assume your server is accessible remotely, so you might want to check the actual ciphers presented to clients by using a SSL test tool (e.g. SSL labs). Your findings, logs, data etc. are very helpful, as I do not own the watch and thus cannot do any tests directly. Be sure to remove private information from any logs you share here! If you want to share private urls etc. for me to check, please send me a direct message (also through the Connect IQ app -> SubMusic -> Contact Developer option).

[tsipizic]

I made a lot of tests both with SSLlabs and nmap ssl-enum-ciphers and cipher support should not be the case. I enabled SSL debug logs and inspected requests and ciphers on test server requests that arrived. If any requests were dropped on cipher negotiation lately the logs would be there. The bug report on garmin forum seems new while reports of this issue on this project are pretty old. Can I do anything else to debug this?

[memen45]

Did you also check this more recent solution for the SSL ciphers? It is slightly different than suggested in the old #42

There is a more elaborate way to obtain debug logs from the watch itself. First, you have to enable Debugging from the SubMusic Settings > App Settings menu, or from the Connect IQ app on your phone, then on the SubMusic page choose "Settings", then enable Debugging.
The following steps allow you to retrieve the logs from the device:

• attach the watch to a computer as a mass storage device
• create the log file (/GARMIN/APPS/LOGS/DCIG3029.txt)
• detach the watch and open SubMusic Menu
• go to settings and enable debug log
• go back, choose More and then Sync and wait for completion
• attach the watch to a computer as mass storage device
• retrieve the log file!

[memen45]

From on device logs I found that some server worked (Fenix 7x Pro Solar firmware 17.28, last week) and will log the cipher suites below

Test Server 1 ✔️

# TLS 1.3 (suites in server-preferred order)
TLS_AES_128_GCM_SHA256 (0x1301)   ECDH x25519 (eq. 3072 bits RSA)   FS 	128
TLS_AES_256_GCM_SHA384 (0x1302)   ECDH x25519 (eq. 3072 bits RSA)   FS 	256
TLS_CHACHA20_POLY1305_SHA256 (0x1303)   ECDH x25519 (eq. 3072 bits RSA)   FS 	256
# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH x25519 (eq. 3072 bits RSA)   FS 	128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH x25519 (eq. 3072 bits RSA)   FS 	256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)   ECDH x25519 (eq. 3072 bits RSA)   FS

Test Server 2 ❌

# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   ECDH x25519 (eq. 3072 bits RSA)   FS 	128
OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14)   ECDH x25519 (eq. 3072 bits RSA)   FS 	256P
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)   ECDH x25519 (eq. 3072 bits RSA)   FS 	256P
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)   ECDH x25519 (eq. 3072 bits RSA)   FS   WEAK 	128
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)   ECDH x25519 (eq. 3072 bits RSA)   FS 	256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   ECDH x25519 (eq. 3072 bits RSA)   FS   WEAK 	256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)   ECDH x25519 (eq. 3072 bits RSA)   FS   WEAK 	128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)   ECDH x25519 (eq. 3072 bits RSA)   FS   WEAK 	256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH x25519 (eq. 3072 bits RSA)   FS 	128
OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13)   ECDH x25519 (eq. 3072 bits RSA)   FS 	256P
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)   ECDH x25519 (eq. 3072 bits RSA)   FS 	256P
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH x25519 (eq. 3072 bits RSA)   FS   WEAK 	128
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)   WEAK 	128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   WEAK 	128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH x25519 (eq. 3072 bits RSA)   FS 	256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH x25519 (eq. 3072 bits RSA)   FS   WEAK 	256
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)   WEAK 	256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)   WEAK 	256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH x25519 (eq. 3072 bits RSA)   FS   WEAK 	128
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   WEAK 	128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH x25519 (eq. 3072 bits RSA)   FS   WEAK 	256
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)   WEAK

Would be very helpful if you could share your cipher suites, so we can either confirm that in the new firmware version there is a different set of working SSL ciphers, or it has nothing to do with SSL ciphers (i.e. full overlap with the working one as the above, but not working for you). Thanks!

[tsipizic]

Thanks for your continued support during this issue. My certificate was issued by LetsEncrypt using ec256, when I issued another certificate using RSA2048 everything worked. The rest of my cipher configuration comes from Mozilla SSL Configuration Generator using intermediate configuration (TLS1.2 allowed). As far as I am concerned this is a server configuration issue and you can close this.