from gurux_dlms.objects import GXDLMSSecuritySetup
from gurux_dlms.enums import Security, Authentication

def synchronize_invocation_counter(reader, client, security_obis="0.0.43.1.0.255"):
    # 1. Connect temporarily as Public Client (SAP 16)
    client.clientAddress = 16
    client.authentication = Authentication.NONE
    client.ciphering.security = Security.NONE
    
    # 2. Read Global Invocation Counter (Class 64, Attribute 4)
    ss = GXDLMSSecuritySetup(security_obis)
    current_ic = reader.read(ss, 4)
    print(f"[+] Current Meter Persisted Invocation Counter: {current_ic}")
    
    # 3. Synchronize Management Client with Safety Advance (+50)
    client.clientAddress = 1 # Management Client SAP 1
    client.authentication = Authentication.HIGH_GMAC
    client.ciphering.security = Security.AUTHENTICATION_ENCRYPTION
    client.ciphering.invocation_counter = current_ic + 50
    
    print(f"[+] Management Client IC synchronized to {client.ciphering.invocation_counter}. Ready for AARQ.")

Summary Checklist:

1. $IC$ Persistence: Invocation Counters survive reboots and socket disconnects (Green Book Section 9.2.5.3).
2. Cold-Start Sync: Read Attribute 4 of Class 64 via Public Client (SAP 16).
3. Safety Advance: Set $IC = IC_{\text{meter}} + 50$ to avoid race conditions.

00 01 00 10 00 01 00 0D C0 01 C1 00 40 00 00 2B 01 00 FF 04 00

• Client SAP: 0x0010 (Public Client 16)
• Class ID: 0x0040 (Class 64 Security Setup)
• OBIS: 0.0.43.1.0.255
• Attribute: 4 (global_invocation_counter)

And the meter's response returning current $IC = 14{,}280$ (0x000037C8

00 01 00 10 00 01 00 09 C4 01 C1 00 06 00 00 37 C8

• Management Security Setup (Client SAP 1): 0.0.43.1.0.255
• Firmware Upgrade Security Setup (Client SAP 2): 0.0.43.1.1.255
• Customer Gateway Security Setup (Client SAP 3): 0.0.43.1.2.255

Each logical client has an independent, non-overlapping Invocation Counter tracking sequence!

When the meter powers on or re-establishes an association, it loads $IC_{\text{persisted}}$. If a client attempts a brute-force connection with lower $IC$, the meter will lock out the association after 3 failed attempts per Class 65 (Single Port Protection).

Per DLMS Blue Book Ed. 17 Section 4.6.2 (Security Setup Class 64):
Class 64 defines Attribute 4: global_invocation_counter (Double-Long-Unsigned).

The Standard Synchronization Handshake:

1. Connect via Public Client (Client SAP 0x0010):
   Public Client requires no encryption and allows reading Public objects;
2. Read Current Meter IC:
   Issue Get-Request-Normal for OBIS 0.0.43.1.0.255 (or associated Security Setup object) Attribute 4;
3. Synchronize HES Counter:
   $$\text{HES } IC = \text{Meter } IC + 100$$ (advance by a safety margin);
4. Connect via Management Client (Client SAP 0x0001):
   Transmit AARQ and ciphered APDUs using the newly synchronized $IC$.

Per DLMS Green Book 10th Ed Section 9.2.5.3 (Invocation Counter Management) and IEC 62056-53 Section 8.4.2:
The 4-byte Invocation Counter ($IC$) is a strictly monotonic anti-replay sequence number.

The Meter's Non-Volatile Persistence:

In the meter's security engine (Class 64 Security Setup), the meter stores the last verified Invocation Counter from Client SAP 0x0001 in non-volatile memory (EEPROM / Flash):
$$\text{Condition: } IC_{\text{rx}} > IC_{\text{persisted}}$$

If your HES worker thread restarts and resets $IC$ to 1 (or any value $\le IC_{\text{persisted}}$), the meter's AES-GCM decryption engine flags an active replay attack and drops the frame by design!