AT command APDU driver violates 3GPP TS 27.007 and will not work on e.g. MC7455

[laf0rge]

The AT command APDU driver seems to misunderstand how 3GPP TS 27.007 works. It assumes that the unsoliciated +CCHO response will return the logical channel number, and will then by itself patch that number into the CLA byte.

However, 3GPP TS 27.007 works completely differently:

• the logical channel number is only visible between Modem (MT) and card (eUICC)
• the +CCHO unsolicited response returns a "handle", which is of local significance only between the modem and the application issuing the AT commands
• the application must sent CLA bytes where the logical channel bits are zero; the MT (Modem) will patch the logical number into it

For example, see the following exchange with a Sierra MC7455 modem:

AT_DEBUG: AT+CCHO="A0000005591010FFFFFFFF8900000100"
AT_DEBUG: +CCHO: 000000000385a7cf

clearly the 0x385a7cf is not a logical channel number, but a handle that has no significance other than it must be used for all other subsequent operations like +CCHC or +CGLA

Spec reference: 3GPP TS 27.007 Rel 17.8.0 Section 8.45 which specificly states what I wrote above:

In this case it will be up to the MT to manage the logical channel part of the APDU CLASS byte and to ensure that the chosen logical channel is relevant to the indicated in the AT command.

To me it looks like the AT command driver was not written against what TS 27.007 specifies, but maybe against one specific modem implementation that may itself return the logical channel in the AT+CCHO. However, that is pure coincidence and cannot be assumed in general

[urielka]

@laf0rge look at my patch: https://github.com/estkme-group/lpac/pull/139

Not the cleanest but at least it is working and might be useful for other poor folks that run into this issue