[Ancaritha]

Awesome, thanks!

[Ancaritha]

Ok, thanks for the info.  Our support contract is currently expired and we were going to wait a few months to make sure that our year of support fell within when VS 2022 was released and any VisualGDB updates that had to be made were done but maybe we’ll just update now and hope for the best 🙂

[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 🙂

[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).

[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).

[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]

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]

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]

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()

[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.

[Ancaritha]

I run into this problem quite frequently as well.  I’m always using the “Start debugger with GDB” option from inside Visual Studios.  I sometimes get that error when I haven’t even set any break points yet.  Usually I just hit stop and then “start debugger” again and it works fine, but on occasion I’ve had to flash the entire chip using the ST-Link Utility and then it’ll work.

I was running a year old version of OpenOCD, which I just updated to the latest.  I’m hoping that’s the issue but knowing about that “info breakpoints” command might be useful, see if there is somehow a disconnect between what Visual Studios thinks it has for breakpoints vs what GDB thinks it has.

[Ancaritha]

For the time being I’ve updated the project I’m working on to use the touch in our repository I’ve added but that echo idea might be worth looking into just so I can remove external dependencies.  It might take some work to get right if I ever have to touch more than one file.  We haven’t had to do that on more recent projects but it’s always a possibility that the need for it might pop up again.  I suppose I could probably just be lazy and make multiple ‘echo’ lines in the makefile 🙂

 

Thanks!

[Ancaritha]

One of our source files, contain the GCC commands __DATE and __TIME__.  These only get updated when the file is changed (which makes sense, otherwise it’s not building it).  Since this is a low level file that we seldom change, we need a way to force GCC to rebuild it to get the updated date and time.  That’s what we use touch for.  It fills in a variable that we can access over our communication system to get the buildstamp for the code running on a device.  We can also display it on the system UI and whatnot.

Making a binaries folder somewhere in our source tree and storing touch there is probably the easiest solution; don’t have to modify the system PATH file or do any extra weird copies when setting up a new computer that could be easy to miss/forget about or install antiquated toolchains.

Touch does actually rely on 2 other files in the toolchain (libicon2.dll and libintl3.dll), but those are both also in the toolchain /bin directories so they’re easy to get.

Thanks!

[Ancaritha]

It would appear that the incorrect target configuration file is being selected.  The “Debugged Device” drop down list just has the STM32L0xx option, which selects target/stm32l0.cfg

According to OpenOCD, approximately 2 years ago a patch was merged that makes it so now dual bank devices (such as the L07x) need to use a new configuration file, stm32l0_dual_bank.cfg.  When I manually switch to that file by modifying the command line options, it programs fine.

[Ancaritha]

I opened a ticket with OpenOCD and posted basically the same information I posted here.  If I hear back anything interesting I’ll update this thread so you guys are made aware of it as well.

 

Thanks!

[Author]

Posts