Server License issue vs Wireless Network ConnectionSolved

Dear LimeLm support,Some of our customers that updated the license to the version 4.0.7 have problems with the license server checking.The problem occurs only on their laptops.

If the Wireless Network Connection is disabled our program fails to start due to some license checking.

After enabling the Wireless Network Connection, the problem is solved and our program will get a license from the license server. When they disable the Wireless Network Connection again, it will keep working fine.

It seems that LimeLm needs Wireless Network connection one time to write something to an unknown file or registry?

For security reasons, Wireless Network Connection disables automatically when connecting to the LAN.

For them, it is not an option to enable the wireless network connection even if it is one time.Because the problem occurs only with Wireless Network Connection, their desktops work fine.Previous versions 2.1 of LimeLm did not have this problem.I hope you have a solution for this issue.Thanks in advance.Kind regards,

Use the latest version of TurboActivate currently that's 4.0.9.6. It fixes a number of issues related to network adapters being disabled, and on Windows 8.0 and newer it doesn't even require network adapters to be enabled. Old versions of Windows (Windows 7 and older) will need to enable network adapters once in a while.

Covered here: https://wyday.com/limelm/help/faq/#disabled-adapters

Latest version of TA: https://wyday.com/limelm/api/#turboactivate

Changes in latest TA: https://wyday.com/limelm/api/ta-changes/

The customers use the network license. If we update only the turbo activate, does that cause an issue in communication between the client and server machine which is using 4.07.1 ?

Are you saying youre using TurboFloat? If so, 4.0.7 is an old version for TurboFloat as well. Have them update the TurboFloat Server and make sure your app uses the latest version of the TurboFloat Library.

We gave the customer a turbo activate license to limit the issue on client side only, one machine. Now with the latest turbo activate version. Here is the recap for his testing, our product is an add-in inside another program;

"There are currently two problems we are facing.A. Problem 1: After installing the product, it needs to be enabled. (NOT LICENSED PRODUCT) 1. PRE-ACTIVATION: I must enable the product. This is important because below is the glitch.2. GLITCH: As soon as we enable the product, network adapter gets Disabled. (It doesnt matter if we are on Wi-Fi or Ethernet.) 3. ACTIVATING: How am I supposed to activate without an active Ethernet interface? Well since I am sort of tech-savvy, I can go and manually re-enable the network adapter that was just disabled by the above glitch. (Wi-Fi or Ethernet, I still need to manually re-enable)

B. Problem 2: POST-ACTIVATION; 1. NETWORK LICENSE: Wi-Fi adapter always gets disabled. Not Ethernet. This part is important because your previous build and the new build doesnt seem to affect anything POST-ACTIVATION with an Ethernet connection. This is IMPORANT! I tested this on a laptop and was able to verify that after plugging the laptop with an Ethernet connection, the Add-in would ONLY DISABLE WIFI!In the simplest terms;1. Problem 1: Non-Activated product will always disable your primary working Ethernet interface.2. Problem 2: POST-ACTIVATION. Once the product gets activated and if you have a network license, an Ethernet connection WILL WORK! Once the product gets activated and if you have a network license, Wi-FI connection WILL NOT WORK! This is important because any laptop will not be able to this product due to this glitch. a. Keep in mind that this only affects Network License with a Wi-Fi connection. If you have an Internet License with a Wi-Fi connection, this is not an issue."

Also, running as administrator is a workaround, not a solution. Users dont have the option running as administrator.

Still, the question remains why it doesnt work if Wireless Network connection is disabled?Another problem is that the License manager is not backward compatible.Employees with the old version installed cant use the new version anymore.

Regards,

A lot more information is needed. Start with the basics:

1. Are you using TurboActivate or TurboFloat?

2. What version of TurboActivate or TurboFloat are you using? If it's not the latest, do that before doing anything else. There's absolutely no reason you should waste your time or we should waste our time tracking down bugs that have already been fixed. It sounds like you're using an old version (from the problem the customer is describing)

3. What operating system is the customer running on?

>> "Another problem is that the License manager is not backward compatible."

The TurboFloat Server? Yes, it is. Use the latest version and it supports all old versions of the TurboFloat Library.

TurboActivate? Yes, it is as well. It fully supports all old activations and upgrades them to the latest format.

TurboActivate is not *forwards* compatible (meaning old versions of TA cannot understand *new* formats). But that's a given. We cannot go back in time and program our old versions to learn how to read the new formats.

>> "Still, the question remains why it doesnt work if Wireless Network connection is disabled?"

It doesn't on modern Windows. On modern Windows (8, 8.1, and 10) you can disable all network adapters and everything will just work. On ancient Windows (7, Vista, XP) network adapters must be enabled *briefly* so TurboActivate can accurately "fingerprint" the computer.

Again, this is covered in our FAQ because it's a frequently asked question: https://wyday.com/limelm/help/faq/#disabled-adapters

1. Are you using TurboActivate or TurboFloat? We are using the TurboActivate.

2. What version of TurboActivate or TurboFloat are you using? Turbo activate the latest version 4.0.9.6

Concerning the above issue: Please download and check the customer video recording of the wireless network disabling problem. The customer system is windows 7 SP1 latest.drive.google.com/open?id=0B8mBPf2BH50oT01UWkVUcW8td3M

Important Note: It does happen the same problem with turboFloat.

Please give us an explanation for the above issue than we will discuss the other issues once this problem is fixed

Regards

That video doesn't give a whole lot of information. It looks like they have a version of your plugin that is using an old version of TurboActivate. Why? Because the latest version of TurboActivate doesn't disable network adapters. There was a bug in an old version of the 4.0 branch of TurboActivate that did that. But that was fixed.

Downloading the latest version of TurboActivate is just the first step. You also need to include it in your app. So, please, dig into the customer's installation and make sure they're using the latest version of your plugin, and make sure the latest version of your plugin is using the latest version of TurboActivate.

Also, are you using the static version of dynamic version of TurboActivate?

For your information, the latest version of TurboActivate also disables network adapters. And that video the customer sent before he tries again with the latest version, but just forwarded to you in order to be able to get a hint from it if possible, but the issue STILL exists.

We are using the latest TurboActivate, dynamic version.

Theres not enough information. We cant reproduce this here.

We can remotely debug the customers problem. Shoot me an email at wyatt@wyday.com with the customers info and information about where I can find your product and the TurboActivate.dll on the customers computer.

OK, we will contact the customer and let you know the possibility to schedule with him a meeting to check the issue.

Thank you.

Solved over the phone. Like I suspected they were using an old version of the TurboFloat library.

Anyone that is experiencing issues should first update the version of the TurboActivate or TurboFloat Library. You can find the latest version here: https://wyday.com/limelm/api/