Guide · TS 102 225 · 0x01

PoR 01 — RC/CC/DS failed

RC/CC/DS failed.

Status 01 is the most common security rejection mid-campaign. The card recomputed the cryptographic checksum or redundancy check and got a different value. In mixed estates the operational cause is often inventory drift — MSISDN and IMSI no longer match the key the server used. The other frequent cause is the checksum byte range: for SMS-PP, whether CPI, CPL and CHL are included is implementation-dependent, so a server that includes the wrong prefix produces packets every card rejects identically.

Usual cause

The card recomputed the cryptographic checksum or redundancy check and got a different value. Either the key is wrong, or the checksum was computed over the wrong byte range. In live estates a frequent operational cause is the wrong key for that subscriber: MSISDN and IMSI in inventory no longer match. The other common cause is the checksum byte range: whether CPI, CPL and CHL are included in the CC calculation is implementation-dependent for SMS, so a server that includes the wrong prefix produces a valid-looking packet that every card rejects.

What to do

If inventory is stale, update the MSISDN–IMSI mapping and try again. Also confirm the KID key value and key version, the algorithm and checksum length on the card, and the byte range: for SMS-PP, compute over CPL onward and compare against a known-good packet from the card vendor.

TS 102 225 §5.1.3, table 2 note 2 and note 3

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

Is PoR 01 always a wrong key?
Not always. Stale MSISDN–IMSI inventory is a frequent operational cause. So is computing the checksum over the wrong byte range for SMS-PP — compare against a known-good packet from the card vendor.
Should I retry the same packet on status 01?
No, not until something changes: fix inventory, confirm KID value and version, or correct the checksum byte range. Blind retry fails identically.

Related

Mid-campaign?

A live estate

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