Cannot Connect to Server - Windows 11 Home, Windows 10 Home, macOS 4.6,Answered

We are experiencing the same problem. customers cannot activate or deactivate any licenses on Windows 10 and Windows 11 but works fine on Linux (x64) and MacOS (11.5.2). 

With many customers running our existing version built with the static libs, I’m puzzled as to how this suddenly stopped working for them with no advanced warning. Something broke over the last few days that was working perfectly fine. Customers with live systems running are seriously affected. 

Hi, I am Facing the same problem of “Connection to the server failed” is anyone has a solution for that. Thanks

Wyatt, it worked fine a week ago. This change just affected our users this weekend. I appreciate your references to blog posts and change logs but up until this past few days nothing affected us. If you are informing me that we need to update to the latest API that’s fine. But as commercial software developers we now have to tell our customers to upgrade immediately. It’s less than a satisfactory as some of these customers are serious enterprise users that have to plan these upgrades. clearly something changed on the license servers As nothing in the clients have been touched. 

Wyatt, as developers we understand the need to keep current and that you can't guarantee support for versions from a decade ago.

As evidenced by the multiple reports from your customers all now saying that something changed just within the past week, can you be more specific in identifying what specifically changed on your side, or elsewhere, in this past week that is affecting all of us?

Do we know exactly what problem needs to be solved? If it is something on your side that is incorrect or even just a configuration option that is addressable there, this could save thousands of us from forcing hundreds of thousands of our end user customers to update their software.

What change made this past week could have had such a big impact that my new customers can't activate their software. Do you know with certainty that updating our software to the latest version of TA will fix it?

Thanks.

[…] can you be more specific in identifying what specifically changed on your side, or elsewhere, in this past week that is affecting all of us?

#post-23603

https://wyday.com/blog/2021/limelm-price-changes-and-stricter-web-api/
 

Disable access over HTTP. Disable old TLS versions.
 

Do you know with certainty that updating our software to the latest version of TA will fix it?

Yes.

Wyatt, I was never emailed about those changes that you mention in that blog post, hence the problems we are now facing. 

I am not disagreeing with anything you say, however it seems that removing HTTP GET support has broken all products that used the older TA API. Upgrading to a newer version is not the issue. The issue is that we have to force existing customers to upgrade immediately without any prior warning.

The reason some customers do not upgrade may be based on their financial situation, others it may be that they have to go through and QA their applications written in our products. 

Offline activation of software running as servers in docker containers is not very practical.

A grace period for HTTP and GET of 90 days would have been much more palatable.

Thanks.

We don’t email about TA versions currently. We will in the future. Not a high priority.

Always integrate latest TA into your app to prevent any interruptions in the future.

Hi Wyatt. Besides all the conversation here, I do not think it's February 1 yet anywhere in the world. So you're at least not going by your word in the blog post. 

It seems there are two issue here. One is the API POST/GET discussed in the blog post, the other is that it seems that as of yesterday versions of TurboActivate prior to v4.0.2 released September 3rd 2016 can no longer contact the activations servers (both Windows/Mac, presumably linux). We didn't update to a version 4.x until January 2020. The previous versions worked just fine, our priorities were elsewhere, and there was no suggestion that previous versions of TA would suddenly stop working in the future. So we have a lot of users running older versions of our software that are suddenly going to be faced with loss of activation and the need to update. Or do i misunderstand something ? 

Seriously?? We didn't update our TActivate for a long time, ok, but not to be warned by you (and no, we didn't read your blog, we have a lot of other tasks to complete) is a shame, and now we have to migrate quickly 10 different software. It will break all our development schedule, it will break the release promised to our customers, etc… Our customers cannot activate their license bought recently, they may ask a refund! The good way to proceed is to send an email to your customers, this is a minimum communication to do!

Please restore any working previous version, and let your customers (the software editors) have more time to upgrade!!

I agree with Lauren. I'm completely shut down for new business it appears, and have to tell customers who have paid for the software that it can't be activated or used. Not knowing how long it will take me to implement, test and distribute updated versions for the five versions of my software means I have to offer refunds. If there's any way to restore to the previous version and give us a grace period to implement the required changes to TA that would be very helpful. Thanks.

Use offline activation as a stop-gap (see above).

The newest TA is binary compatible with old versions with 2 function removals in the last decade and a half. So, if you’re using those 2 long-deprecated functions then, yes, you’ll need to compile your app.

If not, just drop in the new dll.

Wyatt, As i mentioned previously, you can't use offline activation for server and docker components that use TA. Additionally any use of older static libs is broken. We had customers complaining last night. Medical insurance, logistics and others. TA is not just used for small applications some enterprise customers rely on it. As it is, our only solution was to write a console application that uses the new API and allows customers to validate using that. We worked all weekend on that caused by this breaking change to our product delivery. Any use of the Community Edition of our products is completely broken until we release new versions of our products. We have upgraded to the latest API now for our next release which is imminent. Please have more empathy for customers that rely on your service just as we have customers that rely on ours. 

I'm sure you are busy just like the rest of us but this whole fiasco could have been avoided with some better communication and a 90 grace period advanced warning that the old API is deprecated and will be removed. That way we could have scheduled the work to upgrade it into our development work.

Thanks.

Thanks Barry & Garry. Lesson for Wyday: the other providers we have (i.e, cloud providers), are sending at least two emails before a major change: one 6 months before, the other one month before the doom's day, and more often a third email the previous day.

Just yesterday, I had to explain to a potential big partner that they cannot use our software because of the license.. What an impact on our image! And a possible loss of this partnership.. 

"The newest TA is binary compatible with old versions with 2 function removals in the last decade and a half. So, if you’re using those 2 long-deprecated functions then, yes, you’ll need to compile your app."

=> which functions? Could you be more clear??

"If not, just drop in the new dll."

=> 90% of our customers don't know what is a dll, nor don't know how to copy a file in hidden folder as you can have on MacOS. 

I can see where you are coming from. You see it as a sudden change with no communication. If in the future we disable access we will send emails in addition to the other methods we used to communicate this change.

To re-iterate: we see this change as inevitable and warned about for the last 6 years of security updates to TurboActivate. Just because we warn about using an insecure version and it “still works” does not mean you should still use it.

We will not be reenabling insecure communication methods. See above for how to fix this or how to workaround in the meantime.

And more than that, a  whole in the security doesn't mean : “stop all the customers” !

You could reenabling the “insecure" for at least one-two months, to support correctly your customers.

“See above for how to fix this or how to workaround in the meantime.” Where exactly? Please publish a whole complete article + link to get it. We don't want to spend any minutes to search your solution.

“See above for how to fix this or how to workaround in the meantime.” Where exactly?

#post-23603

The stopgap until you upgrade TA: offline activation.

Thanks for the quick reply. The offline activation is not a solution: the end-user must download + install the software, then generate a file and send it to us. 90% will not do it, specially our prospects that will find it very weird to use such a complex process to be able to use our software. Our users are very basic end users..

More than that, if the security “hole” exists for several years, you can take the risk (and your customers too), to let it for 2 months more, no? You will take the risk to have unsatisfied customers also, (and we're 12 year customer old!).

More than that, if the security “hole” exists for several years, you can take the risk (and your customers too), to let it for 2 months more, no?

No. From #post-23603

We hang in to old standards and practices as long as (securely) possible. And when we can no longer do it securely we flip the switch.

In our product, we have some buttons linked to a property of the license.

Even with a registered license, we discovered today that we cannot have access to the feature linked to this button anymore!!! Does it mean there is an internet access each time we try to use thsi button through an access to your server, and not just an access to the local file containing the properties of the license?

Not unless you programmed it that way.

No, TA_GetFeatureValue() does not touch the internet.

It sounds like in addition to letting dependencies of your app get out of date, your developers also made a number of other errors. Talk to them and have them fix the many mistakes they made.

A question for you Wyatt re “just drop in the new dll.”

To fix this problem do we just need to rebundle/redistribute our existing apps  with the updated Turboactivate.dll (and TurboActivate.exe) file(s) or do we also need to also change our code?

I'm a one man show with several apps in Xojo, and used your RealBasic (now Xojo) sample code back in 2014 to do a completely vanilla implementation of LimeLm with Fastspring. I have no knowledge or expertise in how to use or revise the LimeLM code on my own. Can I just update the .dll and .exe files in my distribution bundle or is new code required in Xojo? If new code is required, does the Realbasic/Xojo sample code have all the required updates?

Thanks!

I can't speak for Wyatt, but in theory your app loads the .dll at runtime.  If most of the function signatures are the same from the previous dll you can theoretically overwrite the .dll and your app's code that calls on the function in the DLL should work.  In this case, you would not need to re-build your app.  However, if there are breaking changes in the new DLL the code in your app would likely need to be rebuilt and then deployed to your users.  This is one advantage of using dynamically linked libs instead of static libs.  With static libs, they get built (baked) into your apps code, but with dynamically linked libs they are only called upon runtime.  So, the DLL can change without concern with the calling app's codebase.

You said : “your developers also make a number of other errors.”

The code was  simple like this, after a click on a button:

string strDeploy = TurboActivate.GetFeatureValue("deployment");

What could be the error in the code?

After starting to migrate, we discovered that the API has changed: where is the new SetCustomTurboActivateFile()? Do you have the changelog between the 3.3 and the recent 4.4? Where is the list of the functions who disappear /appear?

The static class TurboActivate is no more static.. Another surprise of the migration process.

Another surprise, the signature of the GetPKey() has changed totally..Need to reimplement, another workload for the migration process.

Do you have the changelog between the 3.3 and the recent 4.4?

Yes, linked to above. Also in the API page. Here’s the direct link again:

https://wyday.com/limelm/api/ta-changes/

Since it’s been years since you’ve updated, you’ll have a lot of changes to wade through.

Hi Wyatt. Please answer this:

1) Re “just drop in the new dll,” will rebundling our existing apps  with the updated Turboactivate.dll file fix the problem if using pre 4.x releases of Turboactivate or do we need to change our code too?

2) Your TurboActivate for Windows download includes a \API\Xojo (Real Basic) folder with a RealBasic.rbp sample program and an “Import to your project” folder with Xojo code files. Has this Xojo sample program and Xojo code for import been updated to work with the latest release of TurboActivate?

Thanks.

1) Re “just drop in the new dll,” will rebundling our existing apps  with the updated Turboactivate.dll file fix the problem if using pre 4.x releases of Turboactivate or do we need to change our code too?
 

It depends. See if you’re using deprecated or removed functions. If so, then, no. If not, then yes.

The safest option is to use the latest integration files and follow the latest example code and use the latest TA.

Has this Xojo sample program and Xojo code for import been updated to work with the latest release of TurboActivate?

Yes.

GetPKey(): nothing concerning the signature change in your page. Nor about SetCustomTurboActivateFile disappearance. Don't be surprised to have customers that don't upgrade, because migration from 3. to 4 is a undocumented mess.

Where is the documentation of the API of TA with each signature of each function and its description? We didn't find in the zip file TurboActivate.zip 4.4 nor on your web site.

TurboActivate.h contains all function definitions, parameters used, error codes with full descriptions, etc., etc., Same as it always has been.

GetPKey(): nothing concerning the signature change in your page.

Don't know what you're talking about. Your version is more than a decade old, but even still I can't remember us ever changing it.

Nor about SetCustomTurboActivateFile disappearance.

Ditto. The function looks unfamiliar. Did we have it decade ago? Who knows. If we did you're the only person to ever use it.

Or maybe it was an internal function used inappropriately. Again, who knows. And it's beside the point.

It's clear there isn't binary compatibility between the version more than a decade ago and now. Use the latest TA_* functions instead.

There's a reason it's in the FAQ: it's a very well-documented process.

GetPKey(): nothing concerning the signature change in your page, for 10 years, in all your change logs. So, no excuse, nor the other SetCustomTurboActivateFile(), despite the fact your change log lists all the changes from the beginning.

The reason why we didn't migrate, and there was no 10 years gap as you said, it's precisely because some functions have disappeared/undocumented the last time we tried, and it was between the 3.3 and the 4.0.

The API doc in .h or TurboActivates.cs ? Do you mean this simple line is a documentation? 

the public static extern int TA_GetPKey(UInt32 handle, StringBuilder lpPKeyStr, int cchPKey);

*Got it, found in the .h but please note that a C# developer don't have to look, nor reason to look at a .h file to find documentation… With modern tool, you can generate a document in .chm or PDF format that contains your API.

Take example of this software editor in terms of documentation: https://docs.unity3d.com/ScriptReference/Application.LoadLevel.html

What is the parameter uint32_t handle of the TA_IsProductKeyValid() function? the GUID of the license?

In your doc/.h, there is no explanation

  Possible return codes: TA_OK, TA_FAIL, TA_E_INVALID_HANDLE
*/
TURBOACTIVATE_API HRESULT TA_CC TA_IsProductKeyValid(uint32_t handle);

GUIDMismatchException has disappeared also. And never found / listed in your changelog webpage.

API\C\TurboActivate.h

and there was no 10 years gap as you said,

v3.3.3 — February 28, 2013

ok… 9 years.

What is the parameter uint32_t handle of the TA_IsProductKeyValid() function? the GUID of the license?

You don’t need that function.

See the examples. And docs.

On MacOs  11.x or later, is the libTurboActivate.dylib already signed by you? We are unable to load it in our Editor because of the Apple standard Warning dialog like “Impossible to open libTurboActivate” because Apple cannot verify if it contains malware. This software must be updated". The current version we're using is the last one 4.4.

On MacOs  11.x or later, is the libTurboActivate.dylib already signed by you?

No.

All the function in the TurboActivate.cs are found correctly now, except this one: PDetsFromPath() , under MacOs with the .dylib

from this simple source:

TA = new TurboActivate( Sport.cst_strGUID_PRODUCT );
TA.PDetsFromPath("../TurboActivate/");
bActivated = TA.IsActivated();

Leads to error:

error CS1061: 'TurboActivate' does not contain a definition for 'PDetsFromPath' and no accessible extension method 'PDetsFromPath'

We have found this function in your doc about MacOs 

"TurboActivate loads the "TurboActivate.dat" file from the same directory as the executable. If you want to load the "TurboActivate.dat" file from a directory other than the one the executable's path, then use the TA_PDetsFromPath() function."

The PDetsFromPath can be found also in the TurboActivate.cs

Any idea?

Correct. See the constructor for the TurboActivate object in C#:

/// <summary>Creates a TurboActivate object instance.</summary>
/// <param name="vGUID">The GUID for this product version. This is found on the LimeLM site on the version overview.</param>
/// <param name="pdetsFilename">The absolute location to the TurboActivate.dat file on the disk.</param>
public TurboActivate(string vGUID, string pdetsFilename = null)

I'm experiencing the same “TurboActive failed to connect to the activation servers” errors from my new customers. This has been a thorn in my side as a non-technical business owner because everything worked just fine for years, and then it suddenly doesn't. The software that I sell isn't my livelihood, but it provides some supplemental income for my family. I guess if I want to get back to where I was before this change took place, I'll have to hire a new engineer to figure this out for me, which means I'm out more money on top of what I'm already paying for LimeLM. Or I close shop and then TWO companies are losing money.

Updating TurboActivate is covered in our FAQ.

I wanted to share a success story on this update. I'm an independent developer and use a very vanilla version of LimeLM / TurboActivate with two apps that I developed in Xojo. Following Wyatt's recommendation, I simply cut the old TurboActivate code from my apps and replaced it with the updated version that is provided in the current TurboActivate downloads, along with the updated TurboActivate dll file for Windows and dylib file for Mac.

My app on Mac then generated an error “Insufficient system permission. Either start your process as an admin / elevated user or call the function again with the TF_USER flag.” By poking around the LimeLM forum I found a recommendation to change references in the LimeLM code to TA_USER from TA_SYSTEM. I did that in the five places of LimeLM's vanilla code that I had in my app and it then worked flawlessly.

I'd not updated my apps since 2014 and 2018. I of course had a number of other updates to do on other platforms and processes to have versions ready for customer distribution on both Windows and Mac, but it's all working now fine with the updated version of TurboActivate .

In hindsight, better direct advance notice from WyDay would have helped a lot. For my side, I'll plan on doing an annual update to ALL of the platforms my apps rely upon to assure that I'm dealing with minor maintenance issues and keeping current in my knowledge rather than skating by with years of ease/complacency while all my technology partners are continually enhancing their solutions.

Non-technical/layperson question: I'm working frantically trying to support my new customers who are running into the “connection to the server failed” error. I'm fine with supporting the offline activation method until I can get my developer to update my software. How do instruct my customers on getting the activation request XML file? Note that my clients are generally non-technical as well.

It depends. Covered here: https://wyday.com/forum/t/5137/cannot-connect-to-server-windows-11-home-windows-10-home-macos-4-6/#post-23603