Kodi Community Forum

Full Version: Need help with https media source
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hello,

I have my media behind a https server. Recently I upgraded it to centos 6 and for some reason it can't seem to find the server anymore.

Code:
00:47:30 T:140711540799584 M:6297362432   DEBUG: CFileCurl::GetMimeType - https://example.com/ -> failed
00:47:30 T:140711540799584 M:6297362432   DEBUG: FileCurl::Open(0x7fff4b4a1870) https://example.com/
00:47:30 T:140711540799584 M:6297362432 WARNING: FillBuffer: curl failed with code 35
00:47:30 T:140711540799584 M:6297362432   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
00:47:30 T:140711540799584 M:6297362432   ERROR: GetDirectory - Unable to get http directory
00:47:30 T:140711540799584 M:6297362432   DEBUG: FileCurl::Close(0x7fff4b4a1870) https://example.com/
00:47:30 T:140711540799584 M:6297362432   ERROR: GetDirectory - Error getting https://example.com/

I'm familiar with setting up web servers so I'm pretty sure my configuration is sound, then again the only thing that changed was my server.

the error, "curl failed with code 35" looks odd. According to their docs (http://curl.haxx.se/libcurl/c/libcurl-errors.html), that error means there's something up with the ssl. Googling the error doesn't come up with much. One reference to an FTPS/XBMC problem and then a bunch of pastebin's. The address works perfectly fine inside of firefox and chrome. The ssl cert is a self-signed certificate so using curl on the command line will barf unless you instruct curl to ignore

If anyone has some pointers then please let me know.

PS. I did check and the certificate is not expired. it's valid except for the self-signed part. This was working before so I'm not sure why it isn't.

Does anyone know how to tell xbmc to not try and validate the certs on an ssl site? That would be really helpful.
Please try append the auth method to use (eg. https://example.com?auth=anysafe). Possible values are any, anysafe, digest and ntlm.
vdrfan Wrote:Please try append the auth method to use (eg. https://example.com?auth=anysafe). Possible values are any, anysafe, digest and ntlm.

same error:


Code:
02:11:38 T:139748328929376 M:6355566592   DEBUG: FileCurl::Open(0x7fff8a5cab70) https://example.com/?auth=anysafe
02:11:39 T:139748328929376 M:6355566592 WARNING: FillBuffer: curl failed with code 35
02:11:39 T:139748328929376 M:6355566592   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
02:11:39 T:139748328929376 M:6355566592   ERROR: GetDirectory - Unable to get http directory
I tried to append ?auth=any as well, but same error message. Any other suggestions?
Please enable full debug logging (loglevel 3) via advancedsettings.xml and check the curl output in xbmc.log. See http://wiki.xbmc.org/index.php?title=Adv...oglevel.3E for more information.
The curl error is now, "gnutls_handshake() failed: A TLS warning alert has been received"

Code:
11:17:57 T:140209914521696 M:1831546880    INFO: easy_aquire - Created session to https://example.com
11:17:57 T:140209914521696 M:1831546880   DEBUG: Curl::Debug About to connect() to example.com port 443 (#0)
11:17:57 T:140209914521696 M:1831546880   DEBUG: Curl::Debug   Trying xxx.xxx.xxx.xxx...
11:17:57 T:140209914521696 M:1831546880   DEBUG: Curl::Debug connected
11:17:57 T:140209914521696 M:1831546880   DEBUG: Curl::Debug Connected to example.com (xxx.xxx.xxx.xxx) port 443 (#0)
11:17:57 T:140209914521696 M:1831563264   DEBUG: Curl::Debug found 157 certificates in /etc/ssl/certs/ca-certificates.crt
11:17:57 T:140209914521696 M:1831563264   DEBUG: Curl::Debug gnutls_handshake() failed: A TLS warning alert has been received.
11:17:57 T:140209914521696 M:1831563264   DEBUG: Curl::Debug Closing connection #0
11:17:57 T:140209914521696 M:1831309312   DEBUG: Curl::Debug SSL connect error
11:17:57 T:140209914521696 M:1831309312   DEBUG: CFileCurl::GetMimeType - https://username:[email protected]:443/media/ -> failed
11:17:57 T:140209914521696 M:1831309312   DEBUG: FileCurl::Open(0x7ffffa91f5b0) https://example.com:443/media/
11:17:57 T:140209914521696 M:1831309312   DEBUG: Curl::Debug About to connect() to example.com port 443 (#0)
11:17:57 T:140209914521696 M:1831309312   DEBUG: Curl::Debug   Trying xxx.xxx.xxx.xxx...
11:17:57 T:140209914521696 M:1831309312   DEBUG: Curl::Debug Connected to example.com (xxx.xxx.xxx.xxx) port 443 (#0)
11:17:57 T:140209914521696 M:1831309312   DEBUG: Curl::Debug found 157 certificates in /etc/ssl/certs/ca-certificates.crt
11:17:57 T:140209914521696 M:1831309312   DEBUG: Curl::Debug gnutls_handshake() failed: A TLS warning alert has been received.
11:17:57 T:140209914521696 M:1831309312   DEBUG: Curl::Debug Closing connection #0
11:17:57 T:140209914521696 M:1831309312 WARNING: FillBuffer: curl failed with code 35
11:17:57 T:140209914521696 M:1831309312   ERROR: CFileCurl::CReadState::Open, didn't get any data from stream.
11:17:57 T:140209914521696 M:1831309312   ERROR: GetDirectory - Unable to get http directory
11:17:57 T:140209914521696 M:1831309312   DEBUG: FileCurl::Close(0x7ffffa91f5b0) https://example.com:443/media/
11:17:57 T:140209914521696 M:1831309312   ERROR: GetDirectory - Error getting https://username:[email protected]:443/media/


My google-fu is coming up with a couple of interesting links, mainly this one:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559371

They talk about a similar error and in message #59, a fix is suggested by downgrading libcurl3-gnutls. In the following message a libcurl developer says that a regression was fixed in version 7.21.7 of libcurl. I'm running a current version of ubuntu and it's still at 7.21.6-3ubuntu3.

Could this be the issue? I'm no developer... but I'm going to try to be one anyway. If I run "ldd /usr/bin/xbmc" it tells me, "not a dynamic executable". So it's static and thus not using my libraries, correct? If that's the case, then maybe the ubuntu package was built using a bum version of libcurl? When I get some more time I'm going to try and use an older version of XBMC or a nightly and see if it's just a bug with 10.1.
latest stable ubuntu package of libcurl4-gnutls-dev is 7.21.6-3ubuntu3, so xbmc has probably been built with this.

You can get a newer version of that and build xbmc from git to see if it makes a difference.
rebuilt the latest nightly with an updated libcurl (from debian's sid) and still the same error occurs:


Code:
$ dpkg -l | grep curl
ii  curl                                                        7.23.1-2                                Get a file from an HTTP, HTTPS or FTP server
ii  libcurl3                                                    7.23.1-2                                Multi-protocol file transfer library (OpenSSL)
ii  libcurl3-gnutls                                             7.23.1-2                                Multi-protocol file transfer library (GnuTLS)
ii  libcurl4-gnutls-dev                                         7.23.1-2                                Development files and documentation for libcurl (GnuTLS)

Poking around the code I found where it's setting the curl options and it's not verifying anything which is good (in file ./xbmc/filesystem/FileCurl.cpp):

Code:
// never verify peer, we don't have any certificates to do this
  g_curlInterface.easy_setopt(h, CURLOPT_SSL_VERIFYPEER, 0);
  g_curlInterface.easy_setopt(h, CURLOPT_SSL_VERIFYHOST, 0);


I'm starting to believe that I'm missing something really obvious. Don't you hate it when it's probably something really simple and I jumped WAY past it now and I'm digging through xbmc's source code. xbmc has to be okay in that everything worked before, the only difference is an upgrade from centos 5.x to centos 6. That's a big jump though, lots of new packages... but running a straight up http+mod_ssl server should be fairly straightforward these days.

If anyone has some pointers I'm open to any other suggestions.

--Ajay
FYI, I fixed the problem. And it's one of those unsatisfying fixes in that I don't know the exact culprit. I dumped my http config and started over. First got a basic http server up, then added in the ssl stuff, then added in the settings for what I needed. Testing each step along the way. And in the end it worked fine. So I must've screwed up my apache config during the upgrade. Thanks for your help.
Glad to hear it is working now.
Just had the same problem and managed to SOLVE it.

It had to do with the SSL.
I generated a new SSL for the server with the server FQDN in the certificate.
Also I changed the ServerName entry under the VirtualHost directive from localhost to the same FQDN as I user to access the server and that I defined in the certificate.

Hope this helps.