July 24, 2020 at 14:14 #28785
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.July 25, 2020 at 08:36 #28787
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.July 27, 2020 at 07:43 #28791
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.July 27, 2020 at 07:47 #28792July 27, 2020 at 08:10 #28794
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: 18.104.22.16842
—————— 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()July 27, 2020 at 08:22 #28795
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:C++1var 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.July 27, 2020 at 08:23 #28796
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.July 27, 2020 at 08:35 #28797
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!July 27, 2020 at 08:50 #28798
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.July 30, 2020 at 08:30 #28821
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).July 30, 2020 at 08:38 #28823
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.July 30, 2020 at 10:56 #28825
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).July 30, 2020 at 21:50 #28828
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.July 31, 2020 at 10:25 #28834
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 🙂
You must be logged in to reply to this topic.