The live report: an SPI2 01 secured packet reported no PoR. For such a
packet TS 31.115 4.2/4.4 (b6=0) has the Response Packet retrieved by the
ME from the ENVELOPE exchange (SEND SHORT MESSAGE is the b6=1 case), but
_send_envelope only asked for response bytes after a 61xx answer - the
card signals them with 62xx/63xx instead (the "more data" quirk the
remote-command SWs already acknowledge, _ram_remote_sw_ok), so the whole
PoR stayed on the card and the late-PoR STATUS poll found nothing.
_envelope_get_response (shared with _send_event_download, which had the
same 61xx-only code): a 61xx names the GET RESPONSE length; a 62xx/63xx
without data gets Le 256 (00c0000000 - a bare 61 no longer emits the
odd-length '%02x' % 0x100 APDU). The result is adopted when bytes were
delivered (or for a 61xx); otherwise the warning stays, so the v3.6.58
SEND-SM PoR path (the STATUS poll) keeps working.
Tests: the 61xx length, the 63xx+PoR fetch (Le 256), the bare-61
encoding, the warning-kept path (the poll still runs) and the
event-download sharing. 887 frontend + 880 Python; sw cache simple-v431.
catarrh
d20aac4aeb
