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/class_tables.c > 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 <[email protected]> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
