Banks PCSC transaction timeout with Card mute or absent
Hello, I am having difficulty with a particular SIM card over osmo-remsim. On the bank daemon side, PCSC is timing out after 1 second on the same transaction (modemToCard: 81f2400202) after every reset. This behavior is very reliable and happens on every reset/initialization sequence from the modem. When I enable PCSC debugging, I see it is getting back the error CCID error 0xFE “Card absent or mute” from the CCID reader. When I use this card directly attached to the modem, everything is fine and the modem can go online (but I have no insight as to whether the modem is encountering an issue with the same APDU, or not).f When this transaction error occurs, osmo-remsim-bankd closes the connection, leading to a removal/insertion and card reset event. So, the system is in infinite loop of resetting the card, making a bunch of successful APDU transactions, timing out on the offending transaction, and then resetting again all over again... As an experiment, I changed osmo-remsim-bankd behavior to ignore the PCSC error, leave the connection open, and return a general error (0x6F 0x00) to the modem. When I do that, the modem periodically re-sends the offending APDU every few seconds, but, despite that, everything else is fine and the modem can now go online with this card over osmo-remsim. I’m thinking either card needs more time to answer this query, or perhaps it does not support this query at all. Based on some earlier troubleshooting it appears to be related to eSIM (eUICC) functionality. This particular card reports as an eSIM (side note: curiously, its EID is blank). When I use old modem firmware that does not support eSIM capabilities, the card works just fine over osmo-remsim. It is only when I upgrade the modem firmware to a version that supports eSIM that this problem appears. Other things I tried: - Upgrading to latest libccid and pcsc-lite — no change - Using a different card reader with different chip set — no change, and both are listed as “should be supported” by pcsc-lite. A couple questions: - Is there a way to change the timeout? I tried modifying libccid to set bBWI to 0xFF for this transaction (it was 0x00), but that had to effect. Internal timeouts within pcscd seem to be set to 3 seconds, and so I do not think they are coming into play, here. - What are your feelings on having osmo-remsim-bankd ignore this error and return a 0x6f 0x00? - Any other ideas? Here is the truncated log of traffic leading up to the offending APDU: local4.info: 2024-03-26 03:10:31.221037 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(621982054221001c0383026f408a01058b036f06058002005488009000) local4.info: 2024-03-26 03:10:31.228286 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00b208bc3e) local4.info: 2024-03-26 03:10:31.242339 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(800101a40683010195010880015aa40683010a9501088401d4a40683010a950108ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff9000) local4.info: 2024-03-26 03:10:31.250619 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00b205043e) local4.info: 2024-03-26 03:10:31.255170 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(800103a406830101950108800158a40683010a9501088401d4a40683010a950108ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff9000) local4.info: 2024-03-26 03:10:31.263534 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00b209043e) local4.info: 2024-03-26 03:10:31.267873 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(800101a406830101950108800102a406830181950108800158a40683010a9501088401d4a40683010a950108ffffffffffffffffffffffffffffffffffff9000) local4.info: 2024-03-26 03:10:31.276622 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00b206043e) local4.info: 2024-03-26 03:10:31.280369 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(8001019000800102a406830101950108800158a40683010a9501088401d4a40683010a950108ffffffffffffffffffffffffffffffffffffffffffffffff9000) local4.info: 2024-03-26 03:10:31.288355 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00b201043e) local4.info: 2024-03-26 03:10:31.293560 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(800101900080015aa40683010a9501088401d4a40683010a950108ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff9000) local4.info: 2024-03-26 03:10:31.304765 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00a40804047fff6fc6) local4.info: 2024-03-26 03:10:31.312115 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(611c) local4.info: 2024-03-26 03:10:31.316190 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00c000001c) local4.info: 2024-03-26 03:10:31.319163 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(621a8205422100080183026fc68a01058b036f0601800200088801d09000) local4.info: 2024-03-26 03:10:31.328212 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00a2010408ffffffffffffffff) local4.info: 2024-03-26 03:10:31.330957 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(6282) local4.info: 2024-03-26 03:10:31.335619 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(81f2400202) local4.info: 2024-03-26 03:10:32.363083 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_pcsc.c:319 [000 B1:0 CONN_CLIENT_MAPPED_CARD] SCardTransmit: Transaction failed. (0x80100016) local4.info: 2024-03-26 03:10:32.363239 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:970 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Error handling RSPRO local4.info: 2024-03-26 03:10:32.363364 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:1051 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Error -2146435050 occurred: Cleaning up state local4.info: 2024-03-26 03:10:32.375002 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:492 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Changing state to ACCEPTING local4.info: 2024-03-26 03:10:32.378255 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1764 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:1036 [001 B65535:65535 ACCEPTING] Accepted connection from 100.64.33.10:35063 And here is the experimental patch to osmo-remsim-bankd: diff --git a/src/bankd/bankd.h b/src/bankd/bankd.h index 8a48a21..3c0f18f 100644 --- a/src/bankd/bankd.h +++ b/src/bankd/bankd.h @@ -17,6 +17,8 @@ #include "rspro_client_fsm.h" #include "debug.h" +#define MAX_CONSECUTIVE_TRANSCEIVE_ERRORS 5 + extern struct value_string worker_state_names[]; #define LOGW(w, fmt, args...) \ @@ -102,6 +104,9 @@ struct bankd_worker { /* last known state of the SIM card reset indication */ bool last_resetActive; + + /* number of consecutive transceive errors */ + int consecutive_transceive_errors; }; /* bankd card reader driver operations */ diff --git a/src/bankd/bankd_main.c b/src/bankd/bankd_main.c index 90b05d8..c6cafe0 100644 --- a/src/bankd/bankd_main.c +++ b/src/bankd/bankd_main.c @@ -120,6 +120,7 @@ static struct bankd_worker *bankd_create_worker(struct bankd *bankd, unsigned in worker->ops = &pcsc_driver_ops; worker->last_vccPresent = true; /* allow cold reset should first indication be false */ worker->last_resetActive = false; /* allow warm reset should first indication be true */ + worker->consecutive_transceive_errors = 0; /* in the initial state, the worker has no client.fd, bank_slot or pcsc handle yet */ @@ -787,8 +788,21 @@ static int worker_handle_tpduModemToCard(struct bankd_worker *worker, const Rspr rc = worker->ops->transceive(worker, mdm2sim->data.buf, mdm2sim->data.size, rx_buf, &rx_buf_len); - if (rc < 0) - return rc; + + if (rc < 0) { + LOGW(worker, "Transceieve error %d (count %d/%d)\n", rc, + worker->consecutive_transceive_errors, MAX_CONSECUTIVE_TRANSCEIVE_ERRORS); + + if (++worker->consecutive_transceive_errors == MAX_CONSECUTIVE_TRANSCEIVE_ERRORS) { + return rc; + } + + rx_buf[0] = 0x6f; + rx_buf[1] = 0x00; + rx_buf_len = 2; + } + + worker->consecutive_transceive_errors = 0; LOGW(worker, "Tx RSPRO tpduCardToModem(%s)\n", osmo_hexdump_nospc(rx_buf, rx_buf_len)); /* encode response PDU and send it */ Regards, James
Hi James, On Wed, Mar 27, 2024 at 12:00:50PM -0400, James Tavares wrote:
I am having difficulty with a particular SIM card over osmo-remsim. On the bank daemon side, PCSC is timing out after 1 second on the same transaction (modemToCard: 81f2400202) after every reset.
I'm sorry to hear.
This behavior is very reliable and happens on every reset/initialization sequence from the modem. When I enable PCSC debugging, I see it is getting back the error CCID error 0xFE “Card absent or mute” from the CCID reader. When I use this card directly attached to the modem, everything is fine and the modem can go online (but I have no insight as to whether the modem is encountering an issue with the same APDU, or not).f
Do you have a SIMtrace2 around using which you could trace the successful communication when using the SIM directly in the modem?
Based on some earlier troubleshooting it appears to be related to eSIM (eUICC) functionality. This particular card reports as an eSIM (side note: curiously, its EID is blank). When I use old modem firmware that does not support eSIM capabilities, the card works just fine over osmo-remsim. It is only when I upgrade the modem firmware to a version that supports eSIM that this problem appears.
The 81f2400202 is a "GET STATUS" APDU. the '1' in 81 indicates it happens on a logical channel, not directly on the raw APDU It seems that both GlobalPlatform as well as ETSI TS 102 221 both specify a F2 command, and both for CLA=8x (first nibble 8, any lower bits). Oddly enough, according to https://gitea.osmocom.org/osmocom/libosmocore/src/branch/master/src/sim/clas... the ISO 7816 "case" of those two is different: TS 102 221 is marked as case '2' while GlobalPlatform is marked as case '4' The way how the uicc_sim_ins_case[] is sorted, the ETSI spec will be used first, and hence case '2' is assumed. Those cases refer to ISO 7816-3 12.1.2, where * case 2 means that there are no command bytes (Nc=0) but there are response bytes (Nr > 0) * case 4 measn that there is both Nc > 0 and Nr > 0 I will investigate this further; maybe there's a bug in class_tables.c, or if we somehow have to work around this in some other way.
- Is there a way to change the timeout? I tried modifying libccid to set bBWI to 0xFF for this transaction (it was 0x00), but that had to effect. Internal timeouts within pcscd seem to be set to 3 seconds, and so I do not think they are coming into play, here.
USB-CCID Readers typically handle all those timeouts inside a TPDU (waiting time, guard time, etc.) internally. The timeouts are part of the firmware.
- What are your feelings on having osmo-remsim-bankd ignore this error and return a 0x6f 0x00?
This sounds like a very bad approach, basically plastering over the problem at a much higher level. Without understanding the modem firmware in detail it's not clear what the unexpected consequences of that might be.
- Any other ideas?
Here is the truncated log of traffic leading up to the offending APDU: [...]
in general, a pcap file with the rspro communication is likely easier to analyze. Or even better: Enable the gsmtap logging (-g 127.0.0.1 and then tace a pcap file of 'lo'). This pcap file can then be analyzed by pySim-trace.py for meaningful high-level decode. Admittedly, pySim-trace is much more recent than osmo-remsim and I haven't used them in combination yet, but the GSMTAP SIM pcap format should ensure interoperability.
local4.info: 2024-03-26 03:10:31.221037 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(621982054221001c0383026f408a01058b036f06058002005488009000) local4.info: 2024-03-26 03:10:31.228286 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00b208bc3e) local4.info: 2024-03-26 03:10:31.242339 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(800101a40683010195010880015aa40683010a9501088401d4a40683010a950108ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff9000) local4.info: 2024-03-26 03:10:31.250619 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00b205043e) local4.info: 2024-03-26 03:10:31.255170 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(800103a406830101950108800158a40683010a9501088401d4a40683010a950108ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff9000) local4.info: 2024-03-26 03:10:31.263534 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00b209043e) local4.info: 2024-03-26 03:10:31.267873 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(800101a406830101950108800102a406830181950108800158a40683010a9501088401d4a40683010a950108ffffffffffffffffffffffffffffffffffff9000) local4.info: 2024-03-26 03:10:31.276622 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00b206043e) local4.info: 2024-03-26 03:10:31.280369 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(8001019000800102a406830101950108800158a40683010a9501088401d4a40683010a950108ffffffffffffffffffffffffffffffffffffffffffffffff9000) local4.info: 2024-03-26 03:10:31.288355 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00b201043e) local4.info: 2024-03-26 03:10:31.293560 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(800101900080015aa40683010a9501088401d4a40683010a950108ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff9000) local4.info: 2024-03-26 03:10:31.304765 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00a40804047fff6fc6) local4.info: 2024-03-26 03:10:31.312115 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(611c) local4.info: 2024-03-26 03:10:31.316190 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00c000001c) local4.info: 2024-03-26 03:10:31.319163 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(621a8205422100080183026fc68a01058b036f0601800200088801d09000) local4.info: 2024-03-26 03:10:31.328212 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(00a2010408ffffffffffffffff) local4.info: 2024-03-26 03:10:31.330957 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:793 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Tx RSPRO tpduCardToModem(6282)
all of the above is communication on the primary logical channel (second nibble of CLA octet is 0), so it doesn't have any context to the parallel communication happening on other logical channels, like the 81 on lchan1 below. Having a full/proper trace (ideally GSMTAP as described above) would allow to check what is happening on that logical channel 1 at an earlier time, ideally back to when itw as opened.
local4.info: 2024-03-26 03:10:31.335619 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:766 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Rx RSPRO tpduModemToCard(81f2400202) local4.info: 2024-03-26 03:10:32.363083 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_pcsc.c:319 [000 B1:0 CONN_CLIENT_MAPPED_CARD] SCardTransmit: Transaction failed. (0x80100016) local4.info: 2024-03-26 03:10:32.363239 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:970 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Error handling RSPRO local4.info: 2024-03-26 03:10:32.363364 bdu-arm-ce-imx8mp bankd-wrapper[1762]: 1763 DBANKDW INFO ../../../git/src/bankd/bankd_main.c:1051 [000 B1:0 CONN_CLIENT_MAPPED_CARD] Error -2146435050 occurred: Cleaning up state
-- - Harald Welte <laforge@osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi James, On Mon, Apr 01, 2024 at 10:03:34PM +0200, Harald Welte wrote:
Based on some earlier troubleshooting it appears to be related to eSIM (eUICC) functionality. This particular card reports as an eSIM (side note: curiously, its EID is blank). When I use old modem firmware that does not support eSIM capabilities, the card works just fine over osmo-remsim. It is only when I upgrade the modem firmware to a version that supports eSIM that this problem appears.
The 81f2400202 is a "GET STATUS" APDU. the '1' in 81 indicates it happens on a logical channel, not directly on the raw APDU
It seems that both GlobalPlatform as well as ETSI TS 102 221 both specify a F2 command, and both for CLA=8x (first nibble 8, any lower bits).
Oddly enough, according to https://gitea.osmocom.org/osmocom/libosmocore/src/branch/master/src/sim/clas... the ISO 7816 "case" of those two is different: TS 102 221 is marked as case '2' while GlobalPlatform is marked as case '4'
The way how the uicc_sim_ins_case[] is sorted, the ETSI spec will be used first, and hence case '2' is assumed.
Those cases refer to ISO 7816-3 12.1.2, where * case 2 means that there are no command bytes (Nc=0) but there are response bytes (Nr > 0) * case 4 measn that there is both Nc > 0 and Nr > 0
I will investigate this further; maybe there's a bug in class_tables.c, or if we somehow have to work around
The class_tables.c is correct: * ETSI TS 102 221 Section 11.1.2.2 defines a STATUS command for CLA 8x with INS F2 that does *not* have a command data section, and hence is 'case 2' * GlobalPlatform (v2.2 Setion 11.4) also defines a GET STATUS command with CLA 8x and INS F2 which *does* have a Lc + command data section (the 'search criteria') and hence is 'case 4' As the card is both an UICC and a GlobalPlatform card, it's not really clear to me which of the two commands is executed. It's also not clear to me how one is supposed to properly distinguish those situations. Usually the CLA+INS combined are sufficient to know which instruction of which spec is being processed, but it seems there is at least this one case where it's not clear. One likely would need to track higher-layer state like "what application (if any) is currently selected on this logical channel" in order to know if case 2 or case 4 applies. As a quick hack, you could try the attached patch against libosmocore. This is just a hack to see if we really have found the culprit. It would only work if no other part of the communication uses the UICC F2 instruction at another time. It's far from a proper solution, but worth a try. -- - Harald Welte <laforge@osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi James, On Mon, Apr 01, 2024 at 10:14:40PM +0200, Harald Welte wrote:
As a quick hack, you could try the attached patch against libosmocore.
This is just a hack to see if we really have found the culprit. It would only work if no other part of the communication uses the UICC F2 instruction at another time. It's far from a proper solution, but worth a try.
I've meanwile figured out that the upper 4 bits of the P1 octet are guaranteed to be different in the ETSI UICC vs. GlobalPlatform F2 command. So we can use those as an indicator to distinguish the two situations. See the [still untested] patch at https://gerrit.osmocom.org/c/libosmocore/+/36501 Feel free to give that one a try and let us know if that helps. Thanks, Harald -- - Harald Welte <laforge@osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Apr 2, 2024, at 8:19 AM, Harald Welte <laforge@osmocom.org> wrote:
I've meanwile figured out that the upper 4 bits of the P1 octet are guaranteed to be different in the ETSI UICC vs. GlobalPlatform F2 command. So we can use those as an indicator to distinguish the two situations. See the [still untested] patch at https://gerrit.osmocom.org/c/libosmocore/+/36501
Feel free to give that one a try and let us know if that helps.
Thank you, Harald! Can you clarify, is this patch needed on the client-st2 side, the bankd side, or both? I am also seeing that I am running a fairly old version of libosmocore, circa 2022-09-19. Perhaps I should update. Please give me a few days to try this patch, and I will get back to you. Regards, James
On 3 April 2024 05:47:08 CEST, James Tavares <james.tavares.ml@gmail.com> wrote:
Thank you, Harald! Can you clarify, is this patch needed on the client-st2 side, the bankd side, or both?
It's needed on the remsim-client side.
I am also seeing that I am running a fairly old version of libosmocore, circa 2022-09-19. Perhaps I should update.
This might be a good idea. I do believe there were other simtrace/cardem related fixes since 2022. If you prefer using tagged/stable versions, take the last release and apply the patch on it. Looking forward to hearing your results. Regards, Harald -- Sent from a mobile device. Please excuse my brevity.
participants (3)
-
Harald Welte -
Harald Welte -
James Tavares