Protocol Version in AARQ Packet

By Ankush, 11 June, 2025
Forums
Gurux DLMS for ANSI C

Could you please clarify why the bit string 100001 is used as the value for the protocol-version field in the AARQ APDU?

I have analyzed multiple AARQ exchanges across different tools and interfaces, with specific focus on how the protocol-version field is BER-encoded and interpreted.

Case 1: AARQ Packet from a proprietary client tool on HDLC interface:
Tx -> 7EA02F03211017DDE6E600602180020780A109060760857405080101BE10040E01000000065F1F040000F29F0400939C7E
Rx <- 7EA03B21033058EBE6E700612D80020280A109060760857405080101A203020100A305A103020100BE10040E0800065F1F04000010140400000779DB7E
Here protocol-version TLV: 80 02 07 80
Tag: 80 (Context-specific, Primitive, Tag 0)
Length: 02
Value: 07 80
07 → 7 unused bits in the last byte
80 → 10000000, ignoring the unused bits → actual version: 0000001 → version = 1
Association Result: Connected (00) -> As expected

Case 2: AARQ Packet from DLMS Test Tool (DTT) on Wrapper interface:
i)
Tx -> 0001001000010023602180020284A109060760857405080101BE10040E01000000065F1F040062FEDFFFFF
Rx <- 000100010010002B6129A109060760857405080101A203020100A305A103020100BE10040E0800065F1F040000121008000007
protocol-version TLV: 80 02 02 84
02 → 2 unused bits
84 → 10000100, removing 2 bits gives: 100001 → binary 33 → protocol-version = 33
Association Result: Connected (00) -> Suspicious but getting pass on DTT tool.

ii)
Tx -> 0001001000010023602180020244A109060760857405080101BE10040E01000000065F1F040062FEDFFFFF
Rx <- 000100010010002B6129A109060760857405080101A203020101A305A203020102BE10040E0800065F1F040000121008000007
protocol-version TLV: 80 02 02 44
44 = 01000100, removing 2 bits gives: 010001 → binary 17 → protocol-version = 17
Association Result: Rejected-permanent (01) -> As expected

Here, I suspect:

1. The protocol-version encoding by DTT (e.g., 80020284) doesn't align with DLMS spec expectations.
2. Alternatively, I'm misinterpreting how the DTT encodes and the IUT parses the BIT STRING.

A similar type of discussion had done on this forum at https://www.gurux.fi/comment/22576#comment-22576 but it does not answer this query.

Ankush

4 weeks ago

One more thing here that case 1 is passed with following modification in

int apdu_parseProtocolVersion(dlmsSettings* settings,
gxByteBuffer* buff)
{

if (settings->server && value != 0x84 && value != 0x80)
{
return DLMS_ERROR_CODE_INVALID_PARAMETER;
}
}

Kurumi

4 weeks ago

Hi,

As I have explained in the link you shared, it's a bit string and it's mandatory or DLMS CTT T_APPL_OPEN_4 fails.

I believe that you need to check the bit-string encoding again. The protocol version must be 1 or the test fails, so 33 is not a possible value.

Customers passed DLMS CTT test just last week.

BR,
Mikko

Ankush

4 weeks ago

Hi Mikko,

The customer's DLMS/COSEM device successfully passed the DLMS CTT test primarily because our implementation currently checks for the presence of the protocol version value 0x84 in the AARQ (Association Request) packet as-is, without performing a detailed BER (Basic Encoding Rules) decoding of the associated AARE (Association Response) packet.

Kurumi

4 weeks ago

Hi,

The procol version is defined in ISO/IEC 15954:1999. There is only one protocol version in use at the moment (100001).

There are two T_APPL_OPEN_4 tests that check this.

SubTest 1. Protocol-version present and containing the default value (used value: 100001):
SubTest 2: Protocol-version is present but not containing the default value (used value: 010001)
This test will fail if meter is not returning rejected-permanent.

In short, the proprietary client tool sends the wrong protocol version.

BR,
Mikko