mirror of
https://gitea.osmocom.org/sim-card/pysim.git
synced 2026-09-28 15:06:33 +03:00
Eric Wild
515925228d
TS 102 221 section 7.3.1.1.4 clause 4b lets the card answer a case #4 command TPDU with a 62xx/63xx warning, upon which the terminal sends a dummy GET RESPONSE to obtain the 61xx that announces the response length. __send_apdu_T0() applies that unconditionally, to the status word that terminates a GET RESPONSE... That is not "redundant", as per GPC v2.3.1 section 11.4.3.2 table 11-38 GP GET STATUS (80 F2) answers 6310 "more data available", meaning reissue the command as get next occurrence(s) with P2 bit 1 set (11.4.2.2 table 11-34), so for example a paginated registry listing exchange looks like this: 84f22000024f00 => 61e4 first match, e4 bytes waiting 84c00000e4 => <page 1> 6310 more matches pending 84c0000000 => 6982 <- unsolicited, card rejects it The card rejects the unsolicited GET RESPONSE with 6982, our SCP02 session breaks, and the next command fail with 6985. The 6310 never reaches ADF_SD.get_status() either, so the pagination loop exits after page 1 and prints a sliently truncated listing. Observed with a SJA5. Fix by turning clause 4b würgaround into what it should be: a one shot reaction to the SW returned for the command TPDU. While at it, stop ADF_SD.get_status() from silently returning a truncated registry: it treated every status word other than 6310 as "nothing more to report". 6A88 is now the explicit empty result and anything else raises, so a partial listing can no longer silently pass. Adds unit tests for all of that so we dont break basic T0 things. Change-Id: I10f8afa8dd5623a49a6a0e7132607b3a1fad2d8c