<![CDATA[HighGMAC AARE is accepted, but GET still fails — am I treating HLS like LOW authentication?]]>I am comparing two associations against the same DLMS stack.

With LOW authentication, the client can start GET requests immediately after a successful AARE.

With HighGMAC, the AARE is accepted, but the first normal GET is rejected unless I perform another authentication step.

The captures below are anonymized. Meter addresses, credentials, system titles, challenges, counters and tags were replaced.

LOW authentication AARQ

00 01 00 01 00 01 00 38
60 36
A1 09 06 07 60 85 74 05 08 01 01
8A 02 07 80
8B 07 60 85 74 05 08 02 01
AC 0A 80 08 41 42 43 44 45 46 47 48
BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 3E 1F 32 00

What I read from this:

00 01 00 01 00 01 00 38
└─ DLMS Wrapper header

60 36
└─ AARQ

A1 09 06 07 60 85 74 05 08 01 01
                                    ^^
└─ application-context-name
   LN referencing, no ciphering

8B 07 60 85 74 05 08 02 01
                           ^^
└─ mechanism-name = LOW

AC 0A 80 08 41 42 43 44 45 46 47 48
            └───────────────────────┘
             8-byte authentication value
             ("ABCDEFGH" in this synthetic trace)

In this case the flow is effectively:

AARQ
  ↓
meter validates LOW authentication value
  ↓
AARE accepted
  ↓
GET / SET / ACTION

HighGMAC AARQ

The HighGMAC association looks very different:

60 xx
A1 09 06 07 60 85 74 05 08 01 03
A6 0A 04 08 43 4C 49 45 4E 54 30 31
8A 02 07 80
8B 07 60 85 74 05 08 02 05
AC 0A 80 08 11 22 33 44 55 66 77 88
BE xx 04 xx 30 00 00 00 2A ...

The bytes that caught my attention are:

A1 ... 01 03
          ^^
LN referencing with ciphering

8B ... 02 05
          ^^
HighGMAC authentication mechanism

A6 ... 43 4C 49 45 4E 54 30 31
       └───────────────────────┘
       calling AP title / client system title

AC ... 11 22 33 44 55 66 77 88
       └───────────────────────┘
       client-to-server challenge

The AARE then contains an accepted association, but also an authentication-related diagnostic:

61 ...
A1 09 06 07 60 85 74 05 08 01 03
A2 03 02 01 00
A3 05 A1 03 02 01 0E
...

My current interpretation:

A2 03 02 01 00
            ^^
association-result = accepted

A3 05 A1 03 02 01 0E
                  ^^
authentication is still required

So is the correct conclusion that AARE accepted is the end of LOW authentication, but only the middle of a HighGMAC/HLS association?

]]>https://dlms.sharur.org/topic/51/highgmac-aare-is-accepted-but-get-still-fails-am-i-treating-hls-like-low-authenticationRSS for NodeFri, 16 Oct 2026 19:50:44 GMTSat, 22 Aug 2026 12:44:24 GMT60<![CDATA[Reply to HighGMAC AARE is accepted, but GET still fails — am I treating HLS like LOW authentication? on Sat, 22 Aug 2026 12:44:26 GMT]]>One implementation detail that is worth logging separately:

associationAccepted = true
hlsAuthenticated    = false

I have seen HES code collapse both into one authFinish flag.

That works with LOW and becomes misleading with HLS.

For HighGMAC, log the transition only after the Association LN Method 1 response has been verified.

A successful AARE is necessary, but it is not the final authentication event.

]]>https://dlms.sharur.org/post/134https://dlms.sharur.org/post/134Sat, 22 Aug 2026 12:44:26 GMT<![CDATA[Reply to HighGMAC AARE is accepted, but GET still fails — am I treating HLS like LOW authentication? on Sat, 22 Aug 2026 12:44:26 GMT]]>If Method 1 fails after a perfectly valid AARE, I would check these before touching the OBIS layer:

1. Client system title
2. Server system title
3. Client-to-server challenge
4. Server-to-client challenge
5. Invocation counter
6. Security control
7. Authentication/ciphering key set

A common failure is reusing the wrong invocation counter or calculating the GMAC with the wrong system title.

That gives you a confusing trace:

AARQ  → accepted
AARE  → accepted / authentication required
ACTION → rejected

The association transport is fine. The HLS proof is what failed.

Also make sure the client challenge used in the GMAC calculation is the same challenge that was actually sent in the AARQ. Some test tools regenerate it automatically on reconnect.

]]>https://dlms.sharur.org/post/133https://dlms.sharur.org/post/133Sat, 22 Aug 2026 12:44:26 GMT<![CDATA[Reply to HighGMAC AARE is accepted, but GET still fails — am I treating HLS like LOW authentication? on Sat, 22 Aug 2026 12:44:25 GMT]]>Yes. The two captures show the important distinction.

For LOW, the authentication value in the AARQ is the credential being checked during association establishment.

For HighGMAC, the AARQ/AARE exchange establishes the association context and exchanges the HLS challenges. You still need the Association LN authentication method.

Look for an ACTION request against:

Class ID : 15
OBIS     : 0.0.40.0.0.255
Method   : 1

A decrypted HLS request normally has a shape similar to:

C3 01 C1
00 0F
00 00 28 00 00 FF
01
01
09 11
10 00 00 00 2A AA BB CC DD EE FF 00 11 22 33 44 55

Breakdown:

C3
└─ ActionRequest

01
└─ ActionRequestNormal

C1
└─ invoke-id-and-priority

00 0F
└─ class-id = 15 (Association LN)

00 00 28 00 00 FF
└─ 0.0.40.0.0.255

01
└─ method-id = 1

01
└─ method parameters present

09 11
└─ octet-string, 17 bytes

10
└─ security control used by the HLS GMAC value

00 00 00 2A
└─ invocation counter

AA BB CC DD EE FF 00 11 22 33 44 55
└─ example GMAC authentication tag

Do not mark the session AUTHENTICATED merely because A2 ... 00 says the association was accepted.

For HighGMAC I would keep separate states:

AARQ_SENT
→ ASSOCIATION_ACCEPTED
→ HLS_IN_PROGRESS
→ HLS_VERIFIED
→ BUSINESS_READY
]]>https://dlms.sharur.org/post/132https://dlms.sharur.org/post/132Sat, 22 Aug 2026 12:44:25 GMT