a problematic sim?

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/simtrace@lists.osmocom.org/.

Lukas Kuzmiak lukash at backstep.net
Sun Dec 18 01:05:41 UTC 2011


Hi,

I've quickly tried this with the problematic simcards and it seems to do
the trick, works just fine.

nice work.

Cheers,
Lukas

On Sun, Dec 18, 2011 at 1:45 AM, Holger Hans Peter Freyther <
holger at freyther.de> wrote:

> On 12/16/2011 09:51 AM, Lukas Kuzmiak wrote:
> > Hi Harald,
>
> Hi all,
>
> tnt has had some issues as well... it looks like if for prot_t_supported==1
> the data will not be sent immediately. E.g. a "ih->rctx_must_be_sent = 1;"
> appears to work around this. This means that a mixed ATR/APDU URB will be
> generated and our adpu_split host code will not be called.
>
> static enum iso7816_3_state
> transition_to_tck(struct iso7816_3_handle *ih)
> {
>        if (ih->prot_t_supported == 0x01) {
>                /* If only T=0 supported, there is no TCK but we
>                 * immediately transition to APDUs */
>                set_atr_state(ih, ATR_S_DONE);
>                return ISO7816_S_WAIT_APDU;
>
>
> My idea of a proper patch was to move a lot into the ATR_S_DONE state
> (rctx_must_be_sent, scheduling the tc_etu_set_wtime) but this does not
> appear
> to work properly. So the easiest patch is to add "ih->rctx_must_be_sent =
> 1"
> to the above code path.
>
> cheers
>         holger
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20111218/0d4f1e3c/attachment.htm>


More information about the simtrace mailing list