7 Mar
2010
7 Mar
'10
1:41 a.m.
hi!
we now have a 'struct timer_list' API, its use is similar to that of
the linux kernel (and openbsc).
The caller (e.g. your driver/app) allocates a 'struct timer_list', sets
the 'cb' function pointer to a callback function, and then schedules the
timer with 'schedule_timer(&my_struct_tm, 600) for expiration in e.g. 600ms
from now.
Once the timer expires, it will call the callback. There's also an
'unsigned long' argument that you can pass along.
Calling the timer expiration routines happens by calling update_timers() from
the while (1) loop in the main program. This will of course change once
we have a scheduler and tasks.
Cheers,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
9 Mar
9 Mar
3:12 p.m.
New subject: FYI: SIM
Hi folks.
I have now getting interrupts and i am sending the first little APDUs to
the card. I think i will have something that basicly works soon. But up
to now i think it will be impossible to save processing time during the
transmission - wait phases without having semaphores (or something
semilar that can be used to wait for an event without wasting processing
time in a while loop.) However - this only makes sense with a
multitasking os which we actually do not have ;-)
The driver will get a function like sim_card_transceive(*message,
*response) or so on because a transaction with the card will never be
receive or send only. You always send something to the card and you
always get something back.
The response and answer apdu structures will be the same as in XCOS and
i think i can reuse a lot of the good old XCOS header files that contain
basic constants, returncodes ect...
Thanks a lot to roh who showed me how i can register an interrupt.
regards.
Philipp
4:21 p.m.
New subject: FYI: SIM
Hi,
congrats.
Does the chip manages T=0 or T=1 by itself or do you have to implement it in
software?
Indeed APDU are always exchanged. If the card doesn't answer, it's an error
condition. it should be reported by an error status return value. But the
complete exchange can be long, a card may send "time extension requests".
The reset procedure requires a dedicated API.
What about PPS, ie line speed negociation? This feature is described in
ISO7816-3, and also in TS 11.11 chapter 5.8.2.
Your driver need 4 functions:
-init driver
-stop driver
-reset card and return ATR
-exchange APDU
and, maybe
-suspend and resume, which can stop the clock.
I think official sim cards can be put in sleep state, that the clock can be
stopped, and this sort of energy saving stuff. I don't know a lot about
this, and we don't need this in a first version.
----- Update status for the on-card project: -----
Reminder : I'm using javacard 2.x.y
I'm still working on the file system implementation, I want it sufficiently
versatile for others projects too, so it's a bit long, but already working.
I have routines to create files and directories, support binary files,
record files and directories. I still need to create write() and read()
routines, but they are quite trivial.
I'm spending time on the file selection, even if the SIM spec supports only
a few modes.
The first goal is to have a basic applet that's the most ISO7816-4
compatible, then a sim specific version. The functionalities are equivalent
, but the apdu formats are a bit different.
The final goal is to have the ability to create any file structure (GSM or
not) holding any possible data, without neglecting security (of files, not
gsm algs ;) ).
Speaking of this, the COMP128 alg is already ported to javacard thanks to C
code available on the web. If someone has test vectors (IE encryption
results verified by someone else), I'll be happy to try them.
I still have a small doubt for high-update rate files. What is an high
update rate? Can this really wear a card's eeprom? I may have to create a
specific file type to implement wear levelling, using a log/cyclic
structure. I don't know the urgency level of this feature.
Regards
Sebastien
On Tue, Mar 9, 2010 at 3:12 PM, dexter <zero-kelvin(a)gmx.de> wrote:
Hi folks.
I have now getting interrupts and i am sending the first little APDUs to
the card. I think i will have something that basicly works soon. But up to
now i think it will be impossible to save processing time during the
transmission - wait phases without having semaphores (or something semilar
that can be used to wait for an event without wasting processing time in a
while loop.) However - this only makes sense with a multitasking os which we
actually do not have ;-)
The driver will get a function like sim_card_transceive(*message,
*response) or so on because a transaction with the card will never be
receive or send only. You always send something to the card and you always
get something back.
The response and answer apdu structures will be the same as in XCOS and i
think i can reuse a lot of the good old XCOS header files that contain basic
constants, returncodes ect...
Thanks a lot to roh who showed me how i can register an interrupt.
regards.
Philipp
4:25 p.m.
New subject: FYI: SIM
Something more of a note for later:
I don't know which GSM stack layer needs to exchange APDUs. I guess it's not
level 1, so apdus will be exchanged through the serial link with the phone.
It may be nice to have a pcsclite driver to drive the sim card in the phone.
Then we'll be able to use a SIM cards connected to the real phone, or a ccid
smart card reader connected to the PC running the layer2/layer3, using the
same API.
Sebastien
On Tue, Mar 9, 2010 at 4:21 PM, Sébastien Lorquet <squalyl(a)gmail.com> wrote:
Hi,
congrats.
Does the chip manages T=0 or T=1 by itself or do you have to implement it
in software?
Indeed APDU are always exchanged. If the card doesn't answer, it's an error
condition. it should be reported by an error status return value. But the
complete exchange can be long, a card may send "time extension requests".
The reset procedure requires a dedicated API.
What about PPS, ie line speed negociation? This feature is described in
ISO7816-3, and also in TS 11.11 chapter 5.8.2.
Your driver need 4 functions:
-init driver
-stop driver
-reset card and return ATR
-exchange APDU
and, maybe
-suspend and resume, which can stop the clock.
I think official sim cards can be put in sleep state, that the clock can be
stopped, and this sort of energy saving stuff. I don't know a lot about
this, and we don't need this in a first version.
----- Update status for the on-card project: -----
Reminder : I'm using javacard 2.x.y
I'm still working on the file system implementation, I want it sufficiently
versatile for others projects too, so it's a bit long, but already working.
I have routines to create files and directories, support binary files,
record files and directories. I still need to create write() and read()
routines, but they are quite trivial.
I'm spending time on the file selection, even if the SIM spec supports only
a few modes.
The first goal is to have a basic applet that's the most ISO7816-4
compatible, then a sim specific version. The functionalities are equivalent
, but the apdu formats are a bit different.
The final goal is to have the ability to create any file structure (GSM or
not) holding any possible data, without neglecting security (of files, not
gsm algs ;) ).
Speaking of this, the COMP128 alg is already ported to javacard thanks to C
code available on the web. If someone has test vectors (IE encryption
results verified by someone else), I'll be happy to try them.
I still have a small doubt for high-update rate files. What is an high
update rate? Can this really wear a card's eeprom? I may have to create a
specific file type to implement wear levelling, using a log/cyclic
structure. I don't know the urgency level of this feature.
Regards
Sebastien
On Tue, Mar 9, 2010 at 3:12 PM, dexter <zero-kelvin(a)gmx.de> wrote:
Hi folks.
I have now getting interrupts and i am sending the first little APDUs to
the card. I think i will have something that basicly works soon. But up to
now i think it will be impossible to save processing time during the
transmission - wait phases without having semaphores (or something semilar
that can be used to wait for an event without wasting processing time in a
while loop.) However - this only makes sense with a multitasking os which we
actually do not have ;-)
The driver will get a function like sim_card_transceive(*message,
*response) or so on because a transaction with the card will never be
receive or send only. You always send something to the card and you always
get something back.
The response and answer apdu structures will be the same as in XCOS and i
think i can reuse a lot of the good old XCOS header files that contain basic
constants, returncodes ect...
Thanks a lot to roh who showed me how i can register an interrupt.
regards.
Philipp
4:54 p.m.
New subject: FYI: SIM
On Tue, Mar 09, 2010 at 04:25:11PM +0100, Sébastien Lorquet wrote:
I don't know which GSM stack layer needs to
exchange APDUs. I guess it's not
level 1,
In normal GSM stacks, yes, the Layer1 provides an abstraction layer for
SIM card access.
Hwoever, the actual SIM card read/write commands come from Layer 3 or
the application above that.
so apdus will be exchanged through the serial link
with the phone.
It may be nice to have a pcsclite driver to drive the sim card in the phone.
Then we'll be able to use a SIM cards connected to the real phone, or a ccid
smart card reader connected to the PC running the layer2/layer3, using the
same API.
Yes, I like that idea, and we can easily use yet another of our HLDC
data link connections for this.
However, it seems almost like a bit of over-engineering to me to go a
far as to support PC/SC. Sure, it's a cool hack, and if somebody has
an interest in it and some time to spare.
But then, as long as the Layer3 is on the PC, it would be fine if it can
support real PC/SC readers. Only when we start to support running
layer3 inside the phone, we would require the use of the SIM card reader
inside the phone.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4:59 p.m.
New subject: FYI: SIM
Hmm we can take this the reverse way:
Instead of implementing PCSC for the phone SIM, we can implement the phone
API for PCSC.
This will me MUCH more simpler.
A thread with a queue to collect the commands and call the callback when the
response is received, then we're done (yes, pcsc is synchronous)
On Tue, Mar 9, 2010 at 4:54 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
On Tue, Mar 09, 2010 at 04:25:11PM +0100, Sébastien
Lorquet wrote:
I don't know which GSM stack layer needs to
exchange APDUs. I guess it's
not
level 1,
In normal GSM stacks, yes, the Layer1 provides an abstraction layer for
SIM card access.
Hwoever, the actual SIM card read/write commands come from Layer 3 or
the application above that.
so apdus will be exchanged through the serial
link with the phone.
It may be nice to have a pcsclite driver to drive the sim card in the
phone.
Then we'll be able to use a SIM cards
connected to the real phone, or a
ccid
smart card reader connected to the PC running the
layer2/layer3, using
the
same API.
Yes, I like that idea, and we can easily use yet another of our HLDC
data link connections for this.
However, it seems almost like a bit of over-engineering to me to go a
far as to support PC/SC. Sure, it's a cool hack, and if somebody has
an interest in it and some time to spare.
But then, as long as the Layer3 is on the PC, it would be fine if it can
support real PC/SC readers. Only when we start to support running
layer3 inside the phone, we would require the use of the SIM card reader
inside the phone.
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5:03 p.m.
New subject: FYI: SIM
so apdus will
be exchanged through the serial link with the phone.
It may be nice to have a pcsclite driver to drive the sim card in the phone.
Then we'll be able to use a SIM cards connected to the real phone, or a ccid
smart card reader connected to the PC running the layer2/layer3, using the
same API.
Yes, I like that idea, and we can easily use yet another of our HLDC
data link connections for this.
However, it seems almost like a bit of over-engineering to me to go a
far as to support PC/SC. Sure, it's a cool hack, and if somebody has
an interest in it and some time to spare.
5:05 p.m.
New subject: FYI: SIM
Hi sylvain,
Yes, we're on the same wavelength here.
Sebastien
On Tue, Mar 9, 2010 at 5:03 PM, Sylvain Munaut <246tnt(a)gmail.com> wrote:
I would do it the other way around.
Make sure that all call from layer 3 are in the form of "
apdu_xfer(in,out); "
Then implementing this apdu_xfer either using :
. A HLDC data link to the real phone
. A PCSC reader (the api allows for raw apdu exchange very easily)
. A bare serial link to one of those cheap card reader
. The SIM api directly when running inside the phone.
Sylvain
> so apdus
will be exchanged through the serial link with the phone.
> It may be nice to have a pcsclite driver to drive the sim card in the
phone.
> Then we'll be able to use a SIM cards
connected to the real phone, or a
ccid
> smart card reader connected to the PC running
the layer2/layer3, using
the
same API.
Yes, I like that idea, and we can easily use yet another of our HLDC
data link connections for this.
However, it seems almost like a bit of over-engineering to me to go a
far as to support PC/SC. Sure, it's a cool hack, and if somebody has
an interest in it and some time to spare. 
9:53 p.m.
New subject: FYI: SIM
On Tue, 9 Mar 2010 16:21:43 +0100
Sébastien Lorquet <squalyl(a)gmail.com> wrote:
I think official sim cards can be put in sleep state,
that the clock
can be stopped, and this sort of energy saving stuff. I don't know a
lot about this, and we don't need this in a first version.
All reasonably recent SIM cards (the 3,3V generation and past) support
it and phones have been using this to save power for at least the past
12 Years. But I guess this is not a thing to worry about in this stage
but rather something to keep in mind.
cheers,
nibbler
4:24 p.m.
New subject: FYI: SIM
Hi dexter,
thanks for your update!
On Tue, Mar 09, 2010 at 03:12:47PM +0100, dexter wrote:
I have now getting interrupts and i am sending the
first little
APDUs to the card. I think i will have something that basicly works
soon.
But up to now i think it will be impossible to save
processing time
during the transmission - wait phases without having semaphores (or
something semilar that can be used to wait for an event without
wasting processing time in a while loop.) However - this only makes
sense with a multitasking os which we actually do not have ;-)
yes, if you think about a synchronous / "blocking I/O" scenario.
However, you could always have something asynchronous: The caller calls
something like sim_card_transceive(*message, *cb), and the driver calls
back the 'cb' function when it has received the data.
I think the latter is the best we can do at the moment.
Another possible concept is to introduce some kind of message queue: The
entity that wants to issue a command to the SIM sends a message into the
queue, indicating to which other message queue any responses shall be
queued to.
I agree the synchronous approach seems to be the more natural one
(for most human beings at least). However, it comes at the cost of
scheduling overhead/latency, new possibilities for deadlocks and
potentially difficult debugging than in a single-threaded program.
Right now I don't really know yet how many threads/tasks we will end up
having. I only know we should be careful and not to have too many of
them. Layer2 is certainly going to be one task, Layer3 will have at
least one. Layer3 is he entity that normally talks to the SIM, at least
excluding things coming directly from the app like phonebook access and
storing SMS.
The driver will get a function like
sim_card_transceive(*message,
*response) or so on because a transaction with the card will never
be receive or send only. You always send something to the card and
you always get something back.
If the caller does not care, he could simply specify a NULL pointer as
*response.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4:27 p.m.
New subject: FYI: SIM
We cross posted, you gave me more info, thanks.
The async approach seems very nice here.
Sebastien
On Tue, Mar 9, 2010 at 4:24 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi dexter,
thanks for your update!
On Tue, Mar 09, 2010 at 03:12:47PM +0100, dexter wrote:
I have now getting interrupts and i am sending
the first little
APDUs to the card. I think i will have something that basicly works
soon.
But up to now i think it will be impossible to
save processing time
during the transmission - wait phases without having semaphores (or
something semilar that can be used to wait for an event without
wasting processing time in a while loop.) However - this only makes
sense with a multitasking os which we actually do not have ;-)
yes, if you think about a synchronous / "blocking I/O" scenario.
However, you could always have something asynchronous: The caller calls
something like sim_card_transceive(*message, *cb), and the driver calls
back the 'cb' function when it has received the data.
I think the latter is the best we can do at the moment.
Another possible concept is to introduce some kind of message queue: The
entity that wants to issue a command to the SIM sends a message into the
queue, indicating to which other message queue any responses shall be
queued to.
I agree the synchronous approach seems to be the more natural one
(for most human beings at least). However, it comes at the cost of
scheduling overhead/latency, new possibilities for deadlocks and
potentially difficult debugging than in a single-threaded program.
Right now I don't really know yet how many threads/tasks we will end up
having. I only know we should be careful and not to have too many of
them. Layer2 is certainly going to be one task, Layer3 will have at
least one. Layer3 is he entity that normally talks to the SIM, at least
excluding things coming directly from the app like phonebook access and
storing SMS.
The driver will get a function like
sim_card_transceive(*message,
*response) or so on because a transaction with the card will never
be receive or send only. You always send something to the card and
you always get something back.
If the caller does not care, he could simply specify a NULL pointer as
*response.
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5184
days inactive
5186
days old
baseband-devel@lists.osmocom.org
10 comments
5 participants
participants (5)
-
dexter -
Harald Welte -
nibbler -
Sylvain Munaut -
Sébastien Lorquet