The default bug view has changed. See this FAQ.

B2G RIL: GET_IMSI and ICC IO cannot work on Otoro ICS

RESOLVED FIXED in mozilla17

Status

()

Core
DOM: Device Interfaces
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: allstars, Assigned: allstars)

Tracking

Trunk
mozilla17
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 4 obsolete attachments)

GET_IMSI cannot work on Otoro ICS
I/Gecko   (  105): RIL Worker: Solicited response for request type 11, token 8, error 2
I/Gecko   (  105): RIL Worker: Handling parcel as REQUEST_GET_IMSI

I have tried to revert the patch for Bug 768428, it still cannot work, response for GET_IMSI never comes back.

Also Icc IO cannot work, either.
It fails in READ_RECORD 
I/Gecko   (  105): RIL Worker: We have at least one complete parcel.
I/Gecko   (  105): RIL Worker: Solicited response for request type 28, token 12, error 2
I/Gecko   (  105): RIL Worker: Handling parcel as REQUEST_SIM_IO
I/Gecko   (  105): RIL Worker: Parcel handler didn't consume whole parcel, 16 bytes left over
I
Blocks: 773068
GET_IMSI needs the 'aid' got from GET_SIM_STATUS, 
(which we use null in ril_worker now)

Still debugging on SIM_IO problem,

from adb logcat -b radio

RIL_SIM_IO_Response: sw1=105 sw2=130 data=

to HEX : sw1 = 69, sw2 = 82, which is 'Security status not satisfied' from spec.
Assignee: nobody → allstars.chh
Target Milestone: --- → mozilla16
Version: Trunk → Other Branch
Target Milestone: mozilla16 → ---
Version: Other Branch → Trunk
This bug is SIM-dependent,
when I use a T-Mobile SIM, 
both GET_IMSI and ICC_IO work fine, 
but it fails when I use a Emome SIM.
Continue to work ICC_IO part:
EF_MFBN: it fails in GET_RESPONSE
adb logcat -b radio

D/RILC    (  112): RIL_SIM_IO_Response: sw1=106 sw2=130 data=NULL
D/RILC    (  112): [RID 0] ReqList entries :
D/RILC    (  112):     RIL_REQUEST_SIM_IO (28), token id 13
D/RILC    (  112):     RIL_REQUEST_SIM_IO (28), token id 14
D/RILC    (  112):     RIL_REQUEST_GET_SIM_STATUS (1), token id 19
D/RILC    (  112): UI <--- RIL_REQUEST_SIM_IO (28) Complete --- RIL [RID 0, Token 12, Generic Failure, Len 12 ]

sw1=0x6a, sw2=0x82 --> File not found

other ICC_IO, EF_MSISDN, EF_AD, EF_UST all fail in READ_RECORD/BINARY part

D/RILC    (  112): RIL_SIM_IO_Response: sw1=105 sw2=130 data=
D/RILC    (  112): [RID 0] ReqList entries : Empty 
D/RILC    (  112): UI <--- RIL_REQUEST_SIM_IO (28) Complete --- RIL [RID 0, Token 20, Generic Failure, Len 12 ]

The result is even the same if I add the 'aid' parameter in REQUEST_SIM_IO
Hi MVines,
  I am wondering does the parameter in REQUEST_SIM_IO (RIL_SIM_IO_v6) has changed on Otoro ICS? Or do you know why I always get sw1 = 69, sw2 = 82 when doing READ_RECORD/BINARY in REQUEST_SIM_IO? I've tried three SIM cards(T-Mobile, Movistar and Emome), but only Emome fails in SIM_IO, other SIMs are fine.

Thanks
I can get the ICC IO working on my SIM with the pathId in SIM_IO set to MF_SIM("3f00") + DF_ADF("7fff") now.
Now try to find a way to tell from these SIM cards.

Thanks
Created attachment 646493 [details] [diff] [review]
Part 1: GET_IMSI

Hi, Vicamo
Could you review this patch for me ?
Thanks
Attachment #646493 - Flags: review?(vyang)
Created attachment 646496 [details] [diff] [review]
Part 2: ICC IO

Hi, Vicamo
For ICC IO I change the PATH_ID to ADF, which can be found in TS 102.221 and TS 31.102. ADF means Application-specified DF.

Note that I didn't change the pathid for ADN and FDN because I found those SIM contacts can be only found through global contact, not through ADF contact.

I have tested this patch with Emome and T-Mobile SIM on Otoro and Galaxy-s2. And on emulator most of those ICC also work except the SIM contacts, which are not supported on emulator.

Thanks
Attachment #646496 - Flags: review?(vyang)
Comment on attachment 646493 [details] [diff] [review]
Part 1: GET_IMSI

Review of attachment 646493 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/ril_worker.js
@@ +1015,5 @@
>      }
>      let token = Buf.newParcel(REQUEST_GET_IMSI);
>      Buf.writeUint32(1);
> +    let iccStatus = this.iccStatus;
> +    Buf.writeString(iccStatus.apps[iccStatus.gsmUmtsSubscriptionAppIndex].aid);

Please use:

  let appIndex = this.iccStatus.gsmUmtsSubscriptionAppIndex;
  Buf.writeString(this.iccStatus.apps[appIndex].aid);

The first line will be modified into:

  let appIndex = GSM_SIM ? this.iccStatus.gsmUmtsSubscriptionAppIndex
                         : this.iccStatus.cdmaSubscriptionAppIndex;

when CDMA support is ready.
Attachment #646493 - Flags: review?(vyang) → review+
(In reply to Yoshi Huang[:yoshi][:allstars.chh] from comment #7)
> Created attachment 646496 [details] [diff] [review]
> Part 2: ICC IO
> 
> Hi, Vicamo
> For ICC IO I change the PATH_ID to ADF, which can be found in TS 102.221 and
> TS 31.102. ADF means Application-specified DF.
> 
> Note that I didn't change the pathid for ADN and FDN because I found those
> SIM contacts can be only found through global contact, not through ADF
> contact.
> 
> I have tested this patch with Emome and T-Mobile SIM on Otoro and Galaxy-s2.
> And on emulator most of those ICC also work except the SIM contacts, which
> are not supported on emulator.
> 
> Thanks

https://www.codeaurora.org/gitweb/quic/la/?p=platform/frameworks/base.git;a=commitdiff;h=de653d757f162833067fa15eea8efb12f2c9251a;hp=359e32a3c5abc77e17e71ff0fdc533faaafc3a93
Were it anything to do with this issue?

I also found that our iccIO() implementation differs from that in Android aosp/master, which always writes pin2 & aid, and in aosp/ics-mr1, which always writes pin2. I know little about SIM specification, but I can't really believe we should change PATH_ID. Neither AOSP nor CodeAurora does this.
Comment on attachment 646496 [details] [diff] [review]
Part 2: ICC IO

Review of attachment 646496 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/ril_worker.js
@@ +990,3 @@
>      }
> +    let iccStatus = this.iccStatus;
> +    Buf.writeString(iccStatus.apps[iccStatus.gsmUmtsSubscriptionAppIndex].aid);

Same with the first patch.
Attachment #646496 - Flags: review?(vyang)
Created attachment 647056 [details] [diff] [review]
Part 1: GET_IMSI v2

Address to vicamo's review comments.
Attachment #646493 - Attachment is obsolete: true
Created attachment 647057 [details] [diff] [review]
WID - Part 2 : ICC IO

Update writing pin2/AID in iccIO
The path id in iccIO remains in discussion so I haven't updated it here.
Attachment #647056 - Attachment is obsolete: true
Hi, Vicamo
I found CodeAurora also did the same thing as in my patch

http://bit.ly/MYIyVv
http://bit.ly/MYIvc6

But I didn't find those files in android tree.

How do you think?
(In reply to Yoshi Huang[:yoshi][:allstars.chh] from comment #13)
> Hi, Vicamo
> I found CodeAurora also did the same thing as in my patch
>   http://bit.ly/MYIyVv
>   http://bit.ly/MYIvc6
> But I didn't find those files in android tree. How do you think?

Great! That totally explains your work. I think I have no more questions about your patches. Thanks ;)

(Keep original url)
https://www.codeaurora.org/gitweb/quic/qrd-android/?p=platform/frameworks/base.git;a=blob;f=telephony/java/com/android/internal/telephony/UsimFileHandler.java;hb=refs/heads/ics_master_qrd_qs#l42
https://www.codeaurora.org/gitweb/quic/la/?p=platform/frameworks/base.git;a=blob;f=telephony/java/com/android/internal/telephony/UsimFileHandler.java;hb=refs/heads/ics#l42
Created attachment 647482 [details] [diff] [review]
Part 1: GET_IMSI v2

rebase.
Attachment #646496 - Attachment is obsolete: true
Attachment #647057 - Attachment is obsolete: true
Created attachment 647484 [details] [diff] [review]
Part 2: Icc IO v2

Rebase.
Attachment #647484 - Flags: review?(vyang)
Comment on attachment 647484 [details] [diff] [review]
Part 2: Icc IO v2

Review of attachment 647484 [details] [diff] [review]:
-----------------------------------------------------------------

Sweet!
Attachment #647484 - Flags: review?(vyang) → review+
Part 1: http://hg.mozilla.org/integration/mozilla-inbound/rev/242fcd399b3f
Part 2: http://hg.mozilla.org/integration/mozilla-inbound/rev/e8b047ebaf72
Target Milestone: --- → mozilla17
https://hg.mozilla.org/mozilla-central/rev/242fcd399b3f
https://hg.mozilla.org/mozilla-central/rev/e8b047ebaf72
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.