sim client

Sébastien Lorquet squalyl at gmail.com
Thu Aug 19 13:09:14 UTC 2010


Hi,

I finally found your message. Don't know why it was routed to the spam by
google. Maybe the blue text reminds the color of viagra? Whatever...

The only identifier that can be card-unique is the SFI (short ID from 1 to
30) but it's not used by sim cards.

The 2 bytes ED/DF identifier (LID, long id) is unique in a directory context
so that a select operation is not ambiguous.
The common LID MSB is a classic limitation (used in GSM) that allows to save
memory: Just save the LSB in the file descriptor and the MSB in the DF.
But it's an arbitrary limitation. According to ISO7816-4, LIDs can be
absolutely what you want.

Okay for the result codes to trigger a PIN request.

Sebastien

On Thu, Aug 19, 2010 at 11:42 AM, Andreas.Eversberg <
Andreas.Eversberg at versatel.de> wrote:

>  hi sebastien,
>
> thanx for you advice. i will have job names like SIM_JOB_READ,
> SIM_JOB_UPDATE, SIM_JOB_GSMALGO,... i am a bit unsure about the path array.
> i always thought that each EF has a unique ID. the DF where it is located,
> can be determined by the first byte of the EF ID. but if it is possible to
> have a sim with multiple DFgsm, then a path is required of course.
>
> for PIN handling, i will use result codes that gives cause of an error. if
> a PIN is required (to read the IMSI for example), the error code would show
> that. then the sim reading process prompts for PIN. the SIM can be unlocked
> ("enabled") by a message like SIM_JOB_ENABLE_CHV1.
>
> outgoing data (UPDATE) is located behind the header. incomming data is also
> located behind the header when the job returns (callback fn is called). but
> the READ job must be triggered.
>
> when my code must deal with record types, i will expand the header. i will
> create the API step by step.
>
> regards
>
> andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100819/84f7a742/attachment.html>


More information about the baseband-devel mailing list