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
On Thu, Aug 19, 2010 at 11:42:44AM +0200, Andreas.Eversberg 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.
I think it isn't good to just think of a normal SIM, but keep it as flexible with regard to smartcards compliant to 7816-4. Adding a path will not really make things terribly more complex, so I'd also agree with Sebastien to include tha path and be more flexible as a result.
Hi,
Well the reply from Harald tells me I didn't get Andreas' response in full, and it seems some replies have to be made.
Can someone forward it to the list?
Regards Sebastien
On Thu, Aug 19, 2010 at 1:40 PM, Harald Welte laforge@gnumonks.org wrote:
On Thu, Aug 19, 2010 at 11:42:44AM +0200, Andreas.Eversberg 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.
I think it isn't good to just think of a normal SIM, but keep it as flexible with regard to smartcards compliant to 7816-4. Adding a path will not really make things terribly more complex, so I'd also agree with Sebastien to include tha path and be more flexible as a result.
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@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
baseband-devel@lists.osmocom.org
-
Andreas.Eversberg -
Harald Welte -
Sébastien Lorquet