Client no more able to get a license after switching to FlexNet v11.16

[EricBrunel]

Hello all,

We've been a Flexera customer for quite some time now, we've been upgrading regularly and have been using up to version 11.5 without any issue. We've recently purchased support for Linux 64 bits on the client and the files provided to us were for version 11.16. After updating the file lm_code.h with the provided information, plus adding back the "LM seeds" and the "encryption keys" from the lm_code.h file we were using up to v11.5, the build went OK. But after building the client, it seems it is not able to contact the existing license server (still in v11.5). When an attempt is made, nothing appears in the debug log for the server, and the client gets an error message:

No such feature exists.
Feature: xxx
License path: @192.168.2.102:
FlexNet Licensing error:-5,412. System Error: 2 "No such file or directory"

After digging a little, we realized that even if Flexera obviously knew us (the vendor name hasn't changed and the confirmation email actually lists all the platforms we have purchased), the "vendor keys" provided in their latest email were different from the ones we were using up to version v11.5. Could this be the origin of the issue? We tried to rebuild the client part using the former vendor keys, but the build fails with an error:

Upgrading from v7.2 TRL, using SIGN2= for more security
lc_init failed: Invalid key data supplied.
FlexNet Licensing error:-44,49

So we're a bit stuck for now, as our new client wouldn't be able to connect to existing license servers…

Any hint on what can be happening and on how to solve this issue?

Thanks.

[Aparashar]

Hi Eric,

The reported behavior is expected, because we have changed the way clients were SIGNED (using older lm_code.h - i believe a different VENDOR_KEYS and you may also have played a bit with LM_STRENGTH/TRL keys value)) and 11.16 server (where you have bought support for Linux (so i suspecting the lm_code.h) files to be changed.

As a thumb rule (all information related with lm_code.h):

If LM_STRENGTH and LM_SEEDS values are same (between client and server lm_code.h files), then communication in between server (built with new VENDOR_KEYS and TRL keys) and Client application (built with old VENDOR_KEYS and TRL_KEYS) should not be an issue.

If LM_SEED s are changed : Error -33,376 : Bad Encryption handshake with vendor daemon.
if LM_STRENGTH is changed: Error -8,544: Invalid (inconsistent) license key.

Regards,
Abhay

[EricBrunel]

Hello Abhay and thanks a lot for your answer,

I had indeed changed the value of LM_STRENGTH, which was LM_STRENGTH_DEFAULT in the former lm_code.h, and which I had set to LM_STRENGTH_163BIT in the new one since we had purchased TRL and it was advised to do so in Flexera's confirmation email. Besides, setting LM_STRENGTH to LM_STRENGTH_DEFAULT when TRL keys are specified made the default build fail.

So I set back LM_STRENGTH to LM_STRENGTH_DEFAULT and rebuilt everything with the environment variable FLEXLM_NO_TRL set to 1. The build worked fine, with only a warning saying that TRL was purchased, but not enabled.

Sadly, this didn't change the behavior in any way: I'm still getting an error -5,412 when I try to check out a license.

There's something that made me wonder in your answer though: you say that with the same LM_SEEDs and LM_STRENTGH, a client built with the old keys should be able to communicate with a server built with the new keys. But I'm actually trying to do the opposite here: my Linux 64 bits client is built with the new keys, and I'd like it to be able to communicate with a server/vendor daemon built with the old keys, as there are servers already installed by customers. Is this supposed to work too?

Thanks again.

Regards.
- Eric -

[Aparashar]

Hello Eric,

Error "-5" is LM_NOFEATURE . It seems either the feature you are requesting is not being served by the server. Can you check again?

Also, when you mentioned "" - did you mean LM_SEEDs and LM_STRENTGH? If so, then it won't work. This is like a catch 22 , in which if you choose adding the TRL or changing the seeds/LM_STRANGTH (to add more security), we loose the backward compatibility. There is a section in document advising about it.

If a TRL-enabled application attempts either to communicate with a non-TRL vendor daemon or to authenticate a non-TRL license, an error message is displayed and the application does not run. The error message informs you that either the license file and/or the vendor daemon is not TRL compliant.

It’s important to remember that the TRL application itself is the trigger that requires both TRL licenses and a TRL-enabled vendor daemon in order to run. If your previous FlexNet Publisher toolkit (that includes client application, vendor daemon and license generation tool) was built with LM_STRENGTH set to LM_STRENGTH_DEFAULT ( in machind/lm_code.h), then it is not possible to upgrade to TRL. The upgraded server and the licenses will not work with older clients that were built with LM_STRENGTH_DEFAULT.

If your previous toolkit was built with LM_STRENGTH set to LM_STRENGTH_LICENSE_KEY, you can perform a partial migration which maintains backward compatibility with older clients.

In document "FNP_Programming Referance for License File based Licensing.pdf", the chapter -9 " License Signature Configurations" talks in details about it. Please refer to Table-9.1 and the following details (Added the document library with this chat page). It should help, if not just revert back.

Regards,
Abhay

[EricBrunel]

Hello Abhay, and thanks again for your answer,

Aparashar wrote:
Error "-5" is LM_NOFEATURE . It seems either the feature you are requesting is not being served by the server. Can you check again?

I did check, and not only the feature appears in the license file on the server, but Linux 32 bits clients using the client library built with the licensing toolkit v11.5 are able to connect to the server without any problem and to check-out the license.

Aparashar wrote:
If a TRL-enabled application attempts either to communicate with a non-TRL vendor daemon or to authenticate a non-TRL license, an error message is displayed and the application does not run. The error message informs you that either the license file and/or the vendor daemon is not TRL compliant.

That is what I suspected indeed, thanks for confirming it. Though there are still things I can't understand:

• The error message doesn't say anything about TRL, so it seems to be some other kind of issue that prevents the client from checking out a license. The full message says "No such file or directory", but I don't have any clue about what file or directory is missing. Is there any way to figure that out?
  
• I redid the whole build explicitely disabling TRL: I set both TRL keys to 0x0, used the exact same LM_SEEDs than in v11.5 and the same LM_STRENGTH, i.e LM_STRENGTH_DEFAULT. So now, I basically have the same contents of lm_code.h in v11.16 than in v11.5, except for the VENDOR_KEYs, that have changed. I thought that by doing that, I would turn TRL off and that my client would be able to connect to the existing servers. But it doesn't help, I'm getting the same error message.
  

Aparashar wrote:
In document "FNP_Programming Referance for License File based Licensing.pdf", the chapter -9 " License Signature Configurations" talks in details about it. Please refer to Table-9.1 and the following details (Added the document library with this chat page). It should help, if not just revert back.

I looked in that document, but my configuration is not even listed in the table: I have ENCRYPTION_SEEDs set, LM_SEEDs set, TRL_KEYs not set and LM_STRENGTH to DEFAULT. So this looks like Config 1, but with ENCRYPTION_SEEDs set. So is there any way that it can work?
And what do you mean exactly by "revert back"? I tried to look for FlexNet Publisher v11.5 in the Release Archives on the Flexera website, but it seems it is not available anymore, and the versions before 11.12 don't seem to have a Linux 64 bits version anyway. Do I have more chances to make it work if I use v11.12?

Thank you again.

Regards.
- Eric -