got it....  i thought you meant that in a general term, for other APDU commands such as GET RECORD or BINARY READ

sending PROCEDURE would not help as REMOTE SIM side will not start sending data until after we ACK with INS and subsequent

bytes are obtained and relayed to remote before it will start answering

On 11/10/17 1:38 AM, Harald Welte wrote:

Hi Thomas,

On Thu, Nov 09, 2017 at 08:59:45PM -0500, Thomas Chen wrote:

...

my understand of the protocol is that

ME => SIM (first 5 bytes of APDU)

SIM <=== PROCEDURE (either INS as ack, or 0x60 to hold up the protocol)

but that does not help remote sim, as remote SIM would need the susequent bytes which will not come until we send back INS, so just holding off ME with 0x60 does not alleviate the problem of network delay

you don't hold off the ME at that point. Presuming it is "RUN GSM ALGORITHM" command, then the actual command from ME to card continues here with the random challenge.

Later, a GET RESPONSE is issued from ME to SIM to obtain the SRES + Kc values, and this is where we can delay with waiting time extension (0x60) until we have the result.

Hi Thomas,

remote SIM environment as in OTA? Selecting an AID remotely might not make sense, that's what TARs are for .. but not sure what you're trying to achieve and what context do you send the SELECT in..

Lukas

On Fri, Nov 24, 2017 at 6:53 PM, Thomas Chen tchen@on-go.com wrote:

i am seeing some strnge stuff with SIMTRACE .. when i have a modem communicating with SIM, and simtrace in sniffer mode i see a command 0x00 0xa4 0x04 0x04 0x10 + data (0xa0 0x00 0x00 0x00 0x87 0x10 0x02 0xff 0xff 0xff 0xff 0x89 0x06 0x19 0x00 0x00) and got response + status (0x61, 0x44)

but in remote SIM environment. this SIM card return 0x69 0x99

do you know what that mean ??? i dont know whether it is timing or something else ?

all previous commands seem to work just fine

thanks