The RAM install form sent the `STK parameters (hex)` field, which was only
regenerated when the toolkit checkbox or the mode select changed - editing
the TAR (or any other toolkit field) afterwards was silently dropped. The
live install therefore carried the form defaults (TAR B00001, textLen 0,
menus 0, MSL 16, channels 0) instead of the entered AF4D01 / MSL 12 /
channels 1, and the card rejected the install parameters with 6A80
(TS 102 226 8.2.1.3.2.7: a TAR already assigned on the card).
- every `rc-tk-*` field regenerates the hex on input/change; the install
recomputes it at send time unless the user hand-edited the hex
(`dataset.manual`), so the edit order can no longer drop values;
- one pure `stkParamsBuild` serves the RAM form (`buildRcToolkitParams`) and
the RAM/GP chain rows (`buildTkParams`) - no drift between them (the chain
row also gains the menu-ID <= 7F check);
- applet TAR field: empty by default, no placeholder - B0 00 01 is the
allocated ADF RFM TAR (TS 101 220 Annex D), not an applet TAR; an empty
field is coded as TAR length 00 (the card may take a TAR from the AID only
when the AID carries one, PIX hex digits 15-20);
- the chain builder's INSTALL/LOAD rows drop the trailing Le (the v3.6.8
server form; a trailing Le made the card execute a phantom command);
- tests: stk_params.test.js (the decrypted live parameters, empty-TAR
coding, CA wrapper, long-form lengths, rejection cases, form wiring, and
the form -> hex path with the real builders) and ram_counter_flow.test.js
(the Explore delete persists the consumed counter through the real
ramSaveCntr); STK fixtures no longer use B00001.
631 frontend / 496 Python green; version 3.6.9; sw simple-v282.
The 01 (BIP channel opening) variant was raw hex while 03 (TCP) had a detailed
form. The asymmetry is real - 01 accepts any OPEN CHANNEL COMPREHENSION-TLVs
(TS 102 226 9.2.1) while 03's set is fixed by 9.2.3 - so 01 now offers a
Fields/Hex switch instead of a rigid form:
- Fields (default) composes the most-used OPEN CHANNEL parameters per
SIMalliance Stepping Stones R7 18.6.1: bearer description (default 35 01 03),
transport protocol (UDP 01 / TCP 02, UICC client, remote - the only values
TS 102 223 6.6.27.4 allows when the transport level is present) with the
destination port, destination address, NAA/APN, buffer size, alpha
(transparent checkbox -> 05 00 = no user confirmation) and an extra-TLVs
field for login/password and anything else. The local address is never
emitted (9.2.1 and the guide forbid it).
- Hex keeps the raw COMPREHENSION-TLVs field; pushOpenChannelTlvs() is a pure,
vector-tested composer feeding the same encoder as before.
Help 2.7 EN/RU and the READMEs explain the two modes; sw cache ->
simple-v251; version stays 3.5.0.
- 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