I can not update my KiwiSDR to the latest software version [git + https problem, workaround added]

edited December 2017 in Problems Now Fixed
My receiver works with version 1.46 and I can not update it to a more current version like version 1.151.
I tried to force the update via the admin interface, the system answers "checking" and I get no update, if I look at the log I can read:

Thu Nov 30 09:54:59 2017 0:10:07 .... UPDATE: version 1.46 is current
Thu Nov 30 09:54:59 2017 0:10:07 .... update_task task: P2: T19 exited by returning

I also tried to log into ssh and tried to send the following commands:


These commands have been executed by the system but have no effect on the version.
What is happening ? Can I find a newer image than 1.46?
Any advice will be welcome.


  • jksjks
    edited November 2017
    Hi. I responded to the email you also sent. This can be be caused by a number of things:

    DNS name server(s) not being setup properly in /etc/resolv.conf by DHCP. When you ssh into the Beagle can you get a response typing "ping google.com"?

    A full filesystem (do a "df" command and see). Possibly caused by too many crash dump files in /tmp. Are there a bunch of files in /tmp called beginning with "core". Remove them with "cd /tmp; rm core*"

    I think this will work on v1.46: See if the Makefile updates from Github in preparation for the build. Do "cdp; make git". Now "more Makefile". The second line in the file should now say "VERSION_MIN = 151". If it doesn't there is a problem downloading files. If it works see if you can build without getting any errors: "make; make install".

  • jksjks
    edited December 2017
    The next release will have a workaround for this issue. But Charles and I are stumped by the root cause of the problem. Maybe some of you GNU TLS experts can help us out. If you do this on his Kiwi Beagle you get this error: (note the "https")

    fatal: unable to access 'https://github.com/jks-prv/Beagle_SDR_GPS.git/': gnutls_handshake() failed: The TLS connection was non-properly terminated.

    But this works: (note the use of "git" protocol)
    git pull -v git://github.com/jks-prv/Beagle_SDR_GPS.git

    More confusingly, you can use a browser on the same local network, or curl on the Beagle, to access the https url with no problems. So it seems it's related to GNU TLS specifically and not TLS in general (like whatever TLS is used in the browser/curl).

    Similarly, doing a "apt-get update" will eventually fail when one of the fetches uses https.

    Charles said he's not aware of any https proxy servers in the path that might be causing trouble. I'm wondering if there could be something in his router or something his ISP is doing.

    Some Googling caused me to install the gnutls package on the Beagle and run a "gnutls-cli-debug github.com" (see https://www.osso.nl/blog/git-gnutls-handshake-failed-nginx-ciphers). This worked fine on other Kiwi Beagles, but here each check output line took minutes to respond. So something is definitely wrong. Apologies in advance for my lack of knowledge about these security issues.

    Output from a working Beagle:
    root@kiwisdr:~/Beagle_SDR_GPS# gnutls-cli-debug github.com
    Resolving 'github.com'...
    Connecting to ''...
    Checking for SSL 3.0 support... no
    Checking whether %COMPAT is required... no
    Checking for TLS 1.0 support... no
    Checking for TLS 1.1 support... no
    Checking fallback from TLS 1.1 to... failed
    Checking for TLS 1.2 support... no
    Checking whether we need to disable TLS 1.0... N/A
    Checking for Safe renegotiation support... no
    Checking for Safe renegotiation support (SCSV)... no
    Checking for HTTPS server name... not checked
    Checking for version rollback bug in RSA PMS... yes
    Checking for version rollback bug in Client Hello... yes
    Checking whether the server ignores the RSA PMS version... no
    Checking whether the server can accept Hello Extensions... no
    Checking whether the server can accept cipher suites not in SSL 3.0 spec... no
    Checking whether the server can accept a bogus TLS record version in the client hello... no
    Checking for certificate information... N/A
    Checking for trusted CAs... N/A
    Checking whether the server understands TLS closure alerts... no
    Checking whether the server supports session resumption... no
    Checking for export-grade ciphersuite support... no
    Checking RSA-export ciphersuite info... N/A
    Checking for anonymous authentication support... no
    Checking anonymous Diffie-Hellman group info... N/A
    Checking for ephemeral Diffie-Hellman support... no
    Checking ephemeral Diffie-Hellman group info... N/A
    Checking for AES cipher support (TLS extension)... yes
    Checking for CAMELLIA cipher support (TLS extension)... no
    Checking for 3DES cipher support... no
    Checking for ARCFOUR 128 cipher support... no
    Checking for ARCFOUR 40 cipher support... no
    Checking for MD5 MAC support... no
    Checking for SHA1 MAC support... yes
    Checking for max record size (TLS extension)... no
    Checking for OpenPGP authentication support (TLS extension)... no

Sign In or Register to comment.