All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH 7/8] Add AT driver for STK atom.
Date: Tue, 20 Apr 2010 15:21:08 -0500	[thread overview]
Message-ID: <201004201521.08399.denkenz@gmail.com> (raw)
In-Reply-To: <h2kfb249edb1004201233lf8c2807en734f9ee8d40daeff@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]

Hi Andrew,

> Hi Denis,
> 
> On 15 April 2010 23:48, Denis Kenzior <denkenz@gmail.com> wrote:
> > The terminal response goes something like this:
> >> +
> >> +     len = sprintf(buf, "AT+CSIM=%i,A0140000%02hhX",
> >> +                     10 + length * 2, length);
> >> +
> >> +     for (; length; length--)
> >> +             len += sprintf(buf + len, "%02hhX", *value++);
> >> +
> >
> > In the new stk envelope code it goes something like this:
> >> +     len = sprintf(buf, "AT+CSIM=%i,A0C20000%02hhX",
> >> +                     12 + length * 2, length);
> >> +
> >> +     for (; length; length--)
> >> +             len += sprintf(buf + len, "%02hhX", *command++);
> >> +
> >> +     len += sprintf(buf + len, "FF");
> >
> > What is the point of this last 'FF'?  The code removed from the sim atom
> > driver doesn't have it either...
> 
> Rereading the etsi ts102.221 the "Le" field in the Envelope APDU
> (11.2.2.2) is not explictly defined "not present", instead it says
> "empty or maximum length of expected data".  It doesn't say what the
> default value is when empty so I conclude it's safer to have the field
> present or the card may think it's not allowed to send any response at
> all -- depending on the implementer's interpretation of the spec.
> 
> 10.1.6 says the field is the maximum respose length expected, but then
> some commands suggest it should be the exact length wanted and some
> make the field obligatory.

So I re-read that part of the spec, and I can see why we might want it.  
However, this quote seemed rather interesting: "Le set to '00' indicates that 
the terminal expects to receive at most the maximum number of bytes, i.e. 256, 
in the response ADPU. The UICC may return any number of bytes in the range 1 
to 256."

Shouldn't that 'FF' be changed to '00'?  Also, you might want to include the 
relevant passage or Spec/Section reference in this code so we don't wonder 
where it came from in the future.

Regards,
-Denis

  reply	other threads:[~2010-04-20 20:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-09  6:50 [PATCH 7/8] Add AT driver for STK atom Andrzej Zaborowski
2010-04-15 21:48 ` Denis Kenzior
2010-04-20 19:33   ` Andrzej Zaborowski
2010-04-20 20:21     ` Denis Kenzior [this message]
2010-04-20 20:48       ` Andrzej Zaborowski
2010-04-20 20:55         ` Denis Kenzior
2010-04-20 21:03           ` andrzej zaborowski
2010-04-20 21:32             ` Denis Kenzior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201004201521.08399.denkenz@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ofono@ofono.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.