Wrong path for GCC in VisualGDB Manage Packages

[Ancaritha]

I’m trying to update my ARM toolchain via VisualGDB Packages and the URL for GCC 9.3.1/8.3.1/r1 is incorrect?  I try to download it and it fails with a 404 error.  I copy and pasted the address into my web browser and it also got a 404 error.  I went to the VisualGDB downloads page (https://gnutoolchains.com/download/) and the link on that page for GCC 9.3.1 does not match what the VisualGDB package manager is telling me.

This is where the Package manager is telling me to go: http://sysprogs.com/getfile/1086/arm-eabi-gcc9.3.1.exe

This is where the downloads page says to go: http://sysprogs.com/getfile/1136/arm-eabi-gcc9.3.1.exe

Since this page automatically updates, I feel like this is a server side issue not a client side issue.  I did just update my STM32 Devices and OpenOCD packages to the latest versions without any incident.

 

I’m running VisualGDB 5.4R12 and Visual Studios 2012 just in case that is somehow relevant.

[support]

Hi,

This looks like some cached paths were not updated correctly. Please try reopening the Tools->VisualGDB->Manage VisualGDB Packages window and switch to the Online view.

You can also try deleting the %LOCALAPPDATA%\VisualGDB\PackageCatalog.xml file to make sure it definitely gets re-downloaded when switching to the Online view.

[Ancaritha]

Well, switching to the Online view results in an error message popup that says “The request was aborted: Could not create SSL/TLS secure channel.”  Deleted the PackageCatalog.xml just makes it think I have the latest installed 🙂

 

That sounds an awful lot like something got borked in my installation, so a good old fashioned uninstall/reinstall seems in order.  I figured I’d post the error anyway just in case you guys had seen this before and knew exactly what had to be changed to fix it.

[support]

It actually looks like your firewall or antivirus is preventing VisualGDB from downloading the latest package catalog. Please double-check your settings and make sure VisualGDB is allowed to access https://visualgdb.com/ and https://sysprogs.com/.

[Ancaritha]

I just whitelisted *.visualgdb.com and it still doesn’t work.  Are there any specific sub domains that need to be whitelisted?  I know to download the GCC package I couldn’t just do *.sysprogs.com, I had to specifically do us.cdn.sysprogs.com (though I suspect *.*.sysprogs.com would have worked).  Our firewall kept pegging the GCC download as a Trojan and would prevent it from being downloaded (it’s done this back since version GCC 5 or 6 I think).

 

I did just briefly disable our Geo-IP filter and out Gateway Anti-Virus completely and it still failed.  I checked another developers computer and it failed for them as well, so at least it’s not something that’s just on my computer.   I’m going to poke around on the firewall a bit more and see if there is any other filtering happening that I don’t remember about.

 

The full exception text is:

VisualGDB version: 5.4.112.3242
—————— System.Net.WebException ——————
System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
at System.Net.WebClient.DownloadData(Uri address)
at System.Net.WebClient.DownloadData(String address)
at kx1.b(Boolean b, Boolean a)
at VisualGDB.GUI.WPF.PackageListDataObject.FetchThreadBody()

[support]

Sorry, it’s hard to suggest anything specific, as the problem is happening on the network level and not on the VisualGDB level.

You can try reproducing the problem by creating a basic C# program with this code:

var str = new WebClient().DownloadString("https://visualgdb.com/hwsupport/catalog?version=latest");

Also make sure that the VisualGDB proxy server settings are not set to something incorrect.

[Ancaritha]

Fun fact, I just hopped on the WiFi of another company that we share a space with (they used to be part of us and I help administrate things on their network from time to time) and it also failed on their network.  They also have a SonicWall firewall (though a different model) but everything that’s configured on it is totally different than ours and they have a different ISP.  It’s possible that SonicWall pushed some sort of update that is flagging this connection erroneously as something bad which means other people might also run into this problem.  My VisualGDB packages did have a version of GCC 9.3 available for download, just not the latest so it was working until somewhat recently.

[Ancaritha]

Yup, local C# program throws the same error.  However, I can just click on the link and get the text that it returns.  I can even get it inside of Visual Studios and it formats it as XML automatically for me.  For some reason I just can’t create an SSL connection to it.  I’ll have to poke around on the firewall and see if I can figure out exactly what’s causing that as I can obviously visit the link fine, I just can’t create an SSL connection to it…

 

Thanks for providing the direct link so I have something to test against.  Worst case scenario, in the short term I can at least copy the text and create my own PackageCatalog.xml file 🙂  Thanks!

[Ancaritha]

Ok, I still don’t know exactly where the issue lies, because while it could be a firewall issue it could also be a Windows Update issue causing older version of security protocols to become obsolete.  I suppose it could even be a back-end update on your website that would break older versions of VisualGDB, but I suspect there would be a lot more complaints on the forums if that were the case.

 

This code fails:

WebClient webClient = new WebClient();
string sData = webClient.DownloadString("https://visualgdb.com/hwsupport/catalog?version=latest");

 

This code succeeds:

WebClient webClient = new WebClient();
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
sData = webClient.DownloadString("https://visualgdb.com/hwsupport/catalog?version=latest");

Tls12 is only available starting in .Net framework 4.5 (along with Tls11, which I also tried and it failed).  3.5 and 4 only have Tls available.

[Ancaritha]

So, I’ve determined that this is not a firewall problem, as my laptop fails both at home and at work.  I believe it has to do with what Windows decides to use as the default level of Tls encryption for .Net applications that do not specifically specify it.

Using the initial provided C# code, my work laptop fails to connect and throws the cannot create socket error.  Using Fiddler, I can see that it’s making the connection request using Tls 1.0.  I tested my laptop on my home network and got the same results.  I tested my brand new home computer, and it worked, creating the Tls connection at 1.2.  I tested my older home computer and it failed, creating the Tls connection at 1.0.  All three machines are running Windows 10, version 1909 but only my new home computer is a fresh 1909 install, the others were upgrades from prior versions.

However, I’m not certain that the Windows information is completely relevant (though it might be, so I included it).  My laptop failed to make the connection when I created the project using Visual Studios 2012, which is what we use as our primary development platform.  I do however have Visual Studios 2019 installed (which is what my new home computer uses), so I decided create a project in that.  Using the exact same code, it succeeds.  I then checked if VisualGDB->Manage Packages works correct in VS2019, and it does.  My old home computer is running Visual Studios 2017 and that fails.

So, here’s what I think:

VisualGDB’s website was updated to require Tls 1.2 connections somewhat recently.
VisualGDB’s connection string does not specify a level of Tls.
If a Tls level is not provided by the application, Visual Studios will use a default level.  Older versions (VS2012 and VS2017) default to 1.0, which will fail.  VS2019 uses 1.2 and will thus succeed.

If I am correct, then everyone using an older version of Visual Studios should be encountering this problem.  Fortunately we have a work around such that we can install VS2019 and update packages that way.  Since they store the information in the VisualGDB folder, older versions of VS will see the updated package information as well.  Future versions of VisualGDB should probably enforce a minimum tls level on their connection strings, so this will resolve the issue for people using older versions of VS without having to do any work around (again, this is assuming that my above assumptions are correct).

[support]

Sorry, we have a large set of integration tests that is run on 32-bit and 64-bit Windows 7 and Windows 10 using VS2008, 2010, 2012, 2013, 2015, 2017 and 2019, and they do not trigger the issue.

It looks like something is broken with a specific laptop, so our best advice would be to reinstall Windows there.

[Ancaritha]

This is actually happening on every computer I’ve tried that’s running Visual Studios 2012 (right now that’s 4) and a 5th computer that is running Visual Studios 2017.  Tonight I can install 2012 on my home computer and test it there.  That has a very fresh windows install (2 months old) so shouldn’t have anything else interfering.

I’m assuming integration testing is done before releases.  If that is the case, then this definitely would have passed, as that would have occurred back before the 5.4R12 release in July of 2019 and this broke only within the last few months.  I’m curious if the same tests would pass now (using that code, not the 5.5 preview code).

[support]

OK, thanks for confirming this. We have rechecked everything again and confirmed the problem.

Turns out, the issue was caused by a recent update on our server that was not yet caught by our integration tests (we run the full set of tests before each preview release, such as v5.5 Preview 5). The daily infrastructure tests run on the latest VS2019 and hence didn’t catch this either.

Sorry for being skeptical about it – we had previously encountered very similar errors caused by client-side antivirus software trying to hijack SSL connections without properly installing new root certificates, and another case where it was caused by broken group policy, so it looked like another instance of that problem. Either way, we have fixed the issue on our server and also updated the infrastructure tests to check for it, so it shouldn’t happen again.

[Ancaritha]

Hey no worries, just glad I could help!  Weird certificate/security stuff could very easily be caused by firewalls and anti-virus and that’s the first place I went to look too 🙂

[Author]

Posts