General protection - GeneralGloCiphering vs glo_ActionRequest

3 posts / 0 new
Last post
General protection - GeneralGloCiphering vs glo_ActionRequest

Hi Gurux team!

We are using Gurux DIrector to trying read obis objects list from real meter using HighGMAC without general protection in conformance block.
We are able to see the 2 steps involved in the association in the Director log, but retrieving error from device in second step:
1. InitiateRequest (glo_InitiateRequest)
2. ActionRequest (GeneralGloCiphering) --> getting this exception response from meter

<WRAPPER len="B" >
<TargetAddress Value="1" />
<SourceAddress Value="20" />
<StateError Value="ServiceNotAllowed" />
<ServiceError Value="OperationNotPossible" />

Because in "Supported Services" tab in Gurux Director configuration for the meter we have NOT checked "General protection", we expect for "glo_ActionRequest" instead of "GeneralGloCiphering" in the corrresponding to the second step.

Would we need to check any other config in Gurux Director to obtain a glo_Actionrequest in order to get associacion success with meter using HLS 5 HighGMAC??

Thanks in advance

Kurumi's picture


Can you check what meter is returning? Is General protection returned in negotiated conformance?
I just checked this and if negotiated conformance doesn't include General protection, glo_ActionRequest is used.


Mikko Kurunsaari
Gurux Ltd


Hi Gurux team!

Meter is sending glo_InitiateResponse with GeneralProtection bit as required.
As result of the negotiation, seems GeneralProtection protection required and, for that, GeneralGloCiphering required instead of glo_ActionRequest.

Seems meter is returning ServiceNotAllowed/OperationNotPossible when DLMS client send ActionRequest using GeneralGloCiphering. However, meter is able to let association when DLMS client send ActionRequest using glo_ActionRequest (even when general protection required from meter).
We are checking with manufacturer.

Thanks a lot for the support!!