Guide · TS 102 225 · 0x02

SCP80 CNTR low — counter recovery

CNTR low.

CNTR low is replay protection doing its job: the counter in your command was not higher than the counter the card holds. Typical origins include a database restore, a parallel sending entity using its own counter, replaying an old campaign export, or a previous command the card accepted and counted while your server recorded it as failed. If more than one sending entity shares a key version they share one counter and must be serialised — that is a design fault, not a transient error.

Usual cause

The counter in your command packet was not higher than the counter the card holds, so replay protection rejected it. Your server is behind the card. Typical origins: a database restore, a parallel sending entity using its own counter, a campaign replayed from an old export, or a previous command that the card accepted and counted while your server recorded it as failed.

What to do

Recover by moving the counter up — it can only increase — then retry. MoreOTA ships add 1 and send again; you can add your own step per network or SIM code in the retry CSV. Repeating the same counter fails identically. Read the card-side value where the card allows it. If more than one sending entity shares a key version they share one counter and must be serialised; that is a design fault, not a transient error.

TS 102 225 §5.1.4

Parsers — nothing uploaded

Read the packet. Then talk.

Hex stays in the browser. Do not paste production keys. If the estate is still stuck after the decode, that is the programme.

TS 102 225 / TS 31.115

Packet decoder

SPI, key versions, TAR, counter, CHL — command or PoR.

Tools page

Paste a packet, or load one of the examples above.

TS 102 225 table 5

PoR status lookup

Cause, action, whether retrying can help.

Full table
Hex, with or without 0x

Questions

How do I recover from CNTR low?
Move the counter up — it can only increase — then retry. MoreOTA ships add 1 and send again; you can add your own step per network or SIM code in the retry CSV. Repeating the same counter fails identically.
Can two OTA servers share one key version?
They share one counter if they share a key version. Parallel senders without coordination produce CNTR low spikes. Serialise sends or partition key versions.

Related

Mid-campaign?

A live estate

Rescue, retry policy and mixed-estate forensics — or a CSV in MoreOTA if you already run the server.