Could you help me resolve my problem with connection to the DLMS meter using following settings: GXDLMSSecureClient dlmsSecureMeter = new GXDLMSSecureClient(true, 1, 1, Authentication.HIGH_GMAC, "01234567", InterfaceType.WRAPPER);
dlmsSecureMeter.getCiphering().setSecurity(Security.AUTHENTICATION_ENCRYPTION);
dlmsSecureMeter.getCiphering().setSystemTitle("ABCD1234".getBytes("ASCII"));
dlmsSecureMeter.getCiphering().setAuthenticationKey(GXCommon.hexToBytes("30303030303030303030303030303032"));
dlmsSecureMeter.getCiphering().setBlockCipherKey(GXCommon.hexToBytes("30303030303030303030303030303030"));
Please tell me if I made mistake during configuration or I missed something.
P.S. I'm sure that the authentication and cipher keys are fine because they were tested using another application that doesn't use your library. Also, I have tested your simple client with security level set to NONE and then the connection to meter and reading of meters were sucesfull.
I attached also the results for the GXDLMSDirector tests. After connection I couldn't read the Association view.
Thank you for your reply! Yes, I tested real DLMS meter.
I know also that for the following proper constructed TX & RX messages I can communicate with meter properly. I noticed that the <CallingAuthentication> & <RespondingAuthentication> values are shorter compared with the values from TX & RX messages from my previous post besides I used the same input parameters. Do you have any idea why there are such differences?
CallingAuthentication is a random challenge and it might vary. You can set "Challenge" in "Secured connections" tab if you want to use same challenge every time.
I believe that one of your settings is invalid and for this reason meter read fails.
Next image from the
Next image from the GXDLMSDirector
Next image from
Next image from GXDLMSDirector
Hi,
Hi,
Meter reply for AARQ correctly, but when you are sending Client to server challenge it fails to reply.
Is this implemented for the meter?
BR,
Mikko
Hello Mikko,
Hello Mikko,
Thank you for your reply! Yes, I tested real DLMS meter.
I know also that for the following proper constructed TX & RX messages I can communicate with meter properly. I noticed that the <CallingAuthentication> & <RespondingAuthentication> values are shorter compared with the values from TX & RX messages from my previous post besides I used the same input parameters. Do you have any idea why there are such differences?
Thank you and
Best regards,
Paweł
---------------------------------------
TX: <WRAPPER len="95" >
<TargetAddress Value="1" />
<SourceAddress Value="1" />
<PDU>
<AssociationRequest>
<ApplicationContextName Value="LN_WITH_CIPHERING" />
<CallingAPTitle Value="4142434431323334" />
<SenderACSERequirements Value="1" />
<MechanismName Value="HighGMac" />
<CallingAuthentication Value="D010A7CEC3163A66" />
<glo_InitiateRequest Value="3000007B14DAD8F1F9060A7D94E5C1F0E2309DFECC1DD7A81B385F16B9D001" />
</AssociationRequest>
</PDU>
</WRAPPER>
---------------------------------------
RX: <WRAPPER len="107" >
<TargetAddress Value="1" />
<SourceAddress Value="1" />
<PDU>
<AssociationResponse>
<ApplicationContextName Value="LN_WITH_CIPHERING" />
<AssociationResult Value="0" />
<ResultSourceDiagnostic>
<!--AUTHENTICATION_REQUIRED-->
<ACSEServiceUser Value="14" />
</ResultSourceDiagnostic>
<RespondingAPTitle Value="415041BB04057272" />
<ResponderACSERequirement Value="1" />
<MechanismName Value="HighGMac" />
<RespondingAuthentication Value="D54658F5A176E9C6" />
<glo_InitiateResponse Value="3000308B35BE2C1A6CB7AFBBD9A8EDDBD26AFE7929F352E8B0E5DE8E4769BF" />
</AssociationResponse>
</PDU>
</WRAPPER>
---------------------------------------
TX: <WRAPPER len="59" >
<TargetAddress Value="1" />
<SourceAddress Value="1" />
<PDU>
<glo_ActionRequest Value="3000007B1512AF8564D6F94A4449F265DF47C75491976BF6131E6CD606F63A0A6644CF0E403B80A13F5A62F8C0384441A7" />
</PDU>
</WRAPPER>
Hi,
Hi,
CallingAuthentication is a random challenge and it might vary. You can set "Challenge" in "Secured connections" tab if you want to use same challenge every time.
I believe that one of your settings is invalid and for this reason meter read fails.
BR,
Mikko