View Full Version : Checkout broken feature returns -18 LM_NOSERVSUPP

11-17-2008, 10:44 AM
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?

11-18-2008, 11: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"...

11-19-2008, 08: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)...

11-19-2008, 11:12 AM
In the server's debug log, do you see messages like these?

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...

11-20-2008, 02: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?

11-20-2008, 03: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---
SERVER this_host ANY
# 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?

11-21-2008, 02: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?

11-21-2008, 10: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 (http://www.acresso.com/promolanding/productfeedback.htm) page (so it would have your contact information for tracking, additional follow-up, and so on).