Home of the Squeezebox™ & Transporter® network music players.
Page 5 of 5 FirstFirst ... 345
Results 41 to 49 of 49
  1. #41
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    421
    Quote Originally Posted by bpa View Post
    I don't know SSL details - at a guess there is something wrong with your certificates.

    Not sure what to so but perhaps I'll read the following it may offer some pointers.

    https://maulwuff.de/research/ssl-debugging.html
    Thank you for your help. I have tried lots of things, such as reinstalling openssl, making sure the correct versions of openssl and c_rehash are being called, reinstalled ca-certificates, etc., nothing has changed. I tried setting qw( SSL_VERIFY_NONE ); but that changed nothing as well. I have tried uninstalling LMS, and reinstalling using the _all.deb and the _amd64.deb versions, and reinstalling perl 5.26.1 and related packages such as libio-socket-ssl-perl all to no effect.

    I cannot get past "Net::SSLeay::connect -> -1" which I assume means "Game Over."

    I don't understand how this happened to begin with. I think I am left with the option of reinstalling Ubuntu from scratch.
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 16.04 + Squeezelite + Material Skin > ifi USB iSilencer > Audirect Beam DAC > Senn IE 80 earbuds
    Bedroom: Pixel 3a Phone + SB Player + Material/mobile > Bose SoundLink Revolve
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 7.9.2
    Music: Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify

  2. #42
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,853
    Quote Originally Posted by Ron F. View Post
    Thank you for your help. I have tried lots of things, such as reinstalling openssl, making sure the correct versions of openssl and c_rehash are being called, reinstalled ca-certificates, etc., nothing has changed.
    .
    .
    I don't understand how this happened to begin with. I think I am left with the option of reinstalling Ubuntu from scratch.
    Unlikely to help.

    Have you tried refresh your certificates
    Code:
    sudo update-ca-certificates --fresh
    Did you see that Learnincurve solved their SSL problem (the reasonfor this thread) by clearing DNS cache.

  3. #43
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    421
    Quote Originally Posted by bpa View Post
    Unlikely to help.

    Have you tried refresh your certificates
    Code:
    sudo update-ca-certificates --fresh
    Did you see that Learnincurve solved their SSL problem (the reasonfor this thread) by clearing DNS cache.
    Yes, I tried both of those things: refresh of ca-certificates, and a flush of DNS cache. No change. Before wiping this system and starting over with a fresh install of Ubuntu, I might try to see if I can see anything using Wireshark. I wonder if anything is going out when doing a domain name lookup.

    I apologize for airing my problem in this thread.
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 16.04 + Squeezelite + Material Skin > ifi USB iSilencer > Audirect Beam DAC > Senn IE 80 earbuds
    Bedroom: Pixel 3a Phone + SB Player + Material/mobile > Bose SoundLink Revolve
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 7.9.2
    Music: Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify

  4. #44
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,853
    Quote Originally Posted by Ron F. View Post
    Yes, I tried both of those things: refresh of ca-certificates, and a flush of DNS cache. No change. Before wiping this system and starting over with a fresh install of Ubuntu, I might try to see if I can see anything using Wireshark. I wonder if anything is going out when doing a domain name lookup.
    I always feel it is better to try to find root cause as often the problem can recur.

    When you used SSL_VERIFY_MODE you used a number value and not a string. Strings were used in older versions of the module.


    I apologize for airing my problem in this thread.
    No problem - it didn't distract fromOP thread.

  5. #45
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    421
    Quote Originally Posted by bpa View Post
    I always feel it is better to try to find root cause as often the problem can recur.

    When you used SSL_VERIFY_MODE you used a number value and not a string. Strings were used in older versions of the module.

    ...
    Thanks bpa, for convincing me to stick with this until I figured out what was going on. After studying the TLS attempts LMS was making using Wireshark, it was apparent that IO:Socket:SSL was simply not finding the ca-certificates. DNS was working, but after that connecting to a server would fail during the startup of TLS. I had ca-certificates properly installed and updated. Openssl could find them so using openssl directly worked fine, but a short PERL script calling IO::Socket::SSL would fail.

    Armed with the knowledge I gained using Wireshark, (an indispensable debugging tool,) and a forum, I found a way around this problem. I created a short script which I placed in /etc/profile.d, (running Ubuntu):

    Code:
    #!/bin/sh
    export SSL_CERT_DIR=/etc/ssl/certs
    Scripts placed in /etc/profile.d are run at boot by root so in this way, I could export the shell var SSL_CERT_DIR to all subsequent processes - including LMS. This works; after rebooting, LMS and plugins began working correctly again. PERL modules could now find where the certificates are kept on Ubuntu: /etc/ssl/certs.

    Why this became necessary I still do not understand and I don't know what the normal mechanism is that PERL uses to find ca-certificates, but this stopgap measure has taken care of my issue for the time being.
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 16.04 + Squeezelite + Material Skin > ifi USB iSilencer > Audirect Beam DAC > Senn IE 80 earbuds
    Bedroom: Pixel 3a Phone + SB Player + Material/mobile > Bose SoundLink Revolve
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 7.9.2
    Music: Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify

  6. #46
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,853
    Good to have an answer.

    As it was I found some more perl ssl tools which were going to be next step. So for the record in case osmebody hasl similar issues.
    https://github.com/noxxi/p5-ssl-tools

    The analyze-ssl.pl - create a lot more tracing which might have helped in this case.

  7. #47
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    397
    Quote Originally Posted by Ron F. View Post
    PERL modules could now find where the certificates are kept on Ubuntu: /etc/ssl/certs.

    Why this became necessary I still do not understand and I don't know what the normal mechanism is that PERL uses to find ca-certificates, but this stopgap measure has taken care of my issue for the time being.
    I wonder what your OpenSSL system directory has inside it. Mine contains a /usr/lib/ssl/certs directory that is a symbolic link to /etc/ssl/certs, which contains the certificates. If yours doesn't do that, then maybe that is the source of the problem.

    FWIW (not much, but you tweaked my interest), on my Debian 'Buster' system:

    IO::Socket::SSL interrogates Net::SSLeay for an OpenSSL system directory, and receives an answer /usr/lib/ssl, to which it appends /certs to yield: /usr/lib/ssl/certs.

    But that will be overridden by the environment variable SSL_CERT_DIR, which you have taken advantage of.

    /usr/lib/ssl/certs is installed and implemented as a symbolic link to /etc/ssl/certs, by the openssl package (version 1.1.1d-0+deb10u2). So that's where we end up looking.

    /etc/ssl/certs is populated by the ca-certificates package (version 20190110).

    Net::SSLeay is provided by the libnet-ssleay-perl package (version 1.85-2+b1).

  8. #48
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    421
    Quote Originally Posted by mrw View Post
    I wonder what your OpenSSL system directory has inside it. Mine contains a /usr/lib/ssl/certs directory that is a symbolic link to /etc/ssl/certs, which contains the certificates. If yours doesn't do that, then maybe that is the source of the problem.

    FWIW (not much, but you tweaked my interest), on my Debian 'Buster' system:

    IO::Socket::SSL interrogates Net::SSLeay for an OpenSSL system directory, and receives an answer /usr/lib/ssl, to which it appends /certs to yield: /usr/lib/ssl/certs.

    But that will be overridden by the environment variable SSL_CERT_DIR, which you have taken advantage of.

    /usr/lib/ssl/certs is installed and implemented as a symbolic link to /etc/ssl/certs, by the openssl package (version 1.1.1d-0+deb10u2). So that's where we end up looking.

    /etc/ssl/certs is populated by the ca-certificates package (version 20190110).

    Net::SSLeay is provided by the libnet-ssleay-perl package (version 1.85-2+b1).
    I checked, and /usr/lib/ssl/certs is installed on my system, (Ubuntu 18.04,) as a symbolic link to /etc/ssl/certs - so that is not the source of the problem; very strange.
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 16.04 + Squeezelite + Material Skin > ifi USB iSilencer > Audirect Beam DAC > Senn IE 80 earbuds
    Bedroom: Pixel 3a Phone + SB Player + Material/mobile > Bose SoundLink Revolve
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 7.9.2
    Music: Personal FLAC, Radio Paradise FLAC, Qobuz, Spotify

  9. #49
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    397
    Quote Originally Posted by Ron F. View Post
    I checked, and /usr/lib/ssl/certs is installed on my system, (Ubuntu 18.04,) as a symbolic link to /etc/ssl/certs - so that is not the source of the problem; very strange.
    Well that's one hypothesis blown away !

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •