SSL/TLS error connecting to network share over FTPS

Help and Support
1

I have the network share configured on a D-link 320 NAS and ports are all set up fine for FTPS.

The network share is reachable remotely without issues using other apps like ES File Explorer and FX File Explorer on Android. Having the same issue on RPi (latest OSMC version) so guessing it’s not an OS issue but more specific to Kodi, and the error 35 has led me to believe the SSL protocol version running on my DNS 320 may be a little outdated, or has something to do with the SSL certificate (something I know very little about.) Log shows it appears to be reachable but just won’t complete the handshake. Hopefully someone here can help.

Key part of the log:

2019-12-20 23:58:[13.854](tel:13854) T:[15659](tel:15659) DEBUG: CGUIMediaWindow::GetDirectory (ftps://USERNAME:[PASSWORD@noz.duckdns.org](mailto:PASSWORD@noz.duckdns.org):[3688](tel:3688)/)
2019-12-20 23:58:[13.854](tel:13854) T:[15659](tel:15659) DEBUG: ParentPath = [sources://video/]
2019-12-20 23:58:[13.855](tel:13855) T:[15722](tel:15722) DEBUG: Thread waiting start, auto delete: false
2019-12-20 23:58:[13.855](tel:13855) T:[15722](tel:15722) DEBUG: CurlFile::Open[(0x7353131700](tel:097353131700)) ftps://USERNAME:[PASSWORD@noz.duckdns.org](mailto:PASSWORD@noz.duckdns.org):[3688](tel:3688)/
2019-12-20 23:58:[13.955](tel:13955) T:[15659](tel:15659) DEBUG: ------ Window Init (DialogBusy.xml) ------
2019-12-20 23:58:[13.958](tel:13958) T:[15722](tel:15722) DEBUG: Curl::Debug - TEXT: Trying [92.14.25.17](http://91.13.25.17)...
2019-12-20 23:58:[13.958](tel:13958) T:[15722](tel:15722) DEBUG: Curl::Debug - TEXT: TCP_NODELAY set
2019-12-20 23:58:[14.154](tel:14154) T:[15722](tel:15722) DEBUG: Curl::Debug - TEXT: Connected to [nooz.duckdns.org](http://noz.duckdns.org) [(91.13.25.17](tel:91132517)) port [3688](tel:3688) (#0)
2019-12-20 23:58:[14.187](tel:14187) T:[15722](tel:15722) DEBUG: Curl::Debug - SSL_DATA_OUT: 
2019-12-20 23:58:[14.187](tel:14187) T:[15722](tel:15722) DEBUG: Curl::Debug - TEXT: TLSv1.2 (OUT), TLS handshake, Client hello (1):
2019-12-20 23:58:[14.188](tel:14188) T:[15722](tel:15722) DEBUG: Curl::Debug - SSL_DATA_OUT: 
2019-12-20 23:58:[14.188](tel:14188) T:[15722](tel:15722) DEBUG: Curl::Debug - SSL_DATA_OUT: �
2019-12-20 23:58:[14.188](tel:14188) T:[15722](tel:15722) DEBUG: Curl::Debug - SSL_DATA_OUT:
2019-12-20 23:58:[14.250](tel:14250) T:[15722](tel:15722) DEBUG: Previous line repeats 2 times.
2019-12-20 23:58:[14.250](tel:14250) T:[15722](tel:15722) DEBUG: Curl::Debug - SSL_DATA_IN: 220--
2019-12-20 23:58:[14.250](tel:14250) T:[15722](tel:15722) DEBUG: Curl::Debug - TEXT: error:[1408](tel:1408)F10B:SSL routines:ssl3_get_record:wrong version number
2019-12-20 23:58:[14.250](tel:14250) T:[15722](tel:15722) ERROR: CCurlFile::FillBuffer - Failed: SSL connect error(35)
2019-12-20 23:58:[14.250](tel:14250) T:[15722](tel:15722) ERROR: CCurlFile::Open failed with code 0 for ftps://USERNAME:[PASSWORD@noz.duckdns.org](mailto:PASSWORD@noz.duckdns.org):[3688](tel:3688)/:
2019-12-20 23:58:[14.250](tel:14250) T:[15722](tel:15722) ERROR: GetDirectory - Error getting ftps://USERNAME:[PASSWORD@noz.duckdns.org](mailto:PASSWORD@noz.duckdns.org):[3688](tel:3688)/
2019-12-20 23:58:[14.251](tel:14251) T:[15722](tel:15722) DEBUG: Thread waiting [15722](tel:15722) terminating
2019-12-20 23:58:[14.262](tel:14262) T:[15659](tel:15659) DEBUG: ------ Window Deinit (DialogBusy.xml) ------
2019-12-20 23:58:[14.265](tel:14265) T:[15659](tel:15659) ERROR: CGUIMediaWindow::GetDirectory(ftps://USERNAME:[PASSWORD@noz.duckdns.org](mailto:PASSWORD@noz.duckdns.org):[3688](tel:3688)/) failed
2

Hi,

Looks like a know issue for kodi 18:

Workarounds are suggest in the issue.

Thanks Tom.

3

Hi Tom thanks for this.

So going by the suggested solutions in that thread I added |auth=TLS&verifypeer=false to my source’s path and changed ftps to just ftp at the start, which allowed the handshake to apparently complete successfully.

I don’t think that Kodi is very happy with the cert provided by my NAS however, judging by the log.

And more unfortunately, the network share I’ve created for the user account I’m logging in with does not appear. I just get a blank list with the two dots to go up a directory level.

So some progress, but still not there. Appreciate any further suggestions on this, thanks.

Relevant portion of log hastebin

Also just to note I’m now trying to sort this locally before trying the remote connection.

4

Hi,

I think your going to have issues with the cert provided by dlink. Suggestions install a proper ssl, from letsencyrpt for example, but this will require having a domain name.

Alternatively use plain ftp or another protocol such as nfs.

Regards Tom.

5

Is it really impossible just to accept the cert provided already?

I don’t own a domain and the D-link is not capable of installing a new SSL. NFS is not an option for remote connection iirc and I would prefer not to use unencrypted FTP.

6

Hi,

https://kodi.wiki/view/SSL_certificates

You could try adding the dlinks ssl to the trust store, but wiki also advises:

2.2 Server identity

Verifying the server name in the certificate against the host being connected to is always enabled and cannot be disabled. You have to be careful to ensure that the hostname you enter in Kodi (e.g. as part of an URL or in file source settings) matches the name on the certificate. Otherwise you will get errors similar to SSL: certificate subject name 'xy' does not match target host name 'real.host.name' in your log and connections will fail. For technical details on the check, see (via CURLOPT_SSL_VERIFYHOST.

Thanks Tom.

7

I’m already getting that error shown in the log so not sure how adding D-link SSL to the trust store will fix this.

2019-12-21 14:39:08.710 T:19606   DEBUG: Curl::Debug - TEXT: SSL: certificate subject name '2.84.22.99' does not match target host name '192.168.1.13'
2019-12-21 14:39:08.710 T:19606   DEBUG: Curl::Debug - TEXT: Closing connection 0

I’m struggling to understand how some basic Android apps will connect without issue, but Kodi is incapable of connecting.

Is there really no other solution?

8

HI,

Just tried this with my syno and I couldn’t get kodi to accept the ca-cert. I’m assuming kodi has decided that ssls with domain mismatch are as insecure self signed. If you must use an encrypted ftp the only thing I can suggest is mounting locally with something like curlftpfs.

But I would consider just using plain ftp, is will be easier to setup and in a secure private network there are no security concerns for being unencrypted.

Thanks Tom.

10

This connection is intended for remote access using RPi and therefore should really include some level of encryption.

I don’t know anything of curlftpfs or if this would be useful in this scenario?

11

You can mount FTP (and FTPS should also work) via fstab or autofs. Or if your NAS supports SSHFS you could also do that.

I don’t have time right now, but when I get home from work tonight I can give you some ideas of how to configure it.

But before I do that, can you from an OSMC command line make the FTPS connection to the NAS?

12

Well my recommendation when reading “remote access” is always to go for a VPN solution

14

This sounds like it might work, as long as the cert mismatch issue can be avoided.

I couldn’t help but look into this more and I’ve managed to install curlftpfs on the RPi.

Using info from here and here I have attempted connecting but is not going too well - probably a mistake on my part.

I have made a mountpoint at /mnt/ftp

Trying to connect via command line (credentials omitted here)

curlftpfs 192.168.1.13:3688 /mnt/ftp/ -o ssl,no_verify_peer,no_verify_hostname,user=USER:PASS,allow_other

returns this

fusermount: user has no write access to mountpoint /mnt/ftp

I feel this solution is very close to working. I will wait for further advice now, thanks.

15

Hi Richy,

Sorry forgot the private ip was just for test. Anyway I think this shoud work:

sudo curlftpfs --verbose -o ssl,no_verify_peer,no_verify_hostname,user=admin:password,allow_other ftp://192.168.1.13:3688 /mnt/ftp

If it does we can then look at mounting via fstab or autofs.

Thanks Tom.

16

SUCCESS!!

Here is the SSH log:

osmc@osmc:~$ sudo curlftpfs --verbose -o ssl,no_verify_peer,no_verify_hostname,user=admin:password,allow_other ftp://192.168.1.13:3688 /mnt/ftp
* Couldn't find host 192.168.1.13 in the .netrc file; using defaults
*   Trying 192.168.1.13...
* TCP_NODELAY set
* Connected to 192.168.1.13 (192.168.1.13) port 3688 (#0)
< 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
< 220-You are user number 1 of 10 allowed.
< 220-Local time is now 21:05. Server port: 3688.
< 220-IPv6 connections are also welcome on this server.
< 220 You will be disconnected after 10 minutes of inactivity.
> AUTH SSL
< 500 This security scheme is not implemented
> AUTH TLS
< 234 AUTH TLS OK.
* found 151 certificates in /etc/ssl/certs/ca-certificates.crt
* found 604 certificates in /etc/ssl/certs
* SSL connection using TLS1.0 / RSA_AES_256_CBC_SHA1
*        server certificate verification SKIPPED
*        server certificate status verification SKIPPED
*        common name: 2.84.22.99 (does not match '192.168.1.13')
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=US,ST=D-LINK,L=US,O=D-LINK,CN=2.84.22.99
*        start date: Fri, 20 Dec 2019 17:58:25 GMT
*        expire date: Sun, 20 Dec 2020 17:58:25 GMT
*        issuer: C=US,ST=D-LINK,L=US,O=D-LINK,CN=2.84.22.99
*        compression: NULL
> USER admin
< 331 User admin OK. Password required
> PASS password
< 230 OK. Current restricted directory is /
> PBSZ 0
< 200 PBSZ=0
> PROT P
< 200 Data protection level set to "private"
> PWD
< 257 "/" is your current location
* Entry path is '/'
* ftp_perform ends with SECONDARY: 0
* Remembering we are in dir ""
* Connection #0 to host 192.168.1.13 left intact

Can sort the fstab or autofs now (not sure what autofs is though). I can’t check whether the remote connection is working until I’m at another access point away from my network, unless there is another simple way. I can just switch out the server address and it should work anyway.

17

HI,

Autofs is an alternative to fstab and has a better recovery if the network drops, unfortunately not be unable to get autofs working though. More success with FSTAB though:

curlftpfs#USER:PASS@192.168.1.13:3688 /mnt/ftp fuse ssl,no_verify_peer,no_verify_hostname,allow_other,x-systemd.automount,noauto 0 0

Once you your switched the ip and remounted or rebooted you can:

ls /mnt/ftp

If the ftp shares show, then their should be no issue adding them to kodi.

Thanks Tom.

18

I’ve thought about this some, and I’d suggest using sshfs with autofs. I recommend autofs because it handle network interruptions better than fstab, and sshfs because I’ve used it and now it better :wink: However, since fstab is easier to setup, lets do it that way first and get it working, then we can switch to autofs.

sudo apt install sshfs

Now, with sshfs installed, the best way to setup credentials is by using your ssh keys. For this example, my NAS only allows root to ssh in, so if your’s allows other users, please use another user (or best, create a osmc user if allowed).

ssh-copy-id root@davros.local

You will be prompted for your password. Once that’s done try to ssh in and you should not be prompted for a password. Once that’s working, create the directory in /mnt or /media where you will be mounting.

Now, add this to your fstab:

root@YOUR.NAS.IP.ADDR:/<SHAREMOUNTPOINT> /mnt/<MOUNTPOINT> fuse.sshfs x-systemd.automount,noauto,rw,follow_symlinks,user,identityfile=/home/osmc/.ssh/id_rsa,allow_other,default_permissions,uid=1000,gid=1000 0 0

If you were able to use osmc user, replace root with osmc. Of course is the path to the share as seen by the user when SSHed in. Notice the identityfile part: that handles the credentials for you.

A word of warning, on my NAS, it uses symlinks for mounts. For example, my drives all show under /share (on the NAS), but are actually symlinks. SSHFS will not allow you to mount a symlink, so if you have /share/drive1 and it’s a symlink you can’t mount it. You can only mount /share. But once mounted you can access drive1. For me, it’s not an issue, as once mounted you can still access everything and add the sources. In fact, it’s nice as you only have one mount to the NAS for all the various available mounts. And if you add a new mount, it’s there without having to change your fstab.

Ok, so now that you’ve created the mountpoint and edited fstab, try the mount:

sudo mount /mnt/<MOUNTPOINT>

if that works, you’ve got it! Then we can work on getting autofs working.

If it doesn’t, let me know and we can try and figure out why.

19

Thank you for this but unfortunately my DNS 320 does not support SSH, at least not without significant modifications (by installing “fun_plug”) which are too cumbersome in my circumstances. It would also involve my NAS hard drives being wiped of all data which is not happening.
Hopefully this alternative (better?) method will help someone though.
Sorry I should have made this clearer beforehand.

20

I’ve been testing the fstab FTP mount with some videos this morning just to see how it copes and some not so great news.

The video I’m testing with it about 6GB so not that massive. The video can take from 30 seconds up to a minute to begin playback (not a huge problem) but after about 1 minute the video will freeze playing (as if buffering, but no buffering dialogue shows) and it never seems to catch-up and resume playback.

Im using an old RPi B+ but even still it should have no issues here? I’ve played larger files over SMB and NFS using WiFi with no issues. And currently this is being tested over Ethernet.

I tried tweaking the video cache a little higher (30mb and 40mb from default 20mb) but same issue.

To troubleshoot a little more I mounted the same FTP on my Vero 4K+ and played the same video but even it had issues, stuttering after ~3 mins and never resuming smooth playback again.

Any thoughts on how to resolve this?

UPDATE:
Testing with another setup to try and pin the issues down. This time I connect on Android tablet with FX Explorer and streaming with VLC player - flawless playback, zero skipping or buffering issues playing over 10 minutes now.

21

Hi,

Can you please provide debug logs from both the pi & vero4k:

Thanks Tom.

22

I have some logs from the RPi to start with.

  1. with following settings
<buffermode>1</buffermode>
<memorysize>20971520</memorysize>
<readfactor>2</readfactor>

https://paste.kodi.tv/cobisozaso.kodi

  1. with only buffermode setting

<buffermode>1</buffermode>

https://paste.kodi.tv/upibugixur.kodi

  1. with no cache settings modified

https://paste.kodi.tv/haviculete.kodi

Video file is named

Stan & Ollie 2018 BDRip 1080p AAC 5.1.mp4

Not sure what’s the issue but now I can’t seem to even get playback starting at all in some cases.