Network adaptater for floating license

Here is their network adapter Window:https://imgur.com/a/VPgQV

>> "1- This is the floating license, which is using TurboFloat.dll and not TurboActivate.dll, why does it check the network adapter at all ?"

Network adapters are needed as part of the fingerprint of the computer.

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

More information is needed.

1. What version of TurboFloat are you using? If it's not the very latest version, then do that first. We continually update TurboActivate, TurboFloat, etc. with fixes and features. Get the latest version here: https://wyday.com/limelm/api/#turbofloat

2. What version of Windows is the customer using (it looks like Windows 7, but again -- just a guess -- information is needed). Also, what's the architecture of the Windows build (32-bit or 64-bit)

1. What version of TurboFloat are you using?

TurboFloat.dll 4.0.9.6TurboFloatServer.exe 4.0.9.7

2. What version of Windows is the customer using ?

win7 64bit

What is the next step ?

Hi,We sent you an e-mail as this is taking too much time for this (once again) network adapter problem solving and the client is loosing his patience.You really should enhance this part of LimeLm and at least provide an exhaustive documentation of what could be done to help troubleshoot this situation. In a few months we've been bitten by this problem far too often. Customers rightfully do not like licensing problems and the whole product suffers when that happens: bad reviews, refunds...

Hey Jon,

I've responded to your email with a much more detailed next step for this specific customer.

For the vast majority of the cases where customers get that error, it's because they've disabled adapters and are using an old version of Windows. The FAQ gives them multiple options for resolving the errors.

See:

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

If that doesn't work either the customer is lying, or the customer is running old versions of our software, your software, Windows software, or driver software for the network adapters.

So,

1. Update our software to the latest version. (We fix bugs all the time. It's not useful to waste your customers time, your time, or our time to report bug without first trying the latest version of our software).

2. Update Windows. If possible tell them to update to the latest version of Windows (namely, Windows 10). If that's not possible have them *at least* update their old version of Windows to include the latest updates. You'd be surprised how many customers don't do that (and then get bitten by it).

3. Update their drivers for their network adapters. Drivers are software too and drivers have bugs just like every other piece of software.

If after doing *all* that (yes, every bit of it), and they're *still* getting that error, then we'll actually dig into it further and see if TurboActivate or TurboFloat are making a mistake (i.e. a bug in our software).

In this case (more details in the email I sent you) TurboFloat is acting correctly. The customer really does have 2 network adapters being disabled. Except the customer is disabling them in a way that make them invisible to themselves (but not to Windows, TA, or TF).

Answered by e-mail.To sum-up: this network adapter problem is too frequent and we have lost a large amount of time with multiple customers due to this.We've already followed all the publicly available steps (as well as other steps privately shared by e-mail earlier) before contacting you.Searching this forum show that this happens frequently enough and I hope future LimeLm updates will better handle or at least report about this problem to save time for all parties involved.I'll keep you posted by e-mail about this specific customer and hope you'll be able to provide fast replies next time we're in contact.

>> "Searching this forum show that this happens frequently enough and I hope future LimeLm updates will better handle or at least report about this problem to save time for all parties involved."

It did more when TA 4.0.0 was released (i.e. the first of the 4.0 branch). Mainly because customers were doing crazy things that our testing machines weren't configured to do. Which is to be expected. Computers are complicated and customers are even more complicated, so it follows that a customer will configure a computer to do some crazy things.

Since 4.0.1 release we've had *18* publicly released new versions of TurboActivate. And I'd say about half of them worked around odd and unexpected user behavior related to them disabling network adapters.

And we've continually improved our documentation (the FAQ specifically) to include more information on how to fix their configuration (and why it's important in the first place).

My point is that you can find forum posts that predate releases that have fixed the problems that the customer is reporting. But that's not really a useful indication of anything other than we've had reports of TA inaccurately reporting that network adapters have been disabled, and in cases where that was actually the case (i.e. where there was a bug in TA) we've fixed the bug.

---

We've had 0 reports of TA 4.0.9.6 (the current publicly released version that has been out for 5 months) about the "network adapters disabled" error that have panned out to be a bug. Every case (this one included) from customers using 4.0.9.6 has been TA behaving correctly (namely, reporting accurately that the customer has disabled a network adapter).

Now, in your most recent email you wrote that we should include more logging or information about how to fix these errors for customers who do really nutty stuff (like your particular customer who has disabled 2 network adapters, but also somehow hidden them from their own view, despite them still being visible in the device manager and visible to programs running on the machine).

I agree, we should write a small utility program that helps end-user discover / workaround their own misconfigurations. It has been talked about here behind the scenes and it's something that's been on the back burner for a while.

Now it just becomes a question of priorities. Right now our priorities are getting TA 4.1 out and getting the new LimeLM interface out.