This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- FlexNet Publisher
- :
- FlexNet Publisher Forum
- :
- Re: Checkout broken feature returns -18 LM_NOSERVSUPP
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 17, 2008
09:44 AM
Checkout broken feature returns -18 LM_NOSERVSUPP
When peforming a test checkout on a broken feature using flag LM_CO_LOCALTEST we're getting: -18 LM_NOSERVSUPP "License server system does not support this feature."
but shouldn't lc_checkout return -157 LM_REPAIR_NEEDED "Trusted Storage compromised; repair needed." in this case?
but shouldn't lc_checkout return -157 LM_REPAIR_NEEDED "Trusted Storage compromised; repair needed." in this case?
(7) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 18, 2008
10:01 AM
In what way is the feature broken? Do you get the same error with a normal checkout instead of LM_CO_LOCALTEST?
In a quick test (activating a local trial ASR with appactutil -local brokentest.asr, backing up the trusted storage file, deleting the fulfillment record with appactutil -delete FID-BROKEN-TEST, restoring the old trusted storage file) I get error -157, "Trusted Storage compromised; repair needed"...
In a quick test (activating a local trial ASR with appactutil -local brokentest.asr, backing up the trusted storage file, deleting the fulfillment record with appactutil -delete FID-BROKEN-TEST, restoring the old trusted storage file) I get error -157, "Trusted Storage compromised; repair needed"...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 19, 2008
07:18 AM
In what way is the feature broken? Do you get the same error with a normal checkout instead of LM_CO_LOCALTEST?
Exactly the same way that you broke it. Using ezcalc on a client license the returned error is as you said: -157, "Trusted Storage compromised; repair needed"
but on a license server license you get: -18 LM_NOSERVSUPP "License server system does not support this feature."
As I can see it must be a bug, since the returned error on a normal checkout on a broken license differs between server and client (local)...
Exactly the same way that you broke it. Using ezcalc on a client license the returned error is as you said: -157, "Trusted Storage compromised; repair needed"
but on a license server license you get: -18 LM_NOSERVSUPP "License server system does not support this feature."
As I can see it must be a bug, since the returned error on a normal checkout on a broken license differs between server and client (local)...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 19, 2008
10:12 AM
In the server's debug log, do you see messages like these?
I expect the client application knows only that the server isn't serving those features, which is why it returns LM_NOSERVSUPP...
25:00:00 (demo) Error: Feature B1 is untrusted
25:00:00 (demo) Error: Feature B2 is untrusted
I expect the client application knows only that the server isn't serving those features, which is why it returns LM_NOSERVSUPP...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 20, 2008
01:36 AM
This is not correct as I see it, returning LM_NOSERVSUPP.. on a broken fulfillment in the license server. As it is now the user doesn't know what the problem is from the returned error message.
That's exactly why we do a test checkout (LM_CO_LOCALTEST) to see if a license has expired (LM_LONGGONE), since a normal checkout returns LM_NOSERVSUPP.. in this case.
Are you filing this as an issue/proposal?
That's exactly why we do a test checkout (LM_CO_LOCALTEST) to see if a license has expired (LM_LONGGONE), since a normal checkout returns LM_NOSERVSUPP.. in this case.
Are you filing this as an issue/proposal?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 20, 2008
02:06 PM
My impression is that the behavior is analogous to, say, starting a server with a license file that has a bad signature. If your served license is---
---the debug log states---
---which information (similarly to the untrusted-storage situation) isn't sent out to client applications.
This is different from a local, unserved license file with a broken signature, which does return LM_BADCODE or suchlike to the client application. Is that acceptable?
SERVER this_host ANY
VENDOR demo
# nonsense signature
INCREMENT B3 demo 1.0 1-jan-2010 1 SIGN="11111"
---the debug log states---
25:00:00 (demo) Invalid license key (inconsistent authentication code)
25:00:00 (demo) ==>INCREMENT B3 demo 1.0 1-jan-2010 1 SIGN=11111
---which information (similarly to the untrusted-storage situation) isn't sent out to client applications.
This is different from a local, unserved license file with a broken signature, which does return LM_BADCODE or suchlike to the client application. Is that acceptable?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 21, 2008
01:48 AM
Not really acceptable, but it's not a show stopper either. Getting the generic return error message LM_NOSERVSUPP isn't that informative as it should be, especially when there are correct adequate messages available.
As it is now we have to fill out the manual with different scenarious when getting the LM_NOSERVSUPP from the license server.
Thanks Robert, you're always helpful.
OT. Btw, do you have any clue about my other question (Process Trusted Storage Activations poll rate) in the Operations section?
As it is now we have to fill out the manual with different scenarious when getting the LM_NOSERVSUPP from the license server.
Thanks Robert, you're always helpful.
OT. Btw, do you have any clue about my other question (Process Trusted Storage Activations poll rate) in the Operations section?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 21, 2008
09:05 AM
Thanks for the follow-up---if you do want the specific return-code information to trickle up, you might submit the request through eService or the product feedback page (so it would have your contact information for tracking, additional follow-up, and so on).
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)