This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Sébastien Lorquet squalyl at gmail.comSomething 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 at 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 at 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 >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100309/08d38a21/attachment.htm>