Authentication issues (AARQ) with WASION IM300

By Evaldo, 10 July, 2025
Forums
Gurux DLMS for Java

Hello,

I’m working on a Java project using the Gurux DLMS library to certify DLMS/COSEM communication with the IM300 meter from WASION.
I’ve managed to establish the physical connection to the meter (via serial/TCP), but I’m facing issues during the authentication process. Specifically, I’m encountering errors in the second step of the communication, during the AARQ request (Application Association Request), where the meter should reply with an AARE (Association Response).

Below are the authentication parameters provided by the manufacturer to assist with configuration:

Client: 01 (Management)
System Title: WSE0000000001
Authentication Mechanism: HLS
Security Policy: Encrypted
Master Key: 00112233445566778899AABBCCDDEEFF
Encrypted Key: 000102030405060708090A0B0C0D0E0F
Broadcast E Key: 00112233445566778899AABBCCDDEEFF
Authen Key: D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF
Meter Serial Number: 1975159


Additionally, I identified some information during tests performed with the manufacturer’s software (MPMS3000):

Physical Address: 16
Password: 3333333333 (tested, no effect; currently not set)


Here below is my basic authentication code. I also performed other tests by applying the keys to the DedicatedKey and BroadcastKey fields, but nothing changed.

GXDLMSSecureClient dlms = new GXDLMSSecureClient();
dlms.setUseLogicalNameReferencing(true);
dlms.setInterfaceType(HDLC);
dlms.getHdlcSettings().setMaxInfoRX(1024);
dlms.getHdlcSettings().setMaxInfoTX(1024);
dlms.getHdlcSettings().setWindowSizeRX(7);
dlms.getHdlcSettings().setWindowSizeTX(1);
dlms.setServiceClass(CONFIRMED);
dlms.setClientAddress(1);
dlms.setServerAddress(GXDLMSClient.getServerAddress(1, 16, 4));
dlms.getCiphering().setSystemTitle(new byte[]{87, 83, 69, 0, 0, 0, 0, 1});
dlms.setAuthentication(HIGH_GMAC);
dlms.getCiphering().setSecurity(ENCRYPTION);
dlms.getCiphering().setAuthenticationKey(Hex.decode("D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF"));
dlms.getCiphering().setBlockCipherKey(Hex.decode("000102030405060708090A0B0C0D0E0F"));
dlms.getCiphering().setSecuritySuite(SUITE_0);
dlms.getCiphering().setSigning(NONE);

 

The tests performed using Wasion’s own software work perfectly. Here are the first two VALID request/response exchanges captured from MPMS3000:

1: 7E A0 23 00 02 00 21 03 93 99 F6 81 80 14 05 02 04 00 06 02 04 00 07 04 00 00 00 01 08 04 00 00 00 07 44 86 7E
<HDLC len="22" >
<!-- Logical address:1, Physical address:16 -->
<TargetAddress Value="4010" />
<SourceAddress Value="1" />
<!-- SNRM frame. -->
<FrameType Value="93" />
<PDU>
<Snrm>
 <MaxInfoTX Value="1024" />
 <MaxInfoRX Value="1024" />
 <WindowSizeTX Value="1" />
 <WindowSizeRX Value="7" />
</Snrm>
</PDU>
</HDLC>
2: 7E A0 23 03 00 02 00 21 73 70 7B 81 80 14 05 02 00 AF 06 02 00 AF 07 04 00 00 00 01 08 04 00 00 00 01 D2 0B 7E
<HDLC len="22" >
<TargetAddress Value="1" />
<!-- Logical address:1, Physical address:16 -->
<SourceAddress Value="4010" />
<!-- UA frame. -->
<FrameType Value="73" />
<PDU>
<Ua>
 <MaxInfoTX Value="175" />
 <MaxInfoRX Value="175" />
 <WindowSizeTX Value="1" />
 <WindowSizeRX Value="1" />
</Ua>
</PDU>
</HDLC>
3: 7E A0 77 00 02 00 21 03 10 B3 5D E6 E6 00 60 66 A1 09 06 07 60 85 74 05 08 01 03 A6 0A 04 08 57 53 45 00 00 00 00 01 8A 02 07 80 8B 07 60 85 74 05 08 02 05 AC 0A 80 08 30 30 30 30 30 30 30 30 BE 34 04 32 21 30 30 01 23 45 67 83 B5 C8 24 64 E5 9B 39 62 5A B7 E6 88 15 38 5E E9 9B C9 C4 3F 06 47 C0 F4 73 E5 C2 25 72 BD D1 B5 0E 03 4F E4 84 F7 02 C9 5D B4 35 55 7E
<HDLC len="76" >
<!-- Logical address:1, Physical address:16 -->
<TargetAddress Value="4010" />
<SourceAddress Value="1" />
<!-- AARQ frame. -->
<FrameType Value="10" />
<PDU>
<AssociationRequest>
 <ApplicationContextName Value="LN_WITH_CIPHERING" />
 <CallingAPTitle Value="5753450000000001" />
 <SenderACSERequirements Value="1" />
 <MechanismName Value="HighGMAC" />
 <CallingAuthentication Value="3030303030303030" />
 <!-- Decrypt failed. Invalid authentication tag. -->
 <!-- Decrypted data:
   Security: AuthenticationEncryption
   Invocation Counter: 19088743
   # Error: Failed to decrypt data.
 -->
 <glo_InitiateRequest Value="300123456783B5C82464E59B39625AB7E68815385EE99BC9C43F0647C0F473E5C22572BDD1B50E034FE484F702C95DB4" />
</AssociationRequest>
</PDU>
</HDLC>
4: 7E A0 72 03 00 02 00 21 30 F5 E6 E6 E7 00 61 4E 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 57 53 45 00 00 00 00 01 88 02 07 80 89 07 60 85 74 05 08 02 05 AA 0A 80 08 9F 09 BF 33 DE 45 00 00 BE 23 04 21 28 1F 30 7C 01 00 00 5B 82 5F 6C 7B E7 60 24 7D 0C 43 A7 29 08 91 0E 0A 13 20 5D 14 61 11 15 B7 A7 7F 79 7E
<HDLC len="71" >
<TargetAddress Value="1" />
<!-- Logical address:1, Physical address:16 -->
<SourceAddress Value="4010" />
<!-- AARE frame. -->
<FrameType Value="30" />
<PDU>
<AssociationResponse>
 <ApplicationContextName Value="LN_WITH_CIPHERING" />
 <AssociationResult Value="00" />
 <ResultSourceDiagnostic>
   <!-- AuthenticationRequired -->
   <ACSEServiceUser Value="0E" />
 </ResultSourceDiagnostic>
 <!-- DLMS system title:
Manufacturer Code: WSE
Serial number: 1
-->
 <RespondingAPTitle Value="5753450000000001" />
 <ResponderACSERequirement Value="1" />
 <MechanismName Value="HighGMAC" />
 <RespondingAuthentication Value="9F09BF33DE450000" />
 <!-- Decrypt failed. Invalid authentication tag. -->
 <!-- Decrypted data:
   Security: AuthenticationEncryption
   Invocation Counter: 2080440320
   # Error: Failed to decrypt data.
 -->
 <glo_InitiateResponse Value="307C0100005B825F6C7BE760247D0C43A72908910E0A13205D14611115B7A7" />
</AssociationResponse>
</PDU>
</HDLC>

 

Below are also the first two INVALID request/response exchanges performed through my system:

1: 7E A0 23 00 02 00 21 03 93 99 F6 81 80 14 05 02 04 00 06 02 04 00 07 04 00 00 00 01 08 04 00 00 00 07 44 86 7E
<HDLC len="22" >
<!-- Logical address:1, Physical address:16 -->
<TargetAddress Value="4010" />
<SourceAddress Value="1" />
<!-- SNRM frame. -->
<FrameType Value="93" />
<PDU>
<Snrm>
 <MaxInfoTX Value="1024" />
 <MaxInfoRX Value="1024" />
 <WindowSizeTX Value="1" />
 <WindowSizeRX Value="7" />
</Snrm>
</PDU>
</HDLC>
2: 7E A0 23 03 00 02 00 21 73 70 7B 81 80 14 05 02 00 AF 06 02 00 AF 07 04 00 00 00 01 08 04 00 00 00 01 D2 0B 7E
<HDLC len="22" >
<TargetAddress Value="1" />
<!-- Logical address:1, Physical address:16 -->
<SourceAddress Value="4010" />
<!-- UA frame. -->
<FrameType Value="73" />
<PDU>
<Ua>
 <MaxInfoTX Value="175" />
 <MaxInfoRX Value="175" />
 <WindowSizeTX Value="1" />
 <WindowSizeRX Value="1" />
</Ua>
</PDU>
</HDLC>
3: 7E A0 62 00 02 00 21 03 10 D9 18 E6 E6 00 60 51 A1 09 06 07 60 85 74 05 08 01 03 A6 0A 04 08 57 53 45 00 00 00 00 01 8A 02 07 80 8B 07 60 85 74 05 08 02 05 AC 12 80 10 34 28 29 02 68 1F 16 62 72 59 6A 4F 22 3F 15 75 BE 17 04 15 21 13 20 00 00 00 00 2F BB 42 C1 19 43 52 2D 04 15 6F B4 0F 43 41 9B 7E
<HDLC len="61" >
<!-- Logical address:1, Physical address:16 -->
<TargetAddress Value="4010" />
<SourceAddress Value="1" />
<!-- AARQ frame. -->
<FrameType Value="10" />
<PDU>
<AssociationRequest>
 <ApplicationContextName Value="LN_WITH_CIPHERING" />
 <CallingAPTitle Value="5753450000000001" />
 <SenderACSERequirements Value="1" />
 <MechanismName Value="HighGMAC" />
 <CallingAuthentication Value="34282902681F166272596A4F223F1575" />
 <!-- Decrypted data:
   Security: Encryption
   Invocation Counter: 0
   # Error: Failed to decrypt data.
 -->
 <glo_InitiateRequest Value="20000000002FBB42C11943522D04156FB40F43" />
</AssociationRequest>
</PDU>
</HDLC>
4: 7E A0 59 03 00 02 00 21 30 F4 F3 E6 E7 00 61 48 A1 09 06 07 60 85 74 05 08 01 03 A2 03 02 01 02 A3 05 A1 03 02 01 0D A4 0A 04 08 00 00 00 00 00 00 00 00 BE 23 04 21 28 1F 30 A7 01 00 00 78 4B 38 9A BE 11 80 20 13 09 69 93 CC BE EC 16 BF 93 82 85 5E 93 40 95 9B 80 BD F4 7E
<HDLC len="58" >
<TargetAddress Value="1" />
<!-- Logical address:1, Physical address:16 -->
<SourceAddress Value="4010" />
<!-- AARE frame. -->
<FrameType Value="30" />
<PDU>
<AssociationResponse>
 <ApplicationContextName Value="LN_WITH_CIPHERING" />
 <!-- TransientRejected -->
 <AssociationResult Value="02" />
 <ResultSourceDiagnostic>
   <!-- AuthenticationFailure -->
   <ACSEServiceUser Value="0D" />
 </ResultSourceDiagnostic>
 <!-- UNI/TS system title:
Manufacturer: @@@
Serial number: 000000000000
-->
 <RespondingAPTitle Value="0000000000000000" />
 <!-- Decrypt failed. Invalid authentication tag. -->
 <!-- Decrypted data:
   Security: AuthenticationEncryption
   Invocation Counter: 2801860608
   # Error: Failed to decrypt data.
 -->
 <glo_InitiateResponse Value="30A7010000784B389ABE11802013096993CCBEEC16BF9382855E9340959B80" />
</AssociationResponse>
</PDU>
</HDLC>

I have already certified some manufacturers using the basic configuration above, only changing some data such as Physical Address and System Title. Also, until now, all of them used the security mode AUTHENTICATION_ENCRYPTION.

At this point, I need guidance on which additional parameters I should configure to successfully complete the authentication, or if I simply need to adjust something in my current setup.

Thank you very much for your time and support.

Evaldo

6 months ago

I forgot to show the error that the Gurux Java library is returning:

gurux.dlms.GXDLMSException: Connection is transient rejected
Authentication failure.
	at gurux.dlms.GXAPDU.parsePDU2(GXAPDU.java:1205)
	at gurux.dlms.GXAPDU.parsePDU(GXAPDU.java:838)
	at gurux.dlms.GXDLMSClient.parseAareResponse(GXDLMSClient.java:959)
	at examples.GuruxExample.connectHDLC(GuruxExample.java:310)
	at examples.GuruxExample.guruxConnectionExample(GuruxExample.java:92)
	at main.Main.main(Main.java:12)

Kurumi

6 months ago

Hi,
You are not reading and setting the invocation counter.
In the hex log you shared, the WASION is not reading it, so it might be hardcoded.

Try this:

dlms.getCiphering().setInvocationCounter(19088743);

For some reason, the proposed max PDU size is also zero in the hex log.

BR,
Mikko

Evaldo

6 months ago

Hi,

I’m unable to read the invocation counter in any of the modes.

With WASION meters, whenever I try to read it using either PUBLIC or LOW authentication, I receive the error "No Common ACSE version." in the AARE response frame.
And when I try using HIGH authentication, I also always get the "Authentication failure" error in the AARE response frame.

Could you explain why this happens? In order to read the invocation counter, I first need to successfully complete the SNRM and AARE exchanges, correct?

I’m leaving a few additional questions below that might help me better understand the issue:

Why is it that with meters from other manufacturers I’ve certified (e.g., ELETRA and NANSEN), I never had to retrieve and update the invocation counter?

Also, with those other manufacturers, I never needed data such as the MASTER KEY and BROADCAST KEY (as mentioned in the first comment). Are these not required in this case?

Regarding the password "3333333333" configured in the MPMS3000, is it only required for LOW authentication mode?

And one last question: I noticed the field <CallingAuthentication Value="3030303030303030" /> in the valid frame (the one captured using the MPMS3000 app). It looks like eight zeros are being set as the password. However, in my frame this value is never sent, even when I set the password to eight zeros. Could this be one of the reasons for the issue?

Kurumi

5 months 3 weeks ago

Hi,

It depends on the meter manufacturer how the invocation counter is used.

You need to change the client address for low authentication. That should be on the meter documentation.
The public client address is 0x10.

The password is not sent with GMAC authentication. It's only send with low authentication. You need to set the coeect block cipher and authentication keys for GMAC.

BR,
Mikko