Since upgrading to V3, I’m getting a small percentage of users getting this message who weren’t getting it in V2. All of them have their systems set to auto-sync their system time. Was the tolerance tightened up in V3? Is there anything I can do on my end? I’ve tried setting the matching strategy to loose, but for a few users that doesn’t seem to help.
Hi,
Setting matching strategy to loose, doesn’t affect time, it only allows for weaker fingerprints.
Are you referring to LA_E_TIME status code ?
Which OS is being affected?
Is server sync enabled for licenses?
Server sync is enabled, and yes it’s the LA_E_TIME error. 64 bit Windows, though I’m not sure which specific version (have asked the customer).
Also, unrelated, but your “chat with an agent” bubble sits directly on top of the “next page” arrow when trying to browse the event logs, licenses, etc.
Can you specify the browser and screen resolution?
The only known reason this error could occur is when system time is incorrect. It allows for 60 seconds time skew.
Could that be doubled? Or quadrupled? I’m ok with a user having a couple of extra minutes of use on my dime if it means half the number of support tickets.
For the other issue, it was Mac / Safari… would need to check actual resolution, but a standard desktop.
That won’t help as time can be skewed with a larger amount too on the user machine. Please ask your customer to check the time on internet and see if it matches the local time. Usually in dual boots the time gets skewed by a larger amount on one of the operating systems.
We are planning to allow for controlling the allowed time offset from dashboard for the licenses.
Did the error occurred on ActivateLicense() function or IsLicenseGenuine() function.
Which function is returning LA_E_TIME?
That I couldn’t tell you without adding more instrumenting in my code.
I’m assuming IsLicenseGenuine() because I only have SetProductData() and SetProductId() before that.
Can you confirm it didn’t happen with ActivateLicense ().
The library stores the most recent timestamp if it is greater than previous timestamp. This happens every time IsLicenseGenuine() succeeds. If user changes the time on machine to a previous time, LA_E_TIME is returned. They may have correct time to begin with, but they might be changing time later. Latest time commit on any machine must not be less than current time.
Yes, we are working on it. You will be able to control it through dashboard.
As a temporary fix, your customers may need to re-activate when they see this issue.
The problem is not due to difference in internet and local time (it would have returned LA_E_TIME at the time of activation in that case). The users most probably changed the time after first activation, which caused the time tampering prevention algo to return LA_E_TIME error. Since local time can no more be trusted a reactivation is needed.
I’ve asked - with the other users who’ve experienced the issue, they have not touched their time. Has the system changed dramatically between V2 and V3?
For the net and local time the difference is same as 60 secs in both. But for time tampering detection it was changed from 1 day to 60 secs. We are increasing it to slightly more than an hour which would suffice.
We have released LexActivator 3.1.0. Please update the library, header file and status codes file.
← Back to all topics · 20 posts · 5490 views · opened 2018-08-03
