- The first two Push commands sub-pills carry the HTTP OTA prefix
("HTTP OTA Trigger (Push SMS)", "HTTP OTA Store (SD admin params)"), so the
form headings drop it and read "Administrative session trigger (Push SMS)"
/ "Administrative session store data (SD admin params)".
- BIP channel opening (01) gains the same-message CAT_TP follow-up: an "Also
request the CAT_TP link establishment (02) in the same message" checkbox
with the shared CAT_TP fields (destination port mandatory, optional max SDU
/ identification data / extra TLVs). The preview and Pack then carry the
pair 80EC0101...80EC0102... as one command script (concatenated SMS when
over 140 octets) and -> Expanded Script appends both 22 Command TLVs.
Rationale (SIMalliance Stepping Stones R7 18.6): 01 carries the channel
parameters, 02 only the CAT_TP port, and the guide recommends both in the
same SMS; standalone 02 stays for cards with provisioned defaults.
- Help 2.7 EN/RU, READMEs and AGENTS document the pairing, the fact that 03 is
self-contained (it carries the mandatory OPEN CHANNEL TCP set, so no
companion 01) and the Stepping Stones PoR advice (no PoR on success; on
failure use SMS-SUBMIT / SPI2 0x20).
- pushSectionApdus vectors cover the 01+02 pair and its mandatory port;
sw cache -> simple-v250.
The Push commands pill now has three sub-pills: Trigger (Push SMS), Store
(SD admin params) and Channel / link trigger, which builds all three TS 102 226
§9 establishment requests - 01 BIP channel opening (OPEN CHANNEL), 02 CAT_TP
link, 03 TCP connection - with one shared destination-port field and
per-request field visibility. The TCP parameters are the OPEN CHANNEL TCP
set (BIP, or a direct IP connection per TS 102 483 where supported), so 03
belongs with the other channel/link requests.
The identification packet (04) is not a trigger: it presupposes an already
open TCP channel and only makes sense as a follow-up in the same message, so
it is no longer a standalone request. The TCP request carries an "Also send
the identification packet (04) in the same message" checkbox (optional data,
ICCID when empty): the preview then shows both commands (a command string sent
in one secured packet) and → Expanded Script appends one 22 Command TLV per
command. pushSectionApdus() returns the APDU list; 04 stays available in the
RAM/GP chain's PUSH row for script sequences.
Help 2.7 EN/RU, READMEs and AGENTS describe the three sub-pills and the BIP vs
direct-IP nuance; sw cache -> simple-v249; version stays 3.5.0.
html.test.js also asserts that the document is complete (ends with </html>,
every <script> closed, the inline script parses and defines cApduSwitchSubtab):
a truncated index.html made the browser fail to parse the inline script, so
every onclick handler reported "function is not defined" while the Node tests
still passed.
The former HTTP OTA pill becomes "Push commands" (RU: Пуш/триггер) and groups
everything that makes the card dial out:
- Administrative session (GP Amd B §4.7): the existing Trigger/Store UI,
unchanged, as the first section (most used).
- BIP / CAT_TP trigger (§9): request 01 BIP channel opening (optional OPEN
CHANNEL COMPREHENSION-TLVs) or 02 CAT_TP link (destination port, optional
max SDU / identification data).
- TCP trigger (§9): request 03 TCP connection (bearer, transport level with
protocol type 02, destination address 21/57/F0, NAA/APN, extra TLVs) or
04 identification packet (optional data, ICCID when absent — sent over an
already open channel).
The guided sections reuse chainPushData (the RAM/GP chain PUSH encoder) and
preview the C-APDU; mandatory parameters (02 port, 03 port + address) are
enforced there while the chain row stays lenient. Actions: Pack into Secured
packet (no auto-TAR — a §9 PUSH goes to the target application) and
→ Expanded Script (22 Command TLV import; berAppendApdu extracted from
loadExpandedScript). Each §9 request has a note separating it from the
administration session. Chain-builder PUSH command and the expanded-script
C-APDU picker are unchanged.
Tests: pushSectionApdu vectors in ts102226.test.js; help 2.7 EN/RU
restructured, READMEs, AGENTS; sw cache -> simple-v246.
Phase 1 — the Expanded Script C-APDU rows are no longer hex-only:
- chain containers gained a kind (chainKind/chainIsEmbedded/chainCommands),
so the SIM RFM / USIM RFM / RAM-GP row editors and hex builders can be
embedded as one-row "virtual" chains (ber-<kind>-<uid>) with a listener
hook (chainListen/chainNotify) refreshing the owning row.
- the C-APDU row offers Hex / SIM RFM / USIM RFM / RAM-GP; the built APDU is
echoed next to the picker and wrapped in the 22 Command TLV. GET RESPONSE
is not offered in the embedded pickers (TS 102 226 5.2.1.1).
Phase 2 — "→ Expanded Script" in the SIM RFM / USIM RFM / RAM-GP views
imports the built chain as C-APDU rows (chainApduList drops GET RESPONSE
and splits multi-APDU FID-chain selects; the RAM "To expanded" preview
stays).
Phase 3 — the TS 102 226 table 7.1/8.1/9.1 gaps:
- RFM: SEARCH RECORD (TS 102 221 11.1.7 / SEEK per TS 151 011 9.2.7),
INCREASE (11.1.8 / TS 151 011 9.2.8), CREATE FILE / DELETE FILE /
RESIZE FILE (TS 102 222 6.3/6.4/6.10, with an FCP skeleton builder and
CLA 80 for RESIZE), SET DATA / RETRIEVE DATA (11.3, block + SFI coding);
- RAM: PUT KEY (GP Card Spec 11.8) and the TS 102 226 §9 PUSH command
(80 EC 01 P2) with BIP opening (optional OPEN CHANNEL TLVs), CAT_TP
(3C/39/36), TCP (35/3C/3E/47) and identification-packet variants.
Tests: new frontend/tests/ts102226.test.js (byte-exact spec vectors for
every new command, the FCP skeletons, chainApduList) plus C-APDU row tests
in ber.test.js; 530 frontend / 390 Python green. Help EN/RU, README/RUS
and AGENTS document the Command TLV taxonomy (Tables 5.5/5.9 limits), the
picker and the new commands.
catarrh