High GMAC meters can’t authenticate – can’t read invocation counter

Hi all,

We have ~500 ameter300 DLMS meters deployed across the country. They all use the same key material (system title 5753450000000001, client title 434C4E5400000001, auth key D0…DF, block key 00…0F, GMAC password 0x3333…). The legacy OPC client (C# / MyDaAddressSpaceDevice) talks to them just fine, but it hardcodes Ciphering.InvocationCounter = 1.

I’m trying to migrate the reads to Gurux Python (gurux_dlms 1.0.178, GXDLMSReader/GXSettings). The OPC client’s addressing scheme (m_DevAddr + 0x4000) already works in Python, but every HighGMac association times out unless I guess the exact invocation counter. Unfortunately we can’t read 0.0.43.1.0.255 attr 2: the meters answer SNRM/AARQ with Authentication.NONE and dump the association view, then never deliver the counter before the reader times out. So I can’t sync the IC remotely.

Questions:
1. Is there a recommended way (in Gurux) to read the invocation counter when the meter streams the association view first? GXDLMSReader.readDataBlock() just times out after several `E6E7` frames.
2. If the meter really blocks public access to 0.0.43.1.0.255, how do other users handle GMAC counters at scale? Do you cache them in a database and increment locally, or is there a standard DLMS object/command to resync the counter?
3. Any guidance from Gurux devs on keeping the invocation counter aligned across hundreds of meters would be hugely appreciated. Right now GMAC fails immediately because we don’t know the current IC per device.

Thanks in advance!