Hello,
I am trying to establish HIGH_GMAC communication with the Ziv meter via the optical port, but I am facing a problem that someone might be able to help me with. Just to note, I am already successfully handling public communication and LLS.
Below are the messages exchanged with the meter through my software:
TX: 7ea00a00020021099353297e
RX: 7ea01709000200217342eb818008050200ff060200ff87717e
TX: 7ea077000200210910c3a0e6e6006066a109060760857405080103a60a04085a495600000000008a0207808b0760857405080205ac0a8008ced08d8dfb882348be3404322130310000005631443820b51b07b2f05a01dcf572ee3d169afbc5bb3820678444b3d87aabbe9a75c19c64fc33d56931c2cf2ed87e
RX: 7ea072090002002130fbcfe6e7006161a109060760857405080103a203020100a305a10302010ea40a04085a4956343730393188020780890760857405080285aa0a8008b9f6ed7be607ebb1be230421281f3000000078ad6965f832a2679ea3441d82393addb70985fbb74d62d821055c1f087e
At this point, I can't progress due to the following error:
java.lang.IllegalArgumentException: Invalid tag.
at gurux.dlms.GXAPDU.updateAuthentication(GXAPDU.java:1495)
at gurux.dlms.GXAPDU.parsePDU2(GXAPDU.java:1199)
at gurux.dlms.GXAPDU.parsePDU(GXAPDU.java:941)
at gurux.dlms.GXDLMSClient.parseAareResponse(GXDLMSClient.java:1252)
I also analyzed the messages exchanged by the manufacturer's software, where I got the response to the SNRM Request, and Gurux points out the same error. However, in their software, the process continues normally.
Could someone help me with this problem?
Hi, There is an error with…
Hi,
There is an error with the meter. You need to ask if there is a firmware update available that fixes this. The meter tells you that the authentication level is 0x85, which is wrong because the DLMS standard defines authentication levels from zero to seven.
BR,
Mikko
61 61 A1 09 06 07 60 85 74 05 08 01 03 A2 03 02 01 00 A3 05 A1 03 02 01 0E A4 0A 04 08 5A 49 56 34 37 30 39 31 88 02 07 80
89 07 60 85 74 05 08 02
85 //Invalid authentication Tag. Values are from zero to seven.
AA 0A 80 08 B9 F6 ED 7B E6 07 EB B1 BE 23 04 21 28 1F 30 00 00 00 78 AD 69 65 F8 32 A2 67 9E A3 44 1D 82 39 3A DD B7 09 85 FB B7 4D 62 D8 21 05 5C
Right, This step was…
Right, This step was overcome, but I encountered another problem. The manufacturer's software sends the following frame getApplicationAssociationRequest right after:
7E A0 42 00 02 00 21 09 32 3A 84 E6 E6 00 D3 31
30 00 00 00 1B D7 93 68 DA 70 6E BF 84 72 97 06
11 75 9F 95 8F B7 62 0D AB 3A 65 57 FA 1E E8 FF
C0 83 2A B5 B8 8D A7 5F 3F AA 89 12 86 A9 CB BE
E3 52 F2 7E
Oct 10, 2024 2:07:40 PM gurux.dlms.GXAPDU parsePDU2
WARNING: Unknown tag: 53.
<HDLC len="41" >
<TargetAddress Value="4010" />
<SourceAddress Value="4" />
<!-- I frame. -->
<FrameType Value="32" />
<PDU>
<ded_ActionRequest Value="300000001BD79368DA706EBF8472970611759F958FB7620DAB3A6557FA1EE8FFC0832AB5B88DA75F3FAA891286A9CBBEE3" />
</PDU>
</HDLC>
I noticed something different: instead of glo_ActionRequest, it shows ded_ActionRequest.
the warning disappears when I set the dedicate key, however I see that when I try to run gurux it is not using the dedicate key. Would there be anything else to configure, as I'm already adding it
how enable ded_ActionRequest?
I set ak ek and dedication key, but isn't enable ded_ActionRequest. Can you helpe me?
Hi, You can set the…
Hi,
You can set the dedicated key like this:
byte[] ded = new byte[16];
//Set random value to dedicated key. Now it's filled with zeroes.
dlms.getCiphering().setDedicatedKey(ded);
Some meters expect that the dedicated key is pre-defined, but usually, it's a random value.
BR,
Mikko
Hi, I was already…
Hi,
I was already configuring this.
If so, it's just the configuration. Could it be a bug in gurux? I've already updated to the latest version and nothing has changed.
Below the decrypted content of my message with the settings:
<HDLC len="76" >
<TargetAddress Value="4010" />
<SourceAddress Value="4" />
<!-- AARQ frame. -->
<FrameType Value="10" />
<PDU>
<AssociationRequest>
<ApplicationContextName Value="LN_WITH_CIPHERING" />
<CallingAPTitle Value="5A49560000000000" />
<SenderACSERequirements Value="1" />
<MechanismName Value="HighGMac" />
<CallingAuthentication Value="75757D7B5E57FB20" />
<!-- Decrypted data:
Security: AUTHENTICATION_ENCRYPTION
Invocation Counter: 101
<InitiateRequest>
<DedicatedKey Value="F3C61D191CC39017A3E113A4E3E34D67" />
<ProposedDlmsVersionNumber Value="06" />
<ProposedConformance>
<ConformanceBit Name="Action" />
<ConformanceBit Name="EventNotification" />
<ConformanceBit Name="SelectiveAccess" />
<ConformanceBit Name="Set" />
<ConformanceBit Name="Get" />
<ConformanceBit Name="ParameterizedAccess" />
<ConformanceBit Name="Access" />
<ConformanceBit Name="DataNotification" />
<ConformanceBit Name="InformationReport" />
<ConformanceBit Name="MultipleReferences" />
<ConformanceBit Name="BlockTransferWithAction" />
<ConformanceBit Name="BlockTransferWithSetOrWrite" />
<ConformanceBit Name="BlockTransferWithGetOrRead" />
<ConformanceBit Name="Attribute0SupportedWithGet" />
<ConformanceBit Name="PriorityMgmtSupported" />
<ConformanceBit Name="Attribute0SupportedWithSet" />
<ConformanceBit Name="ReservedSeven" />
<ConformanceBit Name="DeltaValueEncoding" />
<ConformanceBit Name="UnconfirmedWrite" />
<ConformanceBit Name="Write" />
<ConformanceBit Name="Read" />
<ConformanceBit Name="GeneralBlockTransfer" />
<ConformanceBit Name="GeneralProtection" />
<ConformanceBit Name="ReservedZero" />
</ProposedConformance>
<ProposedMaxPduSize Value="FFFF" />
</InitiateRequest>
-->
<glo_InitiateRequest Value="3000000065FDB2E49BD64233FFD5367440EE12E808EDDDFA5F52EF20E3B787387235A91567A63345503EA609A7B79F4E" />
</AssociationRequest>
</PDU>
</HDLC>
Below is the decrypted answer:
<HDLC len="71" >
<TargetAddress Value="4" />
<SourceAddress Value="4010" />
<!-- AARE frame. -->
<FrameType Value="30" />
<PDU>
<AssociationResponse>
<ApplicationContextName Value="LN_WITH_CIPHERING" />
<AssociationResult Value="00" />
<ResultSourceDiagnostic>
<!-- AUTHENTICATION_REQUIRED -->
<ACSEServiceUser Value="0E" />
</ResultSourceDiagnostic>
<RespondingAPTitle Value="5A49563437303931" />
<ResponderACSERequirement Value="1" />
<MechanismName Value="HighGMac" />
<RespondingAuthentication Value="75C943C64958EA18" />
<!-- Decrypted data:
Security: AUTHENTICATION_ENCRYPTION
Invocation Counter: 131
<InitiateResponse>
<NegotiatedDlmsVersionNumber Value="06" />
<NegotiatedConformance>
<ConformanceBit Name="Action" />
<ConformanceBit Name="SelectiveAccess" />
<ConformanceBit Name="Set" />
<ConformanceBit Name="Get" />
<ConformanceBit Name="BlockTransferWithSetOrWrite" />
<ConformanceBit Name="BlockTransferWithGetOrRead" />
</NegotiatedConformance>
<NegotiatedMaxPduSize Value="00FC" />
<VaaName Value="0007" />
</InitiateResponse>
-->
<glo_InitiateResponse Value="30000000831389E9BA098442A74F1638366300EBC26F9007EC453352459DCA" />
</AssociationResponse>
</PDU>
</HDLC>
So far it's coming as expected, but the following continues with the glo_.
Hi, The next one should be…
Hi,
The next one should be glo_message. ded_messsages are started to use after the connection is fully established.
BR,
Mikko
Hi Mikko, The issue is that…
Hi Mikko,
The issue is that subsequent messages are not being encrypted in ded_messages mode.
Regarding the initial question where you responded:
=============================
There is an error with the meter. You need to ask if there is a firmware update available that fixes this. The meter tells you that the authentication level is 0x85, which is wrong because the DLMS standard defines authentication levels from zero to seven.
=============================
Is there a specific value that needs to be received to activate ded_messages mode?
If this value is unrelated, is there a way to force the activation of ded_messages mode?
Below my data log:
snrmRequest
SEND: 7ea00a00020021099353297e
RECIVER: 7ea01709000200217342eb818008050200ff060200ff87717e
aarqRequest
SEND: 7ea077000200210910c3a0e6e6006066a109060760857405080103a60a04085a495600000000008a0207808b0760857405080205ac0a80087684f0944cda9780be34043221303000000095cff623a9de62b703373007fd260e091d03882fe4ac114a85151d8539e36043be05641a515821770deaeb0865f37e
RECIVER: 7ea072090002002130fbcfe6e7006161a109060760857405080103a203020100a305a10302010ea40a04085a4956343730393188020780890760857405080285aa0a8008e34eca274ae6b053be230421281f300000009d97a011ce69d4746df82d48659843486ea4057b415236a78fcb1939c07e
getApplicationAssociationRequest
SEND: 7ea0420002002109323a84e6e600cb313000000096c26bad253a31af5a9aa805ff82d0bc16a164cf739b808085b49febfdcb180bfd41bfaa73b40ad51c635ebfd8d81e7e
RECIVER: 7ea0120900020021526a2be6e700d80202cf5b7e
gurux.dlms.GXDLMSExceptionResponse: Service unknown. Service not supported
at gurux.dlms.GXDLMS.handleExceptionResponse(GXDLMS.java:5373)
at gurux.dlms.GXDLMS.getPdu(GXDLMS.java:5130)
at gurux.dlms.GXDLMS.getData(GXDLMS.java:5721)
at gurux.dlms.GXDLMSClient.getData(GXDLMSClient.java:3096)
at gurux.dlms.GXDLMSClient.getData(GXDLMSClient.java:3025)
I use
client.setUseLogicalNameReferencing(true);
client.setInterfaceType(InterfaceType.HDLC);
client.setAuthentication(Authentication.HIGH_GMAC);
client.getCiphering().setSecuritySuite(SecuritySuite.SUITE_0);
client.getCiphering().setSecurity(Security.AUTHENTICATION_ENCRYPTION);
client.getCiphering().setDedicatedKey(deticatedKey);
client.setCtoSChallenge(challenge);
client.getCiphering().setAuthenticationKey(...
client.getCiphering().setBlockCipherKey(....
this is correct?
Is there anything I can do…
Is there anything I can do or am I forgetting?
Hi, Authentication levels…
Hi,
Authentication levels are defined from zero to seven. 0x85 is not allowed value.
Authentication level doesn't affect to ded_messages. DLMS standard defines that ded messages are start to use after the connection is established and getApplicationAssociationRequest is always send using glo_message.
BR,
Mikko