Need help implementing DLMS-HDLC translator for optical/RS232 meter and bare DLMS HES packets

Hello Gurux Community,

I have a meter that uses HDLC over DLMS/COSEM via optical or RS232 interface, working well with Gurux tools.

My backend HES sends and receives bare DLMS packets without HDLC framing or addressing. For example, a raw DLMS packet from HES looks like this:

00 01 00 30 00 01 00 70 60 6E A1 09 06 07 60 85 74 05 08 01 03
A6 0A 04 08 31 90 97 EB C7 77 DF A1 8A 02 07 80 8B 07 60 85 74
05 08 02 02 AC 12 80 10 6B 59 55 67 72 78 36 44 44 38 4F 4F 66
52 36 30 BE 34 04 32 21 30 30 00 00 00 0E 5D 62 95 19 4A 9E EB
2B D0 A1 37 87 8B 63 75 0B 43 B3 D9 83 37 5A 1E A7 D4 8B 64
88 B2 A1 65 9C BE 84 08 31 98 CF B4 28 D0 F4 99

My goal:

Wrap bare DLMS packets into correct HDLC frames (with addressing and CRC) to send to the meter.

Strip HDLC framing/addressing from meter replies and send bare DLMS upstream.

Important:

The first 8 bytes of DLMS packets contain 4 bytes addressing + 4 bytes metadata.

These must be extracted and used as HDLC address and control bytes when framing.

On parsing, the HDLC layer should extract and prepend these 8 bytes back into the DLMS payload.

What I have done:

Manual HDLC framing/parsing following Gurux style (frame format, length, dest/src addresses, control, CRC16).

Truncate/prepend addressing + metadata correctly.

Handle byte stuffing and multiple concatenated frames.

But still face shifting addresses, DLMS offsets, and zeros replacing metadata on replied packets.

Requesting:

Guidance or sample code on correctly extracting/reinserting first 8 bytes during DLMS↔HDLC translation.

Best practices for clean and lossless handling of address and metadata bytes.

Confirmation of exact DLMS bytes that map to HDLC address/control fields.

References or examples from Gurux DLMS for this translator logic.

Tips on debugging and validating such layered conversions.

Thanks for your time and help!